Re: [PATCH] phy: Add reset callback for not generic phy

[John Youn]

On 10/25/2016 7:15 AM, Randy Li wrote:
> I forget to add a dummy function in case the CONFIG_GENERIC_PHY
> is disabled.
> 
> Signed-off-by: Randy Li 

Fixes: cac18ecb6f44 ("phy: Add reset callback")
Tested-by: John Youn 

Hi Kishon,

Can you take this for 4.9-rc?

Thanks,
John



> ---
>  include/linux/phy/phy.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index ee1bed7..78bb0d7 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum 
> phy_mode mode)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_reset(struct phy *phy)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 
>

Re: [PATCH] phy: Add reset callback for not generic phy

[John Youn]

On 10/25/2016 7:15 AM, Randy Li wrote:
> I forget to add a dummy function in case the CONFIG_GENERIC_PHY
> is disabled.
> 
> Signed-off-by: Randy Li 

Fixes: cac18ecb6f44 ("phy: Add reset callback")
Tested-by: John Youn 

Hi Kishon,

Can you take this for 4.9-rc?

Thanks,
John



> ---
>  include/linux/phy/phy.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index ee1bed7..78bb0d7 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -253,6 +253,13 @@ static inline int phy_set_mode(struct phy *phy, enum 
> phy_mode mode)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_reset(struct phy *phy)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 
>

Re: [PATCH 2/3] usb: dwc3: host: Do not use dma_set_coherent_mask

[Arnd Bergmann]

On Tuesday, October 25, 2016 4:26:27 PM CEST Sriram Dash wrote:
> Do not require dma_set_coherent_mask for hcd
> 
> Signed-off-by: Arnd Bergmann 

Aside from the comments I had for patch 3, you are doing two
different things here:

> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
> index 89a2f71..4d7439c 100644
> --- a/drivers/usb/dwc3/dwc3-st.c
> +++ b/drivers/usb/dwc3/dwc3-st.c
> @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev)
>   if (IS_ERR(regmap))
>   return PTR_ERR(regmap);
>  
> - dma_set_coherent_mask(dev, dev->coherent_dma_mask);
>   dwc3_data->dev = dev;
>   dwc3_data->regmap = regmap;
>  

This one was setting the mask for the device itself (incorrectly),
so it can be removed along with the dma_coerce_mask_and_coherent()
call in dwc3_exynos_probe, or as a separate patch. It is an
independent cleanup.

> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -833,9 +833,6 @@ struct platform_device *ci_hdrc_add_device(struct device 
> *dev,
>
> - dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
>  
>   ret = platform_device_add_resources(pdev, res, nres);
>   if (ret)

> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1059,12 +1059,6 @@ static int dwc3_probe(struct platform_device *pdev)
>  
>   spin_lock_init(>lock);
>  
> - dma_set_coherent_mask(dev, dev->parent->coherent_dma_mask);

> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -72,11 +72,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>   return -ENOMEM;
>   }
>  
> - dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
> -

These three all set the mask for the *child* devices, as
that is no longer needed after the change in patch 1/3.
I'd suggest leaving those changes together with the rest of
that patch.

However, it's probably better to split up that patch along the
boundaries of the drivers, starting with the USB core:

1/4 usb: separate out sysdev pointer from usb_bus
2/4 usb: chipidea: use bus->sysdev for DMA configuration
3/4 usb: xhci: use bus->sysdev for DMA configuration
4/4 usb: dwc3: use bus->sysdev for DMA configuration

Arnd

Re: [PATCH 2/3] usb: dwc3: host: Do not use dma_set_coherent_mask

[Arnd Bergmann]

On Tuesday, October 25, 2016 4:26:27 PM CEST Sriram Dash wrote:
> Do not require dma_set_coherent_mask for hcd
> 
> Signed-off-by: Arnd Bergmann 

Aside from the comments I had for patch 3, you are doing two
different things here:

> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
> index 89a2f71..4d7439c 100644
> --- a/drivers/usb/dwc3/dwc3-st.c
> +++ b/drivers/usb/dwc3/dwc3-st.c
> @@ -218,7 +218,6 @@ static int st_dwc3_probe(struct platform_device *pdev)
>   if (IS_ERR(regmap))
>   return PTR_ERR(regmap);
>  
> - dma_set_coherent_mask(dev, dev->coherent_dma_mask);
>   dwc3_data->dev = dev;
>   dwc3_data->regmap = regmap;
>  

This one was setting the mask for the device itself (incorrectly),
so it can be removed along with the dma_coerce_mask_and_coherent()
call in dwc3_exynos_probe, or as a separate patch. It is an
independent cleanup.

> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -833,9 +833,6 @@ struct platform_device *ci_hdrc_add_device(struct device 
> *dev,
>
> - dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
>  
>   ret = platform_device_add_resources(pdev, res, nres);
>   if (ret)

> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1059,12 +1059,6 @@ static int dwc3_probe(struct platform_device *pdev)
>  
>   spin_lock_init(>lock);
>  
> - dma_set_coherent_mask(dev, dev->parent->coherent_dma_mask);

> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -72,11 +72,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>   return -ENOMEM;
>   }
>  
> - dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
> -

These three all set the mask for the *child* devices, as
that is no longer needed after the change in patch 1/3.
I'd suggest leaving those changes together with the rest of
that patch.

However, it's probably better to split up that patch along the
boundaries of the drivers, starting with the USB core:

1/4 usb: separate out sysdev pointer from usb_bus
2/4 usb: chipidea: use bus->sysdev for DMA configuration
3/4 usb: xhci: use bus->sysdev for DMA configuration
4/4 usb: dwc3: use bus->sysdev for DMA configuration

Arnd

Re: console issue since 3.6, console=ttyS1 hangs

[Sean Young]

On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote:
> [0.974874] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
> [0.975038] pnp 00:04: parse resource options
> [0.975048] pnp 00:04:   dependent set 0 (acceptable) io  min 0x2f8 max 
> 0x2f8 align 1 size 8 flags 0x1
> [0.975056] pnp 00:04:   dependent set 0 (acceptable) irq 3 4 5 6 7 10 11 
> 12 flags 0x1
> [0.975060] pnp 00:04:   dependent set 0 (acceptable) dma  (bitmask 
> 0x0) flags 0x0

So here the bios claims that the serial port can use any of 3 to 12 irqs.

> [1.543636] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled

Why is this kernel compiled with irq sharing disabled?

> [1.565062] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

The isa probe driver find the serial port.

> [1.566453] serial 00:04: pnp_assign_resources, try dependent set 0
> [1.567383] serial 00:04:   couldn't assign io 0 (min 0x2f8 max 0x2f8)

But then decides that the port is already in use (the existing serial driver).

> [1.568366] serial 00:04: pnp_assign_resources failed (-16)
> [1.569188] serial 00:04: unable to assign resources
> [1.569924] serial: probe of 00:04 failed with error -16

Please try and boot 3.7.0 with "8250.share_irqs=1", maybe it will pick
irq 3 and it will be happy again, but that is just a guess.

I think I have not fully understood what the failure is. Does the serial
port not work or does the boot hang? What are the symptoms?

We might be able to fix the problem with a pnp quirk but 3.7 is has not had
any releases for a long time. We will need a reproduction on a concurrent
kernel so a patch can be written for that.


Sean

Re: console issue since 3.6, console=ttyS1 hangs

[Sean Young]

On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote:
> [0.974874] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
> [0.975038] pnp 00:04: parse resource options
> [0.975048] pnp 00:04:   dependent set 0 (acceptable) io  min 0x2f8 max 
> 0x2f8 align 1 size 8 flags 0x1
> [0.975056] pnp 00:04:   dependent set 0 (acceptable) irq 3 4 5 6 7 10 11 
> 12 flags 0x1
> [0.975060] pnp 00:04:   dependent set 0 (acceptable) dma  (bitmask 
> 0x0) flags 0x0

So here the bios claims that the serial port can use any of 3 to 12 irqs.

> [1.543636] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled

Why is this kernel compiled with irq sharing disabled?

> [1.565062] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

The isa probe driver find the serial port.

> [1.566453] serial 00:04: pnp_assign_resources, try dependent set 0
> [1.567383] serial 00:04:   couldn't assign io 0 (min 0x2f8 max 0x2f8)

But then decides that the port is already in use (the existing serial driver).

> [1.568366] serial 00:04: pnp_assign_resources failed (-16)
> [1.569188] serial 00:04: unable to assign resources
> [1.569924] serial: probe of 00:04 failed with error -16

Please try and boot 3.7.0 with "8250.share_irqs=1", maybe it will pick
irq 3 and it will be happy again, but that is just a guess.

I think I have not fully understood what the failure is. Does the serial
port not work or does the boot hang? What are the symptoms?

We might be able to fix the problem with a pnp quirk but 3.7 is has not had
any releases for a long time. We will need a reproduction on a concurrent
kernel so a patch can be written for that.


Sean

Re: [PATCH] clk: Register clkdev after setup of fixed-rate and fixed-factor clocks

[Stephen Boyd]

On 10/22, Xiaolong Zhang wrote:
> On 四, 10月 20, 2016 at 04:01:03下午 -0700, Stephen Boyd wrote:
> > On 10/11, Orson Zhai wrote:
> > > From: Xiaolong Zhang 
> > > 
> > > When common kernel setups fixed clock, of_clk_provider will be 
> > > registerred.
> > > But there is no clkdev being registerred at the same time. This will make
> > > it difficult to get the clock by using clk_get(NULL, con_id).
> > > 
> > > Add clkdev register for fixed-rate and fixed-factor clock and ignore
> > > the error if any.
> > > 
> > > Signed-off-by: Xiaolong Zhang 
> > > Signed-off-by: Orson Zhai 
> > > ---
> > 
> > Why are we using clkdev lookups for clks populated from DT?
> > Shouldn't we be able to point to them from the consumers that
> > would also be in DT? I'm a little lost.
> > 
> The clk_get interface allows the first argument as NULL. We just assure
> consumers can get the clock from DT or by clock name.

Ok. The first argument to clk_get() really shouldn't be NULL. It
should be the device pointer for the device that is associated
with the clk you want to get. The clock name (second argument to
clk_get()) should be device specific and not some globally unique
identifier. It seems that you're using the clk_get() API
incorrectly.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: Register clkdev after setup of fixed-rate and fixed-factor clocks

[Stephen Boyd]

On 10/22, Xiaolong Zhang wrote:
> On 四, 10月 20, 2016 at 04:01:03下午 -0700, Stephen Boyd wrote:
> > On 10/11, Orson Zhai wrote:
> > > From: Xiaolong Zhang 
> > > 
> > > When common kernel setups fixed clock, of_clk_provider will be 
> > > registerred.
> > > But there is no clkdev being registerred at the same time. This will make
> > > it difficult to get the clock by using clk_get(NULL, con_id).
> > > 
> > > Add clkdev register for fixed-rate and fixed-factor clock and ignore
> > > the error if any.
> > > 
> > > Signed-off-by: Xiaolong Zhang 
> > > Signed-off-by: Orson Zhai 
> > > ---
> > 
> > Why are we using clkdev lookups for clks populated from DT?
> > Shouldn't we be able to point to them from the consumers that
> > would also be in DT? I'm a little lost.
> > 
> The clk_get interface allows the first argument as NULL. We just assure
> consumers can get the clock from DT or by clock name.

Ok. The first argument to clk_get() really shouldn't be NULL. It
should be the device pointer for the device that is associated
with the clk you want to get. The clock name (second argument to
clk_get()) should be device specific and not some globally unique
identifier. It seems that you're using the clk_get() API
incorrectly.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2] Input: synaptics-rmi4 - stop scanning PDT after two empty pages

[Nick Dyer]

We have encountered some RMI4 firmwares where there are blank pages in
between PDT pages which contain functions. This change makes them
correctly enumerate all functions on the device.

Tested on S7817 (has empty page 2).

Signed-off-by: Nick Dyer 
---
 drivers/input/rmi4/rmi_driver.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 4a88312..425bd19 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -422,6 +422,7 @@ static void rmi_driver_copy_pdt_to_fd(const struct 
pdt_entry *pdt,
 
 static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
 int page,
+int *empty_pages,
 void *ctx,
 int (*callback)(struct rmi_device *rmi_dev,
 void *ctx,
@@ -449,7 +450,16 @@ static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
return retval;
}
 
-   return (data->f01_bootloader_mode || addr == pdt_start) ?
+   /*
+* Count number of empty PDT pages. If a gap of two pages
+* or more is found, stop scanning.
+*/
+   if (addr == pdt_start)
+   ++*empty_pages;
+   else
+   *empty_pages = 0;
+
+   return (data->f01_bootloader_mode || *empty_pages >= 2) ?
RMI_SCAN_DONE : RMI_SCAN_CONTINUE;
 }
 
@@ -459,10 +469,12 @@ static int rmi_scan_pdt(struct rmi_device *rmi_dev, void 
*ctx,
const struct pdt_entry *entry))
 {
int page;
+   int empty_pages = 0;
int retval = RMI_SCAN_DONE;
 
for (page = 0; page <= RMI4_MAX_PAGE; page++) {
-   retval = rmi_scan_pdt_page(rmi_dev, page, ctx, callback);
+   retval = rmi_scan_pdt_page(rmi_dev, page, _pages,
+  ctx, callback);
if (retval != RMI_SCAN_CONTINUE)
break;
}
-- 
2.7.4

[PATCH v2] Input: synaptics-rmi4 - stop scanning PDT after two empty pages

[Nick Dyer]

We have encountered some RMI4 firmwares where there are blank pages in
between PDT pages which contain functions. This change makes them
correctly enumerate all functions on the device.

Tested on S7817 (has empty page 2).

Signed-off-by: Nick Dyer 
---
 drivers/input/rmi4/rmi_driver.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index 4a88312..425bd19 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -422,6 +422,7 @@ static void rmi_driver_copy_pdt_to_fd(const struct 
pdt_entry *pdt,
 
 static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
 int page,
+int *empty_pages,
 void *ctx,
 int (*callback)(struct rmi_device *rmi_dev,
 void *ctx,
@@ -449,7 +450,16 @@ static int rmi_scan_pdt_page(struct rmi_device *rmi_dev,
return retval;
}
 
-   return (data->f01_bootloader_mode || addr == pdt_start) ?
+   /*
+* Count number of empty PDT pages. If a gap of two pages
+* or more is found, stop scanning.
+*/
+   if (addr == pdt_start)
+   ++*empty_pages;
+   else
+   *empty_pages = 0;
+
+   return (data->f01_bootloader_mode || *empty_pages >= 2) ?
RMI_SCAN_DONE : RMI_SCAN_CONTINUE;
 }
 
@@ -459,10 +469,12 @@ static int rmi_scan_pdt(struct rmi_device *rmi_dev, void 
*ctx,
const struct pdt_entry *entry))
 {
int page;
+   int empty_pages = 0;
int retval = RMI_SCAN_DONE;
 
for (page = 0; page <= RMI4_MAX_PAGE; page++) {
-   retval = rmi_scan_pdt_page(rmi_dev, page, ctx, callback);
+   retval = rmi_scan_pdt_page(rmi_dev, page, _pages,
+  ctx, callback);
if (retval != RMI_SCAN_CONTINUE)
break;
}
-- 
2.7.4

Re: [PATCH 3/3] clk: keystone: Fix missing iounmap calls in an error handling path

[Stephen Boyd]

On 10/25, walter harms wrote:
> Am 24.10.2016 22:43, schrieb Christophe JAILLET:
> > @@ -220,6 +218,12 @@ static void __init _of_pll_clk_init(struct device_node 
> > *node, bool pllctrl)
> >  
> >  out:
> > pr_err("%s: error initializing pll %s\n", __func__, node->name);
> > +   if (pll_data->pllm)
> > +   iounmap(pll_data->pllm);
> > +   if (pll_data->pll_ctl0)
> > +   iounmap(pll_data->pll_ctl0);
> > +   if (pll_data->pllod)
> > +   iounmap(pll_data->pllod);
> > kfree(pll_data);
> >  }
> >  
> 
> IMHO calles the iounmap() need no check for NULL.
> 

ARM doesn't seem to check for NULL there though. So that would be
a bug.

It would be nice to remove the checks though. Perhaps someone
could do that by unifying ionumap into asm-generic with the NULL
check and then have architecture specific functions for the rest
of it?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 3/3] clk: keystone: Fix missing iounmap calls in an error handling path

[Stephen Boyd]

On 10/25, walter harms wrote:
> Am 24.10.2016 22:43, schrieb Christophe JAILLET:
> > @@ -220,6 +218,12 @@ static void __init _of_pll_clk_init(struct device_node 
> > *node, bool pllctrl)
> >  
> >  out:
> > pr_err("%s: error initializing pll %s\n", __func__, node->name);
> > +   if (pll_data->pllm)
> > +   iounmap(pll_data->pllm);
> > +   if (pll_data->pll_ctl0)
> > +   iounmap(pll_data->pll_ctl0);
> > +   if (pll_data->pllod)
> > +   iounmap(pll_data->pllod);
> > kfree(pll_data);
> >  }
> >  
> 
> IMHO calles the iounmap() need no check for NULL.
> 

ARM doesn't seem to check for NULL there though. So that would be
a bug.

It would be nice to remove the checks though. Perhaps someone
could do that by unifying ionumap into asm-generic with the NULL
check and then have architecture specific functions for the rest
of it?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] tpm: sanitize constant expressions

[Jarkko Sakkinen]

On Sat, Oct 22, 2016 at 12:39:27AM +0300, Jarkko Sakkinen wrote:
> Use cpu_to_b32 at the time it is needed in enum tpm_capabilities and
> enum tpm_sub_capabilities in order to be consistent with the other
> enums in drivats/char/tpm/tpm.h.
> 
> Signed-off-by: Jarkko Sakkinen 

I'll apply this to my master branch as it is very trivial patch. Report
if you have any problems.

/Jarkko

> ---
> v2: parameter type of subcap_id to u32
>  drivers/char/tpm/tpm-interface.c | 15 +--
>  drivers/char/tpm/tpm-sysfs.c |  4 ++--
>  drivers/char/tpm/tpm.h   | 25 -
>  3 files changed, 23 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c 
> b/drivers/char/tpm/tpm-interface.c
> index acf89e8..fa97520 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -442,26 +442,29 @@ static const struct tpm_input_header tpm_getcap_header 
> = {
>   .ordinal = TPM_ORD_GET_CAP
>  };
>  
> -ssize_t tpm_getcap(struct tpm_chip *chip, __be32 subcap_id, cap_t *cap,
> +ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
>  const char *desc)
>  {
>   struct tpm_cmd_t tpm_cmd;
>   int rc;
>  
>   tpm_cmd.header.in = tpm_getcap_header;
> - if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) {
> - tpm_cmd.params.getcap_in.cap = subcap_id;
> + if (subcap_id == TPM_CAP_VERSION_1_1 ||
> + subcap_id == TPM_CAP_VERSION_1_2) {
> + tpm_cmd.params.getcap_in.cap = cpu_to_be32(subcap_id);
>   /*subcap field not necessary */
>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
>   tpm_cmd.header.in.length -= cpu_to_be32(sizeof(__be32));
>   } else {
>   if (subcap_id == TPM_CAP_FLAG_PERM ||
>   subcap_id == TPM_CAP_FLAG_VOL)
> - tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG;
> + tpm_cmd.params.getcap_in.cap =
> + cpu_to_be32(TPM_CAP_FLAG);
>   else
> - tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> + tpm_cmd.params.getcap_in.cap =
> + cpu_to_be32(TPM_CAP_PROP);
>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> - tpm_cmd.params.getcap_in.subcap = subcap_id;
> + tpm_cmd.params.getcap_in.subcap = cpu_to_be32(subcap_id);
>   }
>   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0,
> desc);
> diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
> index a76ab4a..59a1ead 100644
> --- a/drivers/char/tpm/tpm-sysfs.c
> +++ b/drivers/char/tpm/tpm-sysfs.c
> @@ -193,7 +193,7 @@ static ssize_t caps_show(struct device *dev, struct 
> device_attribute *attr,
>  be32_to_cpu(cap.manufacturer_id));
>  
>   /* Try to get a TPM version 1.2 TPM_CAP_VERSION_INFO */
> - rc = tpm_getcap(chip, CAP_VERSION_1_2, ,
> + rc = tpm_getcap(chip, TPM_CAP_VERSION_1_2, ,
>   "attempting to determine the 1.2 version");
>   if (!rc) {
>   str += sprintf(str,
> @@ -204,7 +204,7 @@ static ssize_t caps_show(struct device *dev, struct 
> device_attribute *attr,
>  cap.tpm_version_1_2.revMinor);
>   } else {
>   /* Otherwise just use TPM_STRUCT_VER */
> - rc = tpm_getcap(chip, CAP_VERSION_1_1, ,
> + rc = tpm_getcap(chip, TPM_CAP_VERSION_1_1, ,
>   "attempting to determine the 1.1 version");
>   if (rc)
>   return 0;
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 4d183c9..1864932 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -282,21 +282,20 @@ typedef union {
>  } cap_t;
>  
>  enum tpm_capabilities {
> - TPM_CAP_FLAG = cpu_to_be32(4),
> - TPM_CAP_PROP = cpu_to_be32(5),
> - CAP_VERSION_1_1 = cpu_to_be32(0x06),
> - CAP_VERSION_1_2 = cpu_to_be32(0x1A)
> + TPM_CAP_FLAG = 4,
> + TPM_CAP_PROP = 5,
> + TPM_CAP_VERSION_1_1 = 0x06,
> + TPM_CAP_VERSION_1_2 = 0x1A,
>  };
>  
>  enum tpm_sub_capabilities {
> - TPM_CAP_PROP_PCR = cpu_to_be32(0x101),
> - TPM_CAP_PROP_MANUFACTURER = cpu_to_be32(0x103),
> - TPM_CAP_FLAG_PERM = cpu_to_be32(0x108),
> - TPM_CAP_FLAG_VOL = cpu_to_be32(0x109),
> - TPM_CAP_PROP_OWNER = cpu_to_be32(0x111),
> - TPM_CAP_PROP_TIS_TIMEOUT = cpu_to_be32(0x115),
> - TPM_CAP_PROP_TIS_DURATION = cpu_to_be32(0x120),
> -
> + TPM_CAP_PROP_PCR = 0x101,
> + TPM_CAP_PROP_MANUFACTURER = 0x103,
> + TPM_CAP_FLAG_PERM = 0x108,
> + TPM_CAP_FLAG_VOL = 0x109,
> + TPM_CAP_PROP_OWNER = 0x111,
> + TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
> + TPM_CAP_PROP_TIS_DURATION = 0x120,
>  };
>  
>  struct   

Re: [PATCH] tpm: sanitize constant expressions

[Jarkko Sakkinen]

On Sat, Oct 22, 2016 at 12:39:27AM +0300, Jarkko Sakkinen wrote:
> Use cpu_to_b32 at the time it is needed in enum tpm_capabilities and
> enum tpm_sub_capabilities in order to be consistent with the other
> enums in drivats/char/tpm/tpm.h.
> 
> Signed-off-by: Jarkko Sakkinen 

I'll apply this to my master branch as it is very trivial patch. Report
if you have any problems.

/Jarkko

> ---
> v2: parameter type of subcap_id to u32
>  drivers/char/tpm/tpm-interface.c | 15 +--
>  drivers/char/tpm/tpm-sysfs.c |  4 ++--
>  drivers/char/tpm/tpm.h   | 25 -
>  3 files changed, 23 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c 
> b/drivers/char/tpm/tpm-interface.c
> index acf89e8..fa97520 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -442,26 +442,29 @@ static const struct tpm_input_header tpm_getcap_header 
> = {
>   .ordinal = TPM_ORD_GET_CAP
>  };
>  
> -ssize_t tpm_getcap(struct tpm_chip *chip, __be32 subcap_id, cap_t *cap,
> +ssize_t tpm_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
>  const char *desc)
>  {
>   struct tpm_cmd_t tpm_cmd;
>   int rc;
>  
>   tpm_cmd.header.in = tpm_getcap_header;
> - if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) {
> - tpm_cmd.params.getcap_in.cap = subcap_id;
> + if (subcap_id == TPM_CAP_VERSION_1_1 ||
> + subcap_id == TPM_CAP_VERSION_1_2) {
> + tpm_cmd.params.getcap_in.cap = cpu_to_be32(subcap_id);
>   /*subcap field not necessary */
>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
>   tpm_cmd.header.in.length -= cpu_to_be32(sizeof(__be32));
>   } else {
>   if (subcap_id == TPM_CAP_FLAG_PERM ||
>   subcap_id == TPM_CAP_FLAG_VOL)
> - tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG;
> + tpm_cmd.params.getcap_in.cap =
> + cpu_to_be32(TPM_CAP_FLAG);
>   else
> - tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> + tpm_cmd.params.getcap_in.cap =
> + cpu_to_be32(TPM_CAP_PROP);
>   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> - tpm_cmd.params.getcap_in.subcap = subcap_id;
> + tpm_cmd.params.getcap_in.subcap = cpu_to_be32(subcap_id);
>   }
>   rc = tpm_transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, 0,
> desc);
> diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
> index a76ab4a..59a1ead 100644
> --- a/drivers/char/tpm/tpm-sysfs.c
> +++ b/drivers/char/tpm/tpm-sysfs.c
> @@ -193,7 +193,7 @@ static ssize_t caps_show(struct device *dev, struct 
> device_attribute *attr,
>  be32_to_cpu(cap.manufacturer_id));
>  
>   /* Try to get a TPM version 1.2 TPM_CAP_VERSION_INFO */
> - rc = tpm_getcap(chip, CAP_VERSION_1_2, ,
> + rc = tpm_getcap(chip, TPM_CAP_VERSION_1_2, ,
>   "attempting to determine the 1.2 version");
>   if (!rc) {
>   str += sprintf(str,
> @@ -204,7 +204,7 @@ static ssize_t caps_show(struct device *dev, struct 
> device_attribute *attr,
>  cap.tpm_version_1_2.revMinor);
>   } else {
>   /* Otherwise just use TPM_STRUCT_VER */
> - rc = tpm_getcap(chip, CAP_VERSION_1_1, ,
> + rc = tpm_getcap(chip, TPM_CAP_VERSION_1_1, ,
>   "attempting to determine the 1.1 version");
>   if (rc)
>   return 0;
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 4d183c9..1864932 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -282,21 +282,20 @@ typedef union {
>  } cap_t;
>  
>  enum tpm_capabilities {
> - TPM_CAP_FLAG = cpu_to_be32(4),
> - TPM_CAP_PROP = cpu_to_be32(5),
> - CAP_VERSION_1_1 = cpu_to_be32(0x06),
> - CAP_VERSION_1_2 = cpu_to_be32(0x1A)
> + TPM_CAP_FLAG = 4,
> + TPM_CAP_PROP = 5,
> + TPM_CAP_VERSION_1_1 = 0x06,
> + TPM_CAP_VERSION_1_2 = 0x1A,
>  };
>  
>  enum tpm_sub_capabilities {
> - TPM_CAP_PROP_PCR = cpu_to_be32(0x101),
> - TPM_CAP_PROP_MANUFACTURER = cpu_to_be32(0x103),
> - TPM_CAP_FLAG_PERM = cpu_to_be32(0x108),
> - TPM_CAP_FLAG_VOL = cpu_to_be32(0x109),
> - TPM_CAP_PROP_OWNER = cpu_to_be32(0x111),
> - TPM_CAP_PROP_TIS_TIMEOUT = cpu_to_be32(0x115),
> - TPM_CAP_PROP_TIS_DURATION = cpu_to_be32(0x120),
> -
> + TPM_CAP_PROP_PCR = 0x101,
> + TPM_CAP_PROP_MANUFACTURER = 0x103,
> + TPM_CAP_FLAG_PERM = 0x108,
> + TPM_CAP_FLAG_VOL = 0x109,
> + TPM_CAP_PROP_OWNER = 0x111,
> + TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
> + TPM_CAP_PROP_TIS_DURATION = 0x120,
>  };
>  
>  struct   tpm_getcap_params_in {
> @@ -484,7 +483,7 

Re: [tpmdd-devel] [PATCH] tpm, tpm_crb: remove redundant CRB_FL_CRB_START flag

[Jarkko Sakkinen]

On Fri, Oct 21, 2016 at 06:11:41PM +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 20, 2016 at 02:24:21PM -0600, Jason Gunthorpe wrote:
> > On Thu, Oct 20, 2016 at 05:00:11PM +0300, Jarkko Sakkinen wrote:
> > 
> > > > > I have a 4th Gen Core NUC where I experienced this issue. It reported
> > > > > requiring only ACPI start but actually required ACPI + CRB start. The
> > > > > comment could have been better.
> > 
> > Shouldn't bios work arounds be keyed on something? What happens if a
> > system rolls around that cannot do ACPI + CRB start? How does this
> > system work in windows?
> 
> I didn't find anything better to key it on at the time and it has been
> working for two years now without any problems.

I've though about this and came to conclusion that maybe I won't apply
this patch because it is good to keep this robustness in for now. I
think your point is valid.

/Jarkko

Re: [tpmdd-devel] [PATCH] tpm, tpm_crb: remove redundant CRB_FL_CRB_START flag

[Jarkko Sakkinen]

On Fri, Oct 21, 2016 at 06:11:41PM +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 20, 2016 at 02:24:21PM -0600, Jason Gunthorpe wrote:
> > On Thu, Oct 20, 2016 at 05:00:11PM +0300, Jarkko Sakkinen wrote:
> > 
> > > > > I have a 4th Gen Core NUC where I experienced this issue. It reported
> > > > > requiring only ACPI start but actually required ACPI + CRB start. The
> > > > > comment could have been better.
> > 
> > Shouldn't bios work arounds be keyed on something? What happens if a
> > system rolls around that cannot do ACPI + CRB start? How does this
> > system work in windows?
> 
> I didn't find anything better to key it on at the time and it has been
> working for two years now without any problems.

I've though about this and came to conclusion that maybe I won't apply
this patch because it is good to keep this robustness in for now. I
think your point is valid.

/Jarkko

Re: [PATCH 3/3] usb: dwc3: host: Do not use dma_coerce_mask_and_coherent

[Arnd Bergmann]

On Tuesday, October 25, 2016 4:26:28 PM CEST Sriram Dash wrote:
> Do not use dma_coerce_mask_and_coherent for hcd.
> 
> Signed-off-by: Arnd Bergmann 

The patch is good, but please follow the usual rules for submitting
someone else's patch:

- As the first line, have "From: Arnd Bergmann ".
  "git format-patch" adds this automatically if you pass that
  address as the "--author" argument to "git commit".

- Add you "Signed-off-by" line at below mine (or any other lines)

I would also suggest a more elaborate changelog text, the
free-form text should explain why something is done, rather than
repeat the subject:

| The dma mask is correctly set up by the DT probe function, no
| need to override it any more.

Arnd

Re: [PATCH 3/3] usb: dwc3: host: Do not use dma_coerce_mask_and_coherent

[Arnd Bergmann]

On Tuesday, October 25, 2016 4:26:28 PM CEST Sriram Dash wrote:
> Do not use dma_coerce_mask_and_coherent for hcd.
> 
> Signed-off-by: Arnd Bergmann 

The patch is good, but please follow the usual rules for submitting
someone else's patch:

- As the first line, have "From: Arnd Bergmann ".
  "git format-patch" adds this automatically if you pass that
  address as the "--author" argument to "git commit".

- Add you "Signed-off-by" line at below mine (or any other lines)

I would also suggest a more elaborate changelog text, the
free-form text should explain why something is done, rather than
repeat the subject:

| The dma mask is correctly set up by the DT probe function, no
| need to override it any more.

Arnd

Re: [PATCH V2 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()

[Stephen Boyd]

On 10/25, Viresh Kumar wrote:
> On 24-10-16, 16:14, Stephen Boyd wrote:
> > On 10/20, Viresh Kumar wrote:
> > > Pass the entire supply structure instead of all of its fields.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > > ---
> > 
> > This patch should be combined with the previous one.
> 
> I think it is a fair to do this separately as this is a completely different
> logical change.

Let's agree to disagree.

> 
> > I'm still
> > not sure if it even makes sense to do this though.
> 
> :)
> 
> > Do we really
> > have to make duplicate "OPP snapshot" structures just because of
> > how OPPs use RCU?
> 
> I agree. With RCU, yes this change is probably required. But I am not sure if
> RCU fits that well to OPP core anymore. A rw-lock may be much easier to help.
> 

For things like AVS we'll probably want to do that, although it's
sort of funny because replacing RCU with rw-locks is the opposite
direction most people go. With AVS we would be updating the
voltage(s) in use for the current OPP, and we would want that
update to block any OPP transition until the voltage is adjusted.
I don't know how we would do that with RCU very well. Plus, RCU
is for reader heavy things, but we mostly have one or two
readers.

I guess it's ok for now to do all this copying, but it feels like
we'll need to undo a large portion of it later with things like
AVS. Or at least we'll be doing copies for almost no reason
because we'll want to hold the read lock across the whole OPP
transition. I was going to suggest we pass around information
about what we want to grab from the RCU protected data
structures, think index of regulator, etc. and then have small
RCU read-side critical sections to grab that info during the OPP
transition but I'm not sure that's any better. It might be worse
because the OPP could change during the OPP transition and we
could be using half of the old and half of the new data.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V2 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()

[Stephen Boyd]

On 10/25, Viresh Kumar wrote:
> On 24-10-16, 16:14, Stephen Boyd wrote:
> > On 10/20, Viresh Kumar wrote:
> > > Pass the entire supply structure instead of all of its fields.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > > ---
> > 
> > This patch should be combined with the previous one.
> 
> I think it is a fair to do this separately as this is a completely different
> logical change.

Let's agree to disagree.

> 
> > I'm still
> > not sure if it even makes sense to do this though.
> 
> :)
> 
> > Do we really
> > have to make duplicate "OPP snapshot" structures just because of
> > how OPPs use RCU?
> 
> I agree. With RCU, yes this change is probably required. But I am not sure if
> RCU fits that well to OPP core anymore. A rw-lock may be much easier to help.
> 

For things like AVS we'll probably want to do that, although it's
sort of funny because replacing RCU with rw-locks is the opposite
direction most people go. With AVS we would be updating the
voltage(s) in use for the current OPP, and we would want that
update to block any OPP transition until the voltage is adjusted.
I don't know how we would do that with RCU very well. Plus, RCU
is for reader heavy things, but we mostly have one or two
readers.

I guess it's ok for now to do all this copying, but it feels like
we'll need to undo a large portion of it later with things like
AVS. Or at least we'll be doing copies for almost no reason
because we'll want to hold the read lock across the whole OPP
transition. I was going to suggest we pass around information
about what we want to grab from the RCU protected data
structures, think index of regulator, etc. and then have small
RCU read-side critical sections to grab that info during the OPP
transition but I'm not sure that's any better. It might be worse
because the OPP could change during the OPP transition and we
could be using half of the old and half of the new data.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC v2] ARM: memory: da8xx-ddrctl: new driver

[Kevin Hilman]

Kevin Hilman  writes:

> Bartosz Golaszewski  writes:
>
>> Create a new driver for the da8xx DDR2/mDDR controller and implement
>> support for writing to the Peripheral Bus Burst Priority Register.
>>
>> Signed-off-by: Bartosz Golaszewski 
>> ---
>>  .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++
>>  drivers/memory/Kconfig |   8 +
>>  drivers/memory/Makefile|   1 +
>>  drivers/memory/da8xx-ddrctl.c  | 175 
>> +
>>  4 files changed, 204 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>>  create mode 100644 drivers/memory/da8xx-ddrctl.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> new file mode 100644
>> index 000..7e271dd
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> @@ -0,0 +1,20 @@
>> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory 
>> controller
>> +
>> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs 
>> features
>> +a set of registers which allow to tweak the controller's behavior.
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible:   "ti,da850-ddr-controller" - for da850 SoC based 
>> boards
>> +- reg:  a tuple containing the base address of the 
>> memory
>> +controller and the size of the memory area to map
>> +
>> +Example for da850 shown below.
>> +
>> +ddrctl {
>> +compatible = "ti,da850-ddr-controller";
>> +reg = <0xB000 0x100>;
>> +};
>
> Axel's series for the USB PHY reminded me that the PHY also has some
> config registers in this same area, and his series creates a syscon for
> a similar range of registers.
>
> Could you create a syscon for the SYSCFG0 registers, which would then
> be used by ths driver and your other drivers/bus driver?  Then the
> binding  would just reference the sysconf via phandle, and your driver
> can use syscon_regmap_lookup_by_phandle()

Nevermind. I though that the config register in this driver was also in
SYSCFG0, but I see now that it's in the reg region of the DDR controller
itself, so no syscon is needed.

Kevin

Re: [RFC v2] ARM: memory: da8xx-ddrctl: new driver

[Kevin Hilman]

Kevin Hilman  writes:

> Bartosz Golaszewski  writes:
>
>> Create a new driver for the da8xx DDR2/mDDR controller and implement
>> support for writing to the Peripheral Bus Burst Priority Register.
>>
>> Signed-off-by: Bartosz Golaszewski 
>> ---
>>  .../memory-controllers/ti-da8xx-ddrctl.txt |  20 +++
>>  drivers/memory/Kconfig |   8 +
>>  drivers/memory/Makefile|   1 +
>>  drivers/memory/da8xx-ddrctl.c  | 175 
>> +
>>  4 files changed, 204 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>>  create mode 100644 drivers/memory/da8xx-ddrctl.c
>>
>> diff --git
>> a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> new file mode 100644
>> index 000..7e271dd
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> @@ -0,0 +1,20 @@
>> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory 
>> controller
>> +
>> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs 
>> features
>> +a set of registers which allow to tweak the controller's behavior.
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible:   "ti,da850-ddr-controller" - for da850 SoC based 
>> boards
>> +- reg:  a tuple containing the base address of the 
>> memory
>> +controller and the size of the memory area to map
>> +
>> +Example for da850 shown below.
>> +
>> +ddrctl {
>> +compatible = "ti,da850-ddr-controller";
>> +reg = <0xB000 0x100>;
>> +};
>
> Axel's series for the USB PHY reminded me that the PHY also has some
> config registers in this same area, and his series creates a syscon for
> a similar range of registers.
>
> Could you create a syscon for the SYSCFG0 registers, which would then
> be used by ths driver and your other drivers/bus driver?  Then the
> binding  would just reference the sysconf via phandle, and your driver
> can use syscon_regmap_lookup_by_phandle()

Nevermind. I though that the config register in this driver was also in
SYSCFG0, but I see now that it's in the reg region of the DDR controller
itself, so no syscon is needed.

Kevin

Re: [PATCH 1/3] drivers: iommu: arm-smmu: constify iommu_gather_ops structures

[Julia Lawall]

On Tue, 25 Oct 2016, Bhumika Goyal wrote:

> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const.
>
> Signed-off-by: Bhumika Goyal 

Acked-by: Julia Lawall 

> ---
>  drivers/iommu/arm-smmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..a5bc8fb 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -640,7 +640,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long 
> iova, size_t size,
>   }
>  }
>
> -static struct iommu_gather_ops arm_smmu_gather_ops = {
> +static const struct iommu_gather_ops arm_smmu_gather_ops = {
>   .tlb_flush_all  = arm_smmu_tlb_inv_context,
>   .tlb_add_flush  = arm_smmu_tlb_inv_range_nosync,
>   .tlb_sync   = arm_smmu_tlb_sync,
> --
> 1.9.1
>
>

Re: [PATCH 1/3] drivers: iommu: arm-smmu: constify iommu_gather_ops structures

[Julia Lawall]

On Tue, 25 Oct 2016, Bhumika Goyal wrote:

> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const.
>
> Signed-off-by: Bhumika Goyal 

Acked-by: Julia Lawall 

> ---
>  drivers/iommu/arm-smmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..a5bc8fb 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -640,7 +640,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long 
> iova, size_t size,
>   }
>  }
>
> -static struct iommu_gather_ops arm_smmu_gather_ops = {
> +static const struct iommu_gather_ops arm_smmu_gather_ops = {
>   .tlb_flush_all  = arm_smmu_tlb_inv_context,
>   .tlb_add_flush  = arm_smmu_tlb_inv_range_nosync,
>   .tlb_sync   = arm_smmu_tlb_sync,
> --
> 1.9.1
>
>

Re: [PATCH 2/3] drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures

[Julia Lawall]

On Tue, 25 Oct 2016, Bhumika Goyal wrote:

> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const.
>
> Signed-off-by: Bhumika Goyal 

Acked-by: Julia Lawall 

> ---
>  drivers/iommu/arm-smmu-v3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 15c01c3..51d8be4 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1358,7 +1358,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long 
> iova, size_t size,
>   } while (size -= granule);
>  }
>
> -static struct iommu_gather_ops arm_smmu_gather_ops = {
> +static const struct iommu_gather_ops arm_smmu_gather_ops = {
>   .tlb_flush_all  = arm_smmu_tlb_inv_context,
>   .tlb_add_flush  = arm_smmu_tlb_inv_range_nosync,
>   .tlb_sync   = arm_smmu_tlb_sync,
> --
> 1.9.1
>
>

[PATCH v2] cw1200: fix bogus maybe-uninitialized warning

[Arnd Bergmann]

On x86, the cw1200 driver produces a rather silly warning about the
possible use of the 'ret' variable without an initialization
presumably after being confused by the architecture specific definition
of WARN_ON:

drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

We have already checked that 'count' is larger than 0 here, so
we know that 'ret' is initialized. Changing the 'for' loop
into do/while also makes this clear to the compiler.

Suggested-by: David Laight 
Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/st/cw1200/wsm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

v2: rewrite based on David Laight's suggestion, the first version
was completely wrong.

diff --git a/drivers/net/wireless/st/cw1200/wsm.c 
b/drivers/net/wireless/st/cw1200/wsm.c
index 680d60eabc75..ed93bf3474ec 100644
--- a/drivers/net/wireless/st/cw1200/wsm.c
+++ b/drivers/net/wireless/st/cw1200/wsm.c
@@ -379,7 +379,6 @@ static int wsm_multi_tx_confirm(struct cw1200_common *priv,
 {
int ret;
int count;
-   int i;
 
count = WSM_GET32(buf);
if (WARN_ON(count <= 0))
@@ -395,11 +394,10 @@ static int wsm_multi_tx_confirm(struct cw1200_common 
*priv,
}
 
cw1200_debug_txed_multi(priv, count);
-   for (i = 0; i < count; ++i) {
+   do {
ret = wsm_tx_confirm(priv, buf, link_id);
-   if (ret)
-   return ret;
-   }
+   } while (!ret && --count);
+
return ret;
 
 underflow:
-- 
2.9.0

Re: [PATCH 2/3] drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures

[Julia Lawall]

On Tue, 25 Oct 2016, Bhumika Goyal wrote:

> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const.
>
> Signed-off-by: Bhumika Goyal 

Acked-by: Julia Lawall 

> ---
>  drivers/iommu/arm-smmu-v3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 15c01c3..51d8be4 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1358,7 +1358,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long 
> iova, size_t size,
>   } while (size -= granule);
>  }
>
> -static struct iommu_gather_ops arm_smmu_gather_ops = {
> +static const struct iommu_gather_ops arm_smmu_gather_ops = {
>   .tlb_flush_all  = arm_smmu_tlb_inv_context,
>   .tlb_add_flush  = arm_smmu_tlb_inv_range_nosync,
>   .tlb_sync   = arm_smmu_tlb_sync,
> --
> 1.9.1
>
>

[PATCH v2] cw1200: fix bogus maybe-uninitialized warning

[Arnd Bergmann]

On x86, the cw1200 driver produces a rather silly warning about the
possible use of the 'ret' variable without an initialization
presumably after being confused by the architecture specific definition
of WARN_ON:

drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’:
drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]

We have already checked that 'count' is larger than 0 here, so
we know that 'ret' is initialized. Changing the 'for' loop
into do/while also makes this clear to the compiler.

Suggested-by: David Laight 
Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/st/cw1200/wsm.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

v2: rewrite based on David Laight's suggestion, the first version
was completely wrong.

diff --git a/drivers/net/wireless/st/cw1200/wsm.c 
b/drivers/net/wireless/st/cw1200/wsm.c
index 680d60eabc75..ed93bf3474ec 100644
--- a/drivers/net/wireless/st/cw1200/wsm.c
+++ b/drivers/net/wireless/st/cw1200/wsm.c
@@ -379,7 +379,6 @@ static int wsm_multi_tx_confirm(struct cw1200_common *priv,
 {
int ret;
int count;
-   int i;
 
count = WSM_GET32(buf);
if (WARN_ON(count <= 0))
@@ -395,11 +394,10 @@ static int wsm_multi_tx_confirm(struct cw1200_common 
*priv,
}
 
cw1200_debug_txed_multi(priv, count);
-   for (i = 0; i < count; ++i) {
+   do {
ret = wsm_tx_confirm(priv, buf, link_id);
-   if (ret)
-   return ret;
-   }
+   } while (!ret && --count);
+
return ret;
 
 underflow:
-- 
2.9.0

Re: [PATCH] cw1200: fix bogus maybe-uninitialized warning

[Arnd Bergmann]

On Tuesday, October 25, 2016 1:24:55 PM CEST David Laight wrote:
> > diff --git a/drivers/net/wireless/st/cw1200/wsm.c 
> > b/drivers/net/wireless/st/cw1200/wsm.c
> > index 680d60eabc75..094e6637ade2 100644
> > --- a/drivers/net/wireless/st/cw1200/wsm.c
> > +++ b/drivers/net/wireless/st/cw1200/wsm.c
> > @@ -385,14 +385,13 @@ static int wsm_multi_tx_confirm(struct cw1200_common 
> > *priv,
> >   if (WARN_ON(count <= 0))
> >   return -EINVAL;
> > 
> > - if (count > 1) {
> > - /* We already released one buffer, now for the rest */
> > - ret = wsm_release_tx_buffer(priv, count - 1);
> > - if (ret < 0)
> > - return ret;
> > - else if (ret > 0)
> > - cw1200_bh_wakeup(priv);
> > - }
> > + /* We already released one buffer, now for the rest */
> > + ret = wsm_release_tx_buffer(priv, count - 1);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (ret > 0)
> > + cw1200_bh_wakeup(priv);
> 
> That doesn't look equivalent to me (when count == 1).

Ah, that's what I missed, thanks for pointing that out!

> > 
> >   cw1200_debug_txed_multi(priv, count);
> >   for (i = 0; i < count; ++i) {
> 
> Convert this loop into a do ... while so the body executes at least once.

Good idea. Version 2 coming now.

Arnd

Re: [PATCH] cw1200: fix bogus maybe-uninitialized warning

[Arnd Bergmann]

On Tuesday, October 25, 2016 1:24:55 PM CEST David Laight wrote:
> > diff --git a/drivers/net/wireless/st/cw1200/wsm.c 
> > b/drivers/net/wireless/st/cw1200/wsm.c
> > index 680d60eabc75..094e6637ade2 100644
> > --- a/drivers/net/wireless/st/cw1200/wsm.c
> > +++ b/drivers/net/wireless/st/cw1200/wsm.c
> > @@ -385,14 +385,13 @@ static int wsm_multi_tx_confirm(struct cw1200_common 
> > *priv,
> >   if (WARN_ON(count <= 0))
> >   return -EINVAL;
> > 
> > - if (count > 1) {
> > - /* We already released one buffer, now for the rest */
> > - ret = wsm_release_tx_buffer(priv, count - 1);
> > - if (ret < 0)
> > - return ret;
> > - else if (ret > 0)
> > - cw1200_bh_wakeup(priv);
> > - }
> > + /* We already released one buffer, now for the rest */
> > + ret = wsm_release_tx_buffer(priv, count - 1);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (ret > 0)
> > + cw1200_bh_wakeup(priv);
> 
> That doesn't look equivalent to me (when count == 1).

Ah, that's what I missed, thanks for pointing that out!

> > 
> >   cw1200_debug_txed_multi(priv, count);
> >   for (i = 0; i < count; ++i) {
> 
> Convert this loop into a do ... while so the body executes at least once.

Good idea. Version 2 coming now.

Arnd

Re: [PATCH 3/3] drivers: iommu: io-pgtable-arm: use const and __initconst for iommu_gather_ops structures

[Julia Lawall]

On Tue, 25 Oct 2016, Bhumika Goyal wrote:

> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const. Also, replace __initdata
> with __initconst.
>
> Signed-off-by: Bhumika Goyal 

Acked-by: Julia Lawall 

> ---
>  drivers/iommu/io-pgtable-arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index f5c90e1..412e21d 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -916,7 +916,7 @@ static void dummy_tlb_sync(void *cookie)
>   WARN_ON(cookie != cfg_cookie);
>  }
>
> -static struct iommu_gather_ops dummy_tlb_ops __initdata = {
> +static const struct iommu_gather_ops dummy_tlb_ops __initconst = {
>   .tlb_flush_all  = dummy_tlb_flush_all,
>   .tlb_add_flush  = dummy_tlb_add_flush,
>   .tlb_sync   = dummy_tlb_sync,
> --
> 1.9.1
>
>

Re: [PATCH 3/3] drivers: iommu: io-pgtable-arm: use const and __initconst for iommu_gather_ops structures

[Julia Lawall]

On Tue, 25 Oct 2016, Bhumika Goyal wrote:

> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const. Also, replace __initdata
> with __initconst.
>
> Signed-off-by: Bhumika Goyal 

Acked-by: Julia Lawall 

> ---
>  drivers/iommu/io-pgtable-arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index f5c90e1..412e21d 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -916,7 +916,7 @@ static void dummy_tlb_sync(void *cookie)
>   WARN_ON(cookie != cfg_cookie);
>  }
>
> -static struct iommu_gather_ops dummy_tlb_ops __initdata = {
> +static const struct iommu_gather_ops dummy_tlb_ops __initconst = {
>   .tlb_flush_all  = dummy_tlb_flush_all,
>   .tlb_add_flush  = dummy_tlb_add_flush,
>   .tlb_sync   = dummy_tlb_sync,
> --
> 1.9.1
>
>

Re: [PATCH v2 2/8] IB/core: Replace semaphore sm_sem with completion

[Arnd Bergmann]

On Tuesday, October 25, 2016 9:48:22 AM CEST Jason Gunthorpe wrote:
> 
> Using a completion to model exclusive ownership seems convoluted to
> me - is that a thing now? What about an atomic?

I also totally missed how this is used. I initially mentioned to Binoy
that almost all semaphores can either be converted to a mutex or a
completion unless they rely on the counting behavior of the semaphore.

This driver clearly falls into another category and none of the above
apply here.

> open:
> 
> while (true) {
>wait_event_interruptible(priv->queue,test_bit(CLAIMED_BIT, >flags));
>if (!test_and_set_bit(CLAIMED_BIT, >flags))
> break;
> }

I'd fold the test_and_set_bit() into the wait_event() and get rid of the
loop here, otherwise this looks nice.

I'm generally a bit suspicious of open() functions that try to
protect you from having multiple file descriptors open, as dup()
or fork() will also result in extra file descriptors, but this
use here seems harmless, as the device itself only supports
open() and close() and the only thing it does is to keep track
of whether it is open or not.

It's also interesting that the ib_modify_port() function also
keeps track of the a flag that is set in open() and cleared
in close(), so in principle we should be able to unify this
with the semaphore, but the wait_event() approach is certainly
much simpler.

Arnd

Re: [PATCH v2 2/8] IB/core: Replace semaphore sm_sem with completion

[Arnd Bergmann]

On Tuesday, October 25, 2016 9:48:22 AM CEST Jason Gunthorpe wrote:
> 
> Using a completion to model exclusive ownership seems convoluted to
> me - is that a thing now? What about an atomic?

I also totally missed how this is used. I initially mentioned to Binoy
that almost all semaphores can either be converted to a mutex or a
completion unless they rely on the counting behavior of the semaphore.

This driver clearly falls into another category and none of the above
apply here.

> open:
> 
> while (true) {
>wait_event_interruptible(priv->queue,test_bit(CLAIMED_BIT, >flags));
>if (!test_and_set_bit(CLAIMED_BIT, >flags))
> break;
> }

I'd fold the test_and_set_bit() into the wait_event() and get rid of the
loop here, otherwise this looks nice.

I'm generally a bit suspicious of open() functions that try to
protect you from having multiple file descriptors open, as dup()
or fork() will also result in extra file descriptors, but this
use here seems harmless, as the device itself only supports
open() and close() and the only thing it does is to keep track
of whether it is open or not.

It's also interesting that the ib_modify_port() function also
keeps track of the a flag that is set in open() and cleared
in close(), so in principle we should be able to unify this
with the semaphore, but the wait_event() approach is certainly
much simpler.

Arnd

Re: [PATCH] virtio-net: Update the mtu code to match virtio spec

[Aaron Conole]

Aaron Conole  writes:

>> From: Aaron Conole 
>>
>> The virtio committee recently ratified a change, VIRTIO-152, which
>> defines the mtu field to be 'max' MTU, not simply desired MTU.
>>
>> This commit brings the virtio-net device in compliance with VIRTIO-152.
>>
>> Additionally, drop the max_mtu branch - it cannot be taken since the u16
>> returned by virtio_cread16 will never exceed the initial value of
>> max_mtu.
>>
>> Cc: "Michael S. Tsirkin" 
>> Cc: Jarod Wilson 
>> Signed-off-by: Aaron Conole 
>> ---
>
> Sorry about the subject line, David.  This is targetted at net-next, and
> it appears my from was mangled.  Would you like me to resubmit with
> these details corrected?

I answered my own question.  Sorry for the noise.

Re: [PATCH] virtio-net: Update the mtu code to match virtio spec

[Aaron Conole]

Aaron Conole  writes:

>> From: Aaron Conole 
>>
>> The virtio committee recently ratified a change, VIRTIO-152, which
>> defines the mtu field to be 'max' MTU, not simply desired MTU.
>>
>> This commit brings the virtio-net device in compliance with VIRTIO-152.
>>
>> Additionally, drop the max_mtu branch - it cannot be taken since the u16
>> returned by virtio_cread16 will never exceed the initial value of
>> max_mtu.
>>
>> Cc: "Michael S. Tsirkin" 
>> Cc: Jarod Wilson 
>> Signed-off-by: Aaron Conole 
>> ---
>
> Sorry about the subject line, David.  This is targetted at net-next, and
> it appears my from was mangled.  Would you like me to resubmit with
> these details corrected?

I answered my own question.  Sorry for the noise.

[PATCH v2 net-next] virtio-net: Update the mtu code to match virtio spec

[Aaron Conole]

The virtio committee recently ratified a change, VIRTIO-152, which
defines the mtu field to be 'max' MTU, not simply desired MTU.

This commit brings the virtio-net device in compliance with VIRTIO-152.

Additionally, drop the max_mtu branch - it cannot be taken since the u16
returned by virtio_cread16 will never exceed the initial value of
max_mtu.

Signed-off-by: Aaron Conole 
Acked-by: "Michael S. Tsirkin" 
Acked-by: Jarod Wilson 
---
Nothing code-wise has changed, but I've included the ACKs and fixed up the
subject line.

 drivers/net/virtio_net.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 720809f..2cafd12 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1870,10 +1870,12 @@ static int virtnet_probe(struct virtio_device *vdev)
mtu = virtio_cread16(vdev,
 offsetof(struct virtio_net_config,
  mtu));
-   if (mtu < dev->min_mtu || mtu > dev->max_mtu)
+   if (mtu < dev->min_mtu) {
__virtio_clear_bit(vdev, VIRTIO_NET_F_MTU);
-   else
+   } else {
dev->mtu = mtu;
+   dev->max_mtu = mtu;
+   }
}
 
if (vi->any_header_sg)
-- 
2.7.4

[PATCH v2 net-next] virtio-net: Update the mtu code to match virtio spec

[Aaron Conole]

The virtio committee recently ratified a change, VIRTIO-152, which
defines the mtu field to be 'max' MTU, not simply desired MTU.

This commit brings the virtio-net device in compliance with VIRTIO-152.

Additionally, drop the max_mtu branch - it cannot be taken since the u16
returned by virtio_cread16 will never exceed the initial value of
max_mtu.

Signed-off-by: Aaron Conole 
Acked-by: "Michael S. Tsirkin" 
Acked-by: Jarod Wilson 
---
Nothing code-wise has changed, but I've included the ACKs and fixed up the
subject line.

 drivers/net/virtio_net.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 720809f..2cafd12 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1870,10 +1870,12 @@ static int virtnet_probe(struct virtio_device *vdev)
mtu = virtio_cread16(vdev,
 offsetof(struct virtio_net_config,
  mtu));
-   if (mtu < dev->min_mtu || mtu > dev->max_mtu)
+   if (mtu < dev->min_mtu) {
__virtio_clear_bit(vdev, VIRTIO_NET_F_MTU);
-   else
+   } else {
dev->mtu = mtu;
+   dev->max_mtu = mtu;
+   }
}
 
if (vi->any_header_sg)
-- 
2.7.4

Re: Regression caused by commit c83ed4c9dbb3 "ubifs: Abort readdir on error"

[Richard Weinberger]

Peter,

On 25.10.2016 21:39, Peter Rosin wrote:
> Hi!
> 
> Early on in my boot procedure I create an overlay and shuffle
> things around a bit so that the original rootfs stays readonly
> at the bottom of an overlayed readwrite fs. This way I can just
> toss out the overlayed fs and have a clean and reliable way to
> do a "factory-reset". Both the read-only root and and the overlay
> are ubifs on nand.
> 
> Bisection points to commit c83ed4c9dbb3 "ubifs: Abort readdir
> on error". Reverting that commit on top of v4.9-rc2 fixes things.
> 
> My "shuffle script" is as follows (with an added comment
> indicating the first point of failure) and runs as the first
> script by init.
> 
> If I add a line
>   ls -l /mnt || echo "ls -l /mnt failed"
> where that comment is right before the failure, I get no failure
> indication even with the broken commit, so directory traversal
> seems ok.
> 
> Cheers,
> Peter
> 
> #! /bin/bash
> 
> test "x$1" == xstart || exit 0
> 
> mkdir /tmp/log
> 
> /bin/mount -o remount,rw /dev
> 
> /bin/mount | /bin/grep -q "^overlay on / type overlay" && exit 0
> 
> if test -e /etc/factory-reset; then
>   /usr/sbin/ubiformat /dev/mtd7
>   rm /etc/factory-reset
> fi
> 
> /usr/sbin/ubiattach /dev/ubi_ctrl -m 7
> /usr/sbin/ubimkvol /dev/ubi1 -N ovl -m
> 
> /bin/mkdir -p /mnt/ovl
> /bin/mkdir -p /mnt/roroot
> /bin/mkdir -p /mnt/merge
> /bin/mount -t ubifs /dev/ubi1_0 /mnt/ovl
> 
> /bin/mkdir -p /mnt/ovl/ovl
> /bin/mkdir -p /mnt/ovl/work
> # with c83ed4c9dbb3, the following mount fails with
> # mount: mounting overlay on /mnt/merge failed: No such file or directory
> /bin/mount -t overlay -o 
> lowerdir=/,upperdir=/mnt/ovl/ovl,workdir=/mnt/ovl/work overlay /mnt/merge

U! Thanks for catching this.
I think I know what is going on, the fix exposes now internal UBIFS return 
codes to VFS.
Let me prepare a fix.

Thanks,
//richard

Re: Regression caused by commit c83ed4c9dbb3 "ubifs: Abort readdir on error"

[Richard Weinberger]

Peter,

On 25.10.2016 21:39, Peter Rosin wrote:
> Hi!
> 
> Early on in my boot procedure I create an overlay and shuffle
> things around a bit so that the original rootfs stays readonly
> at the bottom of an overlayed readwrite fs. This way I can just
> toss out the overlayed fs and have a clean and reliable way to
> do a "factory-reset". Both the read-only root and and the overlay
> are ubifs on nand.
> 
> Bisection points to commit c83ed4c9dbb3 "ubifs: Abort readdir
> on error". Reverting that commit on top of v4.9-rc2 fixes things.
> 
> My "shuffle script" is as follows (with an added comment
> indicating the first point of failure) and runs as the first
> script by init.
> 
> If I add a line
>   ls -l /mnt || echo "ls -l /mnt failed"
> where that comment is right before the failure, I get no failure
> indication even with the broken commit, so directory traversal
> seems ok.
> 
> Cheers,
> Peter
> 
> #! /bin/bash
> 
> test "x$1" == xstart || exit 0
> 
> mkdir /tmp/log
> 
> /bin/mount -o remount,rw /dev
> 
> /bin/mount | /bin/grep -q "^overlay on / type overlay" && exit 0
> 
> if test -e /etc/factory-reset; then
>   /usr/sbin/ubiformat /dev/mtd7
>   rm /etc/factory-reset
> fi
> 
> /usr/sbin/ubiattach /dev/ubi_ctrl -m 7
> /usr/sbin/ubimkvol /dev/ubi1 -N ovl -m
> 
> /bin/mkdir -p /mnt/ovl
> /bin/mkdir -p /mnt/roroot
> /bin/mkdir -p /mnt/merge
> /bin/mount -t ubifs /dev/ubi1_0 /mnt/ovl
> 
> /bin/mkdir -p /mnt/ovl/ovl
> /bin/mkdir -p /mnt/ovl/work
> # with c83ed4c9dbb3, the following mount fails with
> # mount: mounting overlay on /mnt/merge failed: No such file or directory
> /bin/mount -t overlay -o 
> lowerdir=/,upperdir=/mnt/ovl/ovl,workdir=/mnt/ovl/work overlay /mnt/merge

U! Thanks for catching this.
I think I know what is going on, the fix exposes now internal UBIFS return 
codes to VFS.
Let me prepare a fix.

Thanks,
//richard

[PATCH v3 1/1] ahci: imx: Add imx53 SATA temperature sensor support

[Fabien Lahoudere]

From: Csaba Kertesz 

Add a hwmon entry to get the temperature from the die of imx53
SATA.

The original patch was made by Richard Zhu for kernel 2.6.x:
ENGR00134041-MX53-Add-the-SATA-AHCI-temperature-monitor.patch

Signed-off-by: Fabien Lahoudere 
---
 drivers/ata/ahci_imx.c | 195 +
 1 file changed, 195 insertions(+)

diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 3f3a7db..420f065 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -26,6 +26,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "ahci.h"
 
 #define DRV_NAME "ahci-imx"
@@ -214,6 +217,180 @@ static int imx_sata_phy_reset(struct ahci_host_priv 
*hpriv)
return timeout ? 0 : -ETIMEDOUT;
 }
 
+enum {
+   /* SATA PHY Register */
+   SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT = 0x0001,
+   SATA_PHY_CR_CLOCK_DAC_CTL = 0x0008,
+   SATA_PHY_CR_CLOCK_RTUNE_CTL = 0x0009,
+   SATA_PHY_CR_CLOCK_ADC_OUT = 0x000A,
+   SATA_PHY_CR_CLOCK_MPLL_TST = 0x0017,
+};
+
+static int read_adc_sum(void *dev, u16 rtune_ctl_reg, void __iomem * mmio)
+{
+   u16 adc_out_reg, read_sum;
+   u32 index, read_attempt;
+   const u32 attempt_limit = 100;
+
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+   imx_phy_reg_write(rtune_ctl_reg, mmio);
+
+   /* two dummy read */
+   index = 0;
+   read_attempt = 0;
+   adc_out_reg = 0;
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_ADC_OUT, mmio);
+   while (index < 2) {
+   imx_phy_reg_read(_out_reg, mmio);
+   /* check if valid */
+   if (adc_out_reg & 0x400)
+   index++;
+
+   read_attempt++;
+   if (read_attempt > attempt_limit) {
+   dev_err(dev, "Read REG more than %d times!\n",
+   attempt_limit);
+   break;
+   }
+   }
+
+   index = 0;
+   read_attempt = 0;
+   read_sum = 0;
+   while (index < 80) {
+   imx_phy_reg_read(_out_reg, mmio);
+   if (adc_out_reg & 0x400) {
+   read_sum = read_sum + (adc_out_reg & 0x3FF);
+   index++;
+   }
+   read_attempt++;
+   if (read_attempt > attempt_limit) {
+   dev_err(dev, "Read REG more than %d times!\n",
+   attempt_limit);
+   break;
+   }
+   }
+
+   /* Use the U32 to make 1000 precision */
+   return (read_sum * 1000) / 80;
+}
+
+/* SATA AHCI temperature monitor */
+static int sata_ahci_read_temperature(void *dev, int *temp)
+{
+   u16 mpll_test_reg, rtune_ctl_reg, dac_ctl_reg, read_sum;
+   u32 str1, str2, str3, str4;
+   int m1, m2, a;
+   struct ahci_host_priv *hpriv = dev_get_drvdata(dev);
+   void __iomem *mmio = hpriv->mmio;
+
+   /* check rd-wr to reg */
+   read_sum = 0;
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT, mmio);
+   imx_phy_reg_write(read_sum, mmio);
+   imx_phy_reg_read(_sum, mmio);
+   if ((read_sum & 0x) != 0)
+   dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+   imx_phy_reg_write(0x5A5A, mmio);
+   imx_phy_reg_read(_sum, mmio);
+   if ((read_sum & 0x) != 0x5A5A)
+   dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+   imx_phy_reg_write(0x1234, mmio);
+   imx_phy_reg_read(_sum, mmio);
+   if ((read_sum & 0x) != 0x1234)
+   dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+   /* start temperature test */
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+   imx_phy_reg_read(_test_reg, mmio);
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+   imx_phy_reg_read(_ctl_reg, mmio);
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+   imx_phy_reg_read(_ctl_reg, mmio);
+
+   /* mpll_tst.meas_iv   ([12:2]) */
+   str1 = (mpll_test_reg >> 2) & 0x7FF;
+   /* rtune_ctl.mode ([1:0]) */
+   str2 = (rtune_ctl_reg) & 0x3;
+   /* dac_ctl.dac_mode   ([14:12]) */
+   str3 = (dac_ctl_reg >> 12)  & 0x7;
+   /* rtune_ctl.sel_atbp ([4]) */
+   str4 = (rtune_ctl_reg >> 4);
+
+   /* Calculate the m1 */
+   /* mpll_tst.meas_iv */
+   mpll_test_reg = (mpll_test_reg & 0xE03) | (512) << 2;
+   /* rtune_ctl.mode */
+   rtune_ctl_reg = (rtune_ctl_reg & 0xFFC) | (1);
+   /* dac_ctl.dac_mode */
+   dac_ctl_reg = (dac_ctl_reg & 0x8FF) | (4) << 12;
+   /* rtune_ctl.sel_atbp */
+   rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (0) << 4;
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+   imx_phy_reg_write(mpll_test_reg, mmio);
+   

[PATCH v3 1/1] ahci: imx: Add imx53 SATA temperature sensor support

[Fabien Lahoudere]

From: Csaba Kertesz 

Add a hwmon entry to get the temperature from the die of imx53
SATA.

The original patch was made by Richard Zhu for kernel 2.6.x:
ENGR00134041-MX53-Add-the-SATA-AHCI-temperature-monitor.patch

Signed-off-by: Fabien Lahoudere 
---
 drivers/ata/ahci_imx.c | 195 +
 1 file changed, 195 insertions(+)

diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 3f3a7db..420f065 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -26,6 +26,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "ahci.h"
 
 #define DRV_NAME "ahci-imx"
@@ -214,6 +217,180 @@ static int imx_sata_phy_reset(struct ahci_host_priv 
*hpriv)
return timeout ? 0 : -ETIMEDOUT;
 }
 
+enum {
+   /* SATA PHY Register */
+   SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT = 0x0001,
+   SATA_PHY_CR_CLOCK_DAC_CTL = 0x0008,
+   SATA_PHY_CR_CLOCK_RTUNE_CTL = 0x0009,
+   SATA_PHY_CR_CLOCK_ADC_OUT = 0x000A,
+   SATA_PHY_CR_CLOCK_MPLL_TST = 0x0017,
+};
+
+static int read_adc_sum(void *dev, u16 rtune_ctl_reg, void __iomem * mmio)
+{
+   u16 adc_out_reg, read_sum;
+   u32 index, read_attempt;
+   const u32 attempt_limit = 100;
+
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+   imx_phy_reg_write(rtune_ctl_reg, mmio);
+
+   /* two dummy read */
+   index = 0;
+   read_attempt = 0;
+   adc_out_reg = 0;
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_ADC_OUT, mmio);
+   while (index < 2) {
+   imx_phy_reg_read(_out_reg, mmio);
+   /* check if valid */
+   if (adc_out_reg & 0x400)
+   index++;
+
+   read_attempt++;
+   if (read_attempt > attempt_limit) {
+   dev_err(dev, "Read REG more than %d times!\n",
+   attempt_limit);
+   break;
+   }
+   }
+
+   index = 0;
+   read_attempt = 0;
+   read_sum = 0;
+   while (index < 80) {
+   imx_phy_reg_read(_out_reg, mmio);
+   if (adc_out_reg & 0x400) {
+   read_sum = read_sum + (adc_out_reg & 0x3FF);
+   index++;
+   }
+   read_attempt++;
+   if (read_attempt > attempt_limit) {
+   dev_err(dev, "Read REG more than %d times!\n",
+   attempt_limit);
+   break;
+   }
+   }
+
+   /* Use the U32 to make 1000 precision */
+   return (read_sum * 1000) / 80;
+}
+
+/* SATA AHCI temperature monitor */
+static int sata_ahci_read_temperature(void *dev, int *temp)
+{
+   u16 mpll_test_reg, rtune_ctl_reg, dac_ctl_reg, read_sum;
+   u32 str1, str2, str3, str4;
+   int m1, m2, a;
+   struct ahci_host_priv *hpriv = dev_get_drvdata(dev);
+   void __iomem *mmio = hpriv->mmio;
+
+   /* check rd-wr to reg */
+   read_sum = 0;
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT, mmio);
+   imx_phy_reg_write(read_sum, mmio);
+   imx_phy_reg_read(_sum, mmio);
+   if ((read_sum & 0x) != 0)
+   dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+   imx_phy_reg_write(0x5A5A, mmio);
+   imx_phy_reg_read(_sum, mmio);
+   if ((read_sum & 0x) != 0x5A5A)
+   dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+   imx_phy_reg_write(0x1234, mmio);
+   imx_phy_reg_read(_sum, mmio);
+   if ((read_sum & 0x) != 0x1234)
+   dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+   /* start temperature test */
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+   imx_phy_reg_read(_test_reg, mmio);
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+   imx_phy_reg_read(_ctl_reg, mmio);
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+   imx_phy_reg_read(_ctl_reg, mmio);
+
+   /* mpll_tst.meas_iv   ([12:2]) */
+   str1 = (mpll_test_reg >> 2) & 0x7FF;
+   /* rtune_ctl.mode ([1:0]) */
+   str2 = (rtune_ctl_reg) & 0x3;
+   /* dac_ctl.dac_mode   ([14:12]) */
+   str3 = (dac_ctl_reg >> 12)  & 0x7;
+   /* rtune_ctl.sel_atbp ([4]) */
+   str4 = (rtune_ctl_reg >> 4);
+
+   /* Calculate the m1 */
+   /* mpll_tst.meas_iv */
+   mpll_test_reg = (mpll_test_reg & 0xE03) | (512) << 2;
+   /* rtune_ctl.mode */
+   rtune_ctl_reg = (rtune_ctl_reg & 0xFFC) | (1);
+   /* dac_ctl.dac_mode */
+   dac_ctl_reg = (dac_ctl_reg & 0x8FF) | (4) << 12;
+   /* rtune_ctl.sel_atbp */
+   rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (0) << 4;
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+   imx_phy_reg_write(mpll_test_reg, mmio);
+   imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+   imx_phy_reg_write(dac_ctl_reg, 

RE: [PATCH] drm/amd/powerplay: mark symbols static where possible

[Deucher, Alexander]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, October 25, 2016 4:15 AM
> To: Baoyou Xie
> Cc: Deucher, Alexander; Dave Airlie; Zhu, Rex; Zhou, Jammy; Huang,
> JinHuiEric; StDenis, Tom; Edward O'Callaghan; Prosyak, Vitaly; Yang, Eric;
> Yang, Young; Huang, Ray; Dan Carpenter; Cui, Flora; Nils Wallménius; Liu,
> Monk; Wang, Ken; Min, Frank; dri-devel; Linux Kernel Mailing List;
> xie.bao...@zte.com.cn; han@zte.com.cn; tang.qiang...@zte.com.cn
> Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where
> possible
> 
> On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote:
> > On 25 October 2016 at 04:51, Arnd Bergmann  wrote:
> > > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> > > The function has no callers, so the easiest way would be to remove it
> > > entirely, but it's possible that there are plans to add users soon.
> > >
> > > It was assumed that this function will be used soon, so this patch remains
> > it.
> > if it still not be used in 4.10, then we can remove it.
> > is it right?
> 
> There is no such rule in general, it's up to the maintainer and
> it depends on the specific reason for why the function ended up
> being unused in the first place.
> 
> However, we can expect the maintainer to come up with some solution
> to address the warning. Possible options include:
> 
> - calling the function from where it was meant to be used
> - removing the function
> - adding __maybe_unused
> - adding an #if 0
> 
> I have not looked at this specific example and do not know
> which of them would be appropriate here. If you look at the
> output of 'git log -p
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c'
> you might find it out yourself.

This is mostly fallout from a big cleanup/re-org of the powerplay code in the 
4.9.  Rex said he was going to use these soon.  

Alex

RE: [PATCH] drm/amd/powerplay: mark symbols static where possible

[Deucher, Alexander]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, October 25, 2016 4:15 AM
> To: Baoyou Xie
> Cc: Deucher, Alexander; Dave Airlie; Zhu, Rex; Zhou, Jammy; Huang,
> JinHuiEric; StDenis, Tom; Edward O'Callaghan; Prosyak, Vitaly; Yang, Eric;
> Yang, Young; Huang, Ray; Dan Carpenter; Cui, Flora; Nils Wallménius; Liu,
> Monk; Wang, Ken; Min, Frank; dri-devel; Linux Kernel Mailing List;
> xie.bao...@zte.com.cn; han@zte.com.cn; tang.qiang...@zte.com.cn
> Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where
> possible
> 
> On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote:
> > On 25 October 2016 at 04:51, Arnd Bergmann  wrote:
> > > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> > > The function has no callers, so the easiest way would be to remove it
> > > entirely, but it's possible that there are plans to add users soon.
> > >
> > > It was assumed that this function will be used soon, so this patch remains
> > it.
> > if it still not be used in 4.10, then we can remove it.
> > is it right?
> 
> There is no such rule in general, it's up to the maintainer and
> it depends on the specific reason for why the function ended up
> being unused in the first place.
> 
> However, we can expect the maintainer to come up with some solution
> to address the warning. Possible options include:
> 
> - calling the function from where it was meant to be used
> - removing the function
> - adding __maybe_unused
> - adding an #if 0
> 
> I have not looked at this specific example and do not know
> which of them would be appropriate here. If you look at the
> output of 'git log -p
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c'
> you might find it out yourself.

This is mostly fallout from a big cleanup/re-org of the powerplay code in the 
4.9.  Rex said he was going to use these soon.  

Alex

Re: [PATCH] virtio-net: Update the mtu code to match virtio spec

[Aaron Conole]

> From: Aaron Conole 
>
> The virtio committee recently ratified a change, VIRTIO-152, which
> defines the mtu field to be 'max' MTU, not simply desired MTU.
>
> This commit brings the virtio-net device in compliance with VIRTIO-152.
>
> Additionally, drop the max_mtu branch - it cannot be taken since the u16
> returned by virtio_cread16 will never exceed the initial value of
> max_mtu.
>
> Cc: "Michael S. Tsirkin" 
> Cc: Jarod Wilson 
> Signed-off-by: Aaron Conole 
> ---

Sorry about the subject line, David.  This is targetted at net-next, and
it appears my from was mangled.  Would you like me to resubmit with
these details corrected?

-Aaron

Re: [PATCH] virtio-net: Update the mtu code to match virtio spec

[Aaron Conole]

> From: Aaron Conole 
>
> The virtio committee recently ratified a change, VIRTIO-152, which
> defines the mtu field to be 'max' MTU, not simply desired MTU.
>
> This commit brings the virtio-net device in compliance with VIRTIO-152.
>
> Additionally, drop the max_mtu branch - it cannot be taken since the u16
> returned by virtio_cread16 will never exceed the initial value of
> max_mtu.
>
> Cc: "Michael S. Tsirkin" 
> Cc: Jarod Wilson 
> Signed-off-by: Aaron Conole 
> ---

Sorry about the subject line, David.  This is targetted at net-next, and
it appears my from was mangled.  Would you like me to resubmit with
these details corrected?

-Aaron

Re: [PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

[Colin Ian King]

On 25/10/16 20:11, Lars-Peter Clausen wrote:
> On 10/25/2016 09:04 PM, Colin King wrote:
>> From: Colin Ian King 
>>
>> In the case that the read size is not 2 or 4 bytes
>> then maxim_thermocouple_read is not initializing ret and
>> hence may return early with a bogus error return or
>> just through to return with a bogos unread value in *val.
>> Fix this by setting ret to -EINVAL for invalid (unhandled)
>> read sizes.
>>
>> Signed-off-by: Colin Ian King 
> 
> Again, Arnd already took the prize, https://lkml.org/lkml/2016/10/25/518
> 
Not my day :-)

Colin

Re: [PATCH] iio: maxim_thermocouple: return -EINVAL on invalid read size

[Colin Ian King]

On 25/10/16 20:11, Lars-Peter Clausen wrote:
> On 10/25/2016 09:04 PM, Colin King wrote:
>> From: Colin Ian King 
>>
>> In the case that the read size is not 2 or 4 bytes
>> then maxim_thermocouple_read is not initializing ret and
>> hence may return early with a bogus error return or
>> just through to return with a bogos unread value in *val.
>> Fix this by setting ret to -EINVAL for invalid (unhandled)
>> read sizes.
>>
>> Signed-off-by: Colin Ian King 
> 
> Again, Arnd already took the prize, https://lkml.org/lkml/2016/10/25/518
> 
Not my day :-)

Colin

Re: [RFC 5/8] mm: Add new flag VM_CDM for coherent device memory

[Dave Hansen]

On 10/25/2016 12:20 PM, Aneesh Kumar K.V wrote:
> Dave Hansen  writes:
>> On 10/23/2016 09:31 PM, Anshuman Khandual wrote:
>>> VMAs containing coherent device memory should be marked with VM_CDM. These
>>> VMAs need to be identified in various core kernel paths and this new flag
>>> will help in this regard.
>>
>> ... and it's sticky?  So if a VMA *ever* has one of these funky pages in
>> it, it's stuck being VM_CDM forever?  Never to be merged with other
>> VMAs?  Never to see the light of autonuma ever again?
>>
>> What if a 100TB VMA has one page of fancy pants device memory, and the
>> rest normal vanilla memory?  Do we really want to consider the whole
>> thing fancy?
> 
> This definitely needs fine tuning. I guess we should look at this as
> possibly stating that, coherent device would like to not participate in
> auto numa balancing
...

Right, in this one, particular case you don't want NUMA balancing.  But,
if you have to take an _explicit_ action to even get access to this
coherent memory (setting a NUMA policy), why keeps that explicit action
from also explicitly disabling NUMA migration?

I really don't think we should tie together the isolation aspect with
anything else, including NUMA balancing.

For instance, on x86, we have the ability for devices to grok the CPU's
page tables, including doing faults.  There's very little to stop us
from doing things like autonuma.

> One possible option is to use a software pte bit (may be steal
> _PAGE_DEVMAP) and prevent a numa pte setup from change_prot_numa().
> ie, if the pfn backing the pte is from coherent device we don't allow
> that to be converted to a prot none pte for numa faults ?

Why would you need to tag individual pages, especially if the VMA has a
policy set on it that disallows migration?

But, even if you did need to identify individual pages from the PTE, you
can easily do:

page_to_nid(pfn_to_page(pte_pfn(pte)))

and then tell if the node is a fancy-pants device node.

Re: [RFC 5/8] mm: Add new flag VM_CDM for coherent device memory

[Dave Hansen]

On 10/25/2016 12:20 PM, Aneesh Kumar K.V wrote:
> Dave Hansen  writes:
>> On 10/23/2016 09:31 PM, Anshuman Khandual wrote:
>>> VMAs containing coherent device memory should be marked with VM_CDM. These
>>> VMAs need to be identified in various core kernel paths and this new flag
>>> will help in this regard.
>>
>> ... and it's sticky?  So if a VMA *ever* has one of these funky pages in
>> it, it's stuck being VM_CDM forever?  Never to be merged with other
>> VMAs?  Never to see the light of autonuma ever again?
>>
>> What if a 100TB VMA has one page of fancy pants device memory, and the
>> rest normal vanilla memory?  Do we really want to consider the whole
>> thing fancy?
> 
> This definitely needs fine tuning. I guess we should look at this as
> possibly stating that, coherent device would like to not participate in
> auto numa balancing
...

Right, in this one, particular case you don't want NUMA balancing.  But,
if you have to take an _explicit_ action to even get access to this
coherent memory (setting a NUMA policy), why keeps that explicit action
from also explicitly disabling NUMA migration?

I really don't think we should tie together the isolation aspect with
anything else, including NUMA balancing.

For instance, on x86, we have the ability for devices to grok the CPU's
page tables, including doing faults.  There's very little to stop us
from doing things like autonuma.

> One possible option is to use a software pte bit (may be steal
> _PAGE_DEVMAP) and prevent a numa pte setup from change_prot_numa().
> ie, if the pfn backing the pte is from coherent device we don't allow
> that to be converted to a prot none pte for numa faults ?

Why would you need to tag individual pages, especially if the VMA has a
policy set on it that disallows migration?

But, even if you did need to identify individual pages from the PTE, you
can easily do:

page_to_nid(pfn_to_page(pte_pfn(pte)))

and then tell if the node is a fancy-pants device node.

Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

[Jagan Teki]

Hi Cyrille,

On Tue, Oct 25, 2016 at 2:38 PM, Jagan Teki  wrote:
> On Mon, Oct 24, 2016 at 7:37 PM, Cyrille Pitchen
>  wrote:
>> Le 24/10/2016 à 14:09, Cyrille Pitchen a écrit :
>>> Hi Jagan,
>>>
>>> Le 24/10/2016 à 09:41, Jagan Teki a écrit :
 On Sun, Oct 23, 2016 at 2:03 AM, Marek Vasut  wrote:
> On 10/22/2016 01:00 PM, Jagan Teki wrote:
>> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen
>>  wrote:
>>> Hi all,
>>>
>>> This series extends support of SPI protocols to new protocols such as
>>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the 
>>> right
>>> op codes, timing parameters (number of mode and dummy cycles) and erase
>>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP)
>>> tables, when available, as defined in the JEDEC JESD216 specifications.
>>>
>>> When SFDP tables are not available, legacy settings are still used for
>>> backward compatibility (SPI and earlier QSPI memories).
>>>
>>> Support of SPI memories >128Mbits is also improved by using the 4byte
>>> address instruction set, when available. Using those dedicated op codes
>>> is stateless as opposed to enter the 4byte address mode, hence a better
>>> compatibility with some boot loaders which expect to use 3byte address
>>> op codes.
>>
>> The memories which are > 128Mbits should have 4-bytes addressing
>> support based on my experience, do you think BAR is also required
>> atleast from spi-nor side?
>
> Yes, I believe BAR is still required for broken/dumb flash chips.
> Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-(

 Do you have list for those broken chips? because I never find any
 chips which has > 16 MiB with not support of 4-byte address opcodes
 and I've seen the controller has dependable with BAR though it can
 access > 16MiB ex: zynq qspi/

 thanks!

>>>
>>> Let's take the case of Micron n25q256* memories. Depending of the part 
>>> number,
>>> the 12h op code is associated with either 4-byte address Page Program 1-1-1
>>> or 3-byte address Page Program 1-4-4.
>>> Then considering parts where the 12h op code is used for 3-byte address Page
>>> Program 1-4-4, there is no op code for a 4-byte address Page Program 1-1-1.
>>>
>>> Note 15, extracted from the Micron n25q_256mb_3v_65nm.pdf datasheet, about
>>> the 3-byte address Page Program 1-4-4 (Extended Quad Input Fast Program):
>>> The code 38h is valid only for part numbers N25Q256A83ESF40x, 
>>> N25Q256A83E1240x
>>> and N25Q256A83ESFA0F; the code 12h is valid for the other part numbers.

I am trying to understand the conflict more clearly with an example of
Micron, so on Table 18 from Micron n25q_256mb_3v_65nm.pdf datasheet,
Page program 3-byte has 02h and Quad page program 3-byte has 32h but
for 4-byte addressing only quad page program (no support of page
program) can be either 02h/32h/12h and indeed these can change based
on the n25q256* parts so why can't we rely on Quad page program for
4-byte addressing? and so there is no necessity for BAR here.

And also other than the un-supported-controller can't we rely directly
on supported page program opcodes for 4-byte addressing? say if it is
supporting QPP on 4-byte then use it as it is and no need to take care
of PP here.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories

[Jagan Teki]

Hi Cyrille,

On Tue, Oct 25, 2016 at 2:38 PM, Jagan Teki  wrote:
> On Mon, Oct 24, 2016 at 7:37 PM, Cyrille Pitchen
>  wrote:
>> Le 24/10/2016 à 14:09, Cyrille Pitchen a écrit :
>>> Hi Jagan,
>>>
>>> Le 24/10/2016 à 09:41, Jagan Teki a écrit :
 On Sun, Oct 23, 2016 at 2:03 AM, Marek Vasut  wrote:
> On 10/22/2016 01:00 PM, Jagan Teki wrote:
>> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen
>>  wrote:
>>> Hi all,
>>>
>>> This series extends support of SPI protocols to new protocols such as
>>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the 
>>> right
>>> op codes, timing parameters (number of mode and dummy cycles) and erase
>>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP)
>>> tables, when available, as defined in the JEDEC JESD216 specifications.
>>>
>>> When SFDP tables are not available, legacy settings are still used for
>>> backward compatibility (SPI and earlier QSPI memories).
>>>
>>> Support of SPI memories >128Mbits is also improved by using the 4byte
>>> address instruction set, when available. Using those dedicated op codes
>>> is stateless as opposed to enter the 4byte address mode, hence a better
>>> compatibility with some boot loaders which expect to use 3byte address
>>> op codes.
>>
>> The memories which are > 128Mbits should have 4-bytes addressing
>> support based on my experience, do you think BAR is also required
>> atleast from spi-nor side?
>
> Yes, I believe BAR is still required for broken/dumb flash chips.
> Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-(

 Do you have list for those broken chips? because I never find any
 chips which has > 16 MiB with not support of 4-byte address opcodes
 and I've seen the controller has dependable with BAR though it can
 access > 16MiB ex: zynq qspi/

 thanks!

>>>
>>> Let's take the case of Micron n25q256* memories. Depending of the part 
>>> number,
>>> the 12h op code is associated with either 4-byte address Page Program 1-1-1
>>> or 3-byte address Page Program 1-4-4.
>>> Then considering parts where the 12h op code is used for 3-byte address Page
>>> Program 1-4-4, there is no op code for a 4-byte address Page Program 1-1-1.
>>>
>>> Note 15, extracted from the Micron n25q_256mb_3v_65nm.pdf datasheet, about
>>> the 3-byte address Page Program 1-4-4 (Extended Quad Input Fast Program):
>>> The code 38h is valid only for part numbers N25Q256A83ESF40x, 
>>> N25Q256A83E1240x
>>> and N25Q256A83ESFA0F; the code 12h is valid for the other part numbers.

I am trying to understand the conflict more clearly with an example of
Micron, so on Table 18 from Micron n25q_256mb_3v_65nm.pdf datasheet,
Page program 3-byte has 02h and Quad page program 3-byte has 32h but
for 4-byte addressing only quad page program (no support of page
program) can be either 02h/32h/12h and indeed these can change based
on the n25q256* parts so why can't we rely on Quad page program for
4-byte addressing? and so there is no necessity for BAR here.

And also other than the un-supported-controller can't we rely directly
on supported page program opcodes for 4-byte addressing? say if it is
supporting QPP on 4-byte then use it as it is and no need to take care
of PP here.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[PATCHv2 7/7] mm: kill arch_mremap

[Dmitry Safonov]

This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and
commit 2ae416b142b6 ("mm: new mm hook framework").
It also keeps the same functionality of mremapping vDSO blob with
introducing vm_special_mapping mremap op for powerpc.

Cc: Laurent Dufour 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Kirill A. Shutemov" 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: Andrew Morton 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org 
Signed-off-by: Dmitry Safonov 
---
v2: use vdso64_pages only under CONFIG_PPC64

 arch/alpha/include/asm/Kbuild|  1 -
 arch/arc/include/asm/Kbuild  |  1 -
 arch/arm/include/asm/Kbuild  |  1 -
 arch/arm64/include/asm/Kbuild|  1 -
 arch/avr32/include/asm/Kbuild|  1 -
 arch/blackfin/include/asm/Kbuild |  1 -
 arch/c6x/include/asm/Kbuild  |  1 -
 arch/cris/include/asm/Kbuild |  1 -
 arch/frv/include/asm/Kbuild  |  1 -
 arch/h8300/include/asm/Kbuild|  1 -
 arch/hexagon/include/asm/Kbuild  |  1 -
 arch/ia64/include/asm/Kbuild |  1 -
 arch/m32r/include/asm/Kbuild |  1 -
 arch/m68k/include/asm/Kbuild |  1 -
 arch/metag/include/asm/Kbuild|  1 -
 arch/microblaze/include/asm/Kbuild   |  1 -
 arch/mips/include/asm/Kbuild |  1 -
 arch/mn10300/include/asm/Kbuild  |  1 -
 arch/nios2/include/asm/Kbuild|  1 -
 arch/openrisc/include/asm/Kbuild |  1 -
 arch/parisc/include/asm/Kbuild   |  1 -
 arch/powerpc/include/asm/mm-arch-hooks.h | 28 
 arch/powerpc/kernel/vdso.c   | 25 +
 arch/powerpc/kernel/vdso_common.c|  1 +
 arch/s390/include/asm/Kbuild |  1 -
 arch/score/include/asm/Kbuild|  1 -
 arch/sh/include/asm/Kbuild   |  1 -
 arch/sparc/include/asm/Kbuild|  1 -
 arch/tile/include/asm/Kbuild |  1 -
 arch/um/include/asm/Kbuild   |  1 -
 arch/unicore32/include/asm/Kbuild|  1 -
 arch/x86/include/asm/Kbuild  |  1 -
 arch/xtensa/include/asm/Kbuild   |  1 -
 include/asm-generic/mm-arch-hooks.h  | 16 
 include/linux/mm-arch-hooks.h| 25 -
 mm/mremap.c  |  4 
 36 files changed, 26 insertions(+), 103 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/mm-arch-hooks.h
 delete mode 100644 include/asm-generic/mm-arch-hooks.h
 delete mode 100644 include/linux/mm-arch-hooks.h

diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
index bf8475ce85ee..0a5e0ec2842b 100644
--- a/arch/alpha/include/asm/Kbuild
+++ b/arch/alpha/include/asm/Kbuild
@@ -6,7 +6,6 @@ generic-y += exec.h
 generic-y += export.h
 generic-y += irq_work.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += preempt.h
 generic-y += sections.h
 generic-y += trace_clock.h
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index c332604606dd..e6059a808463 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -22,7 +22,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 0745538b26d3..44b717cb4a55 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -15,7 +15,6 @@ generic-y += irq_regs.h
 generic-y += kdebug.h
 generic-y += local.h
 generic-y += local64.h
-generic-y += mm-arch-hooks.h
 generic-y += msgbuf.h
 generic-y += msi.h
 generic-y += param.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 44e1d7f10add..a42a1367aea4 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -20,7 +20,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h
diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild
index 241b9b9729d8..519810d0d5e1 100644
--- a/arch/avr32/include/asm/Kbuild
+++ b/arch/avr32/include/asm/Kbuild
@@ -12,7 +12,6 @@ generic-y += irq_work.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += param.h
 generic-y += percpu.h
 generic-y += preempt.h
diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild
index 91d49c0a3118..c80181e4454f 100644
--- a/arch/blackfin/include/asm/Kbuild
+++ 

[PATCHv2 7/7] mm: kill arch_mremap

[Dmitry Safonov]

This reverts commit 4abad2ca4a4d ("mm: new arch_remap() hook") and
commit 2ae416b142b6 ("mm: new mm hook framework").
It also keeps the same functionality of mremapping vDSO blob with
introducing vm_special_mapping mremap op for powerpc.

Cc: Laurent Dufour 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Kirill A. Shutemov" 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: Andrew Morton 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org 
Signed-off-by: Dmitry Safonov 
---
v2: use vdso64_pages only under CONFIG_PPC64

 arch/alpha/include/asm/Kbuild|  1 -
 arch/arc/include/asm/Kbuild  |  1 -
 arch/arm/include/asm/Kbuild  |  1 -
 arch/arm64/include/asm/Kbuild|  1 -
 arch/avr32/include/asm/Kbuild|  1 -
 arch/blackfin/include/asm/Kbuild |  1 -
 arch/c6x/include/asm/Kbuild  |  1 -
 arch/cris/include/asm/Kbuild |  1 -
 arch/frv/include/asm/Kbuild  |  1 -
 arch/h8300/include/asm/Kbuild|  1 -
 arch/hexagon/include/asm/Kbuild  |  1 -
 arch/ia64/include/asm/Kbuild |  1 -
 arch/m32r/include/asm/Kbuild |  1 -
 arch/m68k/include/asm/Kbuild |  1 -
 arch/metag/include/asm/Kbuild|  1 -
 arch/microblaze/include/asm/Kbuild   |  1 -
 arch/mips/include/asm/Kbuild |  1 -
 arch/mn10300/include/asm/Kbuild  |  1 -
 arch/nios2/include/asm/Kbuild|  1 -
 arch/openrisc/include/asm/Kbuild |  1 -
 arch/parisc/include/asm/Kbuild   |  1 -
 arch/powerpc/include/asm/mm-arch-hooks.h | 28 
 arch/powerpc/kernel/vdso.c   | 25 +
 arch/powerpc/kernel/vdso_common.c|  1 +
 arch/s390/include/asm/Kbuild |  1 -
 arch/score/include/asm/Kbuild|  1 -
 arch/sh/include/asm/Kbuild   |  1 -
 arch/sparc/include/asm/Kbuild|  1 -
 arch/tile/include/asm/Kbuild |  1 -
 arch/um/include/asm/Kbuild   |  1 -
 arch/unicore32/include/asm/Kbuild|  1 -
 arch/x86/include/asm/Kbuild  |  1 -
 arch/xtensa/include/asm/Kbuild   |  1 -
 include/asm-generic/mm-arch-hooks.h  | 16 
 include/linux/mm-arch-hooks.h| 25 -
 mm/mremap.c  |  4 
 36 files changed, 26 insertions(+), 103 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/mm-arch-hooks.h
 delete mode 100644 include/asm-generic/mm-arch-hooks.h
 delete mode 100644 include/linux/mm-arch-hooks.h

diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
index bf8475ce85ee..0a5e0ec2842b 100644
--- a/arch/alpha/include/asm/Kbuild
+++ b/arch/alpha/include/asm/Kbuild
@@ -6,7 +6,6 @@ generic-y += exec.h
 generic-y += export.h
 generic-y += irq_work.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += preempt.h
 generic-y += sections.h
 generic-y += trace_clock.h
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index c332604606dd..e6059a808463 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -22,7 +22,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 0745538b26d3..44b717cb4a55 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -15,7 +15,6 @@ generic-y += irq_regs.h
 generic-y += kdebug.h
 generic-y += local.h
 generic-y += local64.h
-generic-y += mm-arch-hooks.h
 generic-y += msgbuf.h
 generic-y += msi.h
 generic-y += param.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 44e1d7f10add..a42a1367aea4 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -20,7 +20,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h
diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild
index 241b9b9729d8..519810d0d5e1 100644
--- a/arch/avr32/include/asm/Kbuild
+++ b/arch/avr32/include/asm/Kbuild
@@ -12,7 +12,6 @@ generic-y += irq_work.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += param.h
 generic-y += percpu.h
 generic-y += preempt.h
diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild
index 91d49c0a3118..c80181e4454f 100644
--- a/arch/blackfin/include/asm/Kbuild
+++ b/arch/blackfin/include/asm/Kbuild
@@ -21,7 +21,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += 

[RFC 2/2] mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read during __sdhci_read_caps

[Zach Brown]

The sdhci capabilities registers can be incorrect. The sdhci-caps-mask
and sdhci-caps dt properties specify which bits of the registers are
incorrect and what their values should be. This patch makes the sdhci
driver use those properties to correct the caps during
__sdhci_read_caps.

During __sdhci_read_caps
Use the sdhci-caps-mask property to turn off the incorrect bits of the
sdhci registers after reading them.
Use the sdhci-caps to turn on bits after using sdhci-caps-mask to turn
off the incorrect ones.

Signed-off-by: Zach Brown 
---
 drivers/mmc/host/sdhci.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1e25b01..d5feae4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -2991,6 +2992,8 @@ static int sdhci_set_dma_mask(struct sdhci_host *host)
 void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 
*caps1)
 {
u16 v;
+   u64 dt_caps_mask = 0;
+   u64 dt_caps = 0;
 
if (host->read_caps)
return;
@@ -3005,18 +3008,35 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 
*ver, u32 *caps, u32 *caps1)
 
sdhci_do_reset(host, SDHCI_RESET_ALL);
 
+   of_property_read_u64(mmc_dev(host->mmc)->of_node,
+"sdhci-caps-mask", _caps_mask);
+   of_property_read_u64(mmc_dev(host->mmc)->of_node,
+"sdhci-caps", _caps);
+
v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
 
if (host->quirks & SDHCI_QUIRK_MISSING_CAPS)
return;
 
-   host->caps = caps ? *caps : sdhci_readl(host, SDHCI_CAPABILITIES);
+   if (caps)
+   host->caps = *caps;
+   else {
+   host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+   host->caps &= ~lower_32_bits(dt_caps_mask);
+   host->caps |= lower_32_bits(dt_caps);
+   }
 
if (host->version < SDHCI_SPEC_300)
return;
 
-   host->caps1 = caps1 ? *caps1 : sdhci_readl(host, SDHCI_CAPABILITIES_1);
+   if (caps1)
+   host->caps1 = *caps1;
+   else {
+   host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+   host->caps1 &= ~upper_32_bits(dt_caps_mask);
+   host->caps1 |= upper_32_bits(dt_caps);
+   }
 }
 EXPORT_SYMBOL_GPL(__sdhci_read_caps);
 
-- 
2.7.4

[RFC 0/2] mmc: sdhci: Fix sdhci caps register bits with corrections provided by dt

[Zach Brown]

For various reasons the sdhci caps register can be incorrect. This patch set
introduces a general way to correct the bits when they are read to accurately
reflect the capabilties of the controller/board combo.

The first patch creates sdhci-caps and sdhci-caps-mask dt properties that
combined represent the correction to the sdhci caps register.

The second patch uses the new dt properties to correct the caps from the
register as they read during __sdhci_read_caps.

Zach Brown (2):
  mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask
  mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read
during __sdhci_read_caps

 Documentation/devicetree/bindings/mmc/mmc.txt |  7 +++
 drivers/mmc/host/sdhci.c  | 24 ++--
 2 files changed, 29 insertions(+), 2 deletions(-)

--
2.7.4

[RFC 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask

[Zach Brown]

On some systems the sdhci capabilty registers are incorrect for one
reason or another.

The sdhci-caps-mask property specifies which bits in the registers
are incorrect and should be turned off before using sdhci-caps to turn
on bits.

The sdhci-caps property specifies which bits should be turned on.

Signed-off-by: Zach Brown 
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 8a37782..1415aa0 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -52,6 +52,13 @@ Optional properties:
 - no-sdio: controller is limited to send sdio cmd during initialization
 - no-sd: controller is limited to send sd cmd during initialization
 - no-mmc: controller is limited to send mmc cmd during initialization
+- sdhci-caps-mask: The sdhci capabilities registers are incorrect. This 64bit
+  property corresponds to the bits in the sdhci capabilty registers. If the bit
+  is on in the mask then the bit is incorrect in the registers and should be
+  turned off.
+- sdhci-caps: The sdhci capabilities registers are incorrect. This 64bit
+  property corresponds to the bits in the sdhci capability registers. If the
+  bit is on in the property then the bit should be on in the reigsters.
 
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"
-- 
2.7.4

[RFC 2/2] mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read during __sdhci_read_caps

[Zach Brown]

The sdhci capabilities registers can be incorrect. The sdhci-caps-mask
and sdhci-caps dt properties specify which bits of the registers are
incorrect and what their values should be. This patch makes the sdhci
driver use those properties to correct the caps during
__sdhci_read_caps.

During __sdhci_read_caps
Use the sdhci-caps-mask property to turn off the incorrect bits of the
sdhci registers after reading them.
Use the sdhci-caps to turn on bits after using sdhci-caps-mask to turn
off the incorrect ones.

Signed-off-by: Zach Brown 
---
 drivers/mmc/host/sdhci.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1e25b01..d5feae4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -2991,6 +2992,8 @@ static int sdhci_set_dma_mask(struct sdhci_host *host)
 void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 
*caps1)
 {
u16 v;
+   u64 dt_caps_mask = 0;
+   u64 dt_caps = 0;
 
if (host->read_caps)
return;
@@ -3005,18 +3008,35 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 
*ver, u32 *caps, u32 *caps1)
 
sdhci_do_reset(host, SDHCI_RESET_ALL);
 
+   of_property_read_u64(mmc_dev(host->mmc)->of_node,
+"sdhci-caps-mask", _caps_mask);
+   of_property_read_u64(mmc_dev(host->mmc)->of_node,
+"sdhci-caps", _caps);
+
v = ver ? *ver : sdhci_readw(host, SDHCI_HOST_VERSION);
host->version = (v & SDHCI_SPEC_VER_MASK) >> SDHCI_SPEC_VER_SHIFT;
 
if (host->quirks & SDHCI_QUIRK_MISSING_CAPS)
return;
 
-   host->caps = caps ? *caps : sdhci_readl(host, SDHCI_CAPABILITIES);
+   if (caps)
+   host->caps = *caps;
+   else {
+   host->caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+   host->caps &= ~lower_32_bits(dt_caps_mask);
+   host->caps |= lower_32_bits(dt_caps);
+   }
 
if (host->version < SDHCI_SPEC_300)
return;
 
-   host->caps1 = caps1 ? *caps1 : sdhci_readl(host, SDHCI_CAPABILITIES_1);
+   if (caps1)
+   host->caps1 = *caps1;
+   else {
+   host->caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+   host->caps1 &= ~upper_32_bits(dt_caps_mask);
+   host->caps1 |= upper_32_bits(dt_caps);
+   }
 }
 EXPORT_SYMBOL_GPL(__sdhci_read_caps);
 
-- 
2.7.4

[RFC 0/2] mmc: sdhci: Fix sdhci caps register bits with corrections provided by dt

[Zach Brown]

For various reasons the sdhci caps register can be incorrect. This patch set
introduces a general way to correct the bits when they are read to accurately
reflect the capabilties of the controller/board combo.

The first patch creates sdhci-caps and sdhci-caps-mask dt properties that
combined represent the correction to the sdhci caps register.

The second patch uses the new dt properties to correct the caps from the
register as they read during __sdhci_read_caps.

Zach Brown (2):
  mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask
  mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read
during __sdhci_read_caps

 Documentation/devicetree/bindings/mmc/mmc.txt |  7 +++
 drivers/mmc/host/sdhci.c  | 24 ++--
 2 files changed, 29 insertions(+), 2 deletions(-)

--
2.7.4

[RFC 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask

[Zach Brown]

On some systems the sdhci capabilty registers are incorrect for one
reason or another.

The sdhci-caps-mask property specifies which bits in the registers
are incorrect and should be turned off before using sdhci-caps to turn
on bits.

The sdhci-caps property specifies which bits should be turned on.

Signed-off-by: Zach Brown 
---
 Documentation/devicetree/bindings/mmc/mmc.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 8a37782..1415aa0 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -52,6 +52,13 @@ Optional properties:
 - no-sdio: controller is limited to send sdio cmd during initialization
 - no-sd: controller is limited to send sd cmd during initialization
 - no-mmc: controller is limited to send mmc cmd during initialization
+- sdhci-caps-mask: The sdhci capabilities registers are incorrect. This 64bit
+  property corresponds to the bits in the sdhci capabilty registers. If the bit
+  is on in the mask then the bit is incorrect in the registers and should be
+  turned off.
+- sdhci-caps: The sdhci capabilities registers are incorrect. This 64bit
+  property corresponds to the bits in the sdhci capability registers. If the
+  bit is on in the property then the bit should be on in the reigsters.
 
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"
-- 
2.7.4

[DOC] Missing completions-design.txt?

[Brian Norris]

Hi,

It looks like Nicholas submitted this doc a while back as patch 2/2:

"[PATCH 2/2] doc: detailed documentation for completion"
http://lkml.iu.edu/hypermail/linux/kernel/1412.2/03676.html

where patch 1/2 got merged as this:

202799be447b doc: brief user documentation for completion

References in the introduced completion.txt doc have pointed lost souls
at an elusive completion-design.txt:

  "for details on completion design and implementation see
  completions-design.txt"

Since as we well know, most developers are religious readers of
documentation, presumably there are people out there waiting expectantly
for such a file to appear in their otherwise exhaustive Documentation/.
Can you help such lost souls out?

Thanks,
Brian

P.S. I haven't actually read the design doc that closely yet. Who would
trust such a random patch off the archives, after all? So just removing
the mention of this file might be a satisfactory solution.

[DOC] Missing completions-design.txt?

[Brian Norris]

Hi,

It looks like Nicholas submitted this doc a while back as patch 2/2:

"[PATCH 2/2] doc: detailed documentation for completion"
http://lkml.iu.edu/hypermail/linux/kernel/1412.2/03676.html

where patch 1/2 got merged as this:

202799be447b doc: brief user documentation for completion

References in the introduced completion.txt doc have pointed lost souls
at an elusive completion-design.txt:

  "for details on completion design and implementation see
  completions-design.txt"

Since as we well know, most developers are religious readers of
documentation, presumably there are people out there waiting expectantly
for such a file to appear in their otherwise exhaustive Documentation/.
Can you help such lost souls out?

Thanks,
Brian

P.S. I haven't actually read the design doc that closely yet. Who would
trust such a random patch off the archives, after all? So just removing
the mention of this file might be a satisfactory solution.

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

[Laszlo Ersek]

On 10/25/16 21:24, Laszlo Ersek wrote:
> On 10/25/16 20:42, Alex Williamson wrote:

>> FWIW, I think the reason
>> this hasn't been done to date is that PCI bus addresses (except for
>> root bus devices) are not stable.  Depending on the system, the address
>> of a given device may change, not only based on the slot where the
>> device is installed, but whether other devices in other slots are
>> populated.
> 
> I agree.
> 
> However, while the addresses are not stable in the face of hardware
> changes, I think the addresses don't change haphazardly (that is,
> without hardware changes).
> 
> So, if you plug in another card, your current pci-stub.except=...
> parameter might become invalid; but that's not very different from the
> case when you plug in the second instance of a preexistent card right
> now -- then the pci-stub.ids=... filter won't match uniquely anymore,
> and assignment vs. host-side use might not work as intented.

Sorry about the self-followup; I just wanted to add -- although it might
not carry a lot of weight for the host kernel -- that the libvirt domain
XML hard-codes the host-side PCI BDF anyway, for assigned devices:

http://libvirt.org/formatdomain.html#elementsHostDev

"""
  

  

  
  ...

  

  ...

  source
The source element describes the device as seen from the host using
the following mechanism to describe:

...

pci
  PCI devices can only be described by their address.
"""

Thanks
Laszlo

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

[Laszlo Ersek]

On 10/25/16 21:24, Laszlo Ersek wrote:
> On 10/25/16 20:42, Alex Williamson wrote:

>> FWIW, I think the reason
>> this hasn't been done to date is that PCI bus addresses (except for
>> root bus devices) are not stable.  Depending on the system, the address
>> of a given device may change, not only based on the slot where the
>> device is installed, but whether other devices in other slots are
>> populated.
> 
> I agree.
> 
> However, while the addresses are not stable in the face of hardware
> changes, I think the addresses don't change haphazardly (that is,
> without hardware changes).
> 
> So, if you plug in another card, your current pci-stub.except=...
> parameter might become invalid; but that's not very different from the
> case when you plug in the second instance of a preexistent card right
> now -- then the pci-stub.ids=... filter won't match uniquely anymore,
> and assignment vs. host-side use might not work as intented.

Sorry about the self-followup; I just wanted to add -- although it might
not carry a lot of weight for the host kernel -- that the libvirt domain
XML hard-codes the host-side PCI BDF anyway, for assigned devices:

http://libvirt.org/formatdomain.html#elementsHostDev

"""
  

  

  
  ...

  

  ...

  source
The source element describes the device as seen from the host using
the following mechanism to describe:

...

pci
  PCI devices can only be described by their address.
"""

Thanks
Laszlo

Regression caused by commit c83ed4c9dbb3 "ubifs: Abort readdir on error"

[Peter Rosin]

Hi!

Early on in my boot procedure I create an overlay and shuffle
things around a bit so that the original rootfs stays readonly
at the bottom of an overlayed readwrite fs. This way I can just
toss out the overlayed fs and have a clean and reliable way to
do a "factory-reset". Both the read-only root and and the overlay
are ubifs on nand.

Bisection points to commit c83ed4c9dbb3 "ubifs: Abort readdir
on error". Reverting that commit on top of v4.9-rc2 fixes things.

My "shuffle script" is as follows (with an added comment
indicating the first point of failure) and runs as the first
script by init.

If I add a line
ls -l /mnt || echo "ls -l /mnt failed"
where that comment is right before the failure, I get no failure
indication even with the broken commit, so directory traversal
seems ok.

Cheers,
Peter

#! /bin/bash

test "x$1" == xstart || exit 0

mkdir /tmp/log

/bin/mount -o remount,rw /dev

/bin/mount | /bin/grep -q "^overlay on / type overlay" && exit 0

if test -e /etc/factory-reset; then
  /usr/sbin/ubiformat /dev/mtd7
  rm /etc/factory-reset
fi

/usr/sbin/ubiattach /dev/ubi_ctrl -m 7
/usr/sbin/ubimkvol /dev/ubi1 -N ovl -m

/bin/mkdir -p /mnt/ovl
/bin/mkdir -p /mnt/roroot
/bin/mkdir -p /mnt/merge
/bin/mount -t ubifs /dev/ubi1_0 /mnt/ovl

/bin/mkdir -p /mnt/ovl/ovl
/bin/mkdir -p /mnt/ovl/work
# with c83ed4c9dbb3, the following mount fails with
# mount: mounting overlay on /mnt/merge failed: No such file or directory
/bin/mount -t overlay -o lowerdir=/,upperdir=/mnt/ovl/ovl,workdir=/mnt/ovl/work 
overlay /mnt/merge

cd /mnt/merge

/sbin/pivot_root . /mnt/merge/mnt/roroot

/bin/mount --rbind /mnt/roroot/proc /proc
/bin/mount --rbind /mnt/roroot/sys /sys
/bin/mount --rbind /mnt/roroot/dev /dev
/bin/mount --rbind /mnt/roroot/tmp /tmp
/bin/mount --rbind /mnt/roroot/run /run
/bin/mount --rbind /mnt/roroot/mnt/ovl /mnt/ovl

kill $PPID
kill -QUIT 1

Regression caused by commit c83ed4c9dbb3 "ubifs: Abort readdir on error"

[Peter Rosin]

Hi!

Early on in my boot procedure I create an overlay and shuffle
things around a bit so that the original rootfs stays readonly
at the bottom of an overlayed readwrite fs. This way I can just
toss out the overlayed fs and have a clean and reliable way to
do a "factory-reset". Both the read-only root and and the overlay
are ubifs on nand.

Bisection points to commit c83ed4c9dbb3 "ubifs: Abort readdir
on error". Reverting that commit on top of v4.9-rc2 fixes things.

My "shuffle script" is as follows (with an added comment
indicating the first point of failure) and runs as the first
script by init.

If I add a line
ls -l /mnt || echo "ls -l /mnt failed"
where that comment is right before the failure, I get no failure
indication even with the broken commit, so directory traversal
seems ok.

Cheers,
Peter

#! /bin/bash

test "x$1" == xstart || exit 0

mkdir /tmp/log

/bin/mount -o remount,rw /dev

/bin/mount | /bin/grep -q "^overlay on / type overlay" && exit 0

if test -e /etc/factory-reset; then
  /usr/sbin/ubiformat /dev/mtd7
  rm /etc/factory-reset
fi

/usr/sbin/ubiattach /dev/ubi_ctrl -m 7
/usr/sbin/ubimkvol /dev/ubi1 -N ovl -m

/bin/mkdir -p /mnt/ovl
/bin/mkdir -p /mnt/roroot
/bin/mkdir -p /mnt/merge
/bin/mount -t ubifs /dev/ubi1_0 /mnt/ovl

/bin/mkdir -p /mnt/ovl/ovl
/bin/mkdir -p /mnt/ovl/work
# with c83ed4c9dbb3, the following mount fails with
# mount: mounting overlay on /mnt/merge failed: No such file or directory
/bin/mount -t overlay -o lowerdir=/,upperdir=/mnt/ovl/ovl,workdir=/mnt/ovl/work 
overlay /mnt/merge

cd /mnt/merge

/sbin/pivot_root . /mnt/merge/mnt/roroot

/bin/mount --rbind /mnt/roroot/proc /proc
/bin/mount --rbind /mnt/roroot/sys /sys
/bin/mount --rbind /mnt/roroot/dev /dev
/bin/mount --rbind /mnt/roroot/tmp /tmp
/bin/mount --rbind /mnt/roroot/run /run
/bin/mount --rbind /mnt/roroot/mnt/ovl /mnt/ovl

kill $PPID
kill -QUIT 1

Re: [RFC] shutdown machine when li-ion battery goes below 3V

[Olaf Titz]

> + res = bq27xxx_battery_voltage(di, );
> + if (res)
> + return res;
> +
> + mV = val.intval / 1000;

Reading that code I stumbled over the comment in
bq27xxx_battery_voltage saying that it returns millivolts. The code
here, the code in bq27xxx_battery_voltage and power_supply.h all
indicate that it in fact returns microvolts. Please double-check and
fix, as it stands now the code looks inconsistent (but not knowing that
device at all I don't feel fit to submit a fix).

regards, Olaf

Re: [RFC] shutdown machine when li-ion battery goes below 3V

[Olaf Titz]

> + res = bq27xxx_battery_voltage(di, );
> + if (res)
> + return res;
> +
> + mV = val.intval / 1000;

Reading that code I stumbled over the comment in
bq27xxx_battery_voltage saying that it returns millivolts. The code
here, the code in bq27xxx_battery_voltage and power_supply.h all
indicate that it in fact returns microvolts. Please double-check and
fix, as it stands now the code looks inconsistent (but not knowing that
device at all I don't feel fit to submit a fix).

regards, Olaf

[PATCH 1/7] powerpc/vdso: unify return paths in setup_additional_pages

[Dmitry Safonov]

Impact: cleanup

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org 
Signed-off-by: Dmitry Safonov 
---
 arch/powerpc/kernel/vdso.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 4111d30badfa..4ffb82a2d9e9 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -154,7 +154,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
struct page **vdso_pagelist;
unsigned long vdso_pages;
unsigned long vdso_base;
-   int rc;
+   int ret = 0;
 
if (!vdso_ready)
return 0;
@@ -203,8 +203,8 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
  ((VDSO_ALIGNMENT - 1) & PAGE_MASK),
  0, 0);
if (IS_ERR_VALUE(vdso_base)) {
-   rc = vdso_base;
-   goto fail_mmapsem;
+   ret = vdso_base;
+   goto out_up_mmap_sem;
}
 
/* Add required alignment. */
@@ -227,21 +227,16 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
 * It's fine to use that for setting breakpoints in the vDSO code
 * pages though.
 */
-   rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
+   ret = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 VM_READ|VM_EXEC|
 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 vdso_pagelist);
-   if (rc) {
+   if (ret)
current->mm->context.vdso_base = 0;
-   goto fail_mmapsem;
-   }
-
-   up_write(>mmap_sem);
-   return 0;
 
- fail_mmapsem:
+out_up_mmap_sem:
up_write(>mmap_sem);
-   return rc;
+   return ret;
 }
 
 const char *arch_vma_name(struct vm_area_struct *vma)
-- 
2.10.0

Re: [PATCH v3 2/9] mtd: spi-nor: add an alternative method to support memory >16MiB

[Marek Vasut]

On 10/25/2016 11:18 AM, Cyrille Pitchen wrote:
> Le 25/10/2016 à 00:10, Marek Vasut a écrit :
>> On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
>>> This patch provides an alternative mean to support memory above 16MiB
>>> (128Mib) by replacing 3byte address op codes by their associated 4byte
>>> address versions.
>>>
>>> Using the dedicated 4byte address op codes doesn't change the internal
>>> state of the SPI NOR memory as opposed to using other means such as
>>> updating a Base Address Register (BAR) and sending command to enter/leave
>>> the 4byte mode.
>>>
>>> Hence when a CPU reset occurs, early bootloaders don't need to be aware
>>> of BAR value or 4byte mode being enabled: they can still access the first
>>> 16MiB of the SPI NOR memory using the regular 3byte address op codes.
>>>
>>> Signed-off-by: Cyrille Pitchen 
>>> Tested-by: Vignesh R 
>>> ---
>>>  drivers/mtd/devices/serial_flash_cmds.h |   7 ---
>>>  drivers/mtd/devices/st_spi_fsm.c|  28 -
>>>  drivers/mtd/spi-nor/spi-nor.c   | 104 
>>> +---
>>>  include/linux/mtd/spi-nor.h |  22 +--
>>>  4 files changed, 113 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/drivers/mtd/devices/serial_flash_cmds.h 
>>> b/drivers/mtd/devices/serial_flash_cmds.h
>>> index f59a125295d0..8b81e15105dd 100644
>>> --- a/drivers/mtd/devices/serial_flash_cmds.h
>>> +++ b/drivers/mtd/devices/serial_flash_cmds.h
>>> @@ -18,19 +18,12 @@
>>>  #define SPINOR_OP_RDVCR0x85
>>>  
>>>  /* JEDEC Standard - Serial Flash Discoverable Parmeters (SFDP) Commands */
>>> -#define SPINOR_OP_READ_1_2_2   0xbb/* DUAL I/O READ */
>>> -#define SPINOR_OP_READ_1_4_4   0xeb/* QUAD I/O READ */
>>> -
>>>  #define SPINOR_OP_WRITE0x02/* PAGE PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_1_2  0xa2/* DUAL INPUT PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_2_2  0xd2/* DUAL INPUT EXT PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_1_4  0x32/* QUAD INPUT PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_4_4  0x12/* QUAD INPUT EXT PROGRAM */
>>>  
>>> -/* READ commands with 32-bit addressing */
>>> -#define SPINOR_OP_READ4_1_2_2  0xbc
>>> -#define SPINOR_OP_READ4_1_4_4  0xec
>>> -
>>
>> It'd be nice to have this move/rename bit factored out into a separate
>> patch.
>>
> 
> OK, I will try to do this. Anyway, this rename seems to break the freshly
> merged drivers/spi/spi-bcm-qspi.c, which uses the SPINOR_OP_READ4_* macro so
> I have to do something about this driver. IMHO, the broadcom driver should not
> select its own op code but use the one provided by read_opcode member of the
> struct spi_flash_read_message.

Thanks

>>>  /* Configuration flags */
>>>  #define FLASH_FLAG_SINGLE  0x00ff
>>>  #define FLASH_FLAG_READ_WRITE  0x0001
>>> diff --git a/drivers/mtd/devices/st_spi_fsm.c 
>>> b/drivers/mtd/devices/st_spi_fsm.c
>>> index 5454b4113589..804313a33f2b 100644
>>
>> [...]
>>
>>> +static u8 spi_nor_convert_opcode(u8 opcode,
>>> +const struct spi_nor_address_entry *entries,
>>> +size_t num_entries)
>>> +{
>>> +   int min, max;
>>> +
>>> +   min = 0;
>>> +   max = num_entries - 1;
>>> +   while (min <= max) {
>>
>> It's really not clear at all what this function does, so please add a
>> comment.
>>
> 
> This is just a dichotomic search to reduce the number of comparisons: it 
> assumes the entries[] array is sorted by ascending src_opcode.
> 
> I will add a comment to clarify this point.

Cool, that'd help. Are you invoking this every time an opcode is
submitted to the SPI NOR ?

>>> +   int mid = (min + max) >> 1;
>>> +   const struct spi_nor_address_entry *entry = [mid];
>>> +
>>> +   if (opcode == entry->src_opcode)
>>> +   return entry->dst_opcode;
>>> +
>>> +   if (opcode < entry->src_opcode)
>>> +   max = mid - 1;
>>> +   else
>>> +   min = mid + 1;
>>> +   }
>>> +
>>> +   /* No conversion found */
>>> +   return opcode;
>>> +}
>>> +
>>> +static u8 spi_nor_3to4_opcode(u8 opcode)
>>> +{
>>> +   /* MUST be sorted by 3byte opcode */
>>
>> Because ... why ?
>>
> 
> As explained above, the dichotomic search implemented in
> spi_nor_convert_opcode() assumes that the input array is sorted by src_opcode.

Maybe you should drop that assumption and do normal traversal of the
array ? I feel this is a bit fragile and will break once someone will
cluelessly add a new opcode.

... or add a comment with a big WARNING statement.

>>> +#define ENTRY_3TO4(_opcode){ _opcode, _opcode##_4B }
>>
>> Will this break/be unflexible for flashes with some different 4B opcodes ?
>>
> 
> Of course I cannot provide any guarantee that it will never happen but
> currently it seems that all manufacturers use the same op codes. Besides, 
> the 4-byte address instruction set is part the of 

Re: [PATCH v3 1/9] mtd: spi-nor: improve macronix_quad_enable()

[Marek Vasut]

On 10/25/2016 10:52 AM, Cyrille Pitchen wrote:
> Hi Marek,
> 
> Le 25/10/2016 à 00:00, Marek Vasut a écrit :
>> On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
>>> The patch checks whether the Quad Enable bit is already set in the Status
>>> Register. If so, the function exits immediately with a successful return
>>> code. Otherwise, a message is now printed telling we're setting the
>>> non-volatile bit.
>>>
>>> Signed-off-by: Cyrille Pitchen 
>>> Reviewed-by: Jagan Teki 
>>> ---
>>>  drivers/mtd/spi-nor/spi-nor.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index d0fc165d7d66..5c87b2d99507 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -1211,6 +1211,11 @@ static int macronix_quad_enable(struct spi_nor *nor)
>>> val = read_sr(nor);
>>> if (val < 0)
>>> return val;
>>> +   if (val & SR_QUAD_EN_MX)
>>> +   return 0;
>>> +
>>> +   /* Update the Quad Enable bit. */
>>> +   dev_info(nor->dev, "setting Macronix Quad Enable (non-volatile) bit\n");
>>
>> Should probably be dev_dbg(), since this is just churn in the kernel
>> log. The user doesn't care and the developer can just up the debug level
>> or add his own printk .
>>
> 
> The Quad Enable bit is non-volatile so this trace should be printed only once
> but I'm perfectly fine with using dev_dbg(). I'll change it in the next 
> version.

I get it, but what's the value of it ? Who will make use of this
information being in the kernel log? The kernel is already chatty enough :)

-- 
Best regards,
Marek Vasut

[PATCH 1/7] powerpc/vdso: unify return paths in setup_additional_pages

[Dmitry Safonov]

Impact: cleanup

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org 
Signed-off-by: Dmitry Safonov 
---
 arch/powerpc/kernel/vdso.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 4111d30badfa..4ffb82a2d9e9 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -154,7 +154,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
struct page **vdso_pagelist;
unsigned long vdso_pages;
unsigned long vdso_base;
-   int rc;
+   int ret = 0;
 
if (!vdso_ready)
return 0;
@@ -203,8 +203,8 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
  ((VDSO_ALIGNMENT - 1) & PAGE_MASK),
  0, 0);
if (IS_ERR_VALUE(vdso_base)) {
-   rc = vdso_base;
-   goto fail_mmapsem;
+   ret = vdso_base;
+   goto out_up_mmap_sem;
}
 
/* Add required alignment. */
@@ -227,21 +227,16 @@ int arch_setup_additional_pages(struct linux_binprm 
*bprm, int uses_interp)
 * It's fine to use that for setting breakpoints in the vDSO code
 * pages though.
 */
-   rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
+   ret = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 VM_READ|VM_EXEC|
 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 vdso_pagelist);
-   if (rc) {
+   if (ret)
current->mm->context.vdso_base = 0;
-   goto fail_mmapsem;
-   }
-
-   up_write(>mmap_sem);
-   return 0;
 
- fail_mmapsem:
+out_up_mmap_sem:
up_write(>mmap_sem);
-   return rc;
+   return ret;
 }
 
 const char *arch_vma_name(struct vm_area_struct *vma)
-- 
2.10.0

Re: [PATCH v3 2/9] mtd: spi-nor: add an alternative method to support memory >16MiB

[Marek Vasut]

On 10/25/2016 11:18 AM, Cyrille Pitchen wrote:
> Le 25/10/2016 à 00:10, Marek Vasut a écrit :
>> On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
>>> This patch provides an alternative mean to support memory above 16MiB
>>> (128Mib) by replacing 3byte address op codes by their associated 4byte
>>> address versions.
>>>
>>> Using the dedicated 4byte address op codes doesn't change the internal
>>> state of the SPI NOR memory as opposed to using other means such as
>>> updating a Base Address Register (BAR) and sending command to enter/leave
>>> the 4byte mode.
>>>
>>> Hence when a CPU reset occurs, early bootloaders don't need to be aware
>>> of BAR value or 4byte mode being enabled: they can still access the first
>>> 16MiB of the SPI NOR memory using the regular 3byte address op codes.
>>>
>>> Signed-off-by: Cyrille Pitchen 
>>> Tested-by: Vignesh R 
>>> ---
>>>  drivers/mtd/devices/serial_flash_cmds.h |   7 ---
>>>  drivers/mtd/devices/st_spi_fsm.c|  28 -
>>>  drivers/mtd/spi-nor/spi-nor.c   | 104 
>>> +---
>>>  include/linux/mtd/spi-nor.h |  22 +--
>>>  4 files changed, 113 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/drivers/mtd/devices/serial_flash_cmds.h 
>>> b/drivers/mtd/devices/serial_flash_cmds.h
>>> index f59a125295d0..8b81e15105dd 100644
>>> --- a/drivers/mtd/devices/serial_flash_cmds.h
>>> +++ b/drivers/mtd/devices/serial_flash_cmds.h
>>> @@ -18,19 +18,12 @@
>>>  #define SPINOR_OP_RDVCR0x85
>>>  
>>>  /* JEDEC Standard - Serial Flash Discoverable Parmeters (SFDP) Commands */
>>> -#define SPINOR_OP_READ_1_2_2   0xbb/* DUAL I/O READ */
>>> -#define SPINOR_OP_READ_1_4_4   0xeb/* QUAD I/O READ */
>>> -
>>>  #define SPINOR_OP_WRITE0x02/* PAGE PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_1_2  0xa2/* DUAL INPUT PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_2_2  0xd2/* DUAL INPUT EXT PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_1_4  0x32/* QUAD INPUT PROGRAM */
>>>  #define SPINOR_OP_WRITE_1_4_4  0x12/* QUAD INPUT EXT PROGRAM */
>>>  
>>> -/* READ commands with 32-bit addressing */
>>> -#define SPINOR_OP_READ4_1_2_2  0xbc
>>> -#define SPINOR_OP_READ4_1_4_4  0xec
>>> -
>>
>> It'd be nice to have this move/rename bit factored out into a separate
>> patch.
>>
> 
> OK, I will try to do this. Anyway, this rename seems to break the freshly
> merged drivers/spi/spi-bcm-qspi.c, which uses the SPINOR_OP_READ4_* macro so
> I have to do something about this driver. IMHO, the broadcom driver should not
> select its own op code but use the one provided by read_opcode member of the
> struct spi_flash_read_message.

Thanks

>>>  /* Configuration flags */
>>>  #define FLASH_FLAG_SINGLE  0x00ff
>>>  #define FLASH_FLAG_READ_WRITE  0x0001
>>> diff --git a/drivers/mtd/devices/st_spi_fsm.c 
>>> b/drivers/mtd/devices/st_spi_fsm.c
>>> index 5454b4113589..804313a33f2b 100644
>>
>> [...]
>>
>>> +static u8 spi_nor_convert_opcode(u8 opcode,
>>> +const struct spi_nor_address_entry *entries,
>>> +size_t num_entries)
>>> +{
>>> +   int min, max;
>>> +
>>> +   min = 0;
>>> +   max = num_entries - 1;
>>> +   while (min <= max) {
>>
>> It's really not clear at all what this function does, so please add a
>> comment.
>>
> 
> This is just a dichotomic search to reduce the number of comparisons: it 
> assumes the entries[] array is sorted by ascending src_opcode.
> 
> I will add a comment to clarify this point.

Cool, that'd help. Are you invoking this every time an opcode is
submitted to the SPI NOR ?

>>> +   int mid = (min + max) >> 1;
>>> +   const struct spi_nor_address_entry *entry = [mid];
>>> +
>>> +   if (opcode == entry->src_opcode)
>>> +   return entry->dst_opcode;
>>> +
>>> +   if (opcode < entry->src_opcode)
>>> +   max = mid - 1;
>>> +   else
>>> +   min = mid + 1;
>>> +   }
>>> +
>>> +   /* No conversion found */
>>> +   return opcode;
>>> +}
>>> +
>>> +static u8 spi_nor_3to4_opcode(u8 opcode)
>>> +{
>>> +   /* MUST be sorted by 3byte opcode */
>>
>> Because ... why ?
>>
> 
> As explained above, the dichotomic search implemented in
> spi_nor_convert_opcode() assumes that the input array is sorted by src_opcode.

Maybe you should drop that assumption and do normal traversal of the
array ? I feel this is a bit fragile and will break once someone will
cluelessly add a new opcode.

... or add a comment with a big WARNING statement.

>>> +#define ENTRY_3TO4(_opcode){ _opcode, _opcode##_4B }
>>
>> Will this break/be unflexible for flashes with some different 4B opcodes ?
>>
> 
> Of course I cannot provide any guarantee that it will never happen but
> currently it seems that all manufacturers use the same op codes. Besides, 
> the 4-byte address instruction set is part the of JESD216B specification,
> so there is a 

Re: [PATCH v3 1/9] mtd: spi-nor: improve macronix_quad_enable()

[Marek Vasut]

On 10/25/2016 10:52 AM, Cyrille Pitchen wrote:
> Hi Marek,
> 
> Le 25/10/2016 à 00:00, Marek Vasut a écrit :
>> On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
>>> The patch checks whether the Quad Enable bit is already set in the Status
>>> Register. If so, the function exits immediately with a successful return
>>> code. Otherwise, a message is now printed telling we're setting the
>>> non-volatile bit.
>>>
>>> Signed-off-by: Cyrille Pitchen 
>>> Reviewed-by: Jagan Teki 
>>> ---
>>>  drivers/mtd/spi-nor/spi-nor.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index d0fc165d7d66..5c87b2d99507 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -1211,6 +1211,11 @@ static int macronix_quad_enable(struct spi_nor *nor)
>>> val = read_sr(nor);
>>> if (val < 0)
>>> return val;
>>> +   if (val & SR_QUAD_EN_MX)
>>> +   return 0;
>>> +
>>> +   /* Update the Quad Enable bit. */
>>> +   dev_info(nor->dev, "setting Macronix Quad Enable (non-volatile) bit\n");
>>
>> Should probably be dev_dbg(), since this is just churn in the kernel
>> log. The user doesn't care and the developer can just up the debug level
>> or add his own printk .
>>
> 
> The Quad Enable bit is non-volatile so this trace should be printed only once
> but I'm perfectly fine with using dev_dbg(). I'll change it in the next 
> version.

I get it, but what's the value of it ? Who will make use of this
information being in the kernel log? The kernel is already chatty enough :)

-- 
Best regards,
Marek Vasut

[PATCH v5 7/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/ads7846.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 400e421..50c85d2 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1532,6 +1532,16 @@ static int ads7846_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+   { "tsc2046", 0 },
+   { "ads7843", 0 },
+   { "ads7845", 0 },
+   { "ads7846", 0 },
+   { "ads7873", 0 },
+   { }
+};
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
.driver = {
.name   = "ads7846",
@@ -1546,4 +1556,3 @@ module_spi_driver(ads7846_driver);
 
 MODULE_DESCRIPTION("ADS7846 TouchScreen Driver");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("spi:ads7846");
-- 
2.7.3

[PATCH v5 6/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../devicetree/bindings/input/ads7846.txt  |  9 +++-
 drivers/input/touchscreen/ads7846.c| 60 ++
 2 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt 
b/Documentation/devicetree/bindings/input/ads7846.txt
index 9fc47b0..29f91ed 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,6 +26,12 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+   Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv  The VREF voltage, in millivolts (u16).
@@ -33,7 +39,7 @@ Optional properties:
(ADS7846).
ti,keep-vref-on set to keep vref on for differential
measurements as well
-   ti,swap-xy  swap x and y axis
+   ti,swap-xy  deprecated name for 
touchscreen-swapped-x-y
ti,settle-delay-usecSettling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers.  If set to non-zero,
@@ -82,6 +88,7 @@ Example for a TSC2046 chip connected to an McSPI controller 
of an OMAP SoC::
pendown-gpio = < 8 0>;
vcc-supply = <_vcc3>;
 
+   touchscreen-swapped-x-y;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 1ce3ecb..400e421 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -109,8 +110,13 @@ struct ads7846 {
u16 vref_delay_usecs;
u16 x_plate_ohms;
u16 pressure_max;
+   u16 x_min;
+   u16 x_max;
+   u16 y_min;
+   u16 y_max;
+
+   struct touchscreen_properties prop;
 
-   boolswap_xy;
booluse_internal;
 
struct ads7846_packet   *packet;
@@ -825,22 +831,36 @@ static void ads7846_report_state(struct ads7846 *ts)
 */
if (Rt) {
struct input_dev *input = ts->input;
+   int sx, sy;
+
+   dev_dbg(>spi->dev,
+   "Raw point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* scale ADC values to desired output range */
+   sx = (ts->prop.max_x * (x - ts->x_min))
+   / (ts->x_max - ts->x_min);
+   sy = (ts->prop.max_y * (y - ts->y_min))
+   / (ts->y_max - ts->y_min);
 
-   if (ts->swap_xy)
-   swap(x, y);
+   dev_dbg(>spi->dev,
+   "Scaled point(%4d,%4d), pressure (%4u)\n",
+   sx, sy, Rt);
 
+   /* report event */
if (!ts->pendown) {
input_report_key(input, BTN_TOUCH, 1);
ts->pendown = true;
dev_vdbg(>spi->dev, "DOWN\n");
}
 
-   input_report_abs(input, ABS_X, x);
-   input_report_abs(input, ABS_Y, y);
+   touchscreen_report_pos(ts->input, >prop,
+  (unsigned int) 

[PATCH v5 7/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/ads7846.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 400e421..50c85d2 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1532,6 +1532,16 @@ static int ads7846_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+   { "tsc2046", 0 },
+   { "ads7843", 0 },
+   { "ads7845", 0 },
+   { "ads7846", 0 },
+   { "ads7873", 0 },
+   { }
+};
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
.driver = {
.name   = "ads7846",
@@ -1546,4 +1556,3 @@ module_spi_driver(ads7846_driver);
 
 MODULE_DESCRIPTION("ADS7846 TouchScreen Driver");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("spi:ads7846");
-- 
2.7.3

[PATCH v5 6/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../devicetree/bindings/input/ads7846.txt  |  9 +++-
 drivers/input/touchscreen/ads7846.c| 60 ++
 2 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt 
b/Documentation/devicetree/bindings/input/ads7846.txt
index 9fc47b0..29f91ed 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,6 +26,12 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+   Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv  The VREF voltage, in millivolts (u16).
@@ -33,7 +39,7 @@ Optional properties:
(ADS7846).
ti,keep-vref-on set to keep vref on for differential
measurements as well
-   ti,swap-xy  swap x and y axis
+   ti,swap-xy  deprecated name for 
touchscreen-swapped-x-y
ti,settle-delay-usecSettling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers.  If set to non-zero,
@@ -82,6 +88,7 @@ Example for a TSC2046 chip connected to an McSPI controller 
of an OMAP SoC::
pendown-gpio = < 8 0>;
vcc-supply = <_vcc3>;
 
+   touchscreen-swapped-x-y;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 1ce3ecb..400e421 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -109,8 +110,13 @@ struct ads7846 {
u16 vref_delay_usecs;
u16 x_plate_ohms;
u16 pressure_max;
+   u16 x_min;
+   u16 x_max;
+   u16 y_min;
+   u16 y_max;
+
+   struct touchscreen_properties prop;
 
-   boolswap_xy;
booluse_internal;
 
struct ads7846_packet   *packet;
@@ -825,22 +831,36 @@ static void ads7846_report_state(struct ads7846 *ts)
 */
if (Rt) {
struct input_dev *input = ts->input;
+   int sx, sy;
+
+   dev_dbg(>spi->dev,
+   "Raw point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* scale ADC values to desired output range */
+   sx = (ts->prop.max_x * (x - ts->x_min))
+   / (ts->x_max - ts->x_min);
+   sy = (ts->prop.max_y * (y - ts->y_min))
+   / (ts->y_max - ts->y_min);
 
-   if (ts->swap_xy)
-   swap(x, y);
+   dev_dbg(>spi->dev,
+   "Scaled point(%4d,%4d), pressure (%4u)\n",
+   sx, sy, Rt);
 
+   /* report event */
if (!ts->pendown) {
input_report_key(input, BTN_TOUCH, 1);
ts->pendown = true;
dev_vdbg(>spi->dev, "DOWN\n");
}
 
-   input_report_abs(input, ABS_X, x);
-   input_report_abs(input, ABS_Y, y);
+   touchscreen_report_pos(ts->input, >prop,
+  (unsigned int) sx, (unsigned int) 

[PATCH v5 4/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This extension provides an iio interface for these adc channels.

Since it is not wasting much resources and is very straightforward,
we simply provide all other adc channels as optional iio interfaces
as weel. This can be used for debugging or special applications.

This patch also splits the tsc2007 driver in several source files:
tsc2007.h -- constants, structs and stubs
tsc2007_core.c -- functional parts of the original driver
tsc2007_iio.c -- the optional iio stuff

Makefile magic allows to conditionally link the iio
stuff if CONFIG_IIO=y in a way that it works with
CONFIG_TOUCHSCREEN_TSC2007=m.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/Makefile |   2 +
 drivers/input/touchscreen/tsc2007.h| 124 
 .../touchscreen/{tsc2007.c => tsc2007_core.c}  | 119 +--
 drivers/input/touchscreen/tsc2007_iio.c| 162 +
 4 files changed, 323 insertions(+), 84 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (85%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 81b8645..d932e2d 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)   += tsc40.o
 obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2004)  += tsc2004.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)  += tsc2005.o
+tsc2007-y  := tsc2007_core.o
+tsc2007-$(CONFIG_IIO)  += tsc2007_iio.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)  += tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)  += ucb1400_ts.o
 obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)  += wacom_w8001.o
diff --git a/drivers/input/touchscreen/tsc2007.h 
b/drivers/input/touchscreen/tsc2007.h
new file mode 100644
index 000..7153bf3
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007.h
@@ -0,0 +1,124 @@
+/*
+ * drivers/input/touchscreen/tsc2007.h
+ *
+ * Copyright (c) 2008 MtekVision Co., Ltd.
+ * Kwangwoo Lee 
+ *
+ * Using code from:
+ *  - ads7846.c
+ * Copyright (c) 2005 David Brownell
+ * Copyright (c) 2006 Nokia Corporation
+ *  - corgi_ts.c
+ * Copyright (C) 2004-2005 Richard Purdie
+ *  - omap_ts.[hc], ads7846.h, ts_osk.c
+ * Copyright (C) 2002 MontaVista Software
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2005 Dirk Behme
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TSC2007_MEASURE_TEMP0  (0x0 << 4)
+#define TSC2007_MEASURE_AUX(0x2 << 4)
+#define TSC2007_MEASURE_TEMP1  (0x4 << 4)
+#define TSC2007_ACTIVATE_XN(0x8 << 4)
+#define TSC2007_ACTIVATE_YN(0x9 << 4)
+#define TSC2007_ACTIVATE_YP_XN (0xa << 4)
+#define TSC2007_SETUP  (0xb << 4)
+#define TSC2007_MEASURE_X  (0xc << 4)
+#define TSC2007_MEASURE_Y  (0xd << 4)
+#define TSC2007_MEASURE_Z1 (0xe << 4)
+#define TSC2007_MEASURE_Z2 (0xf << 4)
+
+#define TSC2007_POWER_OFF_IRQ_EN   (0x0 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS0(0x1 << 2)
+#define TSC2007_ADC_OFF_IRQ_EN (0x2 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS1(0x3 << 2)
+
+#define TSC2007_12BIT  (0x0 << 1)
+#define TSC2007_8BIT   (0x1 << 1)
+
+#defineMAX_12BIT   ((1 << 12) - 1)
+
+#define ADC_ON_12BIT   (TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
+
+#define READ_Y (ADC_ON_12BIT | TSC2007_MEASURE_Y)
+#define READ_Z1(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
+#define READ_Z2(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
+#define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
+#define PWRDOWN(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
+
+struct ts_event {
+   u16 x;
+   u16 y;
+   u16 z1, z2;
+};
+
+struct tsc2007 {
+   struct input_dev*input;
+   charphys[32];
+
+   struct i2c_client   *client;
+
+   u16 model;
+   u16 x_plate_ohms;
+
+   struct touchscreen_properties prop;
+
+   boolreport_resistance;
+   u16 min_x;
+  

[PATCH v5 3/8] drivers:input:tsc2007: check for presence and power down tsc2007 during probe

[H. Nikolaus Schaller]

1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index e9d5086..5e3c4bf 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -538,6 +538,14 @@ static int tsc2007_probe(struct i2c_client *client,
 
tsc2007_stop(ts);
 
+   /* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+   err = tsc2007_xfer(ts, PWRDOWN);
+   if (err < 0) {
+   dev_err(>dev,
+   "Failed to setup chip: %d\n", err);
+   return err; /* usually, chip does not respond */
+   }
+
err = input_register_device(input_dev);
if (err) {
dev_err(>dev,
-- 
2.7.3

[PATCH 6/7] powerpc/vdso: switch from legacy_special_mapping_vmops

[Dmitry Safonov]

This will allow to introduce mremap hook (the next patch).

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org 
Signed-off-by: Dmitry Safonov 
---
 arch/powerpc/kernel/vdso.c| 19 +++
 arch/powerpc/kernel/vdso_common.c |  8 ++--
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index e68601ffc9ad..9ee3fd65c6e9 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -51,7 +51,7 @@
 #define VDSO_ALIGNMENT (1 << 16)
 
 static unsigned int vdso32_pages;
-static struct page **vdso32_pagelist;
+static struct vm_special_mapping vdso32_mapping;
 unsigned long vdso32_sigtramp;
 unsigned long vdso32_rt_sigtramp;
 
@@ -64,7 +64,7 @@ static void *vdso32_kbase;
 extern char vdso64_start, vdso64_end;
 static void *vdso64_kbase = _start;
 static unsigned int vdso64_pages;
-static struct page **vdso64_pagelist;
+static struct vm_special_mapping vdso64_mapping;
 unsigned long vdso64_rt_sigtramp;
 #endif /* CONFIG_PPC64 */
 
@@ -143,10 +143,11 @@ struct lib64_elfinfo
unsigned long   text;
 };
 
-static int map_vdso(struct page **vdso_pagelist, unsigned long vdso_pages,
+static int map_vdso(struct vm_special_mapping *vsm, unsigned long vdso_pages,
unsigned long vdso_base)
 {
struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
int ret = 0;
 
mm->context.vdso_base = 0;
@@ -198,12 +199,14 @@ static int map_vdso(struct page **vdso_pagelist, unsigned 
long vdso_pages,
 * It's fine to use that for setting breakpoints in the vDSO code
 * pages though.
 */
-   ret = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
+   vma = _install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 VM_READ|VM_EXEC|
 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
-vdso_pagelist);
-   if (ret)
+vsm);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
current->mm->context.vdso_base = 0;
+   }
 
 out_up_mmap_sem:
up_write(>mmap_sem);
@@ -220,7 +223,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
return 0;
 
if (is_32bit_task())
-   return map_vdso(vdso32_pagelist, vdso32_pages, VDSO32_MBASE);
+   return map_vdso(_mapping, vdso32_pages, VDSO32_MBASE);
 #ifdef CONFIG_PPC64
else
/*
@@ -228,7 +231,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
 * allows get_unmapped_area to find an area near other mmaps
 * and most likely share a SLB entry.
 */
-   return map_vdso(vdso64_pagelist, vdso64_pages, 0);
+   return map_vdso(_mapping, vdso64_pages, 0);
 #endif
WARN_ONCE(1, "task is not 32-bit on non PPC64 kernel");
return -1;
diff --git a/arch/powerpc/kernel/vdso_common.c 
b/arch/powerpc/kernel/vdso_common.c
index c97c30606b3f..047f6b8b230f 100644
--- a/arch/powerpc/kernel/vdso_common.c
+++ b/arch/powerpc/kernel/vdso_common.c
@@ -14,7 +14,7 @@
 #define VDSO_LBASE CONCAT3(VDSO, BITS, _LBASE)
 #define vdso_kbase CONCAT3(vdso, BITS, _kbase)
 #define vdso_pages CONCAT3(vdso, BITS, _pages)
-#define vdso_pagelist  CONCAT3(vdso, BITS, _pagelist)
+#define vdso_mapping   CONCAT3(vdso, BITS, _mapping)
 
 #undef pr_fmt
 #define pr_fmt(fmt)"vDSO" __stringify(BITS) ": " fmt
@@ -207,6 +207,7 @@ static __init int vdso_setup(struct lib_elfinfo *v)
 static __init void init_vdso_pagelist(void)
 {
int i;
+   struct page **vdso_pagelist;
 
/* Make sure pages are in the correct state */
vdso_pagelist = kzalloc(sizeof(struct page *) * (vdso_pages + 2),
@@ -221,6 +222,9 @@ static __init void init_vdso_pagelist(void)
}
vdso_pagelist[i++] = virt_to_page(vdso_data);
vdso_pagelist[i] = NULL;
+
+   vdso_mapping.pages = vdso_pagelist;
+   vdso_mapping.name = "[vdso]";
 }
 
 #undef find_section
@@ -236,7 +240,7 @@ static __init void init_vdso_pagelist(void)
 #undef VDSO_LBASE
 #undef vdso_kbase
 #undef vdso_pages
-#undef vdso_pagelist
+#undef vdso_mapping
 #undef lib_elfinfo
 #undef BITS
 #undef _CONCAT3
-- 
2.10.0

[PATCH v5 3/8] drivers:input:tsc2007: check for presence and power down tsc2007 during probe

[H. Nikolaus Schaller]

1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index e9d5086..5e3c4bf 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -538,6 +538,14 @@ static int tsc2007_probe(struct i2c_client *client,
 
tsc2007_stop(ts);
 
+   /* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+   err = tsc2007_xfer(ts, PWRDOWN);
+   if (err < 0) {
+   dev_err(>dev,
+   "Failed to setup chip: %d\n", err);
+   return err; /* usually, chip does not respond */
+   }
+
err = input_register_device(input_dev);
if (err) {
dev_err(>dev,
-- 
2.7.3

[PATCH 6/7] powerpc/vdso: switch from legacy_special_mapping_vmops

[Dmitry Safonov]

This will allow to introduce mremap hook (the next patch).

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Andy Lutomirski 
Cc: Oleg Nesterov 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org 
Signed-off-by: Dmitry Safonov 
---
 arch/powerpc/kernel/vdso.c| 19 +++
 arch/powerpc/kernel/vdso_common.c |  8 ++--
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index e68601ffc9ad..9ee3fd65c6e9 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -51,7 +51,7 @@
 #define VDSO_ALIGNMENT (1 << 16)
 
 static unsigned int vdso32_pages;
-static struct page **vdso32_pagelist;
+static struct vm_special_mapping vdso32_mapping;
 unsigned long vdso32_sigtramp;
 unsigned long vdso32_rt_sigtramp;
 
@@ -64,7 +64,7 @@ static void *vdso32_kbase;
 extern char vdso64_start, vdso64_end;
 static void *vdso64_kbase = _start;
 static unsigned int vdso64_pages;
-static struct page **vdso64_pagelist;
+static struct vm_special_mapping vdso64_mapping;
 unsigned long vdso64_rt_sigtramp;
 #endif /* CONFIG_PPC64 */
 
@@ -143,10 +143,11 @@ struct lib64_elfinfo
unsigned long   text;
 };
 
-static int map_vdso(struct page **vdso_pagelist, unsigned long vdso_pages,
+static int map_vdso(struct vm_special_mapping *vsm, unsigned long vdso_pages,
unsigned long vdso_base)
 {
struct mm_struct *mm = current->mm;
+   struct vm_area_struct *vma;
int ret = 0;
 
mm->context.vdso_base = 0;
@@ -198,12 +199,14 @@ static int map_vdso(struct page **vdso_pagelist, unsigned 
long vdso_pages,
 * It's fine to use that for setting breakpoints in the vDSO code
 * pages though.
 */
-   ret = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
+   vma = _install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
 VM_READ|VM_EXEC|
 VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
-vdso_pagelist);
-   if (ret)
+vsm);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
current->mm->context.vdso_base = 0;
+   }
 
 out_up_mmap_sem:
up_write(>mmap_sem);
@@ -220,7 +223,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
return 0;
 
if (is_32bit_task())
-   return map_vdso(vdso32_pagelist, vdso32_pages, VDSO32_MBASE);
+   return map_vdso(_mapping, vdso32_pages, VDSO32_MBASE);
 #ifdef CONFIG_PPC64
else
/*
@@ -228,7 +231,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, 
int uses_interp)
 * allows get_unmapped_area to find an area near other mmaps
 * and most likely share a SLB entry.
 */
-   return map_vdso(vdso64_pagelist, vdso64_pages, 0);
+   return map_vdso(_mapping, vdso64_pages, 0);
 #endif
WARN_ONCE(1, "task is not 32-bit on non PPC64 kernel");
return -1;
diff --git a/arch/powerpc/kernel/vdso_common.c 
b/arch/powerpc/kernel/vdso_common.c
index c97c30606b3f..047f6b8b230f 100644
--- a/arch/powerpc/kernel/vdso_common.c
+++ b/arch/powerpc/kernel/vdso_common.c
@@ -14,7 +14,7 @@
 #define VDSO_LBASE CONCAT3(VDSO, BITS, _LBASE)
 #define vdso_kbase CONCAT3(vdso, BITS, _kbase)
 #define vdso_pages CONCAT3(vdso, BITS, _pages)
-#define vdso_pagelist  CONCAT3(vdso, BITS, _pagelist)
+#define vdso_mapping   CONCAT3(vdso, BITS, _mapping)
 
 #undef pr_fmt
 #define pr_fmt(fmt)"vDSO" __stringify(BITS) ": " fmt
@@ -207,6 +207,7 @@ static __init int vdso_setup(struct lib_elfinfo *v)
 static __init void init_vdso_pagelist(void)
 {
int i;
+   struct page **vdso_pagelist;
 
/* Make sure pages are in the correct state */
vdso_pagelist = kzalloc(sizeof(struct page *) * (vdso_pages + 2),
@@ -221,6 +222,9 @@ static __init void init_vdso_pagelist(void)
}
vdso_pagelist[i++] = virt_to_page(vdso_data);
vdso_pagelist[i] = NULL;
+
+   vdso_mapping.pages = vdso_pagelist;
+   vdso_mapping.name = "[vdso]";
 }
 
 #undef find_section
@@ -236,7 +240,7 @@ static __init void init_vdso_pagelist(void)
 #undef VDSO_LBASE
 #undef vdso_kbase
 #undef vdso_pages
-#undef vdso_pagelist
+#undef vdso_mapping
 #undef lib_elfinfo
 #undef BITS
 #undef _CONCAT3
-- 
2.10.0

[PATCH v5 4/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This extension provides an iio interface for these adc channels.

Since it is not wasting much resources and is very straightforward,
we simply provide all other adc channels as optional iio interfaces
as weel. This can be used for debugging or special applications.

This patch also splits the tsc2007 driver in several source files:
tsc2007.h -- constants, structs and stubs
tsc2007_core.c -- functional parts of the original driver
tsc2007_iio.c -- the optional iio stuff

Makefile magic allows to conditionally link the iio
stuff if CONFIG_IIO=y in a way that it works with
CONFIG_TOUCHSCREEN_TSC2007=m.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/Makefile |   2 +
 drivers/input/touchscreen/tsc2007.h| 124 
 .../touchscreen/{tsc2007.c => tsc2007_core.c}  | 119 +--
 drivers/input/touchscreen/tsc2007_iio.c| 162 +
 4 files changed, 323 insertions(+), 84 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (85%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 81b8645..d932e2d 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -80,6 +80,8 @@ obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)   += tsc40.o
 obj-$(CONFIG_TOUCHSCREEN_TSC200X_CORE) += tsc200x-core.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2004)  += tsc2004.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)  += tsc2005.o
+tsc2007-y  := tsc2007_core.o
+tsc2007-$(CONFIG_IIO)  += tsc2007_iio.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)  += tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)  += ucb1400_ts.o
 obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)  += wacom_w8001.o
diff --git a/drivers/input/touchscreen/tsc2007.h 
b/drivers/input/touchscreen/tsc2007.h
new file mode 100644
index 000..7153bf3
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2007.h
@@ -0,0 +1,124 @@
+/*
+ * drivers/input/touchscreen/tsc2007.h
+ *
+ * Copyright (c) 2008 MtekVision Co., Ltd.
+ * Kwangwoo Lee 
+ *
+ * Using code from:
+ *  - ads7846.c
+ * Copyright (c) 2005 David Brownell
+ * Copyright (c) 2006 Nokia Corporation
+ *  - corgi_ts.c
+ * Copyright (C) 2004-2005 Richard Purdie
+ *  - omap_ts.[hc], ads7846.h, ts_osk.c
+ * Copyright (C) 2002 MontaVista Software
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2005 Dirk Behme
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TSC2007_MEASURE_TEMP0  (0x0 << 4)
+#define TSC2007_MEASURE_AUX(0x2 << 4)
+#define TSC2007_MEASURE_TEMP1  (0x4 << 4)
+#define TSC2007_ACTIVATE_XN(0x8 << 4)
+#define TSC2007_ACTIVATE_YN(0x9 << 4)
+#define TSC2007_ACTIVATE_YP_XN (0xa << 4)
+#define TSC2007_SETUP  (0xb << 4)
+#define TSC2007_MEASURE_X  (0xc << 4)
+#define TSC2007_MEASURE_Y  (0xd << 4)
+#define TSC2007_MEASURE_Z1 (0xe << 4)
+#define TSC2007_MEASURE_Z2 (0xf << 4)
+
+#define TSC2007_POWER_OFF_IRQ_EN   (0x0 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS0(0x1 << 2)
+#define TSC2007_ADC_OFF_IRQ_EN (0x2 << 2)
+#define TSC2007_ADC_ON_IRQ_DIS1(0x3 << 2)
+
+#define TSC2007_12BIT  (0x0 << 1)
+#define TSC2007_8BIT   (0x1 << 1)
+
+#defineMAX_12BIT   ((1 << 12) - 1)
+
+#define ADC_ON_12BIT   (TSC2007_12BIT | TSC2007_ADC_ON_IRQ_DIS0)
+
+#define READ_Y (ADC_ON_12BIT | TSC2007_MEASURE_Y)
+#define READ_Z1(ADC_ON_12BIT | TSC2007_MEASURE_Z1)
+#define READ_Z2(ADC_ON_12BIT | TSC2007_MEASURE_Z2)
+#define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
+#define PWRDOWN(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
+
+struct ts_event {
+   u16 x;
+   u16 y;
+   u16 z1, z2;
+};
+
+struct tsc2007 {
+   struct input_dev*input;
+   charphys[32];
+
+   struct i2c_client   *client;
+
+   u16 model;
+   u16 x_plate_ohms;
+
+   struct touchscreen_properties prop;
+
+   boolreport_resistance;
+   u16 min_x;
+   u16 min_y;
+   

Re: [PATCH v3 8/9] mtd: spi-nor: add support to Macronix mx66l1g45g

[Marek Vasut]

On 10/25/2016 11:39 AM, Cyrille Pitchen wrote:
> Hi Marek,

Hi,

> Le 25/10/2016 à 00:16, Marek Vasut a écrit :
>> On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
>>> This patch adds an entry in the spi_nor_ids[] table to add support
>>> to the Macronix mx66l1g45g.
>>>
>>> Signed-off-by: Cyrille Pitchen 
>>> ---
>>>  drivers/mtd/spi-nor/spi-nor.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index db4874d4af79..eb21d3d4e4e6 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -937,6 +937,7 @@ static const struct flash_info spi_nor_ids[] = {
>>> { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
>>> { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
>>> { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ) 
>>> },
>>> +   { "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) 
>>> },
>>> { "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) 
>>> },
>>>  
>>> /* Micron */
>>>
>> This should be submitted separately as it could be applied right away.
>>
> 
> I totally agree with you. Indeed I have only provided patch 8 and 9 because
> I refer to these memories in the cover letter and to "prove" that I did really
> test every memory of the list. If everyone trust me about the test I do, I
> will remove patch 8 and 9 in the next version.

I think 9 needs to stay or be separated somehow differently from the
series, since it also adds some code to support the flash. Otherwise,
go for submitting them separately.

> By the way, I need to add a remark about the Spansion S25FL127S. The sample I
> have is compliant with neither the JESD216B specification nor the Cypress
> datasheet. More precisely, the Cypress datasheet claims that the S25FL127S
> is compliant with the JESD216B (minor 6) so its Basic Flash Parameter Table
> (BFPT) should contain 16 DWORDS.
> However my sample claims to be JESD216B compliant (I read minor 6) and that
> the BFPT has 16 DWORDS but the 7 last DWORDS of this table are all 0x.
> Only the first 9 DWORDS are properly filled, the DWORDS described in JESD216
> (minor 0).
> Also my sample pretend to provide the optional 4-byte address instruction set
> (4BAIS) table but the data I read are once again all 0x.
> 
> It's surprising that this 128Mbit memory supports the 4-byte address
> instruction set but the 4-byte Fast Read actually seems to be supported.

They probably use the same HDL design for the controller block in many
memories, they just burn in different ID/SFDP/geometry tables for each
chip they roll out from the factory based on how well the memory array
works.

> Consequently, Fast Read operations work but Sector Erase cannot due to the
> 0xFF op code read from the 4BAIS table. I think I just have a broken sample so
> if anyone can test with another sample and confirm that the SFDP series also
> work with Spansion S25FL127S it would be nice! :)

I don't have one, sorry.

-- 
Best regards,
Marek Vasut

Re: [PATCH v3 8/9] mtd: spi-nor: add support to Macronix mx66l1g45g

[Marek Vasut]

On 10/25/2016 11:39 AM, Cyrille Pitchen wrote:
> Hi Marek,

Hi,

> Le 25/10/2016 à 00:16, Marek Vasut a écrit :
>> On 10/24/2016 06:34 PM, Cyrille Pitchen wrote:
>>> This patch adds an entry in the spi_nor_ids[] table to add support
>>> to the Macronix mx66l1g45g.
>>>
>>> Signed-off-by: Cyrille Pitchen 
>>> ---
>>>  drivers/mtd/spi-nor/spi-nor.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index db4874d4af79..eb21d3d4e4e6 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -937,6 +937,7 @@ static const struct flash_info spi_nor_ids[] = {
>>> { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512, 0) },
>>> { "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
>>> { "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_QUAD_READ) 
>>> },
>>> +   { "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) 
>>> },
>>> { "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) 
>>> },
>>>  
>>> /* Micron */
>>>
>> This should be submitted separately as it could be applied right away.
>>
> 
> I totally agree with you. Indeed I have only provided patch 8 and 9 because
> I refer to these memories in the cover letter and to "prove" that I did really
> test every memory of the list. If everyone trust me about the test I do, I
> will remove patch 8 and 9 in the next version.

I think 9 needs to stay or be separated somehow differently from the
series, since it also adds some code to support the flash. Otherwise,
go for submitting them separately.

> By the way, I need to add a remark about the Spansion S25FL127S. The sample I
> have is compliant with neither the JESD216B specification nor the Cypress
> datasheet. More precisely, the Cypress datasheet claims that the S25FL127S
> is compliant with the JESD216B (minor 6) so its Basic Flash Parameter Table
> (BFPT) should contain 16 DWORDS.
> However my sample claims to be JESD216B compliant (I read minor 6) and that
> the BFPT has 16 DWORDS but the 7 last DWORDS of this table are all 0x.
> Only the first 9 DWORDS are properly filled, the DWORDS described in JESD216
> (minor 0).
> Also my sample pretend to provide the optional 4-byte address instruction set
> (4BAIS) table but the data I read are once again all 0x.
> 
> It's surprising that this 128Mbit memory supports the 4-byte address
> instruction set but the 4-byte Fast Read actually seems to be supported.

They probably use the same HDL design for the controller block in many
memories, they just burn in different ID/SFDP/geometry tables for each
chip they roll out from the factory based on how well the memory array
works.

> Consequently, Fast Read operations work but Sector Erase cannot due to the
> 0xFF op code read from the 4BAIS table. I think I just have a broken sample so
> if anyone can test with another sample and confirm that the SFDP series also
> work with Spansion S25FL127S it would be nice! :)

I don't have one, sorry.

-- 
Best regards,
Marek Vasut

Re: [PATCH 4/4] ARM: dts: da850: Add the usb otg device node

[David Lechner]

On 10/25/2016 09:39 AM, Alexandre Bailon wrote:

This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
This also enables the otg usb controller for the lcdk board.

Signed-off-by: Alexandre Bailon 
---
 arch/arm/boot/dts/da850-lcdk.dts |  8 
 arch/arm/boot/dts/da850.dtsi | 15 +++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..dca9735 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
 };

+_phy {
+   status = "okay";
+   };
+
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..b11d395 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -372,6 +372,21 @@
>;
status = "disabled";
};
+   usb_phy: usb-phy {
+   compatible = "ti,da830-usb-phy";
+   #phy-cells = <1>;
+   status = "disabled";
+   };
+   usb20: usb20@20 {


This should be usb0: usb@20


+   compatible = "ti,da830-musb";
+   reg = <0x20 0x1>;
+   interrupts = <58>;
+   interrupt-names = "mc";
+   dr_mode = "otg";
+   phys = <_phy 0>;
+   phy-names = "usb-phy";
+   status = "disabled";
+   };
gpio: gpio@226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;

Re: [PATCH 4/4] ARM: dts: da850: Add the usb otg device node

[David Lechner]

On 10/25/2016 09:39 AM, Alexandre Bailon wrote:

This adds the device tree node for the usb otg
controller present in the da850 family of SoC's.
This also enables the otg usb controller for the lcdk board.

Signed-off-by: Alexandre Bailon 
---
 arch/arm/boot/dts/da850-lcdk.dts |  8 
 arch/arm/boot/dts/da850.dtsi | 15 +++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..dca9735 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -158,6 +158,14 @@
rx-num-evt = <32>;
 };

+_phy {
+   status = "okay";
+   };
+
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index f79e1b9..b11d395 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -372,6 +372,21 @@
>;
status = "disabled";
};
+   usb_phy: usb-phy {
+   compatible = "ti,da830-usb-phy";
+   #phy-cells = <1>;
+   status = "disabled";
+   };
+   usb20: usb20@20 {


This should be usb0: usb@20


+   compatible = "ti,da830-musb";
+   reg = <0x20 0x1>;
+   interrupts = <58>;
+   interrupt-names = "mc";
+   dr_mode = "otg";
+   phys = <_phy 0>;
+   phy-names = "usb-phy";
+   status = "disabled";
+   };
gpio: gpio@226000 {
compatible = "ti,dm6441-gpio";
gpio-controller;

[PATCH v5 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

[H. Nikolaus Schaller]

this should reduce unnecessary input events.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index c1d9593..e9d5086 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
 
wait_queue_head_t   wait;
boolstopped;
+   boolpendown;
 
int (*get_pendown_state)(struct device *);
void(*clear_penirq)(void);
@@ -227,7 +228,11 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
sx, sy, rt);
 
/* report event */
-   input_report_key(input, BTN_TOUCH, 1);
+   if (!ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 1);
+   ts->pendown = true;
+   }
+
touchscreen_report_pos(ts->input, >prop,
(unsigned int) sx,
(unsigned int) sy,
@@ -250,9 +255,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 
dev_dbg(>client->dev, "UP\n");
 
-   input_report_key(input, BTN_TOUCH, 0);
-   input_report_abs(input, ABS_PRESSURE, 0);
-   input_sync(input);
+   if (ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 0);
+   input_report_abs(input, ABS_PRESSURE, 0);
+   input_sync(input);
+
+   ts->pendown = false;
+   }
 
if (ts->clear_penirq)
ts->clear_penirq();
-- 
2.7.3

[PATCH v5 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

[H. Nikolaus Schaller]

this should reduce unnecessary input events.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index c1d9593..e9d5086 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
 
wait_queue_head_t   wait;
boolstopped;
+   boolpendown;
 
int (*get_pendown_state)(struct device *);
void(*clear_penirq)(void);
@@ -227,7 +228,11 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
sx, sy, rt);
 
/* report event */
-   input_report_key(input, BTN_TOUCH, 1);
+   if (!ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 1);
+   ts->pendown = true;
+   }
+
touchscreen_report_pos(ts->input, >prop,
(unsigned int) sx,
(unsigned int) sy,
@@ -250,9 +255,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 
dev_dbg(>client->dev, "UP\n");
 
-   input_report_key(input, BTN_TOUCH, 0);
-   input_report_abs(input, ABS_PRESSURE, 0);
-   input_sync(input);
+   if (ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 0);
+   input_report_abs(input, ABS_PRESSURE, 0);
+   input_sync(input);
+
+   ts->pendown = false;
+   }
 
if (ts->clear_penirq)
ts->clear_penirq();
-- 
2.7.3

[PATCH v5 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Changes V5:
* ads7846: remove an empty line (suggested by Andrew F. Davis )
* ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis 
)
* tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuid test 
robot)
* refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan 
Cameron )

2016-10-17 16:00:02: Changes V4:
* fix a merge/squash issue resulting in a non-bisectable patch set (suggested 
by kbuid test robot)
* remove some unnecessary #include (suggested by Jonathan Cameron 
)
* make the iio extension depend on CONFIG_IIO rather than selecting it 
(suggested by Jonathan Cameron )
* swapped patch 3/n and patch 4/n to remove internal dependency

2016-09-23 14:41:23: Changes V3:
* fix an issue with swapping
* remove hard clipping to min/max rectangle - some systems expect to handle 
negative coordinates
* make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for 
inverted / swapped axes")

2015-11-13 21:36:07: Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property 
(suggested by Rob Herring)

2015-11-06 16:14:53: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.

New common bindings have been defined by
commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):

Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y 
axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (8):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
flipping and rotation
  drivers:input:tsc2007: send pendown and penup only once like
ads7846(+tsc2046) driver does
  drivers:input:tsc2007: check for presence and power down tsc2007
during probe
  drivers:input:tsc2007: add iio interface to read external ADC input
and temperature
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings

 .../devicetree/bindings/input/ads7846.txt  |   9 +-
 .../bindings/input/touchscreen/tsc2007.txt |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |  25 ++-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   3 +-
 drivers/input/touchscreen/Makefile |   2 +
 drivers/input/touchscreen/ads7846.c|  71 --
 drivers/input/touchscreen/tsc2007.h| 124 +++
 .../touchscreen/{tsc2007.c => tsc2007_core.c}  | 240 -
 drivers/input/touchscreen/tsc2007_iio.c| 162 ++
 include/linux/i2c/tsc2007.h|   8 +
 12 files changed, 556 insertions(+), 127 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (70%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

-- 
2.7.3

[PATCH v5 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Tested with OpenPandora.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  3 ++-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index fa611a5..b8b3864 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
ti,y-max = /bits/ 16 <3600>;
ti,x-plate-ohms = /bits/ 16 <80>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
 
wakeup-source;
};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index b0d1551..d12008a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -700,10 +700,19 @@
pendown-gpio = < 30 GPIO_ACTIVE_HIGH>;
vcc-supply = <>;
 
-   ti,x-min = /bits/ 16 <0>;
-   ti,x-max = /bits/ 16 <8000>;
-   ti,y-min = /bits/ 16 <0>;
-   ti,y-max = /bits/ 16 <4800>;
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <16>;
+   touchscreen-fuzz-y = <16>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+
+   ti,x-min = /bits/ 16 <160>;
+   ti,x-max = /bits/ 16 <3900>;
+   ti,y-min = /bits/ 16 <220>;
+   ti,y-max = /bits/ 16 <3750>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345b..3627a63 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -66,6 +66,7 @@
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
ti,swap-xy;
-   wakeup-source;
+   touchscreen-swapped-x-y;
+   linux,wakeup;
};
 };
-- 
2.7.3

[PATCH v5 5/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

While we fix the GTA04 we add proper pinmux for the
penirq gpio.

Tested on: GTA04A4 and Pyra-Handheld

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f..64d6ee3 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -273,6 +273,13 @@
OMAP3_CORE1_IOPAD(0x2134, PIN_INPUT_PULLUP | MUX_MODE4) 
/* gpio112 */
>;
};
+
+   penirq_pins: pinmux_penirq_pins {
+   pinctrl-single,pins = <
+   /* here we could enable to wakeup the cpu from suspend 
by a pen touch */
+   OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT_PULLUP | MUX_MODE4) 
/* gpio160 */
+   >;
+   };
 };
 
 _pmx_core2 {
@@ -410,10 +417,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-   gpios = < 0 GPIO_ACTIVE_LOW>;
-   ti,x-plate-ohms = <600>;
+   gpios = < 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+   touchscreen-size-x = <480>;
+   touchscreen-size-y = <640>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <3>;
+   touchscreen-fuzz-y = <8>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-y;
+   ti,min-x = <0x100>;
+   ti,max-x = <0xf00>;
+   ti,min-y = <0x100>;
+   ti,max-y = <0xf00>;
+   ti,max-rt = <4096>;
+   ti,x-plate-ohms = <550>;
};
 
/* RFID EEPROM */
-- 
2.7.3

[PATCH v5 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Changes V5:
* ads7846: remove an empty line (suggested by Andrew F. Davis )
* ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis 
)
* tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuid test 
robot)
* refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan 
Cameron )

2016-10-17 16:00:02: Changes V4:
* fix a merge/squash issue resulting in a non-bisectable patch set (suggested 
by kbuid test robot)
* remove some unnecessary #include (suggested by Jonathan Cameron 
)
* make the iio extension depend on CONFIG_IIO rather than selecting it 
(suggested by Jonathan Cameron )
* swapped patch 3/n and patch 4/n to remove internal dependency

2016-09-23 14:41:23: Changes V3:
* fix an issue with swapping
* remove hard clipping to min/max rectangle - some systems expect to handle 
negative coordinates
* make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for 
inverted / swapped axes")

2015-11-13 21:36:07: Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property 
(suggested by Rob Herring)

2015-11-06 16:14:53: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.

New common bindings have been defined by
commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):

Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y 
axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (8):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
flipping and rotation
  drivers:input:tsc2007: send pendown and penup only once like
ads7846(+tsc2046) driver does
  drivers:input:tsc2007: check for presence and power down tsc2007
during probe
  drivers:input:tsc2007: add iio interface to read external ADC input
and temperature
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings

 .../devicetree/bindings/input/ads7846.txt  |   9 +-
 .../bindings/input/touchscreen/tsc2007.txt |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |  25 ++-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   3 +-
 drivers/input/touchscreen/Makefile |   2 +
 drivers/input/touchscreen/ads7846.c|  71 --
 drivers/input/touchscreen/tsc2007.h| 124 +++
 .../touchscreen/{tsc2007.c => tsc2007_core.c}  | 240 -
 drivers/input/touchscreen/tsc2007_iio.c| 162 ++
 include/linux/i2c/tsc2007.h|   8 +
 12 files changed, 556 insertions(+), 127 deletions(-)
 create mode 100644 drivers/input/touchscreen/tsc2007.h
 rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (70%)
 create mode 100644 drivers/input/touchscreen/tsc2007_iio.c

-- 
2.7.3

[PATCH v5 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Tested with OpenPandora.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  3 ++-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index fa611a5..b8b3864 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
ti,y-max = /bits/ 16 <3600>;
ti,x-plate-ohms = /bits/ 16 <80>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
 
wakeup-source;
};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index b0d1551..d12008a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -700,10 +700,19 @@
pendown-gpio = < 30 GPIO_ACTIVE_HIGH>;
vcc-supply = <>;
 
-   ti,x-min = /bits/ 16 <0>;
-   ti,x-max = /bits/ 16 <8000>;
-   ti,y-min = /bits/ 16 <0>;
-   ti,y-max = /bits/ 16 <4800>;
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <16>;
+   touchscreen-fuzz-y = <16>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+
+   ti,x-min = /bits/ 16 <160>;
+   ti,x-max = /bits/ 16 <3900>;
+   ti,y-min = /bits/ 16 <220>;
+   ti,y-max = /bits/ 16 <3750>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345b..3627a63 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -66,6 +66,7 @@
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
ti,swap-xy;
-   wakeup-source;
+   touchscreen-swapped-x-y;
+   linux,wakeup;
};
 };
-- 
2.7.3

[PATCH v5 5/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

While we fix the GTA04 we add proper pinmux for the
penirq gpio.

Tested on: GTA04A4 and Pyra-Handheld

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f..64d6ee3 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -273,6 +273,13 @@
OMAP3_CORE1_IOPAD(0x2134, PIN_INPUT_PULLUP | MUX_MODE4) 
/* gpio112 */
>;
};
+
+   penirq_pins: pinmux_penirq_pins {
+   pinctrl-single,pins = <
+   /* here we could enable to wakeup the cpu from suspend 
by a pen touch */
+   OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT_PULLUP | MUX_MODE4) 
/* gpio160 */
+   >;
+   };
 };
 
 _pmx_core2 {
@@ -410,10 +417,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-   gpios = < 0 GPIO_ACTIVE_LOW>;
-   ti,x-plate-ohms = <600>;
+   gpios = < 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+   touchscreen-size-x = <480>;
+   touchscreen-size-y = <640>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <3>;
+   touchscreen-fuzz-y = <8>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-y;
+   ti,min-x = <0x100>;
+   ti,max-x = <0xf00>;
+   ti,min-y = <0x100>;
+   ti,max-y = <0xf00>;
+   ti,max-rt = <4096>;
+   ti,x-plate-ohms = <550>;
};
 
/* RFID EEPROM */
-- 
2.7.3

[PATCH v5 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

Finally, calculate_pressure has been renamed to calculate_resistance
because that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../bindings/input/touchscreen/tsc2007.txt |  20 ++--
 drivers/input/touchscreen/tsc2007.c| 120 +
 include/linux/i2c/tsc2007.h|   8 ++
 3 files changed, 118 insertions(+), 30 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again 
the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = < 0 0>;
ti,x-plate-ohms = <180>;
+   touchscreen-size-x = <640>;
+   touchscreen-size-y = <480>;
};
 
/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..c1d9593 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
u16 model;
u16 x_plate_ohms;
+
+   struct touchscreen_properties prop;
+
+   boolreport_resistance;
+   u16 min_x;
+   u16 min_y;
+   u16 max_x;
+   u16 max_y;
u16 max_rt;
unsigned long   poll_period; /* in jiffies */
int fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct 
ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+   struct ts_event *tc)
 {
u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
struct ts_event tc;
u32 rt;
 

[PATCH v5 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

Finally, calculate_pressure has been renamed to calculate_resistance
because that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../bindings/input/touchscreen/tsc2007.txt |  20 ++--
 drivers/input/touchscreen/tsc2007.c| 120 +
 include/linux/i2c/tsc2007.h|   8 ++
 3 files changed, 118 insertions(+), 30 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again 
the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = < 0 0>;
ti,x-plate-ohms = <180>;
+   touchscreen-size-x = <640>;
+   touchscreen-size-y = <480>;
};
 
/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..c1d9593 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
u16 model;
u16 x_plate_ohms;
+
+   struct touchscreen_properties prop;
+
+   boolreport_resistance;
+   u16 min_x;
+   u16 min_y;
+   u16 max_x;
+   u16 max_y;
u16 max_rt;
unsigned long   poll_period; /* in jiffies */
int fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct 
ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+   struct ts_event *tc)
 {
u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
struct ts_event tc;
u32 rt;
 
+   

Re: [PATCH] PCI: pci-stub: accept exceptions to the ID- and class-based matching

[Laszlo Ersek]

On 10/25/16 20:42, Alex Williamson wrote:
> On Tue, 25 Oct 2016 20:24:19 +0200
> Laszlo Ersek  wrote:
> 
>> Some systems have multiple instances of the exact same kind of PCI device
>> installed. When VFIO users intend to assign these devices to VMs, they
>> occasionally don't want to assign all of them; they'd keep a few for
>> host-side use. The current ID- and class-based matching in pci-stub
>> doesn't accommodate this use case, so users are left with either
>> rc.local-style host boot scripts, or QEMU wrapper scripts (which are
>> inferior to a pure libvirt environment).
>>
>> Introduce the "except" module parameter for pci-stub. In addition to
>> "ids", users can specify a list of Domain:Bus:Device.Function tuples. The
>> tuples are parsed and saved before pci_add_dynid() is called. The pci-stub
>> probe function will fail for the listed devices, for the initial and all
>> later (explicit) binding attempts.
>>
>> Cc: Alex Williamson 
>> Cc: Andrei Grigore 
>> Cc: Bjorn Helgaas 
>> Cc: Jayme Howard 
>> Reported-by: Andrei Grigore 
>> Ref: https://www.redhat.com/archives/vfio-users/2016-October/msg00121.html
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  drivers/pci/pci-stub.c | 63 
>> ++
>>  1 file changed, 63 insertions(+)
>>
>> diff --git a/drivers/pci/pci-stub.c b/drivers/pci/pci-stub.c
>> index 886fb3570278..120c29609c44 100644
>> --- a/drivers/pci/pci-stub.c
>> +++ b/drivers/pci/pci-stub.c
>> @@ -26,8 +26,44 @@ MODULE_PARM_DESC(ids, "Initial PCI IDs to add to the stub 
>> driver, format is "
>>   
>> "\"vendor:device[:subvendor[:subdevice[:class[:class_mask\""
>>   " and multiple comma separated entries can be specified");
>>  
>> +#define MAX_EXCEPT 16
>> +
>> +static unsigned num_except;
>> +static struct except {
>> +u16 domain;
>> +u16 devid;
>> +} except[MAX_EXCEPT];
>> +
>> +/*
>> + * Accommodate substrings like ":00:1c.4," MAX_EXCEPT times, with the 
>> comma
>> + * replaced with '\0' in the last instance
>> + */
>> +static char except_str[13 * MAX_EXCEPT] __initdata;
>> +
>> +module_param_string(except, except_str, sizeof except_str, 0);
>> +MODULE_PARM_DESC(except, "Comma-separated list of PCI addresses to except "
>> + "from the ID- and class-based binding. The address format is "
>> + "Domain:Bus:Device.Function (all components are required and "
>> + "written in hex), for example, :00:1c.4. At most "
>> + __stringify(MAX_EXCEPT) " exceptions are supported.");
> 
> So a user needs to specify both a set of set of vendor:device ids AND an
> exception list?  Wouldn't it be easier to make a list of _included_
> devices by address, w/o needing an ids= list?

First, I didn't want to drop the ids=... parameter for compatibility
reasons.

Second (because I realize you're likely not suggesting to *drop* "ids",
just to provide a positive-sense replacement for it), I have no idea how
to influence the PCI subsystem like this. As far as I know (which is
very little, admittedly), the only way to get the PCI subsystem to call
back into a specific driver probe function is to provide
device/vendor/subsystem IDs, and class patterns, with that device driver.

If I don't provide those IDs (either statically or dynamically), then
the driver will bind nothing, because the core won't invoke the probe
function for any device.

If I provided a match-all pattern (not sure how), then the core would
call the probe function for all devices. While that might help move the
actual positive filtering into the stub probe function (i.e., without
the "ids" parameter), I don't think it would be appreciated.

> FWIW, I think the reason
> this hasn't been done to date is that PCI bus addresses (except for
> root bus devices) are not stable.  Depending on the system, the address
> of a given device may change, not only based on the slot where the
> device is installed, but whether other devices in other slots are
> populated.

I agree.

However, while the addresses are not stable in the face of hardware
changes, I think the addresses don't change haphazardly (that is,
without hardware changes).

So, if you plug in another card, your current pci-stub.except=...
parameter might become invalid; but that's not very different from the
case when you plug in the second instance of a preexistent card right
now -- then the pci-stub.ids=... filter won't match uniquely anymore,
and assignment vs. host-side use might not work as intented.

> This is why when ACPI needs to describe a PCI device (such
> as in the DMAR tables), it does so via paths.  We don't know the bus
> number that will be assigned to a device, but we do know
> deterministically how to traverse to it, for instance root bus -> root
> dev.fn -> intermediate dev.fn -> target dev.fn.  

Applied "ASoC: tlv320aic31xx: add explicit support for tlv320dac31xx" to the asoc tree

[Mark Brown]

The patch

   ASoC: tlv320aic31xx: add explicit support for tlv320dac31xx

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 5e72f824a138a5e6c5600412f307dc279e66ab7a Mon Sep 17 00:00:00 2001
From: Nikita Yushchenko 
Date: Thu, 22 Sep 2016 23:06:43 +0300
Subject: [PATCH] ASoC: tlv320aic31xx: add explicit support for tlv320dac31xx

tlv320dac31xx is a subset of tlv320aic31xx:
- it does not have MIC inputs and ADC, thus capture is not supported,
- it has analog inputs AIN1/AIN2 that can be mixed into output.

Although tlv320dac31xx does work with tlv320aic31xx driver, this setup
does register non-existent widgets and non-existent capture stream.
Thus userspace lists non-existent objects in user interfaces, an can
access these, causing operations with device registers that are
declared as "reserved" in tlv320dac31xx datasheet.

This patch fixes this situation by separating controls/widgets/routes
into common, aic31xx-specific, and dac31xx-specific parts. Only parts
that match actual hardware (as declared in "compatible" device tree
property) are registered.

Signed-off-by: Nikita Yushchenko 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/tlv320aic31xx.c | 212 ---
 sound/soc/codecs/tlv320aic31xx.h |   2 +
 2 files changed, 158 insertions(+), 56 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index 3c5e1df01c19..fb7d64834d8b 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -273,10 +273,20 @@ static const DECLARE_TLV_DB_SCALE(sp_vol_tlv, -6350, 50, 
0);
 /*
  * controls to be exported to the user space
  */
-static const struct snd_kcontrol_new aic31xx_snd_controls[] = {
+static const struct snd_kcontrol_new common31xx_snd_controls[] = {
SOC_DOUBLE_R_S_TLV("DAC Playback Volume", AIC31XX_LDACVOL,
   AIC31XX_RDACVOL, 0, -127, 48, 7, 0, dac_vol_tlv),
 
+   SOC_DOUBLE_R("HP Driver Playback Switch", AIC31XX_HPLGAIN,
+AIC31XX_HPRGAIN, 2, 1, 0),
+   SOC_DOUBLE_R_TLV("HP Driver Playback Volume", AIC31XX_HPLGAIN,
+AIC31XX_HPRGAIN, 3, 0x09, 0, hp_drv_tlv),
+
+   SOC_DOUBLE_R_TLV("HP Analog Playback Volume", AIC31XX_LANALOGHPL,
+AIC31XX_RANALOGHPR, 0, 0x7F, 1, hp_vol_tlv),
+};
+
+static const struct snd_kcontrol_new aic31xx_snd_controls[] = {
SOC_SINGLE_TLV("ADC Fine Capture Volume", AIC31XX_ADCFGA, 4, 4, 1,
   adc_fgain_tlv),
 
@@ -286,14 +296,6 @@ static const struct snd_kcontrol_new 
aic31xx_snd_controls[] = {
 
SOC_SINGLE_TLV("Mic PGA Capture Volume", AIC31XX_MICPGA, 0,
   119, 0, mic_pga_tlv),
-
-   SOC_DOUBLE_R("HP Driver Playback Switch", AIC31XX_HPLGAIN,
-AIC31XX_HPRGAIN, 2, 1, 0),
-   SOC_DOUBLE_R_TLV("HP Driver Playback Volume", AIC31XX_HPLGAIN,
-AIC31XX_HPRGAIN, 3, 0x09, 0, hp_drv_tlv),
-
-   SOC_DOUBLE_R_TLV("HP Analog Playback Volume", AIC31XX_LANALOGHPL,
-AIC31XX_RANALOGHPR, 0, 0x7F, 1, hp_vol_tlv),
 };
 
 static const struct snd_kcontrol_new aic311x_snd_controls[] = {
@@ -397,17 +399,28 @@ static int aic31xx_dapm_power_event(struct 
snd_soc_dapm_widget *w,
return 0;
 }
 
-static const struct snd_kcontrol_new left_output_switches[] = {
+static const struct snd_kcontrol_new aic31xx_left_output_switches[] = {
SOC_DAPM_SINGLE("From Left DAC", AIC31XX_DACMIXERROUTE, 6, 1, 0),
SOC_DAPM_SINGLE("From MIC1LP", AIC31XX_DACMIXERROUTE, 5, 1, 0),
SOC_DAPM_SINGLE("From MIC1RP", AIC31XX_DACMIXERROUTE, 4, 1, 0),
 };
 
-static const struct snd_kcontrol_new right_output_switches[] = {
+static const struct snd_kcontrol_new aic31xx_right_output_switches[] = {
SOC_DAPM_SINGLE("From Right DAC", AIC31XX_DACMIXERROUTE, 2, 1, 0),
SOC_DAPM_SINGLE("From MIC1RP", AIC31XX_DACMIXERROUTE, 1, 1, 0),
 };
 
+static const struct snd_kcontrol_new dac31xx_left_output_switches[] = {
+   SOC_DAPM_SINGLE("From Left DAC",