[PATCH] serial: sirf: Simplify a test

[Christophe JAILLET]

'dmaengine_prep_dma_cyclic()' does not return an error pointer, so the test
can be simplified to be more consistent.

Signed-off-by: Christophe JAILLET 
---
 drivers/tty/serial/sirfsoc_uart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sirfsoc_uart.c 
b/drivers/tty/serial/sirfsoc_uart.c
index b186c9c4f850..666ca3156961 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -609,7 +609,7 @@ static void sirfsoc_uart_start_next_rx_dma(struct uart_port 
*port)
sirfport->rx_dma_items.dma_addr, SIRFSOC_RX_DMA_BUF_SIZE,
SIRFSOC_RX_DMA_BUF_SIZE / 2,
DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
-   if (IS_ERR_OR_NULL(sirfport->rx_dma_items.desc)) {
+   if (!sirfport->rx_dma_items.desc) {
dev_err(port->dev, "DMA slave single fail\n");
return;
}
-- 
2.9.3

[PATCH v2] phy: rcar-gen3-usb2: add sysfs for usb role swap

[Yoshihiro Shimoda]

This patch adds sysfs "otg_inputs" for usb role swap. This parameter
is write-only and if you use them as the following, you can swap
the usb role.

For example:
 1) connect a usb cable using 2 salvator-x boards
 2) On A-device (as host), you input the following command:
   # echo a_bus_req/ > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
 3) On B-device (as peripheral), you input the following command:
   # echo b_bus_req > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs

Then, the A-device acts as a peripheral (A-peripheral) and the B-device
acts as a host (B-host).
Please note that A-device must input the following command if you
want the board to act as a host again. (even if you disconnect the usb
cable, since id state may be the same, the condition keeps "A-peripheral".)
 # echo a_bus_drop > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs

Also you can use the following command if you want the B-device board to
act as a peripheral again.
 # echo b_bus_req/ > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs

Signed-off-by: Yoshihiro Shimoda 
---
 This patch is based on the latest linux-phy.git / next branch.
 (commit id = 7809cd2ce6abd4f431e4b14e6b1276a7cc842ac4)

 Since this patch is related to usb, I added email addresses of Greg, Felipe,
 Peter and USB ML as CC. (This patch doesn't use USB OTG FSM though.)

 Changed from v1:
  - rebase the latest next branch.

 .../ABI/testing/sysfs-platform-phy-rcar-gen3-usb2  |  11 ++
 drivers/phy/phy-rcar-gen3-usb2.c   | 124 -
 2 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2

diff --git a/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2 
b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
new file mode 100644
index 000..c7e715af
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
@@ -0,0 +1,11 @@
+What:  /sys/devices/platform//otg-inputs
+Date:  October 2016
+KernelVersion: 4.10
+Contact:   Yoshihiro Shimoda 
+Description:
+   This write-only file changes the phy mode for role swap of usb.
+   This file accepts the following strings:
+"a_bus_req/" - switching from A-Host to A-Peripheral
+"a_bus_drop" - switching from A-Peripheral to A-Host
+"b_bus_req"  - switching from B-Peripheral to B-Host
+"b_bus_req/" - switching from B-Host to B-Peripheral
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index 3d97ead..80f5bcc 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -70,6 +70,7 @@
 #define USB2_LINECTRL1_DP_RPD  BIT(18)
 #define USB2_LINECTRL1_DMRPD_ENBIT(17)
 #define USB2_LINECTRL1_DM_RPD  BIT(16)
+#define USB2_LINECTRL1_OPMODE_NODRVBIT(6)
 
 /* ADPCTRL */
 #define USB2_ADPCTRL_OTGSESSVLDBIT(20)
@@ -161,6 +162,43 @@ static void rcar_gen3_init_for_peri(struct rcar_gen3_chan 
*ch)
schedule_work(>work);
 }
 
+static void rcar_gen3_init_for_b_host(struct rcar_gen3_chan *ch)
+{
+   void __iomem *usb2_base = ch->base;
+   u32 val;
+
+   val = readl(usb2_base + USB2_LINECTRL1);
+   writel(val | USB2_LINECTRL1_OPMODE_NODRV, usb2_base + USB2_LINECTRL1);
+
+   rcar_gen3_set_linectrl(ch, 1, 1);
+   rcar_gen3_set_host_mode(ch, 1);
+   rcar_gen3_enable_vbus_ctrl(ch, 0);
+
+   val = readl(usb2_base + USB2_LINECTRL1);
+   writel(val & ~USB2_LINECTRL1_OPMODE_NODRV, usb2_base + USB2_LINECTRL1);
+}
+
+static void rcar_gen3_init_for_a_peri(struct rcar_gen3_chan *ch)
+{
+   rcar_gen3_set_linectrl(ch, 0, 1);
+   rcar_gen3_set_host_mode(ch, 0);
+   rcar_gen3_enable_vbus_ctrl(ch, 1);
+}
+
+static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
+{
+   void __iomem *usb2_base = ch->base;
+   u32 val;
+
+   val = readl(usb2_base + USB2_OBINTEN);
+   writel(val & ~USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
+
+   rcar_gen3_enable_vbus_ctrl(ch, 0);
+   rcar_gen3_init_for_host(ch);
+
+   writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
+}
+
 static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
 {
return !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
@@ -174,6 +212,71 @@ static void rcar_gen3_device_recognition(struct 
rcar_gen3_chan *ch)
rcar_gen3_init_for_peri(ch);
 }
 
+/*
+ * The following table is a state transition for usb phy mode:
+ * State   Event   Next state
+ * disconnected:   E1  a_host
+ * E2  b_peripheral
+ * A-Device - a_host:  E2  b_peripheral
+ * E3  disconnected
+ * E4  a_suspend
+ * A-Device - 

[PATCH v3 08/11] pwm: imx: Remove redundant i.MX PWMv2 code

[Lukasz Majewski]

The code providing functionality surpassed by the atomic PWM is not needed
anymore and hence can be removed.

Suggested-by: Stefan Agner 
Suggested-by: Boris Brezillon 
Signed-off-by: Lukasz Majewski 
Reviewed-by: Boris Brezillon 
---
Changes for v3:
- None

Changes for v2:
- None
---
 drivers/pwm/pwm-imx.c | 118 --
 1 file changed, 118 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index cd53c05..b636526 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -53,10 +53,6 @@ struct imx_chip {
void __iomem*mmio_base;
 
struct pwm_chip chip;
-
-   int (*config)(struct pwm_chip *chip,
-   struct pwm_device *pwm, int duty_ns, int period_ns);
-   void (*set_enable)(struct pwm_chip *chip, bool enable);
 };
 
 #define to_imx_chip(chip)  container_of(chip, struct imx_chip, chip)
@@ -228,109 +224,6 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct 
pwm_device *pwm,
return 0;
 }
 
-static int imx_pwm_config_v2(struct pwm_chip *chip,
-   struct pwm_device *pwm, int duty_ns, int period_ns)
-{
-   struct imx_chip *imx = to_imx_chip(chip);
-   unsigned long long c;
-   unsigned long period_cycles, duty_cycles, prescale;
-   bool enable = pwm_is_enabled(pwm);
-   u32 cr;
-
-   /*
-* i.MX PWMv2 has a 4-word sample FIFO.
-* In order to avoid FIFO overflow issue, we do software reset
-* to clear all sample FIFO if the controller is disabled or
-* wait for a full PWM cycle to get a relinquished FIFO slot
-* when the controller is enabled and the FIFO is fully loaded.
-*/
-   if (enable)
-   imx_pwm_wait_fifo_slot(chip, pwm);
-   else
-   imx_pwm_sw_reset(chip);
-
-   c = clk_get_rate(imx->clk_per);
-   c = c * period_ns;
-   do_div(c, 10);
-   period_cycles = c;
-
-   prescale = period_cycles / 0x1 + 1;
-
-   period_cycles /= prescale;
-   c = (unsigned long long)period_cycles * duty_ns;
-   do_div(c, period_ns);
-   duty_cycles = c;
-
-   /*
-* according to imx pwm RM, the real period value should be
-* PERIOD value in PWMPR plus 2.
-*/
-   if (period_cycles > 2)
-   period_cycles -= 2;
-   else
-   period_cycles = 0;
-
-   writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
-   writel(period_cycles, imx->mmio_base + MX3_PWMPR);
-
-   cr = MX3_PWMCR_PRESCALER(prescale) |
-   MX3_PWMCR_DOZEEN | MX3_PWMCR_WAITEN |
-   MX3_PWMCR_DBGEN | MX3_PWMCR_CLKSRC_IPG_HIGH;
-
-   if (enable)
-   cr |= MX3_PWMCR_EN;
-
-   writel(cr, imx->mmio_base + MX3_PWMCR);
-
-   return 0;
-}
-
-static void imx_pwm_set_enable_v2(struct pwm_chip *chip, bool enable)
-{
-   struct imx_chip *imx = to_imx_chip(chip);
-   u32 val;
-
-   val = readl(imx->mmio_base + MX3_PWMCR);
-
-   if (enable)
-   val |= MX3_PWMCR_EN;
-   else
-   val &= ~MX3_PWMCR_EN;
-
-   writel(val, imx->mmio_base + MX3_PWMCR);
-}
-
-static int imx_pwm_config(struct pwm_chip *chip,
-   struct pwm_device *pwm, int duty_ns, int period_ns)
-{
-   struct imx_chip *imx = to_imx_chip(chip);
-
-   return imx->config(chip, pwm, duty_ns, period_ns);
-}
-
-static int imx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-   struct imx_chip *imx = to_imx_chip(chip);
-   int ret;
-
-   ret = clk_prepare_enable(imx->clk_per);
-   if (ret)
-   return ret;
-
-   imx->set_enable(chip, true);
-
-   return 0;
-}
-
-static void imx_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-   struct imx_chip *imx = to_imx_chip(chip);
-
-   imx->set_enable(chip, false);
-
-   clk_disable_unprepare(imx->clk_per);
-}
-
 static struct pwm_ops imx_pwm_ops_v1 = {
.enable = imx_pwm_enable_v1,
.disable = imx_pwm_disable_v1,
@@ -339,17 +232,11 @@ static struct pwm_ops imx_pwm_ops_v1 = {
 };
 
 static struct pwm_ops imx_pwm_ops_v2 = {
-   .enable = imx_pwm_enable,
-   .disable = imx_pwm_disable,
-   .config = imx_pwm_config,
.apply = imx_pwm_apply_v2,
.owner = THIS_MODULE,
 };
 
 struct imx_pwm_data {
-   int (*config)(struct pwm_chip *chip,
-   struct pwm_device *pwm, int duty_ns, int period_ns);
-   void (*set_enable)(struct pwm_chip *chip, bool enable);
struct pwm_ops *pwm_ops;
 };
 
@@ -358,8 +245,6 @@ static struct imx_pwm_data imx_pwm_data_v1 = {
 };
 
 static struct imx_pwm_data imx_pwm_data_v2 = {
-   .config = imx_pwm_config_v2,
-   .set_enable = imx_pwm_set_enable_v2,
.pwm_ops = _pwm_ops_v2,
 };
 
@@ -406,9 +291,6 @@ static int imx_pwm_probe(struct 

[PATCH v3 05/11] pwm: imx: Move PWMv2 software reset code to a separate function

[Lukasz Majewski]

The software reset code has been extracted from imx_pwm_config_v2 function
and moved to new one - imx_pwm_sw_reset().

This change reduces the overall size of imx_pwm_config_v2() and prepares
it for atomic PWM operation.

Suggested-by: Stefan Agner 
Suggested-by: Boris Brezillon 
Signed-off-by: Lukasz Majewski 

---
Changes for v3:
- None

Changes for v2:
- Add missing parenthesis
---
 drivers/pwm/pwm-imx.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 8497902..b4e5803 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -119,6 +119,25 @@ static void imx_pwm_disable_v1(struct pwm_chip *chip, 
struct pwm_device *pwm)
clk_disable_unprepare(imx->clk_per);
 }
 
+static void imx_pwm_sw_reset(struct pwm_chip *chip)
+{
+   struct imx_chip *imx = to_imx_chip(chip);
+   struct device *dev = chip->dev;
+   int wait_count = 0;
+   u32 cr;
+
+   writel(MX3_PWMCR_SWR, imx->mmio_base + MX3_PWMCR);
+   do {
+   usleep_range(200, 1000);
+   cr = readl(imx->mmio_base + MX3_PWMCR);
+   } while ((cr & MX3_PWMCR_SWR) &&
+(wait_count++ < MX3_PWM_SWR_LOOP));
+
+   if (cr & MX3_PWMCR_SWR)
+   dev_warn(dev, "software reset timeout\n");
+}
+
+
 static int imx_pwm_config_v2(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
 {
@@ -128,7 +147,7 @@ static int imx_pwm_config_v2(struct pwm_chip *chip,
unsigned long period_cycles, duty_cycles, prescale;
unsigned int period_ms;
bool enable = pwm_is_enabled(pwm);
-   int wait_count = 0, fifoav;
+   int fifoav;
u32 cr, sr;
 
/*
@@ -151,15 +170,7 @@ static int imx_pwm_config_v2(struct pwm_chip *chip,
dev_warn(dev, "there is no free FIFO slot\n");
}
} else {
-   writel(MX3_PWMCR_SWR, imx->mmio_base + MX3_PWMCR);
-   do {
-   usleep_range(200, 1000);
-   cr = readl(imx->mmio_base + MX3_PWMCR);
-   } while ((cr & MX3_PWMCR_SWR) &&
-(wait_count++ < MX3_PWM_SWR_LOOP));
-
-   if (cr & MX3_PWMCR_SWR)
-   dev_warn(dev, "software reset timeout\n");
+   imx_pwm_sw_reset(chip);
}
 
c = clk_get_rate(imx->clk_per);
-- 
2.1.4

[PATCH v3 10/11] pwm: imx: doc: Update imx-pwm.txt documentation entry

[Lukasz Majewski]

The imx-pwm.txt documentation update as a preparation for polarity
support.

Signed-off-by: Bhuvanchandra DV 
Signed-off-by: Lukasz Majewski 
Acked-by: Rob Herring 
---
Changes for v3:
- None

Changes for v2:
- New patch
---
 Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt 
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index e00c2e9..c61bdf8 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -6,8 +6,8 @@ Required properties:
   - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
   - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
 - reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
-  the cells format.
+- #pwm-cells: 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See pwm.txt
+  in this directory for a description of the cells format.
 - clocks : Clock specifiers for both ipg and per clocks.
 - clock-names : Clock names should include both "ipg" and "per"
 See the clock consumer binding,
@@ -17,7 +17,7 @@ See the clock consumer binding,
 Example:
 
 pwm1: pwm@53fb4000 {
-   #pwm-cells = <2>;
+   #pwm-cells = <3>;
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
clocks = < IMX5_CLK_PWM1_IPG_GATE>,
-- 
2.1.4

Re: [kernel-hardening] rowhammer protection [was Re: Getting interrupt every million cache misses]

[Daniel Micay]

On Tue, 2016-11-01 at 07:33 +0100, Ingo Molnar wrote:
> * Pavel Machek  wrote:
> 
> > I'm not going to buy broken hardware just for a test.
> 
> Can you suggest a method to find heavily rowhammer affected hardware?
> Only by 
> testing it, or are there some chipset IDs ranges or dmidecode info
> that will 
> pinpoint potentially affected machines?
> 
> Thanks,
> 
>   Ingo

You can read the memory timing values, but you can't know if they're
reasonable for that hardware. Higher quality memory can have better
timings without being broken. The only relevant information would be the
memory model, combined with an expensive / time consuming effort to
build a blacklist based on testing. It doesn't seem realistic, unless
it's done in a coarse way based on brand and the date information.

I don't know how to get this data on Linux. The CPU-Z tool for Windows
knows how to obtain it but it's based on a proprietary library.

You definitely don't need to buy broken hardware to test a broken
hardware setup though. You just need a custom computer build where
motherboards expose the memory timing configuration. You can make it
more vulnerable by raising the refresh period (tREF). I wanted to play
around with that but haven't gotten around to it.

signature.asc
Description: This is a digitally signed message part

[PATCH v3 06/11] pwm: imx: Move PWMv2 wait for fifo slot code to a separate function

[Lukasz Majewski]

The code, which waits for fifo slot, has been extracted from
imx_pwm_config_v2 function and moved to new one - imx_pwm_wait_fifo_slot().

This change reduces the overall size of imx_pwm_config_v2() and prepares
it for atomic PWM operation.

Suggested-by: Stefan Agner 
Suggested-by: Boris Brezillon 
Signed-off-by: Lukasz Majewski 
---
Changes for v3:
- None

Changes for v2:
- None
---
 drivers/pwm/pwm-imx.c | 43 +--
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index b4e5803..ebe9b0c 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -137,18 +137,36 @@ static void imx_pwm_sw_reset(struct pwm_chip *chip)
dev_warn(dev, "software reset timeout\n");
 }
 
+static void imx_pwm_wait_fifo_slot(struct pwm_chip *chip,
+  struct pwm_device *pwm)
+{
+   struct imx_chip *imx = to_imx_chip(chip);
+   struct device *dev = chip->dev;
+   unsigned int period_ms;
+   int fifoav;
+   u32 sr;
+
+   sr = readl(imx->mmio_base + MX3_PWMSR);
+   fifoav = sr & MX3_PWMSR_FIFOAV_MASK;
+   if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) {
+   period_ms = DIV_ROUND_UP(pwm_get_period(pwm),
+NSEC_PER_MSEC);
+   msleep(period_ms);
+
+   sr = readl(imx->mmio_base + MX3_PWMSR);
+   if (fifoav == (sr & MX3_PWMSR_FIFOAV_MASK))
+   dev_warn(dev, "there is no free FIFO slot\n");
+   }
+}
 
 static int imx_pwm_config_v2(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
 {
struct imx_chip *imx = to_imx_chip(chip);
-   struct device *dev = chip->dev;
unsigned long long c;
unsigned long period_cycles, duty_cycles, prescale;
-   unsigned int period_ms;
bool enable = pwm_is_enabled(pwm);
-   int fifoav;
-   u32 cr, sr;
+   u32 cr;
 
/*
 * i.MX PWMv2 has a 4-word sample FIFO.
@@ -157,21 +175,10 @@ static int imx_pwm_config_v2(struct pwm_chip *chip,
 * wait for a full PWM cycle to get a relinquished FIFO slot
 * when the controller is enabled and the FIFO is fully loaded.
 */
-   if (enable) {
-   sr = readl(imx->mmio_base + MX3_PWMSR);
-   fifoav = sr & MX3_PWMSR_FIFOAV_MASK;
-   if (fifoav == MX3_PWMSR_FIFOAV_4WORDS) {
-   period_ms = DIV_ROUND_UP(pwm_get_period(pwm),
-NSEC_PER_MSEC);
-   msleep(period_ms);
-
-   sr = readl(imx->mmio_base + MX3_PWMSR);
-   if (fifoav == (sr & MX3_PWMSR_FIFOAV_MASK))
-   dev_warn(dev, "there is no free FIFO slot\n");
-   }
-   } else {
+   if (enable)
+   imx_pwm_wait_fifo_slot(chip, pwm);
+   else
imx_pwm_sw_reset(chip);
-   }
 
c = clk_get_rate(imx->clk_per);
c = c * period_ns;
-- 
2.1.4

Re: [kernel-hardening] rowhammer protection [was Re: Getting interrupt every million cache misses]

[Pavel Machek]

Hi!

> * Pavel Machek  wrote:
> 
> > I'm not going to buy broken hardware just for a test.
> 
> Can you suggest a method to find heavily rowhammer affected hardware? Only by 
> testing it, or are there some chipset IDs ranges or dmidecode info that will 
> pinpoint potentially affected machines?

Testing can be used. https://github.com/mseaborn/rowhammer-test.git
. It finds faults at 1 of 2 machines here (but takes half an
hour). Then, if your hardware is one of ivy/sandy/haswell/skylake,
https://github.com/IAIK/rowhammerjs.git can be used for much faster
attack (many flips a second).

Unfortunately, what I have here is:

cpu family : 6
model: 23
model name   : Intel(R) Core(TM)2 Duo CPU E7400  @ 2.80GHz
stepping : 10
microcode: 0xa07

so rowhammerjs/native is not available for this system. Bit mapping
for memory hash functions would need to be reverse engineered for more
effective attack.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Paul Bolle]

On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
> As always: Are you aware of any other regressions? Then please let me
> know (simply CC regressi...@leemhuis.info).

Do build regressions count?

Because I was trying to fix an obscure build issue in arch/mips, choose
a random configuration that should hit that issue, and promptly ran
into
https://lkml.kernel.org/r/<201610301405.k82kqqw0%25fengguang...@intel.com>
The same configuration does build under v4.8, I tested that of course.

(Side note: I had to manually insert "25" after "%" to get this to
work. Should Intel fix its mail setup, or should lkml.kernel.org learn
to escape "%"?)

Thanks,


Paul Bolle

[PATCH] ASoC: sun4i-codec: Enable bus clock after getting GPIO

[Chen-Yu Tsai]

In the current probe function the GPIO is acquired after the codec's
bus clock is enabled. However if it fails to acquire the GPIO due to
a deferred probe, it does not disable the bus clock before bailing out.
This would result in the clock being enabled multiple times.

Move the code that enables the bus clock after the part that gets the
GPIO, maintaining a separation between resource acquisition and device
enablement in the probe function.

Signed-off-by: Chen-Yu Tsai 
---
 sound/soc/sunxi/sun4i-codec.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a60707761abf..56ed9472e89f 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -829,12 +829,6 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return PTR_ERR(scodec->clk_module);
}
 
-   /* Enable the bus clock */
-   if (clk_prepare_enable(scodec->clk_apb)) {
-   dev_err(>dev, "Failed to enable the APB clock\n");
-   return -EINVAL;
-   }
-
scodec->gpio_pa = devm_gpiod_get_optional(>dev, "allwinner,pa",
  GPIOD_OUT_LOW);
if (IS_ERR(scodec->gpio_pa)) {
@@ -844,6 +838,12 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return ret;
}
 
+   /* Enable the bus clock */
+   if (clk_prepare_enable(scodec->clk_apb)) {
+   dev_err(>dev, "Failed to enable the APB clock\n");
+   return -EINVAL;
+   }
+
/* DMA configuration for TX FIFO */
scodec->playback_dma_data.addr = res->start + SUN4I_CODEC_DAC_TXDATA;
scodec->playback_dma_data.maxburst = 4;
-- 
2.10.1

Re: [PATCH v2 5/7] [media] ir-lirc-codec: don't wait any transmitting time for tx only devices

[Andi Shyti]

Hi Sean,

> Andi, it would be good to know what the use-case for the original change is.

the use case is the ir-spi itself which doesn't need the lirc to
perform any waiting on its behalf.

To me it just doesn't look right to simulate a fake transmission
period and wait unnecessary time. Of course, the "over-wait" is not
a big deal and at the end we can decide to drop it.

Otherwise, an alternative could be to add the boolean
'tx_no_wait' in the rc_dev structure. It could be set by the
device driver during the initialization and the we can follow
your approach.

Something like this:

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index c327730..4553d04 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -161,15 +161,19 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
 
ret *= sizeof(unsigned int);
 
-   /*
-* The lircd gap calculation expects the write function to
-* wait for the actual IR signal to be transmitted before
-* returning.
-*/
-   towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
-   if (towait > 0) {
-   set_current_state(TASK_INTERRUPTIBLE);
-   schedule_timeout(usecs_to_jiffies(towait));
+   if (!dev->tx_no_wait) {
+   /*
+* The lircd gap calculation expects the write function to
+* wait for the actual IR signal to be transmitted before
+* returning.
+*/
+   towait = ktime_us_delta(ktime_add_us(start, duration),
+   ktime_get());
+   if (towait > 0) {
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule_timeout(usecs_to_jiffies(towait));
+   }
+
}
 
 out:
diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
index fcda1e4..e44abfa 100644
--- a/drivers/media/rc/ir-spi.c
+++ b/drivers/media/rc/ir-spi.c
@@ -149,6 +149,7 @@ static int ir_spi_probe(struct spi_device *spi)
if (!idata->rc)
return -ENOMEM;
 
+   idata->rc->tx_no_wait  = true;
idata->rc->tx_ir   = ir_spi_tx;
idata->rc->s_tx_carrier= ir_spi_set_tx_carrier;
idata->rc->s_tx_duty_cycle = ir_spi_set_duty_cycle;
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index fe0c9c4..c3ced9b 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -85,6 +85,9 @@ enum rc_filter_type {
  * @input_dev: the input child device used to communicate events to userspace
  * @driver_type: specifies if protocol decoding is done in hardware or software
  * @idle: used to keep track of RX state
+ * @tx_no_wait: decides whether to perform or not a sync write or not. The
+ *  device driver setting it to true must make sure to not break the ABI
+ *  which requires a sync transfer.
  * @allowed_protocols: bitmask with the supported RC_BIT_* protocols
  * @enabled_protocols: bitmask with the enabled RC_BIT_* protocols
  * @allowed_wakeup_protocols: bitmask with the supported RC_BIT_* wakeup 
protocols
@@ -147,6 +150,7 @@ struct rc_dev {
struct input_dev*input_dev;
enum rc_driver_type driver_type;
boolidle;
+   booltx_no_wait;
u64 allowed_protocols;
u64 enabled_protocols;
u64 allowed_wakeup_protocols;

Thanks,
Andi

[PATCH v3 09/11] pwm: core: make the PWM_POLARITY flag in DTB optional

[Lukasz Majewski]

From: Lothar Wassmann 

Change the pwm chip driver registration, so that a chip driver that
supports polarity inversion can still be used with DTBs that don't
provide the 'PWM_POLARITY' flag.

This is done to provide polarity inversion support for the pwm-imx
driver without having to modify all existing DTS files.

Signed-off-by: Lothar Wassmann 
Signed-off-by: Bhuvanchandra DV 
Suggested-by: Sascha Hauer 
Signed-off-by: Lukasz Majewski 
---
Changes for v3:
- None

Changes for v2:
- None
---
 drivers/pwm/core.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index ec7179f..d80e5c5 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -137,9 +137,14 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct 
of_phandle_args *args)
 {
struct pwm_device *pwm;
 
+   /* check, whether the driver supports a third cell for flags */
if (pc->of_pwm_n_cells < 3)
return ERR_PTR(-EINVAL);
 
+   /* flags in the third cell are optional */
+   if (args->args_count < 2)
+   return ERR_PTR(-EINVAL);
+
if (args->args[0] >= pc->npwm)
return ERR_PTR(-EINVAL);
 
@@ -148,11 +153,10 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct 
of_phandle_args *args)
return pwm;
 
pwm->args.period = args->args[1];
+   pwm->args.polarity = PWM_POLARITY_NORMAL;
 
-   if (args->args[2] & PWM_POLARITY_INVERTED)
+   if (args->args_count > 2 && args->args[2] & PWM_POLARITY_INVERTED)
pwm->args.polarity = PWM_POLARITY_INVERSED;
-   else
-   pwm->args.polarity = PWM_POLARITY_NORMAL;
 
return pwm;
 }
@@ -163,9 +167,14 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const struct 
of_phandle_args *args)
 {
struct pwm_device *pwm;
 
+   /* sanity check driver support */
if (pc->of_pwm_n_cells < 2)
return ERR_PTR(-EINVAL);
 
+   /* all cells are required */
+   if (args->args_count != pc->of_pwm_n_cells)
+   return ERR_PTR(-EINVAL);
+
if (args->args[0] >= pc->npwm)
return ERR_PTR(-EINVAL);
 
@@ -674,13 +683,6 @@ struct pwm_device *of_pwm_get(struct device_node *np, 
const char *con_id)
goto put;
}
 
-   if (args.args_count != pc->of_pwm_n_cells) {
-   pr_debug("%s: wrong #pwm-cells for %s\n", np->full_name,
-args.np->full_name);
-   pwm = ERR_PTR(-EINVAL);
-   goto put;
-   }
-
pwm = pc->of_xlate(pc, );
if (IS_ERR(pwm))
goto put;
-- 
2.1.4

[PATCH v3 11/11] pwm: imx: Add polarity inversion support to i.MX's PWMv2

[Lukasz Majewski]

With this patch the polarity settings for i.MX's PWMv2 is now supported
on top of atomic PWM setting

Signed-off-by: Bhuvanchandra DV 
Signed-off-by: Lukasz Majewski 
---
Changes for v3:
- None

Changes for v2:
- New patch
---
 drivers/pwm/pwm-imx.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index b636526..03b01a4 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -38,6 +38,7 @@
 #define MX3_PWMCR_DOZEEN   (1 << 24)
 #define MX3_PWMCR_WAITEN   (1 << 23)
 #define MX3_PWMCR_DBGEN(1 << 22)
+#define MX3_PWMCR_POUTC(1 << 18)
 #define MX3_PWMCR_CLKSRC_IPG_HIGH  (2 << 16)
 #define MX3_PWMCR_CLKSRC_IPG   (1 << 16)
 #define MX3_PWMCR_SWR  (1 << 3)
@@ -215,6 +216,9 @@ static int imx_pwm_apply_v2(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (state->enabled)
cr |= MX3_PWMCR_EN;
 
+   if (state->polarity == PWM_POLARITY_INVERSED)
+   cr |= MX3_PWMCR_POUTC;
+
writel(cr, imx->mmio_base + MX3_PWMCR);
 
/* Disable the clock if the PWM is being disabled. */
@@ -237,6 +241,7 @@ static struct pwm_ops imx_pwm_ops_v2 = {
 };
 
 struct imx_pwm_data {
+   bool polarity_supported;
struct pwm_ops *pwm_ops;
 };
 
@@ -245,6 +250,7 @@ static struct imx_pwm_data imx_pwm_data_v1 = {
 };
 
 static struct imx_pwm_data imx_pwm_data_v2 = {
+   .polarity_supported = true,
.pwm_ops = _pwm_ops_v2,
 };
 
@@ -285,6 +291,11 @@ static int imx_pwm_probe(struct platform_device *pdev)
imx->chip.base = -1;
imx->chip.npwm = 1;
imx->chip.can_sleep = true;
+   if (data->polarity_supported) {
+   dev_dbg(>dev, "PWM supports output inversion\n");
+   imx->chip.of_xlate = of_pwm_xlate_with_flags;
+   imx->chip.of_pwm_n_cells = 3;
+   }
 
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
imx->mmio_base = devm_ioremap_resource(>dev, r);
-- 
2.1.4

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[John Heenan]

I have a prepared another patch that is not USB VID/PID dependent for
rtl8723bu devices. It is more elegant. I will send it after this
email.

If I have more patches is it preferable I just put them on github only
and notify a link address until there might be some resolution?

What I meant below about not finding a matching function is that I
cannot find matching actions to take on any function calls in
rtl8xxxu_stop as for rtl8xxxu_start.

The function that is called later and potentially more than once for
rtl8723bu devices is rtl8xxxu_init_device. There is no corresponding
rtl8xxxu_deinit_device function.

enable_rf is called in rtl8xxxu_start, not in the delayed call to
rtl8xxxu_init_device. The corresponding disable_rf is called in
rtl8xxxu_stop. So no matching issue here. However please see below for
another potential issue.

power_on is called in rtl8xxxu_init_device. power_off is called in
rtl8xxxu_disconnect. Does not appear to be an issue if calling
power_on has no real effect if already on.

The following should be looked at though. For all devices enable_rf is
only called once. For the proposed patch the first call to
rtl8xxxu_init_device is called after the single call to enable_rf for
rtl8723bu devices. Without the patch enable_rf is called after
rtl8xxxu_init_device for all devices

Perhaps enable_rf just configures RF modes to start up when RF is
powered on or if called after power_on then enters requested RF modes.

So I cannot see appropriate additional matching action to take.

Below is some background for anyone interested

rtl8xxxu_start and rtl8xxxu_stop are assigned to rtl8xxxu_ops.

rtl8xxxu_probe assigns rtl8xxxu_ops to its driver layer with
ieee80211_register_hw.

rtl8xxxu_disconnect unassigns rtl8xxxu_ops from its driver layer with
ieee80211_unregister_hw.

rtl8xxxu_probe and rtl8xxxu_disconnect are USB driver functions

John Heenan


On 1 November 2016 at 08:15, John Heenan  wrote:
> On 1 November 2016 at 07:25, Jes Sorensen  wrote:
>> John Heenan  writes:
>
>>
>>> @@ -5776,9 +5781,17 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>>>   struct rtl8xxxu_tx_urb *tx_urb;
>>>   unsigned long flags;
>>>   int ret, i;
>>> + struct usb_device_descriptor *udesc = >udev->descriptor;
>>>
>>>   ret = 0;
>>>
>>> + if(udesc->idVendor == USB_VENDOR_ID_REALTEK
>>> + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU) {
>>> + ret = rtl8xxxu_init_device(hw);
>>> + if (ret)
>>> + goto error_out;
>>> + }
>>> +
>>
>> As mentioned previously, if this is to be changed here, it has to be
>> matched in the _stop section too.
>
> I looked at this and could not find a matching function. I will have a
> look again.
>

Re: [PATCH] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS features to kvm guest

[He Chen]

On Mon, Oct 31, 2016 at 12:41:32PM +0100, Paolo Bonzini wrote:
> 
> 
> On 31/10/2016 12:05, Borislav Petkov wrote:
> > On Mon, Oct 31, 2016 at 11:47:48AM +0100, Paolo Bonzini wrote:
> >> The information is all in arch/x86/kernel/cpu/scattered.c's cpuid_bits
> >> array.  Borislav, would it be okay to export the cpuid_regs enum?
> > 
> > Yeah, and kill the duplicated one in arch/x86/events/intel/pt.c too
> > please, while at it.
> > 
> > I'd still put it all in arch/x86/kernel/cpu/scattered.c so that it is
> > close-by and call it from outside.
> 
> Good.  Chen, are you going to do this?
> 

Sure.

Before sending a patch, let me check if my understanding is right...
I will add a helper in scattered.c like:

unsigned int get_scattered_cpuid_features(unsigned int level,
unsigned int sub_leaf, enum cpuid_regs 
reg)
{
u32 val = 0;
const struct cpuid_bit *cb;

for (cb = cpuid_bits; cb->feature; cb++) {

if (reg == cb->reg &&
level == cb->level &&
sub_leaf == cb->sub_leaf &&
boot_cpu_has(cb->feature))

val |= cb->bit;
}

return val;
}

And, when KVM wants to mask out features, it can be called outside like:

entry->edx &= kvm_cpuid_7_0_edx_x86_features;
entry->edx &= get_scatterd_cpuid_features(7, 0, CR_EDX);

Thanks,
-He

Re: [PATCH v2 1/2] backlight: pwm_bl: Move the checks for initial power state to a separate function

[Peter Ujfalusi]

On 10/28/2016 04:27 PM, Philipp Zabel wrote:
> Hi Peter,
> 
> Am Donnerstag, den 27.10.2016, 13:01 +0300 schrieb Peter Ujfalusi:
>> Move the checks to select the initial state for the backlight to a new
>> function and document the checks we are doing.
>>
>> At the same time correct the handling of the case when the GPIO is
>> initially configured as input: we need to change the direction of the GPIO
>> to output and set the GPIO to low as the pin was not driven when the GPIO
>> was configured as input.
> 
> I think this part should be a separate patch. At least it is a
> significant enough change to warrant a mention in the subject.

Yes, I should have separated it it.

> And I'm not entirely sure this is better than before. If there happens
> to be a pull-up on the GPIO (for whatever reason), we might introduce
> flicker again if the GPIO goes from input (high) to output (low), and
> back to output (high) again due to FB_BLANK_UNBLANK.

This is plausible if the pull-up is strong enough. It might be better to
not change this logic at all and instead of gpiod_direction_output_raw()
use the gpiod_direction_output(pb->enable_gpio, 1); to enable the GPIO
when it is set as input.

I'll resend the patches.

-- 
Péter

> regards
> Philipp
> 
>> With the separate function it is going to be easier to fix or improve the
>> initial power state configuration later and it is easier to read the code.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/video/backlight/pwm_bl.c | 54 
>> ++--
>>  1 file changed, 35 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/video/backlight/pwm_bl.c 
>> b/drivers/video/backlight/pwm_bl.c
>> index 12614006211e..74083d880144 100644
>> --- a/drivers/video/backlight/pwm_bl.c
>> +++ b/drivers/video/backlight/pwm_bl.c
>> @@ -192,6 +192,32 @@ static int pwm_backlight_parse_dt(struct device *dev,
>>  }
>>  #endif
>>  
>> +static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
>> +{
>> +struct device_node *node = pb->dev->of_node;
>> +
>> +/* Not booted with device tree or no phandle link to the node */
>> +if (!node || !node->phandle)
>> +return FB_BLANK_UNBLANK;
>> +
>> +/*
>> + * If the driver is probed from the device tree and there is a
>> + * phandle link pointing to the backlight node, it is safe to
>> + * assume that another driver will enable the backlight at the
>> + * appropriate time. Therefore, if it is disabled, keep it so.
>> + */
>> +
>> +/* if the enable GPIO is disabled, do not enable the backlight */
> 
> nitpick: s/if/If/ for consistency.
> 
>> +if (pb->enable_gpio && gpiod_get_value(pb->enable_gpio) == 0)
>> +return FB_BLANK_POWERDOWN;
>> +
>> +/* The regulator is disabled, do not enable the backlight */
>> +if (!regulator_is_enabled(pb->power_supply))
>> +return FB_BLANK_POWERDOWN;
>> +
>> +return FB_BLANK_UNBLANK;
>> +}
>> +
>>  static int pwm_backlight_probe(struct platform_device *pdev)
>>  {
>>  struct platform_pwm_backlight_data *data = dev_get_platdata(>dev);
>> @@ -200,7 +226,6 @@ static int pwm_backlight_probe(struct platform_device 
>> *pdev)
>>  struct backlight_device *bl;
>>  struct device_node *node = pdev->dev.of_node;
>>  struct pwm_bl_data *pb;
>> -int initial_blank = FB_BLANK_UNBLANK;
>>  struct pwm_args pargs;
>>  int ret;
>>  
>> @@ -267,20 +292,14 @@ static int pwm_backlight_probe(struct platform_device 
>> *pdev)
>>  pb->enable_gpio = gpio_to_desc(data->enable_gpio);
>>  }
>>  
>> -if (pb->enable_gpio) {
>> -/*
>> - * If the driver is probed from the device tree and there is a
>> - * phandle link pointing to the backlight node, it is safe to
>> - * assume that another driver will enable the backlight at the
>> - * appropriate time. Therefore, if it is disabled, keep it so.
>> - */
>> -if (node && node->phandle &&
>> -gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_OUT &&
>> -gpiod_get_value(pb->enable_gpio) == 0)
>> -initial_blank = FB_BLANK_POWERDOWN;
>> -else
>> -gpiod_direction_output(pb->enable_gpio, 1);
>> -}
>> +/*
>> + * If the GPIO is configured as input, change the direction to output
>> + * and set the GPIO as low since the line was not driven when it was
>> + * configured as input.
>> + */
>> +if (pb->enable_gpio &&
>> +gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN)
>> +gpiod_direction_output_raw(pb->enable_gpio, 0);
>>  
>>  pb->power_supply = devm_regulator_get(>dev, "power");
>>  if (IS_ERR(pb->power_supply)) {
>> @@ -288,9 +307,6 @@ static int pwm_backlight_probe(struct platform_device 
>> *pdev)
>>  goto err_alloc;
>>  }
>>  
>> -if (node && node->phandle 

Re: [PATCH v3 02/11] pwm: imx: remove ipg clock

[Philipp Zabel]

Am Dienstag, den 01.11.2016, 08:10 +0100 schrieb Lukasz Majewski:
> From: Sascha Hauer 
> 
> The use of the ipg clock was introduced with commit 7b27c160c681
> ("pwm: i.MX: fix clock lookup").
> In the commit message it was claimed that the ipg clock is enabled for
> register accesses. This is true for the ->config() callback, but not
> for the ->set_enable() callback. Given that the ipg clock is not
> consistently enabled for all register accesses we can assume that either
> it is not required at all or that the current code does not work.
> Remove the ipg clock code for now so that it's no longer in the way of
> refactoring the driver.
> 
> Signed-off-by: Sascha Hauer 
> Cc: Philipp Zabel 

I don't remember the details, but since I had only worked with i.MX53
and i.MX6 at the time, and Sascha now verified that the i.MX53 PWM
registers can in fact be accessed with the pwmX_ipg_clk bits gated, I
can only assume that this patch is the result of a misinterpretation of
the i.MX53 technical reference manual: Contrary to the i.MX6 TRM it does
not mention the ungated peripheral access clock (ipg_clk_s) at all, but
calls the gated ipg_clk "block interface clock" in Table 18-3.

Acked-by: Philipp Zabel 

regards
Philipp

Re: [PATCH v2 2/2] PM / sleep: don't suspend parent when async child suspend_{noirq,late} fails

[Dmitry Torokhov]

On Mon, Oct 31, 2016 at 10:25 PM, Rafael J. Wysocki  wrote:
> On Thursday, October 27, 2016 09:05:34 AM Brian Norris wrote:
>> Consider two devices, A and B, where B is a child of A, and B utilizes
>> asynchronous suspend (it does not matter whether A is sync or async). If
>> B fails to suspend_noirq() or suspend_late(), or is interrupted by a
>> wakeup (pm_wakeup_pending()), then it aborts and sets the async_error
>> variable. However, device A does not (immediately) check the async_error
>> variable; it may continue to run its own suspend_noirq()/suspend_late()
>> callback. This is bad.
>>
>> We can resolve this problem by checking the async_error flag after
>> waiting for children to suspend, using the same logic for the noirq and
>> late suspend cases as we already do for __device_suspend().
>>
>> It's easy to observe this erroneous behavior by, for example, forcing a
>> device to sleep a bit in its suspend_noirq() (to ensure the parent is
>> waiting for the child to complete), then return an error, and watch the
>> parent suspend_noirq() still get called. (Or similarly, fake a wakeup
>> event at the right (or is it wrong?) time.)
>>
>> Fixes: de377b397272 ("PM / sleep: Asynchronous threads for suspend_late")
>> Fixes: 28b6fd6e3779 ("PM / sleep: Asynchronous threads for suspend_noirq")
>> Reported-by: Jeffy Chen 
>> Signed-off-by: Brian Norris 
>> Reviewed-by: Dmitry Torokhov 
>> ---
>> v2: s/early/late/ in commit message
>>
>>  drivers/base/power/main.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
>> index c58563581345..eaf6b53463a5 100644
>> --- a/drivers/base/power/main.c
>> +++ b/drivers/base/power/main.c
>> @@ -1040,6 +1040,9 @@ static int __device_suspend_noirq(struct device *dev, 
>> pm_message_t state, bool a
>>
>>   dpm_wait_for_children(dev, async);
>>
>> + if (async_error)
>> + goto Complete;
>> +
>
> This is a second chech for async_error in this routine and is the first one
> really needed after adding this?

There is really no point in waiting for children to be suspended if
error has already been signalled; that's what first check achieves.
The 2nd check ensures that we abort suspend if any of the children
failed to suspend.

I'd say both checks are needed (well, 1st is helpful, 2nd is essential).

>
>>   if (dev->pm_domain) {
>>   info = "noirq power domain ";
>>   callback = pm_noirq_op(>pm_domain->ops, state);
>> @@ -1187,6 +1190,9 @@ static int __device_suspend_late(struct device *dev, 
>> pm_message_t state, bool as
>>
>>   dpm_wait_for_children(dev, async);
>>
>> + if (async_error)
>> + goto Complete;
>> +
>
> Same question.
>
>>   if (dev->pm_domain) {
>>   info = "late power domain ";
>>   callback = pm_late_early_op(>pm_domain->ops, state);
>>
>
> Thanks,
> Rafael
>

Thanks.

-- 
Dmitry

Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT ids through ACPI

[Phong Vo]

>From: Mika Westerberg 
>Subject: Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when
using DT ids through ACPI
>Date: Monday 13th June 2016 09:26:55 UTC (5 months ago)
>
>On Fri, Jun 10, 2016 at 06:57:36PM +0300, Crestez Dan Leonard wrote:
>> On 06/10/2016 09:32 AM, Mika Westerberg wrote:
>> > On Thu, Jun 09, 2016 at 04:06:03PM +0300, Crestez Dan Leonard wrote:
>> >> When devices are instatiated through devicetree the i2c_client->name
is
>> >> set to the compatible string with company name stripped out. This is
>> >> then matched to the i2c_device_id table to pass the device_id to the
>> >> probe function. This id parameter is used by some device drivers to
>> >> differentiate between model numbers.
>> >>
>> >> When using ACPI this id parameter is NULL and the driver usually
needs
>> >> to do ACPI-specific differentiation.
>> >>
>> >> This patch attempts to find a valid i2c_device_id when using ACPI
with
>> >> DT-like compatible strings.
>> >
>> > So I don't really understand why it would be good idea to pass
>> > i2c_device_id for devices which are matched against their ACPI/DT
>> > tables. Apparently DT is already doing that so maybe there is some
>> > reason.
>> >
>> > Anyway, why not fill in the device name when it is first enumerated
>> > if it uses DT compatible property? Just like DT does.
>> >
>> This automatic matching of i2c_device_id works for devicetree because
>> of_i2c_register_device sets i2c_board_info.type to the compatible
string
>> with the vendor prefix removed. For I2C devices described via ACPI the
>> i2c_board_info.type string is set to the ACPI device name. This ends up
>> something like "PRP0001:00".
>>
>> This could be changed in acpi_i2c_get_info to use the of_compatible
>> string from DSD if present. Is that what you mean? That would work and
>> it would be cleaner than my patch. Something like this:
>>
>> diff --git drivers/i2c/i2c-core.c drivers/i2c/i2c-core.c
>> index 1e0ef9b..ba2fe7f 100644
>> --- drivers/i2c/i2c-core.c
>> +++ drivers/i2c/i2c-core.c
>> @@ -181,7 +181,24 @@ static int acpi_i2c_get_info(struct acpi_device
>*adev,
>>
>> acpi_dev_free_resource_list(_list);
>>
>> -   strlcpy(info->type, dev_name(>dev), sizeof(info->type));
>> +   /*
>> +    * If we have a DT id set info.type to the first compatible
>> string with
>> +    * the vendor prefix stripped. This is similar to
>of_modalias_node
>> +    */
>> +   if (adev->data.of_compatible) {
>> +   const union acpi_object *obj;
>> +   const char *str, *chr;
>> +
>> +   obj = adev->data.of_compatible;
>> +   if (obj->type == ACPI_TYPE_PACKAGE)
>> +   obj = obj->package.elements;
>> +   str = obj->string.pointer;
>> +   chr = strchr(str, ',');
>> +   if (chr)
>> +   str = chr + 1;
>> +   strlcpy(info->type, str, sizeof(info->type));
>> +   } else
>> +   strlcpy(info->type, dev_name(>dev),
>> sizeof(info->type));
>>
>> return 0;
>>  }>
>
>Yes, that's what I mean.
>
>> The biggest concern is that this would change the i2c device name
>> between kernel versions. Is that acceptable?
>
>I don't think that is a problem since I still have not seen a single
>system using ACPI _DSD so I would not expect anything to break.
>
>However, I'm still not convinced it is good idea to return i2c_device_id
>from a completely different table if we match using ACPI/DT table.

All,

Is there a conclusion on this? We have been tackling the same issue and
incidentally arrived at a
similar solution as like Lenard proposed  in the patch above.

Re: [kernel-hardening] rowhammer protection [was Re: Getting interrupt every million cache misses]

[Ingo Molnar]

* Pavel Machek  wrote:

> I'm not going to buy broken hardware just for a test.

Can you suggest a method to find heavily rowhammer affected hardware? Only by 
testing it, or are there some chipset IDs ranges or dmidecode info that will 
pinpoint potentially affected machines?

Thanks,

Ingo

[PATCH] UBIFS: Remove some dead code

[Christophe JAILLET]

'ubifs_fast_find_freeable()' can not return an error pointer, so this test
can be removed.

Signed-off-by: Christophe JAILLET 
---
 fs/ubifs/gc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index e845c64b6ce1..7b35e3d6cde7 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -846,10 +846,6 @@ int ubifs_gc_start_commit(struct ubifs_info *c)
 */
while (1) {
lp = ubifs_fast_find_freeable(c);
-   if (IS_ERR(lp)) {
-   err = PTR_ERR(lp);
-   goto out;
-   }
if (!lp)
break;
ubifs_assert(!(lp->flags & LPROPS_TAKEN));
-- 
2.9.3

[PATCH] net/mlx5: Simplify a test

[Christophe JAILLET]

'create_root_ns()' does not return an error pointer, so the test can be
simplified to be more consistent.

Signed-off-by: Christophe JAILLET 
---
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c 
b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index 904853f9cf7a..330955f6badc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1833,7 +1833,7 @@ static int init_root_ns(struct mlx5_flow_steering 
*steering)
 {
 
steering->root_ns = create_root_ns(steering, FS_FT_NIC_RX);
-   if (IS_ERR_OR_NULL(steering->root_ns))
+   if (!steering->root_ns)
goto cleanup;
 
if (init_root_tree(steering, _fs, >root_ns->ns.node))
-- 
2.9.3

[tip:x86/fpu] x86/fpu: Get rid of two redundant clts() calls

[tip-bot for Andy Lutomirski]

Commit-ID:  36fd4f0249f8cb445835acb7c6937a0ffa2b5f14
Gitweb: http://git.kernel.org/tip/36fd4f0249f8cb445835acb7c6937a0ffa2b5f14
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:42 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:53 +0100

x86/fpu: Get rid of two redundant clts() calls

CR0.TS is cleared by a direct CR0 write in fpu__init_cpu_generic().
We don't need to call clts() two more times right after that.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/476d2d5066eda24838853426ea74c94140b50c85.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/fpu/init.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 1a09d13..60dece3 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -10,15 +10,6 @@
 #include 
 
 /*
- * Initialize the TS bit in CR0 according to the style of context-switches
- * we are using:
- */
-static void fpu__init_cpu_ctx_switch(void)
-{
-   clts();
-}
-
-/*
  * Initialize the registers found in all CPUs, CR0 and CR4:
  */
 static void fpu__init_cpu_generic(void)
@@ -55,7 +46,6 @@ void fpu__init_cpu(void)
 {
fpu__init_cpu_generic();
fpu__init_cpu_xstate();
-   fpu__init_cpu_ctx_switch();
 }
 
 /*
@@ -290,14 +280,6 @@ void __init fpu__init_system(struct cpuinfo_x86 *c)
 */
fpu__init_cpu();
 
-   /*
-* But don't leave CR0::TS set yet, as some of the FPU setup
-* methods depend on being able to execute FPU instructions
-* that will fault on a set TS, such as the FXSAVE in
-* fpu__init_system_mxcsr().
-*/
-   clts();
-
fpu__init_system_generic();
fpu__init_system_xstate_size_legacy();
fpu__init_system_xstate();

[tip:x86/fpu] x86/fpu: Remove irq_ts_save() and irq_ts_restore()

[tip-bot for Andy Lutomirski]

Commit-ID:  5a83d60c074ddf4f6364be25654a643d0e941824
Gitweb: http://git.kernel.org/tip/5a83d60c074ddf4f6364be25654a643d0e941824
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:44 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:54 +0100

x86/fpu: Remove irq_ts_save() and irq_ts_restore()

Now that lazy FPU is gone, we don't use CR0.TS (except possibly in
KVM guest mode).  Remove irq_ts_save(), irq_ts_restore(), and all of
their callers.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/70b9b9e7ba70659bedcb08aba63d0f9214f338f2.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/fpu/api.h   | 10 --
 arch/x86/kernel/fpu/core.c   | 29 -
 drivers/char/hw_random/via-rng.c |  8 ++--
 drivers/crypto/padlock-aes.c | 23 ++-
 drivers/crypto/padlock-sha.c | 18 --
 5 files changed, 4 insertions(+), 84 deletions(-)

diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h
index 1429a7c..0877ae0 100644
--- a/arch/x86/include/asm/fpu/api.h
+++ b/arch/x86/include/asm/fpu/api.h
@@ -27,16 +27,6 @@ extern void kernel_fpu_end(void);
 extern bool irq_fpu_usable(void);
 
 /*
- * Some instructions like VIA's padlock instructions generate a spurious
- * DNA fault but don't modify SSE registers. And these instructions
- * get used from interrupt context as well. To prevent these kernel 
instructions
- * in interrupt context interacting wrongly with other user/kernel fpu usage, 
we
- * should use them only in the context of irq_ts_save/restore()
- */
-extern int  irq_ts_save(void);
-extern void irq_ts_restore(int TS_state);
-
-/*
  * Query the presence of one or more xfeatures. Works on any legacy CPU as 
well.
  *
  * If 'feature_name' is set then put a human-readable description of
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 52f56844..7d8e262 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -138,35 +138,6 @@ void kernel_fpu_end(void)
 EXPORT_SYMBOL_GPL(kernel_fpu_end);
 
 /*
- * CR0::TS save/restore functions:
- */
-int irq_ts_save(void)
-{
-   /*
-* If in process context and not atomic, we can take a spurious DNA 
fault.
-* Otherwise, doing clts() in process context requires disabling 
preemption
-* or some heavy lifting like kernel_fpu_begin()
-*/
-   if (!in_atomic())
-   return 0;
-
-   if (read_cr0() & X86_CR0_TS) {
-   clts();
-   return 1;
-   }
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(irq_ts_save);
-
-void irq_ts_restore(int TS_state)
-{
-   if (TS_state)
-   stts();
-}
-EXPORT_SYMBOL_GPL(irq_ts_restore);
-
-/*
  * Save the FPU state (mark it for reload if necessary):
  *
  * This only ever gets called for the current task.
diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index 44ce806..d1f5bb5 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -70,21 +70,17 @@ enum {
  * until we have 4 bytes, thus returning a u32 at a time,
  * instead of the current u8-at-a-time.
  *
- * Padlock instructions can generate a spurious DNA fault, so
- * we have to call them in the context of irq_ts_save/restore()
+ * Padlock instructions can generate a spurious DNA fault, but the
+ * kernel doesn't use CR0.TS, so this doesn't matter.
  */
 
 static inline u32 xstore(u32 *addr, u32 edx_in)
 {
u32 eax_out;
-   int ts_state;
-
-   ts_state = irq_ts_save();
 
asm(".byte 0x0F,0xA7,0xC0 /* xstore %%edi (addr=%0) */"
: "=m" (*addr), "=a" (eax_out), "+d" (edx_in), "+D" (addr));
 
-   irq_ts_restore(ts_state);
return eax_out;
 }
 
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 441e86b..b386974 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -183,8 +183,8 @@ static inline void padlock_store_cword(struct cword *cword)
 
 /*
  * While the padlock instructions don't use FP/SSE registers, they
- * generate a spurious DNA fault when cr0.ts is '1'. These instructions
- * should be used only inside the 

[tip:x86/fpu] x86/fpu, lguest: Remove CR0.TS support

[tip-bot for Andy Lutomirski]

Commit-ID:  cd95ea81f25608c403052d0508ee5c9b32e2bc7d
Gitweb: http://git.kernel.org/tip/cd95ea81f25608c403052d0508ee5c9b32e2bc7d
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:46 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:54 +0100

x86/fpu, lguest: Remove CR0.TS support

Now that Linux never sets CR0.TS, lguest doesn't need to support it.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/8a7bf2c11231c082258fd67705d0f275639b8475.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/lguest_hcall.h |  1 -
 arch/x86/lguest/boot.c  | 17 +++--
 drivers/lguest/hypercalls.c |  4 
 drivers/lguest/lg.h |  1 -
 drivers/lguest/x86/core.c   | 19 +--
 5 files changed, 8 insertions(+), 34 deletions(-)

diff --git a/arch/x86/include/asm/lguest_hcall.h 
b/arch/x86/include/asm/lguest_hcall.h
index ef01fef..6c119cf 100644
--- a/arch/x86/include/asm/lguest_hcall.h
+++ b/arch/x86/include/asm/lguest_hcall.h
@@ -9,7 +9,6 @@
 #define LHCALL_FLUSH_TLB   5
 #define LHCALL_LOAD_IDT_ENTRY  6
 #define LHCALL_SET_STACK   7
-#define LHCALL_TS  8
 #define LHCALL_SET_CLOCKEVENT  9
 #define LHCALL_HALT10
 #define LHCALL_SET_PMD 13
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 25da5bc8..d74afcd 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -497,27 +497,24 @@ static void lguest_cpuid(unsigned int *ax, unsigned int 
*bx,
  * a whole series of functions like read_cr0() and write_cr0().
  *
  * We start with cr0.  cr0 allows you to turn on and off all kinds of basic
- * features, but Linux only really cares about one: the horrifically-named Task
- * Switched (TS) bit at bit 3 (ie. 8)
+ * features, but the only cr0 bit that Linux ever used at runtime was the
+ * horrifically-named Task Switched (TS) bit at bit 3 (ie. 8)
  *
  * What does the TS bit do?  Well, it causes the CPU to trap (interrupt 7) if
  * the floating point unit is used.  Which allows us to restore FPU state
- * lazily after a task switch, and Linux uses that gratefully, but wouldn't a
- * name like "FPUTRAP bit" be a little less cryptic?
+ * lazily after a task switch if we wanted to, but wouldn't a name like
+ * "FPUTRAP bit" be a little less cryptic?
  *
- * We store cr0 locally because the Host never changes it.  The Guest sometimes
- * wants to read it and we'd prefer not to bother the Host unnecessarily.
+ * Fortunately, Linux keeps it simple and doesn't use TS, so we can ignore
+ * cr0.
  */
-static unsigned long current_cr0;
 static void lguest_write_cr0(unsigned long val)
 {
-   lazy_hcall1(LHCALL_TS, val & X86_CR0_TS);
-   current_cr0 = val;
 }
 
 static unsigned long lguest_read_cr0(void)
 {
-   return current_cr0;
+   return 0;
 }
 
 /*
diff --git a/drivers/lguest/hypercalls.c b/drivers/lguest/hypercalls.c
index 19a3228..601f81c 100644
--- a/drivers/lguest/hypercalls.c
+++ b/drivers/lguest/hypercalls.c
@@ -109,10 +109,6 @@ static void do_hcall(struct lg_cpu *cpu, struct hcall_args 
*args)
case LHCALL_SET_CLOCKEVENT:
guest_set_clockevent(cpu, args->arg1);
break;
-   case LHCALL_TS:
-   /* This sets the TS flag, as we saw used in run_guest(). */
-   cpu->ts = args->arg1;
-   break;
case LHCALL_HALT:
/* Similarly, this sets the halted flag for run_guest(). */
cpu->halted = 1;
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
index 69b3814..2356a23 100644
--- a/drivers/lguest/lg.h
+++ b/drivers/lguest/lg.h
@@ -43,7 +43,6 @@ struct lg_cpu {
struct mm_struct *mm;   /* == tsk->mm, but that becomes NULL on exit */
 
u32 cr2;
-   int ts;
u32 esp1;
u16 ss1;
 
diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
index 6e9042e..743253f 100644
--- a/drivers/lguest/x86/core.c
+++ b/drivers/lguest/x86/core.c
@@ -247,14 +247,6 @@ unsigned long *lguest_arch_regptr(struct lg_cpu *cpu, 
size_t reg_off, bool any)
 void lguest_arch_run_guest(struct lg_cpu *cpu)
 {
/*
-* Remember the awfully-named TS bit?  If the Guest has asked to 

[PATCH v3 01/11] pwm: print error messages with pr_err() instead of pr_debug()

[Lukasz Majewski]

From: Lothar Wassmann 

Make the messages that are printed in case of fatal errors actually
visible to the user without having to recompile the driver with
debugging enabled.

Signed-off-by: Lothar Waßmann 
Signed-off-by: Bhuvanchandra DV 
---
Changes for v3:
- None
---
 drivers/pwm/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 172ef82..ec7179f 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -663,13 +663,13 @@ struct pwm_device *of_pwm_get(struct device_node *np, 
const char *con_id)
err = of_parse_phandle_with_args(np, "pwms", "#pwm-cells", index,
 );
if (err) {
-   pr_debug("%s(): can't parse \"pwms\" property\n", __func__);
+   pr_err("%s(): can't parse \"pwms\" property\n", __func__);
return ERR_PTR(err);
}
 
pc = of_node_to_pwmchip(args.np);
if (IS_ERR(pc)) {
-   pr_debug("%s(): PWM chip not found\n", __func__);
+   pr_err("%s(): PWM chip not found\n", __func__);
pwm = ERR_CAST(pc);
goto put;
}
-- 
2.1.4

[tip:x86/fpu] x86/fpu, kvm: Remove host CR0.TS manipulation

[tip-bot for Andy Lutomirski]

Commit-ID:  04ac88abaf758bd76edcc3be5549003a017e7963
Gitweb: http://git.kernel.org/tip/04ac88abaf758bd76edcc3be5549003a017e7963
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:45 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:54 +0100

x86/fpu, kvm: Remove host CR0.TS manipulation

Now that x86 always uses eager FPU switching on the host, there's no
need for KVM to manipulate the host's CR0.TS.

This should be both simpler and faster.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/b212064922537c05d0c81d931fc4dbe769127ce7.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/kvm/vmx.c | 12 
 arch/x86/kvm/x86.c |  5 -
 2 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index cf1b16d..531c446 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2144,12 +2144,6 @@ static void __vmx_load_host_state(struct vcpu_vmx *vmx)
 #endif
if (vmx->host_state.msr_host_bndcfgs)
wrmsrl(MSR_IA32_BNDCFGS, vmx->host_state.msr_host_bndcfgs);
-   /*
-* If the FPU is not active (through the host task or
-* the guest vcpu), then restore the cr0.TS bit.
-*/
-   if (!fpregs_active() && !vmx->vcpu.guest_fpu_loaded)
-   stts();
load_gdt(this_cpu_ptr(_gdt));
 }
 
@@ -4871,9 +4865,11 @@ static void vmx_set_constant_host_state(struct vcpu_vmx 
*vmx)
u32 low32, high32;
unsigned long tmpl;
struct desc_ptr dt;
-   unsigned long cr4;
+   unsigned long cr0, cr4;
 
-   vmcs_writel(HOST_CR0, read_cr0() & ~X86_CR0_TS);  /* 22.2.3 */
+   cr0 = read_cr0();
+   WARN_ON(cr0 & X86_CR0_TS);
+   vmcs_writel(HOST_CR0, cr0);  /* 22.2.3 */
vmcs_writel(HOST_CR3, read_cr3());  /* 22.2.3  FIXME: shadow tables */
 
/* Save the most likely value for this task's CR4 in the VMCS. */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7f9fa2d..cfe6a75b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5060,11 +5060,6 @@ static void emulator_get_fpu(struct x86_emulate_ctxt 
*ctxt)
 {
preempt_disable();
kvm_load_guest_fpu(emul_to_vcpu(ctxt));
-   /*
-* CR0.TS may reference the host fpu state, not the guest fpu state,
-* so it may be clear at this point.
-*/
-   clts();
 }
 
 static void emulator_put_fpu(struct x86_emulate_ctxt *ctxt)

Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

[Sascha Hauer]

On Tue, Nov 01, 2016 at 06:57:23AM +0100, Lukasz Majewski wrote:
> Hi Sascha,
> 
> > The current assumption as discussed by Philipp and me is that the ipg
> > clk is only needed when the pwm output is driven by the ipg clk
> > (MX3_PWMCR[16:17] = MX3_PWMCR_CLKSRC_IPG)
> 
> At least on my setup (i.MX6q) the ipg clock (ipg_clk) don't need to be
> explicitly enabled in the ->apply() callback (in the pwm-imx.c) when
> MX3_PWMCR_CLKSRC_IPG (0x01 - ipg_clk) is selected as the PWM source.

No. If you look in the device tree you'll see that there is no special
gateable ipg clock for the PWM. Instead the SoC ipg clock is registered
for the PWM which is not gateable.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[tip:x86/asm] x86/copy_user: Unify the code by removing the 64-bit asm _copy_*_user() variants

[tip-bot for Borislav Petkov]

Commit-ID:  adb402cd1461eef6e1a21db4532a3b9e6a6be853
Gitweb: http://git.kernel.org/tip/adb402cd1461eef6e1a21db4532a3b9e6a6be853
Author: Borislav Petkov 
AuthorDate: Mon, 31 Oct 2016 16:10:15 +0100
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:41:27 +0100

x86/copy_user: Unify the code by removing the 64-bit asm _copy_*_user() variants

We already have the same functionality in usercopy_32.c. Share it with
64-bit and get rid of some more asm glue which is not needed anymore.

Signed-off-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20161031151015.22087-1...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/lib/copy_user_64.S | 47 ---
 arch/x86/lib/usercopy.c | 49 +
 arch/x86/lib/usercopy_32.c  | 49 -
 3 files changed, 49 insertions(+), 96 deletions(-)

diff --git a/arch/x86/lib/copy_user_64.S b/arch/x86/lib/copy_user_64.S
index d376e4b..c595957 100644
--- a/arch/x86/lib/copy_user_64.S
+++ b/arch/x86/lib/copy_user_64.S
@@ -16,53 +16,6 @@
 #include 
 #include 
 
-/* Standard copy_to_user with segment limit checking */
-ENTRY(_copy_to_user)
-   mov PER_CPU_VAR(current_task), %rax
-   movq %rdi,%rcx
-   addq %rdx,%rcx
-   jc bad_to_user
-   cmpq TASK_addr_limit(%rax),%rcx
-   ja bad_to_user
-   ALTERNATIVE_2 "jmp copy_user_generic_unrolled", \
- "jmp copy_user_generic_string",   \
- X86_FEATURE_REP_GOOD, \
- "jmp copy_user_enhanced_fast_string", \
- X86_FEATURE_ERMS
-ENDPROC(_copy_to_user)
-EXPORT_SYMBOL(_copy_to_user)
-
-/* Standard copy_from_user with segment limit checking */
-ENTRY(_copy_from_user)
-   mov PER_CPU_VAR(current_task), %rax
-   movq %rsi,%rcx
-   addq %rdx,%rcx
-   jc bad_from_user
-   cmpq TASK_addr_limit(%rax),%rcx
-   ja bad_from_user
-   ALTERNATIVE_2 "jmp copy_user_generic_unrolled", \
- "jmp copy_user_generic_string",   \
- X86_FEATURE_REP_GOOD, \
- "jmp copy_user_enhanced_fast_string", \
- X86_FEATURE_ERMS
-ENDPROC(_copy_from_user)
-EXPORT_SYMBOL(_copy_from_user)
-
-
-   .section .fixup,"ax"
-   /* must zero dest */
-ENTRY(bad_from_user)
-bad_from_user:
-   movl %edx,%ecx
-   xorl %eax,%eax
-   rep
-   stosb
-bad_to_user:
-   movl %edx,%eax
-   ret
-ENDPROC(bad_from_user)
-   .previous
-
 /*
  * copy_user_generic_unrolled - memory copy with exception handling.
  * This version is for CPUs like P4 that don't have efficient micro
diff --git a/arch/x86/lib/usercopy.c b/arch/x86/lib/usercopy.c
index b490878..c074799 100644
--- a/arch/x86/lib/usercopy.c
+++ b/arch/x86/lib/usercopy.c
@@ -34,3 +34,52 @@ copy_from_user_nmi(void *to, const void __user *from, 
unsigned long n)
return ret;
 }
 EXPORT_SYMBOL_GPL(copy_from_user_nmi);
+
+/**
+ * copy_to_user: - Copy a block of data into user space.
+ * @to:   Destination address, in user space.
+ * @from: Source address, in kernel space.
+ * @n:Number of bytes to copy.
+ *
+ * Context: User context only. This function may sleep if pagefaults are
+ *  enabled.
+ *
+ * Copy data from kernel space to user space.
+ *
+ * Returns number of bytes that could not be copied.
+ * On success, this will be zero.
+ */
+unsigned long _copy_to_user(void __user *to, const void *from, unsigned n)
+{
+   if (access_ok(VERIFY_WRITE, to, n))
+   n = __copy_to_user(to, from, n);
+   return n;
+}
+EXPORT_SYMBOL(_copy_to_user);
+
+/**
+ * copy_from_user: - Copy a block of data from user space.
+ * @to:   Destination address, in kernel space.
+ * @from: Source address, in user space.
+ * @n:Number of bytes to copy.
+ *
+ * Context: User context only. This function may sleep if pagefaults are
+ *  enabled.
+ *
+ * Copy data from user space to kernel space.
+ *
+ * Returns number of bytes that could not be copied.
+ * On success, this will be zero.
+ *
+ * If some data could not be copied, this function will pad the copied
+ * data to the requested size using zero bytes.
+ */
+unsigned long _copy_from_user(void *to, const void __user *from, unsigned n)
+{
+   if (access_ok(VERIFY_READ, from, n))
+   n = __copy_from_user(to, from, n);
+   else
+   memset(to, 0, n);
+   return n;
+}

[tip:x86/fpu] x86/fpu: Remove stts()

[tip-bot for Andy Lutomirski]

Commit-ID:  0d50612c041f213fb6b98e3ff06e306a859c36f2
Gitweb: http://git.kernel.org/tip/0d50612c041f213fb6b98e3ff06e306a859c36f2
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:48 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:55 +0100

x86/fpu: Remove stts()

It has no callers any more, and it was always a bit confusing, as
there is no STTS instruction.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/04247401710b230849e58bf2112ce4fd0b9840e1.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/special_insns.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/include/asm/special_insns.h 
b/arch/x86/include/asm/special_insns.h
index 19a2224..29b417b 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -216,8 +216,6 @@ static inline void clts(void)
 
 #endif/* CONFIG_PARAVIRT */
 
-#define stts() write_cr0(read_cr0() | X86_CR0_TS)
-
 static inline void clflush(volatile void *__p)
 {
asm volatile("clflush %0" : "+m" (*(volatile char __force *)__p));

[tip:x86/fpu] x86/fpu: Handle #NM without FPU emulation as an error

[tip-bot for Andy Lutomirski]

Commit-ID:  bef8b6da95229f780a0a7f63e23124058bfad6d3
Gitweb: http://git.kernel.org/tip/bef8b6da95229f780a0a7f63e23124058bfad6d3
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:47 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:54 +0100

x86/fpu: Handle #NM without FPU emulation as an error

Don't use CR0.TS.  Make it an error rather than making nonsensical
changes to the FPU state.

(The cond_local_irq_enable() appears to have been pointless, too.)

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/f1ee6bf73ed1025fccaab321ba43d0594245f927.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/traps.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bd4e3d4..bf0c6d0 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -853,6 +853,8 @@ do_spurious_interrupt_bug(struct pt_regs *regs, long 
error_code)
 dotraplinkage void
 do_device_not_available(struct pt_regs *regs, long error_code)
 {
+   unsigned long cr0;
+
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
 
 #ifdef CONFIG_MATH_EMULATION
@@ -866,10 +868,20 @@ do_device_not_available(struct pt_regs *regs, long 
error_code)
return;
}
 #endif
-   fpu__restore(>thread.fpu); /* interrupts still off */
-#ifdef CONFIG_X86_32
-   cond_local_irq_enable(regs);
-#endif
+
+   /* This should not happen. */
+   cr0 = read_cr0();
+   if (WARN(cr0 & X86_CR0_TS, "CR0.TS was set")) {
+   /* Try to fix it up and carry on. */
+   write_cr0(cr0 & ~X86_CR0_TS);
+   } else {
+   /*
+* Something terrible happened, and we're better off trying
+* to kill the task than getting stuck in a never-ending
+* loop of #NM faults.
+*/
+   die("unexpected #NM exception", regs, error_code);
+   }
 }
 NOKPROBE_SYMBOL(do_device_not_available);
 

[PATCH v3 07/11] pwm: imx: Provide atomic PWM support for i.MX PWMv2

[Lukasz Majewski]

This commit provides apply() callback implementation for i.MX's PWMv2.

Suggested-by: Stefan Agner 
Suggested-by: Boris Brezillon 
Signed-off-by: Lukasz Majewski 
Reviewed-by: Boris Brezillon 
---
Changes for v3:
- Remove ipg clock enable/disable functions

Changes for v2:
- None
---
 drivers/pwm/pwm-imx.c | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index ebe9b0c..cd53c05 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -159,6 +159,75 @@ static void imx_pwm_wait_fifo_slot(struct pwm_chip *chip,
}
 }
 
+static int imx_pwm_apply_v2(struct pwm_chip *chip, struct pwm_device *pwm,
+   struct pwm_state *state)
+{
+   unsigned long period_cycles, duty_cycles, prescale;
+   struct imx_chip *imx = to_imx_chip(chip);
+   struct pwm_state cstate;
+   unsigned long long c;
+   u32 cr = 0;
+   int ret;
+
+   pwm_get_state(pwm, );
+
+   c = clk_get_rate(imx->clk_per);
+   c *= state->period;
+
+   do_div(c, 10);
+   period_cycles = c;
+
+   prescale = period_cycles / 0x1 + 1;
+
+   period_cycles /= prescale;
+   c = (unsigned long long)period_cycles * state->duty_cycle;
+   do_div(c, state->period);
+   duty_cycles = c;
+
+   /*
+* according to imx pwm RM, the real period value should be
+* PERIOD value in PWMPR plus 2.
+*/
+   if (period_cycles > 2)
+   period_cycles -= 2;
+   else
+   period_cycles = 0;
+
+   /* Enable the clock if the PWM is being enabled. */
+   if (state->enabled && !cstate.enabled) {
+   ret = clk_prepare_enable(imx->clk_per);
+   if (ret)
+   return ret;
+   }
+
+   /*
+* Wait for a free FIFO slot if the PWM is already enabled, and flush
+* the FIFO if the PWM was disabled and is about to be enabled.
+*/
+   if (cstate.enabled)
+   imx_pwm_wait_fifo_slot(chip, pwm);
+   else if (state->enabled)
+   imx_pwm_sw_reset(chip);
+
+   writel(duty_cycles, imx->mmio_base + MX3_PWMSAR);
+   writel(period_cycles, imx->mmio_base + MX3_PWMPR);
+
+   cr |= MX3_PWMCR_PRESCALER(prescale) |
+ MX3_PWMCR_DOZEEN | MX3_PWMCR_WAITEN |
+ MX3_PWMCR_DBGEN | MX3_PWMCR_CLKSRC_IPG_HIGH;
+
+   if (state->enabled)
+   cr |= MX3_PWMCR_EN;
+
+   writel(cr, imx->mmio_base + MX3_PWMCR);
+
+   /* Disable the clock if the PWM is being disabled. */
+   if (!state->enabled && cstate.enabled)
+   clk_disable_unprepare(imx->clk_per);
+
+   return 0;
+}
+
 static int imx_pwm_config_v2(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
 {
@@ -273,6 +342,7 @@ static struct pwm_ops imx_pwm_ops_v2 = {
.enable = imx_pwm_enable,
.disable = imx_pwm_disable,
.config = imx_pwm_config,
+   .apply = imx_pwm_apply_v2,
.owner = THIS_MODULE,
 };
 
-- 
2.1.4

Re: [PATCH v10 10/19] vfio iommu: Add blocking notifier to notify DMA_UNMAP

[Kirti Wankhede]

On 11/1/2016 9:15 AM, Dong Jia Shi wrote:
> * Alex Williamson  [2016-10-29 08:03:01 -0600]:
> 
>> On Sat, 29 Oct 2016 16:07:05 +0530
>> Kirti Wankhede  wrote:
>>
>>> On 10/29/2016 2:03 AM, Alex Williamson wrote:
 On Sat, 29 Oct 2016 01:32:35 +0530
 Kirti Wankhede  wrote:
   
> On 10/28/2016 6:10 PM, Alex Williamson wrote:  
>> On Fri, 28 Oct 2016 15:33:58 +0800
>> Jike Song  wrote:
>> 
>>> ...
  
 +/*
 + * This function finds pfn in domain->external_addr_space->pfn_list 
 for given
 + * iova range. If pfn exist, notify pfn to registered notifier list. 
 On
 + * receiving notifier callback, vendor driver should invalidate the 
 mapping and
 + * call vfio_unpin_pages() to unpin this pfn. With that vfio_pfn for 
 this pfn
 + * gets removed from rb tree of pfn_list. That re-arranges rb tree, 
 so while
 + * searching for next vfio_pfn in rb tree, start search from first 
 node again.
 + * If any vendor driver doesn't unpin that pfn, vfio_pfn would not 
 get removed
 + * from rb tree and so in next search vfio_pfn would be same as 
 previous
 + * vfio_pfn. In that case, exit from loop.
 + */
 +static void vfio_notifier_call_chain(struct vfio_iommu *iommu,
 +   struct vfio_iommu_type1_dma_unmap 
 *unmap)
 +{
 +  struct vfio_domain *domain = iommu->external_domain;
 +  struct rb_node *n;
 +  struct vfio_pfn *vpfn = NULL, *prev_vpfn;
 +
 +  do {
 +  prev_vpfn = vpfn;
 +  mutex_lock(>external_addr_space->pfn_list_lock);
 +
 +  n = rb_first(>external_addr_space->pfn_list);
 +
 +  for (; n; n = rb_next(n), vpfn = NULL) {
 +  vpfn = rb_entry(n, struct vfio_pfn, node);
 +
 +  if ((vpfn->iova >= unmap->iova) &&
 +  (vpfn->iova < unmap->iova + unmap->size))
 +  break;
 +  }
 +
 +  
 mutex_unlock(>external_addr_space->pfn_list_lock);
 +
 +  /* Notify any listeners about DMA_UNMAP */
 +  if (vpfn)
 +  blocking_notifier_call_chain(>notifier,
 +  
 VFIO_IOMMU_NOTIFY_DMA_UNMAP,
 +  >pfn);  
>>>
>>> Hi Kirti, 
>>>
>>> The information carried by notifier is only a pfn.
>>>
>>> Since your pin/unpin interfaces design, it's the vendor driver who 
>>> should
>>> guarantee pin/unpin same times. To achieve that, the vendor driver must
>>> cache it's iova->pfn mapping on its side, to avoid pinning a same page
>>> for multiple times.
>>>
>>> With the notifier carrying only a pfn, to find the iova by this pfn,
>>> the vendor driver must *also* keep a reverse-mapping. That's a bit
>>> too much.
>>>
>>> Since the vendor could also suffer from IOMMU-compatible problem,
>>> which means a local cache is always helpful, so I'd like to have the
>>> iova carried to the notifier.
>>>
>>> What'd you say?
>>
>> I agree, the pfn is not unique, multiple guest pfns (iovas) might be
>> backed by the same host pfn.  DMA_UNMAP calls are based on iova, the
>> notifier through to the vendor driver must be based on the same.
>
> Host pfn should be unique, right?  

 Let's say a user does a malloc of a single page and does 100 calls to
 MAP_DMA populating 100 pages of IOVA space all backed by the same
 malloc'd page.  This is valid, I have unit tests that do essentially
 this.  Those will all have the same pfn.  The user then does an
 UNMAP_DMA to a single one of those IOVA pages.  Did the user unmap
 everything matching that pfn?  Of course not, they only unmapped that
 one IOVA page.  There is no guarantee of a 1:1 mapping of pfn to IOVA.
 UNMAP_DMA works based on IOVA.  Invalidation broadcasts to the vendor
 driver MUST therefore also work based on IOVA.  This is not an academic
 problem, address space aliases exist in real VMs, imagine a virtual
 IOMMU.  Thanks,
   
>>>
>>>
>>> So struct vfio_iommu_type1_dma_unmap should be passed as argument to
>>> notifier callback:
>>>
>>> if (unmapped && iommu->external_domain)
>>> -   vfio_notifier_call_chain(iommu, unmap);
>>> +   blocking_notifier_call_chain(>notifier,
>>> +   VFIO_IOMMU_NOTIFY_DMA_UNMAP,

Re: [ANNOUNCE] Git v2.11.0-rc0

[Patrick Steinhardt]

Hi Junio,

On Mon, Oct 31, 2016 at 02:49:42PM -0700, Junio C Hamano wrote:
[snip]
>  * In some projects, it is common to use "[RFC PATCH]" as the subject
>prefix for a patch meant for discussion rather than application.  A
>new option "--rfc" was a short-hand for "--subject-prefix=RFC PATCH"
~~~
>to help the participants of such projects.

This should probably be 'A new option "--rfc" was introduced as a
short-hand for…' or similar.

>  * When given an abbreviated object name that is not (or more
>realistically, "no longer") unique, we gave a fatal error
>"ambiguous argument".  This error is now accompanied by hints that
>lists the objects that begins with the given prefix.  During the
>course of development of this new feature, numerous minor bugs were
>uncovered and corrected, the most notable one of which is that we
>gave "short SHA1  is ambiguous." twice without good reason.

I think "This error is now accompanied by a hint that lists the
objects beginning with the given prefix." would be grammatically
more correct.

>  * "git diff -W" output needs to extend the context backward to
>include the header line of the current function and also forward to
>include the body of the entire current function up to the header
>line of the next one.  This process may have to merge to adjacent
   ~~
>hunks, but the code forgot to do so in some cases.

This should probably be "_two_ adjacent hunks".

>  * In a worktree connected to a repository elsewhere, created via "git
>worktree", "git checkout" attempts to protect users from confusion
>by refusing to check out a branch that is already checked out in
>another worktree.  However, this also prevented checking out a
>branch, which is designated as the primary branch of a bare
>reopsitory, in a worktree that is connected to the bare
 ~~
>repository.  The check has been corrected to allow it.

There's a typo here in "reopsitory".


Regards
Patrick Steinhardt


signature.asc
Description: PGP signature

Re: [PATCH] drm/imx: Fix error handling

[Philipp Zabel]

Hi Christophe,

Am Montag, den 31.10.2016, 18:59 +0100 schrieb Christophe JAILLET:
> 'drm_dev_alloc()' returns an error pointer in case of error, not NULL
> So test it with IS_ERR.
> 
> This behavior has been introduced recently in 0f2886057be3. For some
> reason, this file has not been updated.
> 
> Fixes: 0f2886057be3 ("drm: Don't swallow error codes in drm_dev_alloc()")
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 98df09c2b388..3acc976cc04e 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -357,8 +357,8 @@ static int imx_drm_bind(struct device *dev)
>   int ret;
>  
>   drm = drm_dev_alloc(_drm_driver, dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>  
>   imxdrm = devm_kzalloc(dev, sizeof(*imxdrm), GFP_KERNEL);
>   if (!imxdrm) {

Thank you for the patch. The same fix is in the queue already:
8cca354816ad ("drm/imx: drm_dev_alloc() returns error pointers"). Only
Dan selected commit 54db5decce17 ("drm/imx: drop deprecated load/unload
drm_driver ops") as the culprit.

regards
Philipp

RE: [PATCH v3 2/3] clocksource: update "fn" at CLOCKSOURCE_OF_DECLARE() of nps400 timer

[Noam Camus]

> From: Thomas Gleixner [mailto:t...@linutronix.de] 
> Sent: Monday, October 31, 2016 7:40 PM

>>  
>>  static unsigned long nps_timer_rate;
>> +static int nps_get_timer_clk(struct device_node *node,
>
>Please don't glue variables and functions together w/o a new line. That's 
>horrible to read.
Will be fixed in V4

>> +static int __init nps_setup_clocksource(struct device_node *node)
>>  {
>>  int ret, cluster;
>> +struct clk *clk;
>>  
>>  for (cluster = 0; cluster < NPS_CLUSTER_NUM; cluster++)
>>  nps_msu_reg_low_addr[cluster] =
>>  nps_host_reg((cluster << NPS_CLUSTER_OFFSET),
>>   NPS_MSU_BLKID, NPS_MSU_TICK_LOW);
>>  
>> -ret = clk_prepare_enable(clk);
>> -if (ret) {
>> -pr_err("Couldn't enable parent clock\n");
>> -return ret;
>> -}
>> -
>> -nps_timer_rate = clk_get_rate(clk);
>> +nps_get_timer_clk(node, _timer_rate, clk);

>Why are you ignoring the return code? It was handled before your change ...
Will be fixed in V4

Regards,
Noam

Re: [PATCH] clk: fix link error for rcar-gen2

[Simon Horman]

On Mon, Oct 31, 2016 at 11:02:36AM +0100, Geert Uytterhoeven wrote:
> On Mon, Oct 31, 2016 at 10:52 AM, Simon Horman  wrote:
> > From: Simon Horman 
> > Subject: [PATCH] ARM: shmobile: only call rcar_gen2_clocks_init() if present
> >
> > The RZ/G1M (r8a7743) uses the R-Car Gen2 core, but not the R-Car Gen2 clock
> > driver. This is a harbinger of a transition for R-Car Gen2 SoCs. As the
> > process to get all the required pieces in place is somewhat complex it
> > seems useful to try to disentangle dependencies where possible.
> >
> > The approach here is to temporarily disable calling rcar_gen2_clocks_init()
> > if no R-Car Gen2 SoC are configured and thus the symbol will not be
> 
> SoCs
> 
> > present.
> >
> > Fixes: 1254f607fc3d ("ARM: shmobile: r8a7743: basic SoC support")
> > Signed-off-by: Simon Horman 
> 
> Acked-by: Geert Uytterhoeven 

Thanks, I will queue this up.

Re: [PATCH 1/4] MIPS: Fix ISA I FP sigcontext access violation handling

[Paul Burton]

On Monday, 31 October 2016 16:25:44 GMT Maciej W. Rozycki wrote:
> Complement commit 0ae8dceaebe3 ("Merge with 2.3.10.") and use the local
> `fault' handler to recover from FP sigcontext access violation faults,
> like corresponding code does in r4k_fpu.S.  The `bad_stack' handler is
> in syscall.c and is not suitable here as we want to propagate the error
> condition up through the caller rather than killing the thread outright.
> 
> Signed-off-by: Maciej W. Rozycki 
> ---
>  I guess it hardly ever triggers and code still builds, so it has aged so
> well...
> 
>   Maciej
> 
> linux-mips-isa1-sig-fp-context-fault.patch
> Index: linux-sfr-test/arch/mips/kernel/r2300_fpu.S
> ===
> --- linux-sfr-test.orig/arch/mips/kernel/r2300_fpu.S  2016-10-22
> 02:36:46.0 +0100 +++
> linux-sfr-test/arch/mips/kernel/r2300_fpu.S   2016-10-22 02:37:20.891186000
> +0100 @@ -21,7 +21,7 @@
>  #define EX(a,b)  \
>  9:   a,##b;  \
>   .section __ex_table,"a";\
> - PTR 9b,bad_stack;   \
> + PTR 9b,fault;   \
>   .previous
> 
>   .setnoreorder

Hi Maciej,

Looks good to me:

Reviewed-by: Paul Burton 

Thanks,
Paul

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2] ARM: davinci: da850: Fix pwm name matching

[Sekhar Nori]

On Tuesday 01 November 2016 01:34 AM, David Lechner wrote:
> This fixes pwm name matching for DA850 familiy devices. When using device
> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
> same name, which caused errors when trying to register the devices.
> 
> We cannot have multiple entries for the same clock in in da850_clks[], so
> we have added child clocks to the EHRPWM and ECAP LPSC clocks so that each
> PWM device will have its own clock for proper name matching.
> 
> Signed-off-by: David Lechner 

This looks good to me. Thanks!

I have added it to my fixes branch for further testing before sending
upstream.

Thanks,
Sekhar

[tip:core/urgent] fork: Add task stack refcounting sanity check and prevent premature task stack freeing

[tip-bot for Andy Lutomirski]

Commit-ID:  405c0759712f57b680f66aee9c55cd06ad1cbdef
Gitweb: http://git.kernel.org/tip/405c0759712f57b680f66aee9c55cd06ad1cbdef
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 08:11:43 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:39:17 +0100

fork: Add task stack refcounting sanity check and prevent premature task stack 
freeing

If something goes wrong with task stack refcounting and a stack
refcount hits zero too early, warn and leak it rather than
potentially freeing it early (and silently).

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/f29119c783a9680a4b4656e751b6123917ace94b.1477926663.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 kernel/fork.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/fork.c b/kernel/fork.c
index 623259f..997ac1d 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -315,6 +315,9 @@ static void account_kernel_stack(struct task_struct *tsk, 
int account)
 
 static void release_task_stack(struct task_struct *tsk)
 {
+   if (WARN_ON(tsk->state != TASK_DEAD))
+   return;  /* Better to leak the stack than to free prematurely */
+
account_kernel_stack(tsk, -1);
arch_release_thread_stack(tsk->stack);
free_thread_stack(tsk);
@@ -1862,6 +1865,7 @@ bad_fork_cleanup_count:
atomic_dec(>cred->user->processes);
exit_creds(p);
 bad_fork_free:
+   p->state = TASK_DEAD;
put_task_stack(p);
free_task(p);
 fork_out:

[PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[John Heenan]

The rtl8723bu wireless IC shows evidence of a more agressive approach to
power saving, powering down its RF side when there is no wireless
interfacing but leaving USB interfacing intact. This makes the wireless
IC more suitable for use in devices which need to keep their power use
as low as practical, such as tablets and Surface Pro type devices.

In effect this means that a full initialisation must be performed
whenever a wireless interface is brought up. It also means that
interpretations of power status from general wireless registers should
not be relied on to influence an init sequence.

The patch works by forcing a fuller initialisation and forcing it to
occur more often in code paths (such as occurs during a low level
authentication that initiates wireless interfacing).

The initialisation sequence is now more consistent with code based
directly on vendor code. For example while the vendor derived code
interprets a register as indcating a particular powered state, it does
not use this information to influence its init sequence.

Only devices that use the rtl8723bu driver are affected by this patch.

With this patch wpa_supplicant reliably and consistently connects with
an AP. Before a workaround such as executing rmmod and modprobe before
each call to wpa_supplicant worked with some distributions.

Signed-off-by: John Heenan 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 04141e5..ab2f2ef 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3900,7 +3900,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
 * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
 * initialized. First MAC returns 0xea, second MAC returns 0x00
 */
-   if (val8 == 0xea)
+   if (val8 == 0xea || priv->fops == _fops)
macpower = false;
else
macpower = true;
@@ -5779,6 +5779,12 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
 
ret = 0;
 
+   if(priv->fops == _fops) {
+   ret = rtl8xxxu_init_device(hw);
+   if (ret)
+   goto error_out;
+   }
+
init_usb_anchor(>rx_anchor);
init_usb_anchor(>tx_anchor);
init_usb_anchor(>int_anchor);
@@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface 
*interface,
goto exit;
}
 
-   ret = rtl8xxxu_init_device(hw);
-   if (ret)
-   goto exit;
+   if(priv->fops != _fops) {
+   ret = rtl8xxxu_init_device(hw);
+   if (ret)
+   goto exit;
+   }
 
hw->wiphy->max_scan_ssids = 1;
hw->wiphy->max_scan_ie_len = IEEE80211_MAX_DATA_LEN;
-- 
2.10.1

Re: [kernel-hardening] rowhammer protection [was Re: Getting interrupt every million cache misses]

[Daniel Gruss]

On 01.11.2016 07:33, Ingo Molnar wrote:

Can you suggest a method to find heavily rowhammer affected hardware? Only by
testing it, or are there some chipset IDs ranges or dmidecode info that will
pinpoint potentially affected machines?


I have worked with many different systems both on running rowhammer 
attacks and testing defense mechanisms. So far, every Ivy Bridge i5 
(DDR3) that I had access to was susceptible to bit flips - you will have 
highest chances with Ivy Bridge i5...

Re: [PATCH v6 2/6] mm/cma: introduce new zone, ZONE_CMA

[Chen Feng]

Hello, I hava a question on cma zone.

When we have cma zone, cma zone will be the highest zone of system.

In android system, the most memory allocator is ION. Media system will
alloc unmovable memory from it.

On low memory scene, will the CMA zone always do balance?

Should we transmit the highest available zone to kswapd？

On 2016/10/14 11:03, js1...@gmail.com wrote:
> From: Joonsoo Kim 
> 
> Attached cover-letter:
> 
> This series try to solve problems of current CMA implementation.
> 
> CMA is introduced to provide physically contiguous pages at runtime
> without exclusive reserved memory area. But, current implementation
> works like as previous reserved memory approach, because freepages
> on CMA region are used only if there is no movable freepage. In other
> words, freepages on CMA region are only used as fallback. In that
> situation where freepages on CMA region are used as fallback, kswapd
> would be woken up easily since there is no unmovable and reclaimable
> freepage, too. If kswapd starts to reclaim memory, fallback allocation
> to MIGRATE_CMA doesn't occur any more since movable freepages are
> already refilled by kswapd and then most of freepage on CMA are left
> to be in free. This situation looks like exclusive reserved memory case.
> 
> In my experiment, I found that if system memory has 1024 MB memory and
> 512 MB is reserved for CMA, kswapd is mostly woken up when roughly 512 MB
> free memory is left. Detailed reason is that for keeping enough free
> memory for unmovable and reclaimable allocation, kswapd uses below
> equation when calculating free memory and it easily go under the watermark.
> 
> Free memory for unmovable and reclaimable = Free total - Free CMA pages
> 
> This is derivated from the property of CMA freepage that CMA freepage
> can't be used for unmovable and reclaimable allocation.
> 
> Anyway, in this case, kswapd are woken up when (FreeTotal - FreeCMA)
> is lower than low watermark and tries to make free memory until
> (FreeTotal - FreeCMA) is higher than high watermark. That results
> in that FreeTotal is moving around 512MB boundary consistently. It
> then means that we can't utilize full memory capacity.
> 
> To fix this problem, I submitted some patches [1] about 10 months ago,
> but, found some more problems to be fixed before solving this problem.
> It requires many hooks in allocator hotpath so some developers doesn't
> like it. Instead, some of them suggest different approach [2] to fix
> all the problems related to CMA, that is, introducing a new zone to deal
> with free CMA pages. I agree that it is the best way to go so implement
> here. Although properties of ZONE_MOVABLE and ZONE_CMA is similar, I
> decide to add a new zone rather than piggyback on ZONE_MOVABLE since
> they have some differences. First, reserved CMA pages should not be
> offlined. If freepage for CMA is managed by ZONE_MOVABLE, we need to keep
> MIGRATE_CMA migratetype and insert many hooks on memory hotplug code
> to distiguish hotpluggable memory and reserved memory for CMA in the same
> zone. It would make memory hotplug code which is already complicated
> more complicated. Second, cma_alloc() can be called more frequently
> than memory hotplug operation and possibly we need to control
> allocation rate of ZONE_CMA to optimize latency in the future.
> In this case, separate zone approach is easy to modify. Third, I'd
> like to see statistics for CMA, separately. Sometimes, we need to debug
> why cma_alloc() is failed and separate statistics would be more helpful
> in this situtaion.
> 
> Anyway, this patchset solves four problems related to CMA implementation.
> 
> 1) Utilization problem
> As mentioned above, we can't utilize full memory capacity due to the
> limitation of CMA freepage and fallback policy. This patchset implements
> a new zone for CMA and uses it for GFP_HIGHUSER_MOVABLE request. This
> typed allocation is used for page cache and anonymous pages which
> occupies most of memory usage in normal case so we can utilize full
> memory capacity. Below is the experiment result about this problem.
> 
> 8 CPUs, 1024 MB, VIRTUAL MACHINE
> make -j16
> 
> 
> CMA reserve:0 MB512 MB
> Elapsed-time:   92.4  186.5
> pswpin: 8218647
> pswpout:160   69839
> 
> 
> CMA reserve:0 MB512 MB
> Elapsed-time:   93.1  93.4
> pswpin: 8446
> pswpout:183   92
> 
> FYI, there is another attempt [3] trying to solve this problem in lkml.
> And, as far as I know, Qualcomm also has out-of-tree solution for this
> problem.
> 
> 2) Reclaim problem
> Currently, there is no logic to distinguish CMA pages in reclaim path.
> If reclaim is initiated for unmovable and reclaimable allocation,
> reclaiming CMA pages doesn't help to satisfy the request and reclaiming
> CMA page is just waste. By managing 

Re: [PATCH v2 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

[Oliver O'Halloran]

On Thu, Oct 27, 2016 at 7:35 PM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> In the current code for powernv_add_idle_states, there is a lot of code
> duplication while initializing an idle state in powernv_states table.
>
> Add an inline helper function to populate the powernv_states[] table for
> a given idle state. Invoke this for populating the "Nap", "Fastsleep"
> and the stop states in powernv_add_idle_states.
>
> Signed-off-by: Gautham R. Shenoy 
> ---
>  drivers/cpuidle/cpuidle-powernv.c | 82 
> +++
>  include/linux/cpuidle.h   |  1 +
>  2 files changed, 49 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle-powernv.c 
> b/drivers/cpuidle/cpuidle-powernv.c
> index 7fe442c..11b22b9 100644
> --- a/drivers/cpuidle/cpuidle-powernv.c
> +++ b/drivers/cpuidle/cpuidle-powernv.c
> @@ -167,6 +167,28 @@ static int powernv_cpuidle_driver_init(void)
> return 0;
>  }
>
> +static inline void add_powernv_state(int index, const char *name,
> +unsigned int flags,
> +int (*idle_fn)(struct cpuidle_device *,
> +   struct cpuidle_driver *,
> +   int),
> +unsigned int target_residency,
> +unsigned int exit_latency,
> +u64 psscr_val)
> +{
> +   strncpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> +   strncpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);

If the supplied name is equal to CPUIDLE_NAME_LEN then strncpy() won't
terminate the string. The least annoying fix is to memset() the whole
structure to zero and set n to CPUIDLE_NAME_LEN - 1.

> +   powernv_states[index].flags = flags;
> +   powernv_states[index].target_residency = target_residency;
> +   powernv_states[index].exit_latency = exit_latency;
> +   powernv_states[index].enter = idle_fn;
> +
> +   if (idle_fn != stop_loop)
> +   return;

This can probably be deleted. The nap/sleep loops don't look at the
psscr setting and you've passed in a dummy value of zero anyway.

> +
> +   stop_psscr_table[index] = psscr_val;
> +}
> +
>  static int powernv_add_idle_states(void)
>  {
> struct device_node *power_mgt;
> @@ -236,6 +258,7 @@ static int powernv_add_idle_states(void)
> "ibm,cpu-idle-state-residency-ns", residency_ns, 
> dt_idle_states);
>
> for (i = 0; i < dt_idle_states; i++) {
> +   unsigned int exit_latency, target_residency;
> /*
>  * If an idle state has exit latency beyond
>  * POWERNV_THRESHOLD_LATENCY_NS then don't use it
> @@ -244,27 +267,30 @@ static int powernv_add_idle_states(void)
> if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
> continue;
>
> +   exit_latency = ((unsigned int)latency_ns[i]) / 1000;
> +   target_residency = (!rc) ? ((unsigned int)residency_ns[i]) : 
> 0;
> +   /*
> +* Firmware passes residency values in ns.
> +* cpuidle expects it in us.
> +*/
> +   target_residency /= 1000;
> +
> /*
>  * Cpuidle accepts exit_latency and target_residency in us.

This comment says the same thing as the one above.

>  * Use default target_residency values if f/w does not expose 
> it.
>  */
> if (flags[i] & OPAL_PM_NAP_ENABLED) {
> +   target_residency = 100;

Hmm, the above comment says that we should only use the default value
for target_residency if firmware hasn't provided a value. Is there a
reason we always use the hard coded value?

> /* Add NAP state */
> -   strcpy(powernv_states[nr_idle_states].name, "Nap");
> -   strcpy(powernv_states[nr_idle_states].desc, "Nap");
> -   powernv_states[nr_idle_states].flags = 0;
> -   powernv_states[nr_idle_states].target_residency = 100;
> -   powernv_states[nr_idle_states].enter = nap_loop;
> +   add_powernv_state(nr_idle_states, "Nap",
> + CPUIDLE_FLAG_NONE, nap_loop,
> + target_residency, exit_latency, 0);
> } else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
> !(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
> -   strncpy(powernv_states[nr_idle_states].name,
> -   names[i], CPUIDLE_NAME_LEN);
> -   strncpy(powernv_states[nr_idle_states].desc,
> -  

Re: [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.

[Hans Verkuil]

On 01/11/16 09:08, Songjun Wu wrote:

Release the filehandle in 'isc_open' if it's not the only filehandle
opened for the associated video_device.


What's wrong with that? You should always be able to open the device
multiple times. v4l2-compliance will fail after this patch. I'm not sure
what you intended to do here, but this patch is wrong.

Regards,

Hans



Signed-off-by: Songjun Wu 
---

 drivers/media/platform/atmel/atmel-isc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 8e25d3f..5e08404 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -926,21 +926,21 @@ static int isc_open(struct file *file)
if (ret < 0)
goto unlock;

-   if (!v4l2_fh_is_singular_file(file))
-   goto unlock;
+   ret = !v4l2_fh_is_singular_file(file);
+   if (ret)
+   goto fh_rel;

ret = v4l2_subdev_call(sd, core, s_power, 1);
-   if (ret < 0 && ret != -ENOIOCTLCMD) {
-   v4l2_fh_release(file);
-   goto unlock;
-   }
+   if (ret < 0 && ret != -ENOIOCTLCMD)
+   goto fh_rel;

ret = isc_set_fmt(isc, >fmt);
-   if (ret) {
+   if (ret)
v4l2_subdev_call(sd, core, s_power, 0);
-   v4l2_fh_release(file);
-   }

+fh_rel:
+   if (ret)
+   v4l2_fh_release(file);
 unlock:
mutex_unlock(>lock);
return ret;

Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support

[Borislav Petkov]

On Tue, Nov 01, 2016 at 08:51:57AM +0100, Paul Bolle wrote:
> And as probably everybody capable of hacking on lguest (ie, other
> people than me) came up with doubts similar to yours, these two issues
> never got fixed.

You can always try to fix them and see where it gets ya. I think that's
the *ultimate* goal of lguest.

:-)

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.

[Wu, Songjun]

Sorry, my mistake, the device should be able to opened multiple times.
It's a wrong patch.

On 11/1/2016 16:52, Hans Verkuil wrote:

On 01/11/16 09:08, Songjun Wu wrote:

Release the filehandle in 'isc_open' if it's not the only filehandle
opened for the associated video_device.


What's wrong with that? You should always be able to open the device
multiple times. v4l2-compliance will fail after this patch. I'm not sure
what you intended to do here, but this patch is wrong.

Regards,

Hans



Signed-off-by: Songjun Wu 
---

 drivers/media/platform/atmel/atmel-isc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c
b/drivers/media/platform/atmel/atmel-isc.c
index 8e25d3f..5e08404 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -926,21 +926,21 @@ static int isc_open(struct file *file)
 if (ret < 0)
 goto unlock;

-if (!v4l2_fh_is_singular_file(file))
-goto unlock;
+ret = !v4l2_fh_is_singular_file(file);
+if (ret)
+goto fh_rel;

 ret = v4l2_subdev_call(sd, core, s_power, 1);
-if (ret < 0 && ret != -ENOIOCTLCMD) {
-v4l2_fh_release(file);
-goto unlock;
-}
+if (ret < 0 && ret != -ENOIOCTLCMD)
+goto fh_rel;

 ret = isc_set_fmt(isc, >fmt);
-if (ret) {
+if (ret)
 v4l2_subdev_call(sd, core, s_power, 0);
-v4l2_fh_release(file);
-}

+fh_rel:
+if (ret)
+v4l2_fh_release(file);
 unlock:
 mutex_unlock(>lock);
 return ret;

Re: [x86/acpi] 04c197c080: BUG: unable to handle kernel paging request at 0000003000000010

[Dou Liyang]

Hi xiaolong,

Sorry for the late reply.

I think I should need to explain for this.

Firstly, please ignore this bug. Because, this patch has be discarded.
The work of this patch has already in the upstream(f3bf1dbe64).

Secondly, I think the cause of the bug is:

I use the "-EINVAL" incorrectly.

Thanks,
Dou.

This patch is repeated with him
At 10/11/2016 10:15 AM, kernel test robot wrote:

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Dou-Liyang/Fix-the-local-APIC-id-validation-in-case-of-0xff/20161008-154907
commit 04c197c080f2ed7a022f79701455c6837f4b9573 ("x86/acpi: Fix the local APIC id 
validation in case of 0xff")

in testcase: will-it-scale
with following parameters:

test: unlink2
cpufreq_governor: performance


Will It Scale takes a testcase and runs it from 1 through to n parallel copies 
to see if the testcase will scale. It builds both a process and threads based 
test in order to see any differences between the two.


on test machine: 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz with 128G 
memory

caused below changes:


+---+++
|   | 1e1a4b0f54 | 
04c197c080 |
+---+++
| boot_successes| 2  | 4
  |
| boot_failures | 0  | 7
  |
| BUG:unable_to_handle_kernel   | 0  | 3
  |
| Oops  | 0  | 3
  |
| RIP:check_timer   | 0  | 3
  |
| calltrace:native_smp_prepare_cpus | 0  | 3
  |
| Kernel_panic-not_syncing:Fatal_exception  | 0  | 3
  |
| PANIC:double_fault| 0  | 2
  |
| Bad_pagetable | 0  | 1
  |
| RIP:copy_user_enhanced_fast_string| 0  | 1
  |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 0  | 1
  |
| Kernel_panic-not_syncing:Machine_halted   | 0  | 1
  |
| RIP:vgacon_scroll | 0  | 1
  |
| invoked_oom-killer:gfp_mask=0x| 0  | 4
  |
| Mem-Info  | 0  | 4
  |
+---+++



[0.492621] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[0.499130] ...trying to set up timer (IRQ0) through the 8259A ...
[0.506027] . (found apic 2 pin 0) ...
[0.510601] BUG: unable to handle kernel paging request at 00300010
[0.518391] IP: [] check_timer+0x21d/0x61e
[0.524722] PGD 0
[0.526974] Oops:  [#1] SMP
[0.530477] Modules linked in:
[0.533901] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-00989-g04c197c #1
[0.541865] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS 
SE5C610.86B.01.01.0008.021120151325 02/11/2015
[0.553521] task: 882023b0 task.stack: c9000c468000
[0.560129] RIP: 0010:[]  [] 
check_timer+0x21d/0x61e
[0.569170] RSP: :c9000c46bd90  EFLAGS: 00010082
[0.575095] RAX: 0030 RBX:  RCX: 81e5cb48
[0.583058] RDX: 0001 RSI: 0046 RDI: 0046
[0.591031] RBP: c9000c46be08 R08:  R09: 
[0.598994] R10: 0040 R11: 0208 R12: 0002
[0.606957] R13: 0002 R14: 0002 R15: 88103f00ae20
[0.614927] FS:  () GS:88103f40() 
knlGS:
[0.623958] CS:  0010 DS:  ES:  CR0: 80050033
[0.630368] CR2: 00300010 CR3: 00207ee06000 CR4: 001406f0
[0.638331] Stack:
[0.640574]   0246  
88103f002080
[0.648870]  88103f002080 0017 0001 
c9000c46bdd8
[0.657165]  8145869d c9000c46bde8 0718 
0001
[0.665459] Call Trace:
[0.668193]  [] ? radix_tree_lookup+0xd/0x10
[0.674710]  [] setup_IO_APIC+0x17d/0x1c5
[0.680937]  [] apic_bsp_setup+0xa1/0xac
[0.687059]  [] native_smp_prepare_cpus+0x297/0x317
[0.694259]  [] kernel_init_freeable+0xcf/0x225
[0.701072]  [] ? rest_init+0x90/0x90
[0.706911]  [] kernel_init+0xe/0x100
[0.712744]  [] ret_from_fork+0x25/0x30
[0.718776] Code: ff 48 c7 c7 50 6d c9 81 e8 31 54 17 ff 89 da 44 89 ee 48 c7 c7 
90 6d c9 81 e8 20 54 17 ff 48 8b 45 a8 48 8b 00 48 39 45 a8 74 1a <44> 39 70 10 
75 0f 44 39 60 

Re: [PATCH v3 0/2] remoteproc: Add sysfs interface

[Matt Redfearn]

On 01/11/16 00:31, Bjorn Andersson wrote:

On Thu 27 Oct 07:10 PDT 2016, Matt Redfearn wrote:


On 19/10/16 13:05, Matt Redfearn wrote:

It is often desireable to boot a remote processor with different
firmware files, depending on the needs of the system at a particular
time. This series adds a sysfs interface to the remoteproc core,
exposing interfaces to manipulate the remote processor. One interface is
the "state" file which performs the same function as the one in debugfs
(which is removed later in the series). The other is a "firmware" file
which allows retrieval of the name of the running firmware, and allows a
new firmware to be loaded when written, as long as the remote processor
is currently stopped.

Some groundwork must be laid first, changing the storage mechanism of
the firmware name such that it can be rewritten easily, then that is
wired up to the new sysfs interface.

This series is based on v4.9-rc1


Changes in v3:
Drop call to rproc_add_virtio_devices from sysfs firmware_store
Use strcspn to find firmware name length
Explicit indexes for state strings

Changes in v2:
Have firmware_store perform the necessary steps inline.
Use sysfs_streq when dealing with writes to sysfs files

Matt Redfearn (2):
   remoteproc: Add a sysfs interface for firmware and state
   remoteproc: debugfs: Remove state entry which is duplicated is sysfs

  Documentation/ABI/testing/sysfs-class-remoteproc |  50 
  drivers/remoteproc/Makefile  |   1 +
  drivers/remoteproc/remoteproc_core.c |   3 +
  drivers/remoteproc/remoteproc_debugfs.c  |  71 ---
  drivers/remoteproc/remoteproc_internal.h |   5 +
  drivers/remoteproc/remoteproc_sysfs.c| 151 +++
  6 files changed, 210 insertions(+), 71 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-class-remoteproc
  create mode 100644 drivers/remoteproc/remoteproc_sysfs.c


Hi Bjorn,

Is this version of the patchset ok? Any feedback welcome :-)


Hi Matt,

I was hoping for some comments or verification from others, so I
conveniently did let it hang out in my TODO list.

I think the new interface looks good and have merged the two patches!


Great, thanks! :-)

Matt



Regards,
Bjorn

Re: [PATCH v14 1/4] clk: mediatek: Add MT2701 clock support

[James Liao]

Hi Stephen,

On Mon, 2016-10-31 at 11:06 -0700, Stephen Boyd wrote:
> On 10/31, James Liao wrote:
> > On Thu, 2016-10-27 at 18:17 -0700, Stephen Boyd wrote:
> > > On 10/21, Erin Lo wrote:
> > > > @@ -244,3 +256,31 @@ void mtk_clk_register_composites(const struct 
> > > > mtk_composite *mcs,
> > > > clk_data->clks[mc->id] = clk;
> > > > }
> > > >  }
> > > > +
> > > > +void mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
> > > > +   int num, void __iomem *base, spinlock_t *lock,
> > > > +   struct clk_onecell_data *clk_data)
> > > > +{
> > > > +   struct clk *clk;
> > > > +   int i;
> > > > +
> > > > +   for (i = 0; i <  num; i++) {
> > > > +   const struct mtk_clk_divider *mcd = [i];
> > > > +
> > > > +   if (clk_data && 
> > > > !IS_ERR_OR_NULL(clk_data->clks[mcd->id]))
> > > 
> > > NULL is a valid clk. IS_ERR_OR_NULL is usually wrong.
> > 
> > Why NULL is a valid clk?
> 
> Perhaps at some point we'll want to return a NULL pointer to
> clk_get() callers so that they can handle things like optional
> clocks easily without having any storage requirements. I don't
> know if we'll ever do that, but that's just a possibility.
> 
> > 
> > clk_data is designed for multiple initialization from different clock
> > types, such as infra_clk_data in clk-mt2701.c. So it will ignore valid
> > clocks to avoid duplicated clock registration. Here I assume a clock
> > pointer with error code or NULL to be an invalid (not initialized)
> > clock.
> > 
> 
> Ok. Would it be possible to initialize the array with all error
> pointers? That would make things less error prone, but it

Yes. Current mtk_alloc_clk_data() implementation init all elements with
ERR_PTR(-ENOENT). 

> probably doesn't matter at all anyway because this is done during
> registration time. IS_ERR_OR_NULL makes me take a second look
> each time, because it's usually wrong.

I see. Although currently all Mediatek clk drivers use
mtk_alloc_clk_data() to allocate clk_data, I would like to keep the
flexibility to support zero-initialized clk_data such as a static
structure. So I prefer to treat a NULL pointer as an uninitialized
clock.


Best regards,

James

RE: [PATCH 5/9] ARC: breakout aux handling into a seperate header

[Noam Camus]

>From: Vineet Gupta [mailto:vineet.gup...@synopsys.com] 
>Sent: Tuesday, November 1, 2016 12:48 AM

>ARC timers use aux registers for programming and this paves way for moving ARC 
>timer drivers into drivers/clocksource

Maybe in this patch or just another one could you move from timer.c to the new 
soc header all timer related Aux registers definitions?
This could be used by timer-nps driver.
 
i.e.:
/* Timer related Aux registers */
#define ARC_REG_TIMER0_LIMIT0x23/* timer 0 limit */
#define ARC_REG_TIMER0_CTRL 0x22/* timer 0 control */
#define ARC_REG_TIMER0_CNT  0x21/* timer 0 count */
#define ARC_REG_TIMER1_LIMIT0x102   /* timer 1 limit */
#define ARC_REG_TIMER1_CTRL 0x101   /* timer 1 control */
#define ARC_REG_TIMER1_CNT  0x100   /* timer 1 count */

#define TIMER_CTRL_IE   (1 << 0) /* Interrupt when Count reaches limit */
#define TIMER_CTRL_NH   (1 << 1) /* Count only when CPU NOT halted */

#define ARC_TIMER_MAX   0x

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

[Ivaylo Dimitrov]

Hi,

On  1.11.2016 00:54, Sakari Ailus wrote:

Hi Pavel,

On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:

Hi!


Thanks, this answered half of my questions already. ;-)


:-).

I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/video-bus-switch.c is needed for
camera switching, then some omap3isp patches to bind flash and
autofocus into the subdevice.

Then, device tree support on n900 can be added.


I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.



Yes, lets merge what we have till now, it will be way easier to improve 
on it once it is part of the mainline.


BTW, I have (had) patched VBS working almost without problems, when it 
comes to it I'll dig it.



Do all the modes work for you currently btw.?


I don't think I got 5MP mode to work. Even 2.5MP mode is tricky (needs
a lot of continuous memory).


The OMAP 3 ISP has got an MMU, getting some contiguous memory is not really
a problem when you have a 4 GiB empty space to use.


Anyway, I have to start somewhere, and I believe this is a good
starting place; I'd like to get the code cleaned up and merged, then
move to the next parts.


I wonder if something else could be the problem. I think the data rate is
higher in the 5 MP mode, and that might be the reason. I don't remember how
similar is the clock tree in the 3430 to the 3630. Could it be that the ISP
clock is lower than it should be for some reason, for instance?



IIRC I checked what Nokia kernel does, and according to my vague 
memories the frequency was the same. Still, it seems the problem is in 
ISP, it has some very fragile calculations. Yet again, having main 
camera merged will ease the problem hunting.


Regards,
Ivo

[PATCH] mfd: bcm590xx: Simplify a test

[Christophe JAILLET]

'i2c_new_dummy()' does not return an error pointer, so the test can be
simplified to be more consistent.

Signed-off-by: Christophe JAILLET 
---
 drivers/mfd/bcm590xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index 0d76d690176b..c572a35a9341 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -67,7 +67,7 @@ static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri,
/* Secondary I2C slave address is the base address with A(2) asserted */
bcm590xx->i2c_sec = i2c_new_dummy(i2c_pri->adapter,
  i2c_pri->addr | BIT(2));
-   if (IS_ERR_OR_NULL(bcm590xx->i2c_sec)) {
+   if (!bcm590xx->i2c_sec) {
dev_err(_pri->dev, "failed to add secondary I2C device\n");
return -ENODEV;
}
-- 
2.9.3

[PATCH v2] video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()

[Lukasz Majewski]

The commit a55944ca82d2 ("backlight: update bd state & fb_blank properties
when necessary") has posed some extra restrictions on blanking and 
unblanking frame buffer device.

Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.

This code in case of initial unblank of backlight device (default 
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe 
how much and which fb devices will be assigned).

Without this code, the backlight works properly until one tries to blank
it manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.

Signed-off-by: Lukasz Majewski 
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference

---
 drivers/video/backlight/pwm_bl.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1261400..6859ba0 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct pwm_bl_data *pb;
int initial_blank = FB_BLANK_UNBLANK;
struct pwm_args pargs;
-   int ret;
+   int ret, i;
 
if (!data) {
ret = pwm_backlight_parse_dt(>dev, );
@@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
 
bl->props.brightness = data->dft_brightness;
bl->props.power = initial_blank;
+
+   if (initial_blank == FB_BLANK_UNBLANK) {
+   for (i = 0; i < FB_MAX; i++)
+   bl->fb_bl_on[i] = true;
+
+   bl->use_count = 1;
+   }
+
backlight_update_status(bl);
 
platform_set_drvdata(pdev, bl);
-- 
2.1.4

[PATCH v2] mm/filemap: don't allow partially uptodate page for pipes

[Eryu Guan]

Starting from 4.9-rc1 kernel, I started noticing some test failures
of sendfile(2) and splice(2) (sendfile0N and splice01 from LTP) when
testing on sub-page block size filesystems (tested both XFS and
ext4), these syscalls start to return EIO in the tests. e.g.

sendfile021  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return 
expected value, expected: 26, got: -1
sendfile022  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return 
expected value, expected: 24, got: -1
sendfile023  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return 
expected value, expected: 22, got: -1
sendfile024  TFAIL  :  sendfile02.c:133: sendfile(2) failed to return 
expected value, expected: 20, got: -1

This is because that in sub-page block size cases, we don't need the
whole page to be uptodate, only the part we care about is uptodate
is OK (if fs has ->is_partially_uptodate defined). But
page_cache_pipe_buf_confirm() doesn't have the ability to check the
partially-uptodate case, it needs the whole page to be uptodate. So
it returns EIO in this case.

This is a regression introduced by commit 82c156f85384 ("switch
generic_file_splice_read() to use of ->read_iter()"). Prior to the
change, generic_file_splice_read() doesn't allow partially-uptodate
page either, so it worked fine.

Fix it by skipping the partially-uptodate check if we're working on
a pipe in do_generic_file_read(), so we read the whole page from
disk as long as the page is not uptodate.

Signed-off-by: Eryu Guan 
---

I think the other way to fix it is to add the ability to check & allow
partially-uptodate page to page_cache_pipe_buf_confirm(), but that is much
harder to do and seems gain little.

v2:
- Update summary a little bit
- Update commit log
- Add comment to the code
- Add more people/list to cc

v1: http://marc.info/?l=linux-mm=147756897431777=2

 mm/filemap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/filemap.c b/mm/filemap.c
index 849f459..670264d 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1734,6 +1734,9 @@ static ssize_t do_generic_file_read(struct file *filp, 
loff_t *ppos,
if (inode->i_blkbits == PAGE_SHIFT ||
!mapping->a_ops->is_partially_uptodate)
goto page_not_up_to_date;
+   /* pipes can't handle partially uptodate pages */
+   if (unlikely(iter->type & ITER_PIPE))
+   goto page_not_up_to_date;
if (!trylock_page(page))
goto page_not_up_to_date;
/* Did it get truncated before we got the lock? */
-- 
2.7.4

Re: [kernel-hardening] rowhammer protection [was Re: Getting interrupt every million cache misses]

[Daniel Gruss]

On 01.11.2016 09:10, Pavel Machek wrote:

cpu family : 6
model: 23
model name   : Intel(R) Core(TM)2 Duo CPU E7400  @ 2.80GHz
stepping : 10
microcode: 0xa07

so rowhammerjs/native is not available for this system. Bit mapping
for memory hash functions would need to be reverse engineered for more
effective attack.


By coincidence, we wrote a tool to do that in software: 
https://github.com/IAIK/drama ;)

[PATCH] [media] atmel-isc: release the filehandle if it's not the only one.

[Songjun Wu]

Release the filehandle in 'isc_open' if it's not the only filehandle
opened for the associated video_device.

Signed-off-by: Songjun Wu 
---

 drivers/media/platform/atmel/atmel-isc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 8e25d3f..5e08404 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -926,21 +926,21 @@ static int isc_open(struct file *file)
if (ret < 0)
goto unlock;
 
-   if (!v4l2_fh_is_singular_file(file))
-   goto unlock;
+   ret = !v4l2_fh_is_singular_file(file);
+   if (ret)
+   goto fh_rel;
 
ret = v4l2_subdev_call(sd, core, s_power, 1);
-   if (ret < 0 && ret != -ENOIOCTLCMD) {
-   v4l2_fh_release(file);
-   goto unlock;
-   }
+   if (ret < 0 && ret != -ENOIOCTLCMD)
+   goto fh_rel;
 
ret = isc_set_fmt(isc, >fmt);
-   if (ret) {
+   if (ret)
v4l2_subdev_call(sd, core, s_power, 0);
-   v4l2_fh_release(file);
-   }
 
+fh_rel:
+   if (ret)
+   v4l2_fh_release(file);
 unlock:
mutex_unlock(>lock);
return ret;
-- 
2.7.4

Re: [PATCH] swapfile: fix memory corruption via malformed swapfile

[Jerome Marchand]

On 10/31/2016 10:32 PM, Jann Horn wrote:
> When root activates a swap partition whose header has the wrong endianness,
> nr_badpages elements of badpages are swabbed before nr_badpages has been
> checked, leading to a buffer overrun of up to 8GB.
> 
> This normally is not a security issue because it can only be exploited by
> root (more specifically, a process with CAP_SYS_ADMIN or the ability to
> modify a swap file/partition), and such a process can already e.g. modify
> swapped-out memory of any other userspace process on the system.
> 
> Testcase for reproducing the bug (must be run as root, should crash your
> kernel):
> =
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define PAGE_SIZE 4096
> #define __u32 unsigned int
> 
> 
> // from include/linux/swap.h
> union swap_header {
>   struct {
> char reserved[PAGE_SIZE - 10];
> char magic[10]; /* SWAP-SPACE or SWAPSPACE2 */
>   } magic;
>   struct {
> charbootbits[1024]; /* Space for disklabel etc. */
> __u32   version;
> __u32   last_page;
> __u32   nr_badpages;
> unsigned char sws_uuid[16];
> unsigned char sws_volume[16];
> __u32   padding[117];
> __u32   badpages[1];
>   } info;
> };
> 
> int main(void) {
>   char file[] = "/tmp/swapfile.XX";
>   int file_fd = mkstemp(file);
>   if (file_fd == -1)
> err(1, "mkstemp");
>   if (ftruncate(file_fd, PAGE_SIZE))
> err(1, "ftruncate");
>   union swap_header swap_header = {
> .info = {
>   .version = __builtin_bswap32(1),
>   .nr_badpages = __builtin_bswap32(INT_MAX)
> }
>   };
>   memcpy(swap_header.magic.magic, "SWAPSPACE2", 10);
>   if (write(file_fd, _header, sizeof(swap_header)) !=
>   sizeof(swap_header))
> err(1, "write");
> 
>   // not because the attack needs it, just in case you forgot to
>   // sync yourself before crashing your machine
>   sync();
> 
>   // now die
>   if (swapon(file, 0))
> err(1, "swapon");
>   puts("huh, we survived");
>   if (swapoff(file))
> err(1, "swapoff");
>   unlink(file);
> }
> =
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jann Horn 
> ---
>  mm/swapfile.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 2210de290b54..f30438970cd1 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -2224,6 +2224,8 @@ static unsigned long read_swap_header(struct 
> swap_info_struct *p,
>   swab32s(_header->info.version);
>   swab32s(_header->info.last_page);
>   swab32s(_header->info.nr_badpages);
> + if (swap_header->info.nr_badpages > MAX_SWAP_BADPAGES)
> + return 0;
>   for (i = 0; i < swap_header->info.nr_badpages; i++)
>   swab32s(_header->info.badpages[i]);
>   }
> 

Nice catch!

Acked-by: Jerome Marchand 





signature.asc
Description: OpenPGP digital signature

[tip:x86/fpu] x86/fpu: Remove clts()

[tip-bot for Andy Lutomirski]

Commit-ID:  af25ed59b5616b389d90877f7085dc5d457a3d49
Gitweb: http://git.kernel.org/tip/af25ed59b5616b389d90877f7085dc5d457a3d49
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:49 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:55 +0100

x86/fpu: Remove clts()

The kernel doesn't use clts() any more.  Remove it and all of its
paravirt infrastructure.

A careful reader may notice that xen_clts() appears to have been
buggy -- it didn't update xen_cr0_value.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/3d3c8ca62f17579b9849a013d71e59a4d5d1b079.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/paravirt.h   |  5 -
 arch/x86/include/asm/paravirt_types.h |  2 --
 arch/x86/include/asm/special_insns.h  | 11 ---
 arch/x86/kernel/paravirt.c|  1 -
 arch/x86/kernel/paravirt_patch_32.c   |  2 --
 arch/x86/kernel/paravirt_patch_64.c   |  2 --
 arch/x86/lguest/boot.c| 12 
 arch/x86/xen/enlighten.c  | 13 -
 8 files changed, 48 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index ce93281..f1fb4db 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -41,11 +41,6 @@ static inline void set_debugreg(unsigned long val, int reg)
PVOP_VCALL2(pv_cpu_ops.set_debugreg, reg, val);
 }
 
-static inline void clts(void)
-{
-   PVOP_VCALL0(pv_cpu_ops.clts);
-}
-
 static inline unsigned long read_cr0(void)
 {
return PVOP_CALL0(unsigned long, pv_cpu_ops.read_cr0);
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 0f400c0..545426a 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -103,8 +103,6 @@ struct pv_cpu_ops {
unsigned long (*get_debugreg)(int regno);
void (*set_debugreg)(int regno, unsigned long value);
 
-   void (*clts)(void);
-
unsigned long (*read_cr0)(void);
void (*write_cr0)(unsigned long);
 
diff --git a/arch/x86/include/asm/special_insns.h 
b/arch/x86/include/asm/special_insns.h
index 29b417b..12af3e3 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -6,11 +6,6 @@
 
 #include 
 
-static inline void native_clts(void)
-{
-   asm volatile("clts");
-}
-
 /*
  * Volatile isn't enough to prevent the compiler from reordering the
  * read/write functions for the control registers and messing everything up.
@@ -208,12 +203,6 @@ static inline void load_gs_index(unsigned selector)
 
 #endif
 
-/* Clear the 'TS' bit */
-static inline void clts(void)
-{
-   native_clts();
-}
-
 #endif/* CONFIG_PARAVIRT */
 
 static inline void clflush(volatile void *__p)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index bbf3d59..a1bfba0 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -328,7 +328,6 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
.cpuid = native_cpuid,
.get_debugreg = native_get_debugreg,
.set_debugreg = native_set_debugreg,
-   .clts = native_clts,
.read_cr0 = native_read_cr0,
.write_cr0 = native_write_cr0,
.read_cr4 = native_read_cr4,
diff --git a/arch/x86/kernel/paravirt_patch_32.c 
b/arch/x86/kernel/paravirt_patch_32.c
index 920c6ae..d3f7f14 100644
--- a/arch/x86/kernel/paravirt_patch_32.c
+++ b/arch/x86/kernel/paravirt_patch_32.c
@@ -8,7 +8,6 @@ DEF_NATIVE(pv_cpu_ops, iret, "iret");
 DEF_NATIVE(pv_mmu_ops, read_cr2, "mov %cr2, %eax");
 DEF_NATIVE(pv_mmu_ops, write_cr3, "mov %eax, %cr3");
 DEF_NATIVE(pv_mmu_ops, read_cr3, "mov %cr3, %eax");
-DEF_NATIVE(pv_cpu_ops, clts, "clts");
 
 #if defined(CONFIG_PARAVIRT_SPINLOCKS)
 DEF_NATIVE(pv_lock_ops, queued_spin_unlock, "movb $0, (%eax)");
@@ -48,7 +47,6 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
PATCH_SITE(pv_mmu_ops, read_cr2);
PATCH_SITE(pv_mmu_ops, read_cr3);
PATCH_SITE(pv_mmu_ops, write_cr3);
-   PATCH_SITE(pv_cpu_ops, clts);
 #if defined(CONFIG_PARAVIRT_SPINLOCKS)
case PARAVIRT_PATCH(pv_lock_ops.queued_spin_unlock):

[tip:x86/fpu] x86/fpu: Stop saving and restoring CR0.TS in fpu__init_check_bugs()

[tip-bot for Andy Lutomirski]

Commit-ID:  fc560a80bac91e512fc37cdfe03a982ef4543c6b
Gitweb: http://git.kernel.org/tip/fc560a80bac91e512fc37cdfe03a982ef4543c6b
Author: Andy Lutomirski 
AuthorDate: Mon, 31 Oct 2016 15:18:43 -0700
Committer:  Ingo Molnar 
CommitDate: Tue, 1 Nov 2016 07:47:53 +0100

x86/fpu: Stop saving and restoring CR0.TS in fpu__init_check_bugs()

fpu__init_check_bugs() runs long after the early FPU init, so CR0.TS
will be clear by the time it runs.  The save-and-restore dance would
have been unnecessary anyway, though, as kernel_fpu_begin() would
have been good enough.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Rik van Riel 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: kvm list 
Link: 
http://lkml.kernel.org/r/76d1f1eacb5caead98197d1eb50ac6110ab20c6a.1477951965.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/fpu/bugs.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/x86/kernel/fpu/bugs.c b/arch/x86/kernel/fpu/bugs.c
index aad34aa..d913047 100644
--- a/arch/x86/kernel/fpu/bugs.c
+++ b/arch/x86/kernel/fpu/bugs.c
@@ -23,17 +23,12 @@ static double __initdata y = 3145727.0;
  */
 void __init fpu__init_check_bugs(void)
 {
-   u32 cr0_saved;
s32 fdiv_bug;
 
/* kernel_fpu_begin/end() relies on patched alternative instructions. */
if (!boot_cpu_has(X86_FEATURE_FPU))
return;
 
-   /* We might have CR0::TS set already, clear it: */
-   cr0_saved = read_cr0();
-   write_cr0(cr0_saved & ~X86_CR0_TS);
-
kernel_fpu_begin();
 
/*
@@ -56,8 +51,6 @@ void __init fpu__init_check_bugs(void)
 
kernel_fpu_end();
 
-   write_cr0(cr0_saved);
-
if (fdiv_bug) {
set_cpu_bug(_cpu_data, X86_BUG_FDIV);
pr_warn("Hmm, FPU with FDIV bug\n");

Re: [PATCHv6 08/11] i2c: match vendorless strings on the internal string length

[Lee Jones]

On Mon, 31 Oct 2016, Kieran Bingham wrote:
> On 31/10/16 13:55, Peter Rosin wrote:
> > On 2016-10-26 10:53, Lee Jones wrote:
> >> On Tue, 25 Oct 2016, Kieran Bingham wrote:
> >>
> >>> If a user provides a shortened string to match a device to the sysfs i2c
> >>> interface it will match on the first string that contains that string
> >>> prefix.
> >>>
> >>> for example:
> >>>   echo a 0x68 > /sys/bus/i2c/devices/i2c-2/new_device
> >>>
> >>> will match as3711, as3722, and ak8975 incorrectly.
> >>>
> >>> Signed-off-by: Kieran Bingham 
> >>
> >> Acked-by: Lee Jones 
> >>   
> >>> ---
> >>>  drivers/i2c/i2c-core.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> >>> index 01bce56f733a..50c9cfdb87b7 100644
> >>> --- a/drivers/i2c/i2c-core.c
> >>> +++ b/drivers/i2c/i2c-core.c
> >>> @@ -1708,7 +1708,7 @@ i2c_of_match_device_strip_vendor(const struct 
> >>> of_device_id *matches,
> >>>   else
> >>>   name++;
> >>>  
> >>> - if (!strncasecmp(client->name, name, strlen(client->name)))
> >>> + if (!strncasecmp(client->name, name, strlen(name)))
> >>>   return matches;
> >>>   }
> >>>  
> >>
> > 
> > Is that really so much better?
> 
> My original thought was that it verifies 'more' of the userspace input.
> but...
> 
> > With this patch
> > echo as3711CRAP 0x68 > /sys/...
> > will match as3711.
> >
> > What if there is some as37112 driver that is the real target?
> 
> You're right - It looks like the only way to do this correctly is to
> match the strncasecmp and the strlen of both strings.
> 
> So really we should be using sysfs_streq(). The only limitation there is
> that this original code was performing a case-insensitive compare.
> 
> Lee - Where did the requirement for case insensitive matching come from
> in your original code. Is it expected to be case-insensitive from the
> I2C sysfs interface? or are dt-nodes expected to be case-sensitive?

Compatible strings are always lower-case.

> Does anyone see reason that this shouldn't be using sysfs_streq()? or do
> we need a sysfs_strcaseeq()...

... but I don't see an issue with not being case sensitive.  Certainly
if it makes the logic easier/more consistent.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v3 00/11] pwm: imx: Provide atomic operation for IMX PWM driver

[Lukasz Majewski]

This patch set brings atomic operation to i.MX's PWMv2 driver.

This work has been supported and suggested by Boris Brezillon [1] and 
Stefan Agner, by showing how simple the transition could be :-).

It has been divided into several steps:

- Remove ipg clock enable/disable code (as proposed by Sascha Hauer) - this
  is the most notable change for v3

- Provide different pwm ops for PWMv1 and PWMv2

- Separate PWMv1 commits from "generic" and non atomic PWM code

  NOTE: Since I do _not_ have board with PWMv1, I would like to ask somebody
for testing

- Move some imx_config_v2 code to separate functions

- Provide PWM atomic implementation (the ->apply() driver) for PWMv2 in a
  single patch for better readability.

- Remove redundant PWM code (disable, enable, config callbacks)

- Update proper documentation entries

- Provide support for polarity inversion on top of atomic PWM rework

Test HW:

This patch set has been tested on i.MX6q board with
v4.9-rc3 kernel SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30


The PWM operation has been tested with pwm_bl backlight driver by changing
its brightness.

[1]: http://patchwork.ozlabs.org/patch/685402/


Lothar Wassmann (2):
  pwm: print error messages with pr_err() instead of pr_debug()
  pwm: core: make the PWM_POLARITY flag in DTB optional

Lukasz Majewski (8):
  pwm: imx: Add separate set of pwm ops for PWMv1 and PWMv2
  pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm
operation
  pwm: imx: Move PWMv2 software reset code to a separate function
  pwm: imx: Move PWMv2 wait for fifo slot code to a separate function
  pwm: imx: Provide atomic PWM support for i.MX PWMv2
  pwm: imx: Remove redundant i.MX PWMv2 code
  pwm: imx: doc: Update imx-pwm.txt documentation entry
  pwm: imx: Add polarity inversion support to i.MX's PWMv2

Sascha Hauer (1):
  pwm: imx: remove ipg clock

 Documentation/devicetree/bindings/pwm/imx-pwm.txt |   6 +-
 drivers/pwm/core.c|  26 +--
 drivers/pwm/pwm-imx.c | 247 ++
 3 files changed, 134 insertions(+), 145 deletions(-)

-- 
2.1.4

[PATCH v3 04/11] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

[Lukasz Majewski]

The code has been rewritten to remove "generic" calls to
imx_pwm_{enable|disable|config}.

Such approach would facilitate switch to atomic PWM (a.k.a ->apply())
implementation.

Suggested-by: Stefan Agner 
Suggested-by: Boris Brezillon 
Signed-off-by: Lukasz Majewski 
---
Changes for v3:
- Remove ipg clock

Changes for v2:
- Add missing clock unprepare for clk_ipg
- Enable peripheral PWM clock (clk_per)
---
 drivers/pwm/pwm-imx.c | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index d594501..8497902 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -64,8 +64,6 @@ struct imx_chip {
 static int imx_pwm_config_v1(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
 {
-   struct imx_chip *imx = to_imx_chip(chip);
-
/*
 * The PWM subsystem allows for exact frequencies. However,
 * I cannot connect a scope on my device to the PWM line and
@@ -83,6 +81,7 @@ static int imx_pwm_config_v1(struct pwm_chip *chip,
 * both the prescaler (/1 .. /128) and then by CLKSEL
 * (/2 .. /16).
 */
+   struct imx_chip *imx = to_imx_chip(chip);
u32 max = readl(imx->mmio_base + MX1_PWMP);
u32 p = max * duty_ns / period_ns;
writel(max - p, imx->mmio_base + MX1_PWMS);
@@ -90,19 +89,34 @@ static int imx_pwm_config_v1(struct pwm_chip *chip,
return 0;
 }
 
-static void imx_pwm_set_enable_v1(struct pwm_chip *chip, bool enable)
+static int imx_pwm_enable_v1(struct pwm_chip *chip, struct pwm_device *pwm)
 {
struct imx_chip *imx = to_imx_chip(chip);
+   int ret;
u32 val;
 
+   ret = clk_prepare_enable(imx->clk_per);
+   if (ret)
+   return ret;
+
val = readl(imx->mmio_base + MX1_PWMC);
+   val |= MX1_PWMC_EN;
+   writel(val, imx->mmio_base + MX1_PWMC);
 
-   if (enable)
-   val |= MX1_PWMC_EN;
-   else
-   val &= ~MX1_PWMC_EN;
+   return 0;
+}
+
+static void imx_pwm_disable_v1(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+   struct imx_chip *imx = to_imx_chip(chip);
+   u32 val;
+
+   val = readl(imx->mmio_base + MX1_PWMC);
+   val &= ~MX1_PWMC_EN;
 
writel(val, imx->mmio_base + MX1_PWMC);
+
+   clk_disable_unprepare(imx->clk_per);
 }
 
 static int imx_pwm_config_v2(struct pwm_chip *chip,
@@ -231,9 +245,9 @@ static void imx_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
 }
 
 static struct pwm_ops imx_pwm_ops_v1 = {
-   .enable = imx_pwm_enable,
-   .disable = imx_pwm_disable,
-   .config = imx_pwm_config,
+   .enable = imx_pwm_enable_v1,
+   .disable = imx_pwm_disable_v1,
+   .config = imx_pwm_config_v1,
.owner = THIS_MODULE,
 };
 
@@ -252,8 +266,6 @@ struct imx_pwm_data {
 };
 
 static struct imx_pwm_data imx_pwm_data_v1 = {
-   .config = imx_pwm_config_v1,
-   .set_enable = imx_pwm_set_enable_v1,
.pwm_ops = _pwm_ops_v1,
 };
 
-- 
2.1.4

[PATCH v3 03/11] pwm: imx: Add separate set of pwm ops for PWMv1 and PWMv2

[Lukasz Majewski]

This patch provides separate set of pwm ops utilized by
i.MX's PWMv1 and PWMv2.

Signed-off-by: Lothar Waßmann 
Signed-off-by: Bhuvanchandra DV 
Signed-off-by: Lukasz Majewski 
Acked-by: Shawn Guo 
Reviewed-by: Sascha Hauer 
---
Changes for v3:
- Adjust the code to work with ipg clock removed

Changes for v2:
- New patch
---
 drivers/pwm/pwm-imx.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index 70609ef2..d594501 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -230,7 +230,14 @@ static void imx_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
clk_disable_unprepare(imx->clk_per);
 }
 
-static struct pwm_ops imx_pwm_ops = {
+static struct pwm_ops imx_pwm_ops_v1 = {
+   .enable = imx_pwm_enable,
+   .disable = imx_pwm_disable,
+   .config = imx_pwm_config,
+   .owner = THIS_MODULE,
+};
+
+static struct pwm_ops imx_pwm_ops_v2 = {
.enable = imx_pwm_enable,
.disable = imx_pwm_disable,
.config = imx_pwm_config,
@@ -241,16 +248,19 @@ struct imx_pwm_data {
int (*config)(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns);
void (*set_enable)(struct pwm_chip *chip, bool enable);
+   struct pwm_ops *pwm_ops;
 };
 
 static struct imx_pwm_data imx_pwm_data_v1 = {
.config = imx_pwm_config_v1,
.set_enable = imx_pwm_set_enable_v1,
+   .pwm_ops = _pwm_ops_v1,
 };
 
 static struct imx_pwm_data imx_pwm_data_v2 = {
.config = imx_pwm_config_v2,
.set_enable = imx_pwm_set_enable_v2,
+   .pwm_ops = _pwm_ops_v2,
 };
 
 static const struct of_device_id imx_pwm_dt_ids[] = {
@@ -272,6 +282,8 @@ static int imx_pwm_probe(struct platform_device *pdev)
if (!of_id)
return -ENODEV;
 
+   data = of_id->data;
+
imx = devm_kzalloc(>dev, sizeof(*imx), GFP_KERNEL);
if (imx == NULL)
return -ENOMEM;
@@ -283,7 +295,7 @@ static int imx_pwm_probe(struct platform_device *pdev)
return PTR_ERR(imx->clk_per);
}
 
-   imx->chip.ops = _pwm_ops;
+   imx->chip.ops = data->pwm_ops;
imx->chip.dev = >dev;
imx->chip.base = -1;
imx->chip.npwm = 1;
@@ -294,7 +306,6 @@ static int imx_pwm_probe(struct platform_device *pdev)
if (IS_ERR(imx->mmio_base))
return PTR_ERR(imx->mmio_base);
 
-   data = of_id->data;
imx->config = data->config;
imx->set_enable = data->set_enable;
 
-- 
2.1.4

[PATCH v3 02/11] pwm: imx: remove ipg clock

[Lukasz Majewski]

From: Sascha Hauer 

The use of the ipg clock was introduced with commit 7b27c160c681
("pwm: i.MX: fix clock lookup").
In the commit message it was claimed that the ipg clock is enabled for
register accesses. This is true for the ->config() callback, but not
for the ->set_enable() callback. Given that the ipg clock is not
consistently enabled for all register accesses we can assume that either
it is not required at all or that the current code does not work.
Remove the ipg clock code for now so that it's no longer in the way of
refactoring the driver.

Signed-off-by: Sascha Hauer 
Cc: Philipp Zabel 
---
[commit message text refactored by Lukasz Majewski ]
---
Changes for v3:
- New patch
---
 drivers/pwm/pwm-imx.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index d600fd5..70609ef2 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -49,7 +49,6 @@
 
 struct imx_chip {
struct clk  *clk_per;
-   struct clk  *clk_ipg;
 
void __iomem*mmio_base;
 
@@ -204,17 +203,8 @@ static int imx_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm, int duty_ns, int period_ns)
 {
struct imx_chip *imx = to_imx_chip(chip);
-   int ret;
-
-   ret = clk_prepare_enable(imx->clk_ipg);
-   if (ret)
-   return ret;
 
-   ret = imx->config(chip, pwm, duty_ns, period_ns);
-
-   clk_disable_unprepare(imx->clk_ipg);
-
-   return ret;
+   return imx->config(chip, pwm, duty_ns, period_ns);
 }
 
 static int imx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
@@ -293,13 +283,6 @@ static int imx_pwm_probe(struct platform_device *pdev)
return PTR_ERR(imx->clk_per);
}
 
-   imx->clk_ipg = devm_clk_get(>dev, "ipg");
-   if (IS_ERR(imx->clk_ipg)) {
-   dev_err(>dev, "getting ipg clock failed with %ld\n",
-   PTR_ERR(imx->clk_ipg));
-   return PTR_ERR(imx->clk_ipg);
-   }
-
imx->chip.ops = _pwm_ops;
imx->chip.dev = >dev;
imx->chip.base = -1;
-- 
2.1.4

Re: [PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[Rafał Miłecki]

On 1 November 2016 at 08:24, John Heenan  wrote:
> @@ -5779,6 +5779,12 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>
> ret = 0;
>
> +   if(priv->fops == _fops) {

OK, let me be the first. Documentation/CodingStyle also says to use
space between "if" and "(" ;)


> @@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface 
> *interface,
> goto exit;
> }
>
> -   ret = rtl8xxxu_init_device(hw);
> -   if (ret)
> -   goto exit;
> +   if(priv->fops != _fops) {

Same here.

I reviewed style only.

-- 
Rafał

Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support

[Paul Bolle]

On Tue, 2016-11-01 at 00:48 +0100, Borislav Petkov wrote:
> --- a/drivers/lguest/Kconfig
> +++ b/drivers/lguest/Kconfig

>  config LGUEST
>   tristate "Linux hypervisor example code"
> - depends on X86_32 && EVENTFD && TTY && PCI_DIRECT
> > +   depends on X86_32 && EVENTFD && TTY && PCI_DIRECT && !MICROCODE
>   select HVC_DRIVER
>   ---help---
>     This is a very simple module which allows you to run

LGUEST is the symbol for host support. The symbol for guest support is
LGUEST_GUEST and it lives in arch/x86/. Yes, it's a bit of a gotcha.

> but maybe the better fix is to hack in MSR emulation in lguest and
> intercept the *MSR accesses and do the writes/reads in the exception
> fixup and ...
> 
> I haven't looked at the lguest code, of course and whether that's easily
> doable and whether it even makes sense and whether one should simply use
> qemu/kvm instead and, and, and...

Yeah, I thought about adding negative dependencies (eg, "!OLPC &&
!MICROCODE") too. But that would be contrary to the neat lguest goal to
be able to use the same kernel image as a host and a guest. At least, I
think that is one of its goals.

And as probably everybody capable of hacking on lguest (ie, other
people than me) came up with doubts similar to yours, these two issues
never got fixed.   

Thanks,


Paul Bolle

Re: [PATCH v10 05/19] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops

[Jike Song]

On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added two new callback functions to struct vfio_iommu_driver_ops. Backend
> IOMMU module that supports pining and unpinning pages for mdev devices
> should provide these functions.
> Added APIs for pining and unpining pages to VFIO module. These calls back
> into backend iommu module to actually pin and unpin pages.
> 
> Signed-off-by: Kirti Wankhede 
> Signed-off-by: Neo Jia 
> Change-Id: Ia7417723aaae86bec2959ad9ae6c2915ddd340e0
> ---
>  drivers/vfio/vfio.c  | 92 
> 
>  include/linux/vfio.h | 12 ++-
>  2 files changed, 103 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 2e83bdf007fe..28b50ca14c52 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1799,6 +1799,98 @@ void vfio_info_cap_shift(struct vfio_info_cap *caps, 
> size_t offset)
>  }
>  EXPORT_SYMBOL_GPL(vfio_info_cap_shift);
>  
> +
> +/*
> + * Pin a set of guest PFNs and return their associated host PFNs for local
> + * domain only.
> + * @dev [in] : device
> + * @user_pfn [in]: array of user/guest PFNs
> + * @npage [in]: count of array elements
> + * @prot [in] : protection flags
> + * @phys_pfn[out] : array of host PFNs
> + */

Hi Kirti,

Would you also add the documentation what the return value is? It's kind
not clear, and any reason to use long instead of int?

> +long vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
> + long npage, int prot, unsigned long *phys_pfn)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !user_pfn || !phys_pfn)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_pin_pages;
> +
> + container = group->container;
> + down_read(>group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->pin_pages))
> + ret = driver->ops->pin_pages(container->iommu_data, user_pfn,
> +  npage, prot, phys_pfn);
> + else
> + ret = -EINVAL;
> +
> + up_read(>group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_pin_pages:
> + vfio_group_put(group);
> + return ret;
> +
> +}
> +EXPORT_SYMBOL(vfio_pin_pages);
> +
> +/*
> + * Unpin set of host PFNs for local domain only.
> + * @dev [in] : device
> + * @pfn [in] : array of host PFNs to be unpinned.
> + * @npage [in] :count of elements in array, that is number of pages.
> + */

Ditto

--
Thanks,
Jike

> +long vfio_unpin_pages(struct device *dev, unsigned long *pfn, long npage)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
> + if (!dev || !pfn)
> + return -EINVAL;
> +
> + group = vfio_group_get_from_dev(dev);
> + if (IS_ERR(group))
> + return PTR_ERR(group);
> +
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + goto err_unpin_pages;
> +
> + container = group->container;
> + down_read(>group_lock);
> +
> + driver = container->iommu_driver;
> + if (likely(driver && driver->ops->unpin_pages))
> + ret = driver->ops->unpin_pages(container->iommu_data, pfn,
> +npage);
> + else
> + ret = -EINVAL;
> +
> + up_read(>group_lock);
> + vfio_group_try_dissolve_container(group);
> +
> +err_unpin_pages:
> + vfio_group_put(group);
> + return ret;
> +}
> +EXPORT_SYMBOL(vfio_unpin_pages);
> +
>  /**
>   * Module/class support
>   */
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 0ecae0b1cd34..0609a2052846 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -75,7 +75,11 @@ struct vfio_iommu_driver_ops {
>   struct iommu_group *group);
>   void(*detach_group)(void *iommu_data,
>   struct iommu_group *group);
> -
> + long(*pin_pages)(void *iommu_data, unsigned long *user_pfn,
> +  long npage, int prot,
> +  unsigned long *phys_pfn);
> + long(*unpin_pages)(void *iommu_data, unsigned long *pfn,
> +long npage);
>  };
>  
>  extern int vfio_register_iommu_driver(const struct vfio_iommu_driver_ops 
> *ops);
> @@ -127,6 +131,12 @@ static inline long vfio_spapr_iommu_eeh_ioctl(struct 
> iommu_group *group,
>  }
>  #endif /* CONFIG_EEH */
>  
> +extern long vfio_pin_pages(struct device *dev, unsigned long 

Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

[Lukasz Majewski]

Hi Sascha

> On Tue, Nov 01, 2016 at 06:57:23AM +0100, Lukasz Majewski wrote:
> > Hi Sascha,
> > 
> > > The current assumption as discussed by Philipp and me is that the
> > > ipg clk is only needed when the pwm output is driven by the ipg
> > > clk (MX3_PWMCR[16:17] = MX3_PWMCR_CLKSRC_IPG)
> > 
> > At least on my setup (i.MX6q) the ipg clock (ipg_clk) don't need to
> > be explicitly enabled in the ->apply() callback (in the pwm-imx.c)
> > when MX3_PWMCR_CLKSRC_IPG (0x01 - ipg_clk) is selected as the PWM
> > source.
> 
> No. If you look in the device tree you'll see that there is no special
> gateable ipg clock for the PWM. Instead the SoC ipg clock is
> registered for the PWM which is not gateable.

I do understand that the goal is to enable ipg clock only on demand
(when we access registers) and just wanted to say that the approach with
ipg enabled in dts works on my setup (and for now is sufficient).

I suppose that ipg gating support for PWM will be provided in a separate
patch.

> 
> Sascha
> 

Best regards,

Łukasz Majewski


pgpqQbDhKjZpq.pgp
Description: OpenPGP digital signature

Re: [PATCH v10 00/19] Add Mediated device support

[Jike Song]

On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> This series adds Mediated device support to Linux host kernel. Purpose
> of this series is to provide a common interface for mediated device
> management that can be used by different devices. This series introduces
> Mdev core module that creates and manages mediated devices, VFIO based
> driver for mediated devices that are created by mdev core module and
> update VFIO type1 IOMMU module to support pinning & unpinning for mediated
> devices.
> 
> What changed in v10?
> vfio:
>  - Split commits in multple individual commits.
>  - Removed the function added in v9 to get device_api string.
>  - Defined constant strings in include/uapi/linux/vfio.h that should be used 
> by
>vendor driver for device_api attribute.
> 
> vfio_iommu_type1:
>  - Fixed accounting when pass through device is unplugged while mdev device
>exist in a domain.
>  - Added blocking notifier to notify DMA_UNMAP to vendor driver to invalidate
>mappings.
>  - Exported APIs to register notifier for DMA_UNMAP action.
> 
> Documentation:
>  - Added sysfs ABI for mediated device framework.
>  - Updated Documentation/vfio-mdev/vfio-mediated-device.txt.
>  - Updated mtty.c with bug fixes.
> 
> Kirti Wankhede (19):
>   vfio: Mediated device Core driver
>   vfio: VFIO based driver for Mediated devices
>   vfio: Rearrange functions to get vfio_group from dev
>   vfio: Common function to increment container_users
>   vfio iommu: Added pin and unpin callback functions to
> vfio_iommu_driver_ops
>   vfio iommu type1: Update arguments of vfio_lock_acct
>   vfio iommu type1: Update argument of vaddr_get_pfn()
>   vfio iommu type1: Add find_iommu_group() function
>   vfio iommu type1: Add support for mediated devices
>   vfio iommu: Add blocking notifier to notify DMA_UNMAP
>   vfio: Introduce common function to add capabilities
>   vfio_pci: Update vfio_pci to use vfio_info_add_capability()
>   vfio: Introduce vfio_set_irqs_validate_and_prepare()
>   vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare()
>   vfio_platform: Updated to use vfio_set_irqs_validate_and_prepare()
>   vfio: Define device_api strings
>   docs: Add Documentation for Mediated devices
>   docs: Sysfs ABI for mediated device framework
>   docs: Sample driver to demonstrate how to use Mediated device
> framework.
> 
>  Documentation/ABI/testing/sysfs-bus-vfio-mdev|  111 ++
>  Documentation/vfio-mdev/Makefile |   13 +
>  Documentation/vfio-mdev/mtty.c   | 1503 
> ++
>  Documentation/vfio-mdev/vfio-mediated-device.txt |  398 ++
>  drivers/vfio/Kconfig |1 +
>  drivers/vfio/Makefile|1 +
>  drivers/vfio/mdev/Kconfig|   17 +
>  drivers/vfio/mdev/Makefile   |5 +
>  drivers/vfio/mdev/mdev_core.c|  384 ++
>  drivers/vfio/mdev/mdev_driver.c  |  122 ++
>  drivers/vfio/mdev/mdev_private.h |   41 +
>  drivers/vfio/mdev/mdev_sysfs.c   |  286 
>  drivers/vfio/mdev/vfio_mdev.c|  148 +++
>  drivers/vfio/pci/vfio_pci.c  |   78 +-
>  drivers/vfio/platform/vfio_platform_common.c |   31 +-
>  drivers/vfio/vfio.c  |  322 -
>  drivers/vfio/vfio_iommu_type1.c  |  808 ++--
>  include/linux/mdev.h |  167 +++
>  include/linux/vfio.h |   30 +-
>  include/uapi/linux/vfio.h|   10 +
>  20 files changed, 4270 insertions(+), 206 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-vfio-mdev
>  create mode 100644 Documentation/vfio-mdev/Makefile
>  create mode 100644 Documentation/vfio-mdev/mtty.c
>  create mode 100644 Documentation/vfio-mdev/vfio-mediated-device.txt
>  create mode 100644 drivers/vfio/mdev/Kconfig
>  create mode 100644 drivers/vfio/mdev/Makefile
>  create mode 100644 drivers/vfio/mdev/mdev_core.c
>  create mode 100644 drivers/vfio/mdev/mdev_driver.c
>  create mode 100644 drivers/vfio/mdev/mdev_private.h
>  create mode 100644 drivers/vfio/mdev/mdev_sysfs.c
>  create mode 100644 drivers/vfio/mdev/vfio_mdev.c
>  create mode 100644 include/linux/mdev.h

A side note:

I rebased KVMGT upon v10, with 2 minor changes:

1, get_user_pages_remote has only 7 args
2, vfio iommu notifier calls vendor callback with iova instead of pfn

so far it works pretty well. Thanks!

--
Thanks,
Jike

Re: [PATCH] x86/cpuid: expose AVX512_4VNNIW and AVX512_4FMAPS features to kvm guest

[Borislav Petkov]

On Tue, Nov 01, 2016 at 03:48:50PM +0800, He Chen wrote:
> Before sending a patch, let me check if my understanding is right...
> I will add a helper in scattered.c like:
> 
> unsigned int get_scattered_cpuid_features(unsigned int level,
>   unsigned int sub_leaf, enum cpuid_regs 
> reg)
> {
>   u32 val = 0;
>   const struct cpuid_bit *cb;
> 
>   for (cb = cpuid_bits; cb->feature; cb++) {

Right, we can improve that by keeping cpuid_bit.level sorted so that you
can break out early if the level is exceeded. For that please sort it
and add a comment stating that the leaf should be kept sorted ontop of
it.

And then you do something like this:

u32 get_scattered_cpuid_leaf(unsigned int level, unsigned int sub_leaf,
 enum cpuid_regs reg)
{
u32 cpuid_val = 0;

for (cb = cpuid_bits; cb->feature; cb++) {

if (level < cb->level)
continue;

if (level > cb->level)
break;

if (cb->reg == reg && sub_leaf == cb->sub_leaf) {
if (cpu_has(cb->feature))
cpuid_val |= BIT(cb->bit);
}
}

return cpuid_val;
}

Completely untested, of course.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

Re: [RFC][PATCH v2] mount: In propagate_umount handle overlapping mount propagation trees

[Andrei Vagin]

On Tue, Oct 25, 2016 at 04:45:44PM -0500, Eric W. Biederman wrote:
> Andrei Vagin  writes:
> >
> > From 8e0f45c0272aa1f789d1657a0acc98c58919dcc3 Mon Sep 17 00:00:00 2001
> > From: Andrei Vagin 
> > Date: Tue, 25 Oct 2016 13:57:31 -0700
> > Subject: [PATCH] mount: skip all mounts from a shared group if one is marked
> >
> > If we meet a marked mount, it means that all mounts from
> > its group have been already revised.
> >
> > Signed-off-by: Andrei Vagin 
> > ---
> >  fs/pnode.c | 18 +++---
> >  1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/pnode.c b/fs/pnode.c
> > index 8fd1a3f..ebb7134 100644
> > --- a/fs/pnode.c
> > +++ b/fs/pnode.c
> > @@ -426,10 +426,16 @@ static struct mount *propagation_visit_child(struct 
> > mount *last_child,
> > if (child && !IS_MNT_MARKED(child))
> > return child;
> >  
> > -   if (!child)
> > +   if (!child) {
> > m = propagation_next(m, origin);
> > -   else
> > +   } else {
> > +   if (IS_MNT_MARKED(child)) {
> > +   if (m->mnt_group_id == origin->mnt_group_id)
> > +   return NULL;
> > +   m = m->mnt_master;
> > +   }
> > m = propagation_next_sib(m, origin);
> > +   }
> > }
> > return NULL;
> >  }
> > @@ -456,8 +462,14 @@ static struct mount *propagation_revisit_child(struct 
> > mount *last_child,
> >  
> > if (!child)
> > m = propagation_next(m, origin);
> > -   else
> > +   else {
> > +   if (!IS_MNT_MARKED(child)) {
> > +   if (m->mnt_group_id == origin->mnt_group_id)
> > +   return NULL;
> > +   m = m->mnt_master;
> > +   }
> > m = propagation_next_sib(m, origin);
> > +   }
> > }
> > return NULL;
> >  }
> 
> That is certainly interesting.  The problem is that the reason we were
> going slow is that there were in fact mounts that had not been traversed
> in the share group.
> 
> And in fact the entire idea of visiting a vfsmount mountpoint pair
> exactly once is wrong in the face of shadow mounts.  For a vfsmount
> mountpoint pair that has shadow mounts the number of shadow mounts needs
> to be descreased by one each time the propgation tree is traversed
> during unmount. Which means that as far as I can see we have to kill
> shadow mounts to correctly optimize this code.  Once shadow mounts are
> gone I don't know of a case where need your optimization.

I am not sure that now shadow mounts are worked as you described
here. start_umount_propagation() doesn't remove a mount from mnt_hash,
so in a second time we will look up the same mount again.

Look at this script:

[root@fc24 mounts]# cat ./opus02.sh
set -e
mkdir -p /mnt
mount -t tmpfs zdtm /mnt
mkdir -p /mnt/A/a
mkdir -p /mnt/B/a
mount --bind --make-shared /mnt/A /mnt/A
mount --bind /mnt/A /mnt/B
mount --bind /mnt/A/a /mnt/A/a
mount --bind /mnt/A/a /mnt/A/a

umount -l /mnt/A
cat /proc/self/mountinfo | grep zdtm

[root@fc24 mounts]# unshare --propagation private -m ./opus02.sh
159 121 0:46 / /mnt rw,relatime - tmpfs zdtm rw
162 159 0:46 /A /mnt/B rw,relatime shared:67 - tmpfs zdtm rw
167 162 0:46 /A/a /mnt/B/a rw,relatime shared:67 - tmpfs zdtm rw

We mount nothing into /mnt/B, but when we umount everything from A, we
still have something in B.

Thanks,
Andrei
> 
> I am busily verifying my patch to kill shadow mounts but the following
> patch is the minimal version.  As far as I can see propagate_one
> is the only place we create shadow mounts, and holding the
> namespace_lock over attach_recursive_mnt, propagate_mnt, and
> propgate_one is sufficient for that __lookup_mnt to be competely safe.
> 
> diff --git a/fs/pnode.c b/fs/pnode.c
> index 234a9ac49958..b14119b370d4 100644
> --- a/fs/pnode.c
> +++ b/fs/pnode.c
> @@ -217,6 +217,9 @@ static int propagate_one(struct mount *m)
> /* skip if mountpoint isn't covered by it */
> if (!is_subdir(mp->m_dentry, m->mnt.mnt_root))
> return 0;
> +   /* skip if mountpoint already has a mount on it */
> +   if (__lookup_mnt(>mnt, mp->m_dentry))
> +   return 0;
> if (peers(m, last_dest)) {
> type = CL_MAKE_SHARED;
> } else {
> 
> If you run with that patch you will see that there are go faster stripes.
> 
> Eric
> 

Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

[Sascha Hauer]

On Mon, Oct 31, 2016 at 10:29:37AM +0100, Sascha Hauer wrote:
> > accesses. This is true for the ->config() callback, but not for the
> > ->set_enable() callback. Given that the ipg clock is not consistently
> > enabled for all register accesses we can assume that either it is not
> > required at all or that the current code does not work.
> > Remove the ipg clock code for now so that it's no longer in the way of
> > refactoring the driver.
> 
> For reference:
> 
> I verified on i.MX53 and i.MX25 that the ipg clock provided to the pwm
> driver is not needed when accessing registers. I would have to verify
> that on i.MX27 aswell, but I do not have a board handy at the moment.

Also on i.MX27 disabling the PWMs ipg_clk does not disable register
accesses.

Sascha

> 
> The current assumption as discussed by Philipp and me is that the ipg
> clk is only needed when the pwm output is driven by the ipg clk
> (MX3_PWMCR[16:17] = MX3_PWMCR_CLKSRC_IPG)
> 
> Sascha
> 
> -- 
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH] mfd: stmpe: Fix RESET regression on STMPE2401

[Linus Walleij]

Since commit c4dd1ba355aae2bc3d1213da6c66c53e3c31e028
("mfd: stmpe: Add reset support for all STMPE variant")
we're resetting the STMPE expanders before use.

This caused a regression on the STMP2401 on the Nomadik
NHK8815:

stmpe-i2c 0-0043: stmpe2401 detected, chip id: 0x101
nmk-i2c 101f8000.i2c0: write to slave 0x43 timed out
nmk-i2c 101f8000.i2c0: no ack received after address transmission
stmpe-i2c 0-0044: stmpe2401 detected, chip id: 0x101
nmk-i2c 101f8000.i2c0: write to slave 0x44 timed out
nmk-i2c 101f8000.i2c0: no ack received after address transmission

It turns out that we start to poll for the reset bit to
go low again too quickly: the STMPE2401 is not yet online and
ready to be asked for the status of the RESET bit.

By introducing a 10ms delay before starting to hammer
the register for information, we get back to normal:

stmpe-i2c 0-0043: stmpe2401 detected, chip id: 0x101
stmpe-i2c 0-0044: stmpe2401 detected, chip id: 0x101

Cc: sta...@vger.kernel.org
Cc: Patrice Chotard 
Cc: Amelie Delaunay 
Cc: Lee Jones 
Fixes: c4dd1ba355aa ("mfd: stmpe: Add reset support for all STMPE variant")
Signed-off-by: Linus Walleij 
---
 drivers/mfd/stmpe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index cfdae8a3d779..b0c7bcdaf5df 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -851,6 +851,8 @@ static int stmpe_reset(struct stmpe *stmpe)
if (ret < 0)
return ret;
 
+   msleep(10);
+
timeout = jiffies + msecs_to_jiffies(100);
while (time_before(jiffies, timeout)) {
ret = __stmpe_reg_read(stmpe, stmpe->regs[STMPE_IDX_SYS_CTRL]);
-- 
2.7.4

Re: [PATCH 3/4] MIPS: Fix ISA I/II FP signal context offsets

[Paul Burton]

On Monday, 31 October 2016 16:27:01 GMT Maciej W. Rozycki wrote:
> Fix a regression introduced with commit 2db9ca0a3551 ("MIPS: Use struct
> mips_abi offsets to save FP context") for MIPS I/I FP signal contexts,
> by converting save/restore code to the updated internal API.  Start FGR
> offsets from 0 rather than SC_FPREGS from $a0 and use $a1 rather than
> the offset of SC_FPC_CSR from $a0 for the Floating Point Control/Status
> Register (FCSR).
> 
> Document the new internal API and adjust assembly code formatting for
> consistency.
> 
> Signed-off-by: Maciej W. Rozycki 
> ---
> linux-mips-isa12-sig-fp-context-offsets.patch
> Index: linux-sfr-test/arch/mips/kernel/r2300_fpu.S
> ===
> --- linux-sfr-test.orig/arch/mips/kernel/r2300_fpu.S  2016-10-22
> 02:28:09.266462000 +0100 +++
> linux-sfr-test/arch/mips/kernel/r2300_fpu.S   2016-10-22 02:29:01.523906000
> +0100 @@ -26,97 +26,104 @@
> 
>   .setnoreorder
>   .setmips1
> - /* Save floating point context */
> +
> +/**
> + * _save_fp_context() - save FP context from the FPU
> + * @a0 - pointer to fpregs field of sigcontext
> + * @a1 - pointer to fpc_csr field of sigcontext
> + *
> + * Save FP context, including the 32 FP data registers and the FP
> + * control & status register, from the FPU to signal context.
> + */
>  LEAF(_save_fp_context)
>   .setpush
>   SET_HARDFLOAT
>   li  v0, 0   # assume success
> - cfc1t1,fcr31
> - EX(swc1 $f0,(SC_FPREGS+0)(a0))
> - EX(swc1 $f1,(SC_FPREGS+8)(a0))
> - EX(swc1 $f2,(SC_FPREGS+16)(a0))
> - EX(swc1 $f3,(SC_FPREGS+24)(a0))
> - EX(swc1 $f4,(SC_FPREGS+32)(a0))
> - EX(swc1 $f5,(SC_FPREGS+40)(a0))
> - EX(swc1 $f6,(SC_FPREGS+48)(a0))
> - EX(swc1 $f7,(SC_FPREGS+56)(a0))
> - EX(swc1 $f8,(SC_FPREGS+64)(a0))
> - EX(swc1 $f9,(SC_FPREGS+72)(a0))
> - EX(swc1 $f10,(SC_FPREGS+80)(a0))
> - EX(swc1 $f11,(SC_FPREGS+88)(a0))
> - EX(swc1 $f12,(SC_FPREGS+96)(a0))
> - EX(swc1 $f13,(SC_FPREGS+104)(a0))
> - EX(swc1 $f14,(SC_FPREGS+112)(a0))
> - EX(swc1 $f15,(SC_FPREGS+120)(a0))
> - EX(swc1 $f16,(SC_FPREGS+128)(a0))
> - EX(swc1 $f17,(SC_FPREGS+136)(a0))
> - EX(swc1 $f18,(SC_FPREGS+144)(a0))
> - EX(swc1 $f19,(SC_FPREGS+152)(a0))
> - EX(swc1 $f20,(SC_FPREGS+160)(a0))
> - EX(swc1 $f21,(SC_FPREGS+168)(a0))
> - EX(swc1 $f22,(SC_FPREGS+176)(a0))
> - EX(swc1 $f23,(SC_FPREGS+184)(a0))
> - EX(swc1 $f24,(SC_FPREGS+192)(a0))
> - EX(swc1 $f25,(SC_FPREGS+200)(a0))
> - EX(swc1 $f26,(SC_FPREGS+208)(a0))
> - EX(swc1 $f27,(SC_FPREGS+216)(a0))
> - EX(swc1 $f28,(SC_FPREGS+224)(a0))
> - EX(swc1 $f29,(SC_FPREGS+232)(a0))
> - EX(swc1 $f30,(SC_FPREGS+240)(a0))
> - EX(swc1 $f31,(SC_FPREGS+248)(a0))
> + cfc1t1, fcr31
> + EX(swc1 $f0, 0(a0))
> + EX(swc1 $f1, 8(a0))
> + EX(swc1 $f2, 16(a0))
> + EX(swc1 $f3, 24(a0))
> + EX(swc1 $f4, 32(a0))
> + EX(swc1 $f5, 40(a0))
> + EX(swc1 $f6, 48(a0))
> + EX(swc1 $f7, 56(a0))
> + EX(swc1 $f8, 64(a0))
> + EX(swc1 $f9, 72(a0))
> + EX(swc1 $f10, 80(a0))
> + EX(swc1 $f11, 88(a0))
> + EX(swc1 $f12, 96(a0))
> + EX(swc1 $f13, 104(a0))
> + EX(swc1 $f14, 112(a0))
> + EX(swc1 $f15, 120(a0))
> + EX(swc1 $f16, 128(a0))
> + EX(swc1 $f17, 136(a0))
> + EX(swc1 $f18, 144(a0))
> + EX(swc1 $f19, 152(a0))
> + EX(swc1 $f20, 160(a0))
> + EX(swc1 $f21, 168(a0))
> + EX(swc1 $f22, 176(a0))
> + EX(swc1 $f23, 184(a0))
> + EX(swc1 $f24, 192(a0))
> + EX(swc1 $f25, 200(a0))
> + EX(swc1 $f26, 208(a0))
> + EX(swc1 $f27, 216(a0))
> + EX(swc1 $f28, 224(a0))
> + EX(swc1 $f29, 232(a0))
> + EX(swc1 $f30, 240(a0))
> + EX(swc1 $f31, 248(a0))
>   jr  ra
> -  EX(sw  t1,(SC_FPC_CSR)(a0))
> +  EX(sw  t1, (a1))
>   .setpop
>   END(_save_fp_context)
> 
> -/*
> - * Restore FPU state:
> - *  - fp gp registers
> - *  - cp1 status/control register
> +/**
> + * _restore_fp_context() - restore FP context to the FPU
> + * @a0 - pointer to fpregs field of sigcontext
> + * @a1 - pointer to fpc_csr field of sigcontext
>   *
> - * We base the decision which registers to restore from the signal stack
> - * frame on the current content of c0_status, not on the content of the
> - * stack frame which might have been changed by the user.
> + * Restore FP context, including the 32 FP data registers and the FP
> + * control & status register, from signal context to the FPU.
>   */
>  LEAF(_restore_fp_context)
>   .setpush
>   SET_HARDFLOAT
>   li  v0, 0   # assume success
> - EX(lw t0,(SC_FPC_CSR)(a0))
> - EX(lwc1 $f0,(SC_FPREGS+0)(a0))
> - EX(lwc1 $f1,(SC_FPREGS+8)(a0))
> - EX(lwc1 $f2,(SC_FPREGS+16)(a0))
> - EX(lwc1 $f3,(SC_FPREGS+24)(a0))
> - EX(lwc1 

Re: [PATCH] staging: vc04_services: setup DMA and coherent mask

[Russell King - ARM Linux]

On Mon, Oct 31, 2016 at 12:53:13PM -0700, Michael Zoran wrote:
> On Mon, 2016-10-31 at 11:40 -0700, Michael Zoran wrote:
> > The comment is easy to change.
> > 
> > I don't have the log available ATM, but if I remember the DMA API's
> > bugcheck the first time that are used.  
> > 
> > I think this was a policy decision or something because the
> > information
> > should be available in the dma-ranges.
> > 
> > If it's important, I can setup a test again without the change and e-
> > mail the logs.
> > 
> > If you look at the DWC2 driver you will see that it also sets this
> > mask.
> 
> OK, I'm begging to understand this.  It appears the architecture
> specific paths are very different.
> 
> In arm the mask and coherent is set to DMA_BIT_MASK(32) in mm/dma-
> mapping.c the first time the dma APIs are used.

I'm not sure where you get that from, this is absolutely not the case.

>  On arm64, it appears
> this variable is uninitialized and will contain random crude.
> 
> Like I said, I don't know if this is a policy decision or if it just
> slipped through the cracks.
> 
> arch/arm/mm/dma-mapping.c(Note the call to get_coherent_dma_mask(dev))
> 
> static u64 get_coherent_dma_mask(struct device *dev)
> {
>   u64 mask = (u64)DMA_BIT_MASK(32);
> 
>   if (dev) {
>   mask = dev->coherent_dma_mask;
> 
>   /*
>    * Sanity check the DMA mask - it must be non-zero, and
>    * must be able to be satisfied by a DMA allocation.
>    */
>   if (mask == 0) {
>   dev_warn(dev, "coherent DMA mask is unset\n");
>   return 0;

If the mask is unset (iow, zero) this function returns zero.  There
is no "the first time" here anywhere - dev->coherent_dma_mask remains
at zero and doesn't change as a result of calling this path.

>   }
> 
>   if (!__dma_supported(dev, mask, true))
>   return 0;
>   }
> 
>   return mask;
> }
> 
> static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t
> *handle,
>    gfp_t gfp, pgprot_t prot, bool is_coherent,
>    unsigned long attrs, const void *caller)
> {
>   u64 mask = get_coherent_dma_mask(dev);
>   struct page *page = NULL;
>   void *addr;
>   bool allowblock, cma;
>   struct arm_dma_buffer *buf;
>   struct arm_dma_alloc_args args = {
>   .dev = dev,
>   .size = PAGE_ALIGN(size),
>   .gfp = gfp,
>   .prot = prot,
>   .caller = caller,
>   .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) ==
> 0),
>   .coherent_flag = is_coherent ? COHERENT : NORMAL,
>   };

which then causes:

if (!mask)
return NULL;

this function to return NULL, hence failing the request.  Rightfully
so, because we don't know what an acceptable allocation for the device
would be, as the device is effectively saying "I support 0 bits of DMA
address."

Now, firstly, the driver is required to call one of:

dma_set_mask_and_coherent()
dma_set_coherent_mask()

if it is to use coherent DMA - see Documentation/DMA-API-HOWTO.txt.
However, the bus code should already have setup a default mask in both
dev->dma_mask and the coherent DMA mask if DMA is possible, which
normally will be the 32-bit mask.

As explained in the document, if the device and driver supports 64-bit
addressing, and wants to make use of it, it must successfully negotiate
with the kernel before using it, which includes making calls to change
the DMA masks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v8: 2/4] x86/elf: Use HWCAP2 to expose ring 3 MWAIT

[Grzegorz Andrejczuk]

Add HWCAP2 for x86 and reserve its bit 0 to expose
ring 3 mwait.

Signed-off-by: Grzegorz Andrejczuk 
---
 arch/x86/include/asm/elf.h | 9 +
 arch/x86/include/uapi/asm/hwcap2.h | 7 +++
 arch/x86/kernel/cpu/common.c   | 3 +++
 3 files changed, 19 insertions(+)
 create mode 100644 arch/x86/include/uapi/asm/hwcap2.h

diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index e7f155c..59703aa 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -258,6 +258,15 @@ extern int force_personality32;
 
 #define ELF_HWCAP  (boot_cpu_data.x86_capability[CPUID_1_EDX])
 
+extern unsigned int elf_hwcap2;
+
+/*
+ * HWCAP2 supplies mask with kernel enabled CPU features, so that
+ * the application can discover that it can safely use them.
+ * The bits are defined in uapi/asm/hwcap2.h.
+ */
+#define ELF_HWCAP2 elf_hwcap2
+
 /* This yields a string that ld.so will use to load implementation
specific libraries for optimization.  This is more specific in
intent than poking at uname or /proc/cpuinfo.
diff --git a/arch/x86/include/uapi/asm/hwcap2.h 
b/arch/x86/include/uapi/asm/hwcap2.h
new file mode 100644
index 000..9e7c117
--- /dev/null
+++ b/arch/x86/include/uapi/asm/hwcap2.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_HWCAP2_H
+#define _ASM_HWCAP2_H
+
+/* Kernel enabled Ring 3 MWAIT for Xeon Phi*/
+#define HWCAP2_RING3MWAIT  (1 << 0)
+
+#endif
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index bcc9ccc..fdbf708 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,8 @@
 
 #include "cpu.h"
 
+unsigned int elf_hwcap2 __read_mostly;
+
 /* all of these masks are initialized in setup_cpu_local_masks() */
 cpumask_var_t cpu_initialized_mask;
 cpumask_var_t cpu_callout_mask;
-- 
2.5.1

[PATCH v8: 4/4] x86/cpufeatures: Handle RING3MWAIT on Xeon Phi models

[Grzegorz Andrejczuk]

Unfortunately presence of this feature cannot be detected
automatically (by reading some other MSR) therefore it is required
to do explicit check for the family and model of the cpu.

If processor is Intel Xeon Phi x200 RING3MWAIT feature is enabled
by setting cpu cap X86_FEATURE_PHIR3MWAIT and elf HWCAP2_RING3MWAIT.

Signed-off-by: Grzegorz Andrejczuk 
---
 Documentation/kernel-parameters.txt   |  5 
 Documentation/x86/x86_64/boot-options.txt |  5 
 arch/x86/kernel/cpu/intel.c   | 39 +++
 3 files changed, 49 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index a4f4d69..7754310 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3120,6 +3120,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
pg. [PARIDE]
See Documentation/blockdev/paride.txt.
 
+   phir3mwait= [X86-64] Do not enable Intel Xeon Phi x200 ring 3 
MONITOR/MWAIT
+   feature for all cpus.
+   Format: { disable }
+   See Documentation/x86/x86_64/boot-options.txt
+
pirq=   [SMP,APIC] Manual mp-table setup
See Documentation/x86/i386/IO-APIC.txt.
 
diff --git a/Documentation/x86/x86_64/boot-options.txt 
b/Documentation/x86/x86_64/boot-options.txt
index 0965a71..1a515e8 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -281,6 +281,11 @@ Debugging
 
   kstack=N Print N words from the kernel stack in oops dumps.
 
+  phir3mwait=disable
+  Disables unconditional setting bit 1 of the MSR_MISC_FEATURE_ENABLES
+  for Intel Xeon Phi, this way administrator can switch off ring 3 mwait
+  feature.
+
 Miscellaneous
 
nogbpages
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fcd484d..670dd98 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -61,6 +63,41 @@ void check_mpx_erratum(struct cpuinfo_x86 *c)
}
 }
 
+#ifdef CONFIG_X86_64
+static int phi_r3mwait_disabled __read_mostly;
+
+static int __init phir3mwait_disable(char *__unused)
+{
+   phi_r3mwait_disabled = 1;
+   return 1;
+}
+__setup("phir3mwait=disable", phir3mwait_disable);
+
+static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *c)
+{
+   /*
+* Rign 3 MWAIT feature cannot be detected without
+* ugly model and family comparison.
+*/
+   if (c->x86 != 6 || c->x86_model != INTEL_FAM6_XEON_PHI_KNL)
+   return;
+
+   if (phi_r3mwait_disabled) {
+   msr_clear_bit(MSR_MISC_FEATURE_ENABLES,
+ MSR_MISC_FEATURE_ENABLES_PHIR3MWAIT_BIT);
+   return;
+   }
+
+   msr_set_bit(MSR_MISC_FEATURE_ENABLES,
+   MSR_MISC_FEATURE_ENABLES_PHIR3MWAIT_BIT);
+   set_cpu_cap(c, X86_FEATURE_PHIR3MWAIT);
+   ELF_HWCAP2 |= HWCAP2_RING3MWAIT;
+}
+
+#else
+static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *__unused) {}
+#endif
+
 static void early_init_intel(struct cpuinfo_x86 *c)
 {
u64 misc_enable;
@@ -565,6 +602,8 @@ static void init_intel(struct cpuinfo_x86 *c)
detect_vmx_virtcap(c);
 
init_intel_energy_perf(c);
+
+   probe_xeon_phi_r3mwait(c);
 }
 
 #ifdef CONFIG_X86_32
-- 
2.5.1

Re: [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver

[Sekhar Nori]

On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
> 
> Signed-off-by: Bartosz Golaszewski 

Reviewed-by: Sekhar Nori 

Thanks,
Sekhar

Re: [PREEMPT-RT] Oops in rapl_cpu_prepare()

[M. Vefa Bicakci]

> On 2016-10-27 15:00:32 [-0400], Charles (Chas) Williams wrote:
>>
>> [snip]
>>
>> But sometimes the topology info is correct and if I get lucky, the
>> package id could be valid for all the CPU's.  Given the behavior,
>> I have seen so far it makes me thing the RAPL isn't being emulated.
>> So even if I did boot onto a "valid" set of cores, would I always be
>> certain that I will be on those cores?
> 
> I don't what vmware does here. Nor do they ship source to check. So if
> you have a big HW box with say two packages, it might make sense to give
> this information to the guest _if_ the CPUs are pinned and the guest
> never migrates.
> 
>> Per your request in your next email:
>> 
>> > One thing I forgot to ask: Could you please check if you get the same
>> > pkgid reported for cpu 0-3 on a pre-v4.8 kernel? (before the hotplug
>> > rework).
>> 
>> Our previous kernel was 4.4, and didn't use the logical package id:
>
> I see.
> 
> Did the patch I sent fixed it for you and were you not able to test?

Hello Sebastian,

The patch fixes the kernel oops for me.

I am using a custom 4.8.5-based kernel on Qubes OS R3.2, which is based
on Xen 4.6.3. Apparently, Xen also has a similar bug/flaw/quirk regarding
the allocation of package identifiers for the virtual CPUs.

Prior to your patch, my Xen-based virtual machines would intermittently
crash most of the time at boot-up with the backtrace reported by Charles.
Due to this, I was under the impression that this is a subtle race
condition.

With your patch, the virtual machines boot-up successfully, all the time.
Here are the relevant excerpts from dmesg:

=== 8< ===
[0.263936] RAPL PMU: rapl pmu error: max package: 1 but CPU0 belongs to 
65535
...
[2.213669] intel_rapl: Found RAPL domain package
[2.213689] intel_rapl: Found RAPL domain core
[2.216337] intel_rapl: Found RAPL domain uncore
[2.216370] intel_rapl: RAPL package 0 domain package locked by BIOS
=== >8 ===

Thank you,

Vefa

Please note: I am not subscribed to the Linux kernel mailing list, so
I had to manually construct the headers of this reply with the proper
In-Reply-To and References values (which were extracted from marc.info).
As a result, this e-mail may not show up as a reply to your earlier
conversation with Charles.

[PATCH] mfd: core: fix device reference leak in mfd_clone_cell

[Johan Hovold]

Make sure to drop the reference taken by bus_find_device_by_name()
before returning from mfd_clone_cell().

Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd")
Signed-off-by: Johan Hovold 
---
 drivers/mfd/mfd-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 3ac486a597f3..c57e407020f1 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -399,6 +399,8 @@ int mfd_clone_cell(const char *cell, const char **clones, 
size_t n_clones)
clones[i]);
}
 
+   put_device(dev);
+
return 0;
 }
 EXPORT_SYMBOL(mfd_clone_cell);
-- 
2.7.3

[PATCH] stm class: fix device leak in open error path

[Johan Hovold]

Make sure to drop the reference taken by class_find_device() also on
allocation errors in open().

Fixes: 7bd1d4093c2f ("stm class: Introduce an abstraction for...")
Signed-off-by: Johan Hovold 
---
 drivers/hwtracing/stm/core.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 51f81d64ca37..47811f5c9bc9 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -368,8 +368,10 @@ static int stm_char_open(struct inode *inode, struct file 
*file)
return -ENODEV;
 
stmf = kzalloc(sizeof(*stmf), GFP_KERNEL);
-   if (!stmf)
-   return -ENOMEM;
+   if (!stmf) {
+   err = -ENOMEM;
+   goto err_put_device;
+   }
 
stm_output_init(>output);
stmf->stm = to_stm_device(dev);
@@ -382,9 +384,10 @@ static int stm_char_open(struct inode *inode, struct file 
*file)
return nonseekable_open(inode, file);
 
 err_free:
+   kfree(stmf);
+err_put_device:
/* matches class_find_device() above */
put_device(dev);
-   kfree(stmf);
 
return err;
 }
-- 
2.7.3

[PATCH 2/2] of/platform: clarify of_find_device_by_node refcounting

[Johan Hovold]

Add comment clarifying that of_find_device_by_node() takes a reference
to the embedded struct device which needs to be dropped after use.

Note that most current users fail to do so.

Signed-off-by: Johan Hovold 
---
 drivers/of/platform.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index cb4c7800f37d..b8064bc2b6eb 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -45,6 +45,9 @@ static int of_dev_node_match(struct device *dev, void *data)
  * of_find_device_by_node - Find the platform_device associated with a node
  * @np: Pointer to device tree node
  *
+ * Takes a reference to the embedded struct device which needs to be dropped
+ * after use.
+ *
  * Returns platform_device pointer, or NULL if not found
  */
 struct platform_device *of_find_device_by_node(struct device_node *np)
-- 
2.7.3

RE: [PATCH v3 3/3] clocksource: Add clockevent support to NPS400 driver

[Noam Camus]

> From: Thomas Gleixner [mailto:t...@linutronix.de] 
> Sent: Monday, October 31, 2016 8:13 PM

>>  
>> -static unsigned long nps_timer_rate;
>> +static unsigned long nps_timer1_freq;

>This should be either in the previous patch or seperate.
Will fix in V4



>> @@ -101,3 +101,215 @@ static int __init nps_setup_clocksource(struct 
>> device_node *node)
>>  
>>  CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
>> nps_setup_clocksource);
>> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
>> +   nps_setup_clocksource);

>What's the point of this change?
I do this as preparation for next patch where we use timer0 for clockevent 
while timer1 is kept for clocksource. 
I realize that it is not aligned with binding document, so I will move this to 
next patch.

>> +/*
>> + * Arm the timer to interrupt after @cycles  */ static void 
>> +nps_clkevent_timer_event_setup(unsigned int cycles) {
>> +write_aux_reg(NPS_REG_TIMER0_LIMIT, cycles);
>> +write_aux_reg(NPS_REG_TIMER0_CNT, 0);   /* start from 0 */

>Please do not use tail comments. They break the reading flow.
Will fix in V4

>> +
>> +write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_IE | TIMER0_CTRL_NH); 
>> +}
>> +
>> +static void nps_clkevent_rm_thread(bool remove_thread)

>I have a hard time to understand why a remove_thread function needs a 
>remove_thread boolean argument. Commenting things like this would be more 
>helpful than commenting the obvious.
Sorry for that, will be commented in V4

>> +{
>> +unsigned int cflags;
>> +unsigned int enabled_threads;
>>+ unsigned long flags;
>> +int thread;
>> +
>> +local_irq_save(flags);

>That's pointless. Both call sites have interrupts disabled.
Will be fixed in V4

...
>> +
>> +static void nps_clkevent_add_thread(bool set_event) {
>> +int thread;
>> +unsigned int cflags, enabled_threads;
>> +unsigned long flags;
>> +
>> +local_irq_save(flags);

>Ditto.
Will be removed as well at V4

...

>> +static int nps_clkevent_set_next_event(unsigned long delta,
>> +   struct clock_event_device *dev) {
>> +struct irq_desc *desc = irq_to_desc(nps_timer0_irq);
>> +struct irq_chip *chip = irq_data_get_irq_chip(>irq_data);
>> +
>> +nps_clkevent_add_thread(true);
>> +chip->irq_unmask(>irq_data);

>Oh no. You are not supposed to fiddle in the guts of the interrupts from a 
>random driver. Can you please explain what you are trying to do and why >the 
>existing interfaces are not sufficient?
This function is assigned and used by several hooks at clock_event_device type.
Main purpose is to support oneshot timer mode and in general support NOHZ_FULL 
and finally TASK_ISOLATION.
The idea for this is borrowed from arch/tile timer driver that just like us 
aiming to support the TASK_ISOLATION.
Will it be better to replace these with 
irq_percpu_enable()/irq_percpu_disable() which seem to achieve quiet the same 
affect?
...

>> +static int nps_clkevent_set_periodic(struct clock_event_device *dev) 
>> +{
>> +nps_clkevent_add_thread(false);
>> +if (read_aux_reg(CTOP_AUX_THREAD_ID) == 0)
>> +nps_clkevent_timer_event_setup(nps_timer0_freq / HZ);

>So how is that enabling interrupts again?
I guess that in our system we never switch back to periodic.
Time infrastructure starts as periodic (I set CLOCK_EVT_FEAT_PERIODIC) and when 
timer is ready
state is switched to oneshot mode and never goes back to periodic.
I might be missing here, but couldn't find any place where 
CLOCK_EVT_STATE_PERIODIC is set but in tick_setup_periodic().
Should I call here to enable interrupts anyway?

>> +
>> +static irqreturn_t timer_irq_handler(int irq, void *dev_id) {
>> +/*
>> + * Note that generic IRQ core could have passed @evt for @dev_id if
>> + * irq_set_chip_and_handler() asked for handle_percpu_devid_irq()
>
>And why are you not doing that?
Will do that in V4

>> +static int __init nps_setup_clockevent(struct device_node *node) {
>> +struct clock_event_device *evt = this_cpu_ptr(_clockevent_device);
>> +struct clk *clk;
>> +int ret;
>> +
>> +nps_timer0_irq = irq_of_parse_and_map(node, 0);
>> +if (nps_timer0_irq <= 0) {
>> +pr_err("clockevent: missing irq");
>> +return -EINVAL;
>> +}
>> +
>> +nps_get_timer_clk(node, _timer0_freq, clk);
>> +
>> +/* Needs apriori irq_set_percpu_devid() done in intc map function */
>> +ret = request_percpu_irq(nps_timer0_irq, timer_irq_handler,
>> + "Timer0 (per-cpu-tick)", evt);
>
>This is wrong. the dev_id argument wants to be a __per_cpu pointer. So it 
>should be _clockevent_device and not a pointer to the cpu local one.
Will fix that in V4

>> +if (ret) {
>> +pr_err("Couldn't request irq\n");
>> +clk_disable_unprepare(clk);
>> +return ret;
>> +}
>> +
>> +ret = 

Re: [PATCH][resend] drm: bridge: add DesignWare HDMI I2S audio support

[Russell King - ARM Linux]

On Tue, Nov 01, 2016 at 12:36:29AM +, Kuninori Morimoto wrote:
> 
> Hi Russell again
> 
> > > > +static struct platform_driver snd_dw_hdmi_driver = {
> > > > +   .probe  = snd_dw_hdmi_probe,
> > > 
> > > The driver must have a .remove function, because the platform device it
> > > is binding against can appear and disappear.
> > 
> > Thank you for your feedback
> > OK, I will add it
> 
> This driver uses platform_device_register_full() and calls hdmi-codec
> driver. This driver itself doesn't register sound card, like 
> dw-hdmi-ahb-audio.c
> Then, what does .remove should do in this case ?

Remove the platform device that was created by
platform_device_register_full().

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/2] Input: gpio_keys - Set ABS params when using axes

[Paul Cercueil]

The gpio-keys supports the EV_ABS event type, but does not actually
configure the input device to work with that mode.

This patch configures the axis corresponding to button->code as being
in the range [-1,+1]. This makes it possible to use gpio-keys to
implement a hat (using the ABS_HAT0X /ABS_HAT0Y axes, with two GPIOs
each with values -1/+1).

Signed-off-by: Paul Cercueil 
---
 drivers/input/keyboard/gpio_keys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index 7018c49..1f2850a 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -540,6 +540,9 @@ static int gpio_keys_setup_key(struct platform_device *pdev,
 
input_set_capability(input, button->type ?: EV_KEY, button->code);
 
+   if (button->type == EV_ABS)
+   input_set_abs_params(input, button->code, -1, 1, 0, 0);
+
/*
 * Install custom action to cancel release timer and
 * workqueue item.
-- 
2.9.3

Re: [PATCH] ARM: davinci: da850: Fix pwm name matching

[Sekhar Nori]

On Monday 31 October 2016 08:18 PM, David Lechner wrote:
> On 10/31/2016 05:18 AM, Sekhar Nori wrote:
>> On Tuesday 25 October 2016 11:24 PM, David Lechner wrote:
>>> This fixes pwm name matching for DA850 familiy devices. When using
>>> device
>>> tree, the da850_auxdata_lookup[] table caused pwm devices to have the
>>> exact
>>> same name, which caused errors when trying to register the devices.
>>>
>>> The names for clock matching in da850_clks[] also have to be updated to
>>> to exactly match in order for the clock lookup to work correctly.
>>>
>>> Signed-off-by: David Lechner 
>>> ---
>>>
>>> Tested working on LEGO MINDSTORMS EV3.
>>>
>>>
>>>  arch/arm/mach-davinci/da850.c| 10 +++---
>>>  arch/arm/mach-davinci/da8xx-dt.c | 10 +-
>>>  2 files changed, 12 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-davinci/da850.c
>>> b/arch/arm/mach-davinci/da850.c
>>> index ed3d0e9..6b78a8f 100644
>>> --- a/arch/arm/mach-davinci/da850.c
>>> +++ b/arch/arm/mach-davinci/da850.c
>>> @@ -510,9 +510,13 @@ static struct clk_lookup da850_clks[] = {
>>>  CLK("vpif",NULL,_clk),
>>>  CLK("ahci_da850",NULL,_clk),
>>>  CLK("davinci-rproc.0",NULL,_clk),
>>> -CLK("ehrpwm","fck",_clk),
>>> -CLK("ehrpwm","tbclk",_tbclk),
>>> -CLK("ecap","fck",_clk),
>>> +CLK("ehrpwm.0","fck",_clk),
>>> +CLK("ehrpwm.0","tbclk",_tbclk),
>>> +CLK("ehrpwm.1","fck",_clk),
>>> +CLK("ehrpwm.1","tbclk",_tbclk),
>>> +CLK("ecap.0","fck",_clk),
>>> +CLK("ecap.1","fck",_clk),
>>> +CLK("ecap.2","fck",_clk),
>>
>> This has exposed a limitation of DaVinci clock framework. The struct clk
>> are stored as a linked list themselves. So a node repeating in the table
>> above will create a loop in the linked list. This is easily seen on the
>> LCDK board. davinci_clk_disable_unused() never returns. PWMs are unused
>> on that board.
>>
>> There is no "simple" solution to this AFAICS. One solution is to
>> separate the iterator from the clock hardware structure and use struct
>> clk_hw available in struct clk_lookup.
>>
>> Or move DaVinci to common clock framework. This is of course preferred
>> but much more involved as all 6 supported SoCs have to be moved together.
>>
>> Thanks,
>> Sekhar
>>
>>
> 
> The simple solution for now could be to make child clocks for each of
> these that simply enable the parent clock. e.g. ehrpwm0_clk and
> ehpwm1_clk are children of ehrpwm_clk, etc.

That sounds good. I saw the v2 patch you sent and it looks good. I
noticed that aemif clock is repeated in da850.c too. That needs fixing.

> Looking at da830.c, it looks like the solution was to make multiple
> clocks that use the same LPSC, but this does not seem right to me.

The PWM clock definitions there are definitely wrong. It should be
fixed. Looks like its been like that forever.

Thanks,
Sekhar

[PATCH] PM / sleep: fix device reference leak in test_suspend

[Johan Hovold]

Make sure to drop the reference taken by class_find_device() after
opening the rtc device.

Fixes: 77437fd4e61f ("pm: boot time suspend selftest")
Signed-off-by: Johan Hovold 
---
 kernel/power/suspend_test.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/power/suspend_test.c b/kernel/power/suspend_test.c
index 084452e34a12..bdff5ed57f10 100644
--- a/kernel/power/suspend_test.c
+++ b/kernel/power/suspend_test.c
@@ -203,8 +203,10 @@ static int __init test_suspend(void)
 
/* RTCs have initialized by now too ... can we use one? */
dev = class_find_device(rtc_class, NULL, NULL, has_wakealarm);
-   if (dev)
+   if (dev) {
rtc = rtc_class_open(dev_name(dev));
+   put_device(dev);
+   }
if (!rtc) {
printk(warn_no_rtc);
return 0;
-- 
2.7.3

[PATCH 1/2] of/platform: fix of_platform_device_destroy comment

[Johan Hovold]

Update the comment to of_platform_device_destroy() to reflect that it no
longer returns a status value.

Fixes: 75f353b61342 ("of/platform: Fix of_platform_device_destroy...")
Signed-off-by: Johan Hovold 
---
 drivers/of/platform.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index e4bf07d20f9b..cb4c7800f37d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -558,9 +558,6 @@ static int of_platform_device_destroy(struct device *dev, 
void *data)
  * of the given device (and, recurrently, their children) that have been
  * created from their respective device tree nodes (and only those,
  * leaving others - eg. manually created - unharmed).
- *
- * Returns 0 when all children devices have been removed or
- * -EBUSY when some children remained.
  */
 void of_platform_depopulate(struct device *parent)
 {
-- 
2.7.3

[PATCH net 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks

[Johan Hovold]

Make sure to drop the references taken by of_get_child_by_name() and
bus_find_device() before returning from cpsw_phy_sel().

Note that there is no guarantee that the devres-managed struct
cpsw_phy_sel_priv will continue to be valid until this function returns
regardless of this change.

Fixes: 5892cd135e16 ("drivers: net: cpsw-phy-sel: Add new driver...")
Signed-off-by: Johan Hovold 
---
 drivers/net/ethernet/ti/cpsw-phy-sel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c 
b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index 054a8dd23dae..589beb843f56 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -176,8 +176,11 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t 
phy_mode, int slave)
}
 
dev = bus_find_device(_bus_type, NULL, node, match);
+   of_node_put(node);
priv = dev_get_drvdata(dev);
 
+   put_device(dev);
+
priv->cpsw_phy_sel(priv, phy_mode, slave);
 }
 EXPORT_SYMBOL_GPL(cpsw_phy_sel);
-- 
2.7.3

[PATCH net 1/4] phy: fix device reference leaks

[Johan Hovold]

Make sure to drop the reference taken by bus_find_device_by_name()
before returning from phy_connect() and phy_attach().

Note that both function still take a reference to the phy device
through phy_attach_direct().

Fixes: e13934563db0 ("[PATCH] PHY Layer fixup")
Signed-off-by: Johan Hovold 
---
 drivers/net/phy/phy_device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e977ba931878..1a4bf8acad78 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -723,6 +723,7 @@ struct phy_device *phy_connect(struct net_device *dev, 
const char *bus_id,
phydev = to_phy_device(d);
 
rc = phy_connect_direct(dev, phydev, handler, interface);
+   put_device(d);
if (rc)
return ERR_PTR(rc);
 
@@ -953,6 +954,7 @@ struct phy_device *phy_attach(struct net_device *dev, const 
char *bus_id,
phydev = to_phy_device(d);
 
rc = phy_attach_direct(dev, phydev, phydev->dev_flags, interface);
+   put_device(d);
if (rc)
return ERR_PTR(rc);
 
-- 
2.7.3

Re: [BUG][REGRESSION] mangled display since -rc1

[Martin Kepplinger]

Am 31. Oktober 2016 22:54:54 MEZ, schrieb Joerg Roedel :
>On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
>> This is one machine booting a bad kernel. I could provide another
>> example later this week.
>
>You have an Intel system without any IOMMU (enabled), otherwise you
>would have a DMAR-ACPI table, but there is none:
>
>> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
>> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS
>ACRPRDCT 0001  0113)
>> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS
>ACRPRDCT  1025 0004)
>> [0.00] ACPI: FACS 0xA6FBB000 40
>> [0.00] ACPI: FACS 0xA6FBB000 40
>> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS
>ACRPRDCT 1000 1025 0004)
>> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS
>ACRPRDCT 0001 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS
>ACRPRDCT 3000 1025 0004)
>> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS
>ACRPRDCT 3000 1025 0004)
>
>So it is pretty unlikely that any change in IOMMU code causes your
>issue. Not sure why your bisecting ended up there. You also have an
>Intel GPU in the system:
>
>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
>Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
>00 [VGA controller])
>>  Subsystem: Acer Incorporated [ALI] Device 0748
>>  Flags: bus master, fast devsel, latency 0, IRQ 28
>>  Memory at c000 (64-bit, non-prefetchable) [size=4M]
>>  Memory at b000 (64-bit, prefetchable) [size=256M]
>>  I/O ports at 2000 [size=64]
>>  [virtual] Expansion ROM at 000c [disabled] [size=128K]
>>  Capabilities: 
>>  Kernel driver in use: i915
>
>My best guess is that some changes in the i915 driver cause your issue,
>I add the maintainers of i915 to the cc-list, maybe they have an idea.
>
>
>   Joerg


I'll come up with a nouveau system example and it was quite easy to bisect. To 
quote the merge commit msg:

This also required some changes outside of the IOMMU code, but these are acked 
by the respective maintainers.

Any help on bisecting into it would be awesome.

Re: [PATCH] UBIFS: Remove some dead code

[Richard Weinberger]

On 01.11.2016 07:45, Christophe JAILLET wrote:
> 'ubifs_fast_find_freeable()' can not return an error pointer, so this test
> can be removed.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  fs/ubifs/gc.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
> index e845c64b6ce1..7b35e3d6cde7 100644
> --- a/fs/ubifs/gc.c
> +++ b/fs/ubifs/gc.c
> @@ -846,10 +846,6 @@ int ubifs_gc_start_commit(struct ubifs_info *c)
>*/
>   while (1) {
>   lp = ubifs_fast_find_freeable(c);
> - if (IS_ERR(lp)) {
> - err = PTR_ERR(lp);
> - goto out;
> - }

Good catch, how did you find this?
If you have a tool/script I'd like to use it too.

Thanks,
//richard

Re: [BUG][REGRESSION] mangled display since -rc1

[Jani Nikula]

On Tue, 01 Nov 2016, Martin Kepplinger  wrote:
> Am 31. Oktober 2016 22:54:54 MEZ, schrieb Joerg Roedel :
>>On Mon, Oct 31, 2016 at 09:44:51PM +0100, Martin Kepplinger wrote:
>>> This is one machine booting a bad kernel. I could provide another
>>> example later this week.
>>
>>You have an Intel system without any IOMMU (enabled), otherwise you
>>would have a DMAR-ACPI table, but there is none:
>>
>>> [0.00] ACPI: RSDP 0x000FE020 24 (v02 ACRSYS)
>>> [0.00] ACPI: XSDT 0xA6FFE210 8C (v01 ACRSYS
>>ACRPRDCT 0001  0113)
>>> [0.00] ACPI: FACP 0xA6FFB000 F4 (v04 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: DSDT 0xA6FEC000 00B903 (v01 ACRSYS
>>ACRPRDCT  1025 0004)
>>> [0.00] ACPI: FACS 0xA6FBB000 40
>>> [0.00] ACPI: FACS 0xA6FBB000 40
>>> [0.00] ACPI: UEFI 0xA6FFD000 000236 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: ASF! 0xA6FFC000 A5 (v32 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: HPET 0xA6FFA000 38 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: APIC 0xA6FF9000 8C (v02 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: MCFG 0xA6FF8000 3C (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SLIC 0xA6FEB000 000176 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FEA000 0006FE (v01 ACRSYS
>>ACRPRDCT 1000 1025 0004)
>>> [0.00] ACPI: BOOT 0xA6FE8000 28 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: ASPT 0xA6FE3000 34 (v07 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: FPDT 0xA6FE1000 44 (v01 ACRSYS
>>ACRPRDCT 0001 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FE 00079A (v01 ACRSYS
>>ACRPRDCT 3000 1025 0004)
>>> [0.00] ACPI: SSDT 0xA6FDF000 000A92 (v01 ACRSYS
>>ACRPRDCT 3000 1025 0004)
>>
>>So it is pretty unlikely that any change in IOMMU code causes your
>>issue. Not sure why your bisecting ended up there. You also have an
>>Intel GPU in the system:
>>
>>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
>>Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
>>00 [VGA controller])
>>> Subsystem: Acer Incorporated [ALI] Device 0748
>>> Flags: bus master, fast devsel, latency 0, IRQ 28
>>> Memory at c000 (64-bit, non-prefetchable) [size=4M]
>>> Memory at b000 (64-bit, prefetchable) [size=256M]
>>> I/O ports at 2000 [size=64]
>>> [virtual] Expansion ROM at 000c [disabled] [size=128K]
>>> Capabilities: 
>>> Kernel driver in use: i915
>>
>>My best guess is that some changes in the i915 driver cause your issue,
>>I add the maintainers of i915 to the cc-list, maybe they have an idea.
>>
>>
>>  Joerg
>
>
> I'll come up with a nouveau system example and it was quite easy to bisect. 
> To quote the merge commit msg:
>
> This also required some changes outside of the IOMMU code, but these are 
> acked by the respective maintainers.
>
> Any help on bisecting into it would be awesome.

So the information here is pretty scarce. Please file a bug at [1],
describe the problem, perhaps add drm.debug=14 module parameter and
attach dmesg from boot to reproducing the problem.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH V4 10/10] arm64: KVM: add guest SEA support

[Russell King - ARM Linux]

On Mon, Oct 31, 2016 at 04:36:33PM -0600, Baicar, Tyler wrote:
> Hello Russell,
> 
> On 10/31/2016 4:02 AM, Russell King - ARM Linux wrote:
> >The subject line on this patch is misleading - it's not only ARM64
> >specific...
> Thank you for the feedback!
> 
> I only put ARM64 in the subject line because this patch only really adds
> guest SEA support for the ARM64 KVM code. The ARM code had to be edited
> since both the ARM and ARM64 KVM code use arch/arm/kvm/mmu.c. I can change
> the subject line to "arm/arm64: KVM: add guest SEA support" if you think
> that is better.

Yes please, I almost skipped over it while catching up because it didn't
say "arm", it was only that I'd happened to read the cover message that
I'd spotted arch/arm in the diffstat, and then had to go digging for the
changes to review.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH net-next 04/11] net: dsa: mv88e6xxx: add port FID accessors

[Andrew Lunn]

> --- a/drivers/net/dsa/mv88e6xxx/port.c
> +++ b/drivers/net/dsa/mv88e6xxx/port.c
> @@ -61,6 +61,8 @@ int mv88e6xxx_port_set_state(struct mv88e6xxx_chip *chip, 
> int port, u8 state)
>   return 0;
>  }
>  
> +/* Offset 0x05: Port Control 1 */
> +
>  /* Offset 0x06: Port Based VLAN Map */
>  
>  int mv88e6xxx_port_set_vlan_map(struct mv88e6xxx_chip *chip, int port, u16 
> map)

Hi Vivien

This comment seems in an odd place.

 Andrew

Re: [RFC PATCH v2 3/5] ARM64: dts: meson-gxl: Add ethernet nodes with internal PHY

[Sergei Shtylyov]

Hello.

On 10/31/2016 7:56 PM, Neil Armstrong wrote:


Add Ethernet node with Internal PHY selection for the Amlogic GXL SoCs

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index d1bf381..71670c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -47,6 +47,24 @@

 / {
compatible = "amlogic,meson-gxl";
+
+


   No need for these empty lines.


+};
+
+ {
+   reg = <0x0 0xc941 0x0 0x1
+  0x0 0xc8834540 0x0 0x4>;
+
+   clocks = < CLKID_ETH>,
+< CLKID_FCLK_DIV2>,
+< CLKID_MPLL2>;
+   clock-names = "stmmaceth", "clkin0", "clkin1";
+
+   mdio0: mdio0 {


   Should be "mdio0: mdio {" in oprder to comply woth the DT spec.


+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "snps,dwmac-mdio";
+   };
 };

  {

[...]

MBR, Sergei

Re: [PATCH v8 2/3] ARM: davinci: da8xx: add usb phy clocks

[Sekhar Nori]

On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
> Up to this point, the USB phy clock configuration was handled manually in
> the board files and in the usb drivers. This adds proper clocks so that
> the usb drivers can use clk_get and clk_enable and not have to worry about
> the details. Also, the related code is removed from the board files and
> replaced with the new clock registration functions.
> 
> This also removes the #if IS_ENABLED(CONFIG_USB_MUSB_HDRC) around the musb
> declaration and renames the musb platform device so that we can reference
> it from the usb20 clock even if the musb device is not used.
> 
> Signed-off-by: David Lechner 
> Signed-off-by: Axel Haslam 

Applied to v4.10/soc

Thanks,
Sekhar

[PATCH] clk: ingenic: Fix recalc_rate for clocks with fixed divider

[Paul Cercueil]

Previously, the clocks with a fixed divider would report their rate
as being the same as the one of their parent, independently of the
divider in use. This commit fixes this behaviour.

This went unnoticed as neither the jz4740 nor the jz4780 CGU code
have clocks with fixed dividers yet.

Signed-off-by: Paul Cercueil 
---
 drivers/clk/ingenic/cgu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/ingenic/cgu.c b/drivers/clk/ingenic/cgu.c
index e8248f9..eb9002c 100644
--- a/drivers/clk/ingenic/cgu.c
+++ b/drivers/clk/ingenic/cgu.c
@@ -328,6 +328,8 @@ ingenic_clk_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
div *= clk_info->div.div;
 
rate /= div;
+   } else if (clk_info->type & CGU_CLK_FIXDIV) {
+   rate /= clk_info->fixdiv.div;
}
 
return rate;
-- 
2.10.1

[PATCH v8: 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

[Grzegorz Andrejczuk]

These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT
instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs.
Then expose it as CPU feature and introduces elf HWCAP capability for x86.
Reference:
https://software.intel.com/en-us/blogs/2016/10/06/intel-xeon-phi-product-family-x200-knl-user-mode-ring-3-monitor-and-mwait

v8:
Fixed commit messages
Removed logging
Used msr_set/clear_bit functions instesd of wrmsrl
Fixed documentation
Renamed HWCAP2_PHIR3MWAIT to HWCAP2_RING3MWAIT

v7:
Change order of the patches, with this code looks cleaner.
Changed the name of MSR to MSR_MISC_FEATURE_ENABLES.
Used Word 3 25th bit to expose feature.

v6: 

v5:
When phir3mwait=disable is cmdline switch off r3 mwait feature
Fix typos

v4:
Wrapped the enabling code by CONFIG_X86_64
Add documentation for phir3mwait=disable cmdline switch
Move probe_ function call from early_intel_init to intel_init
Fixed commit messages

v3:
Included Daves and Thomas comments

v2:
Check MSR before wrmsrl
Shortened names
Used Word 3 for feature init_scattered_cpuid_features()
Fixed commit messages


Grzegorz Andrejczuk (4):
  x86/msr: Add MSR_MISC_FEATURE_ENABLES and PHIR3MWAIT bit
  x86/elf: Use HWCAP2 to expose ring 3 MWAIT
  x86/cpufeature: Add PHIR3MWAIT to CPU features
  x86/cpufeatures: Handle RING3MWAIT on Xeon Phi models

 Documentation/kernel-parameters.txt   |  5 
 Documentation/x86/x86_64/boot-options.txt |  5 
 arch/x86/include/asm/cpufeatures.h|  2 +-
 arch/x86/include/asm/elf.h|  9 +++
 arch/x86/include/asm/msr-index.h  |  5 
 arch/x86/include/uapi/asm/hwcap2.h|  7 ++
 arch/x86/kernel/cpu/common.c  |  3 +++
 arch/x86/kernel/cpu/intel.c   | 39 +++
 8 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/include/uapi/asm/hwcap2.h

-- 
2.5.1