Re: [PATCH] i2c: mux: mlxcpld: fix i2c mux selection caching

2016-12-17 Thread Wolfram Sang
On Sat, Dec 17, 2016 at 09:29:11PM +0100, Peter Rosin wrote:
> smbus functions return -ve on error, 0 on success.  However,
> __i2c_transfer() have a different return signature - -ve on error, or
> number of buffers transferred (which may be zero or greater.)
> 
> The upshot of this is that the sense of the text is reversed when using
> the mux on a bus supporting the master_xfer method: we cache the value
> and never retry if we fail to transfer any buffers, but if we succeed,
> we clear the cached value
> 
> Fix this by making mlxcpld_mux_reg_write() return a -ve error code for
> all failure cases, just as was done in commit 7f638c1cb0a1 ("i2c: mux:
> pca954x: fix i2c mux selection caching")
> 
> This also aligns the implementations of these two muxes in this area.
> 
> Signed-off-by: Peter Rosin 

Fixed the commit message and applied to for-current, thanks!



signature.asc
Description: PGP signature


Re: [PATCH] i2c: mux: mlxcpld: fix i2c mux selection caching

2016-12-17 Thread Wolfram Sang
On Sat, Dec 17, 2016 at 09:29:11PM +0100, Peter Rosin wrote:
> smbus functions return -ve on error, 0 on success.  However,
> __i2c_transfer() have a different return signature - -ve on error, or
> number of buffers transferred (which may be zero or greater.)
> 
> The upshot of this is that the sense of the text is reversed when using
> the mux on a bus supporting the master_xfer method: we cache the value
> and never retry if we fail to transfer any buffers, but if we succeed,
> we clear the cached value
> 
> Fix this by making mlxcpld_mux_reg_write() return a -ve error code for
> all failure cases, just as was done in commit 7f638c1cb0a1 ("i2c: mux:
> pca954x: fix i2c mux selection caching")
> 
> This also aligns the implementations of these two muxes in this area.
> 
> Signed-off-by: Peter Rosin 

Fixed the commit message and applied to for-current, thanks!



signature.asc
Description: PGP signature


Re: [PATCH] fix code alignment with open parenthesis in drivers/staging/fbtft/fb_agm1264k-fl.c

2016-12-17 Thread Greg KH
On Sat, Dec 17, 2016 at 08:42:53PM -0600, Scott Matheina wrote:
> Signed-off-by: Scott Matheina 

I can't take patches without any changelog text :(

> ---
>  drivers/staging/fbtft/fb_agm1264k-fl.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
> b/drivers/staging/fbtft/fb_agm1264k-fl.c
> index a6e3af7..4e371ed 100644
> --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> @@ -186,8 +186,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int 
> len, ...)
> 
>   va_end(args);
>   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
> - par->info->device, u8, buf, len, "%s: ", __func__);
> - }
> +   par->info->device, u8, buf, len,
> +   "%s: ", __func__);
> +}

I don't think you did this correctly, do you?


Re: [PATCH] fix code alignment with open parenthesis in drivers/staging/fbtft/fb_agm1264k-fl.c

2016-12-17 Thread Greg KH
On Sat, Dec 17, 2016 at 08:42:53PM -0600, Scott Matheina wrote:
> Signed-off-by: Scott Matheina 

I can't take patches without any changelog text :(

> ---
>  drivers/staging/fbtft/fb_agm1264k-fl.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
> b/drivers/staging/fbtft/fb_agm1264k-fl.c
> index a6e3af7..4e371ed 100644
> --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> @@ -186,8 +186,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int 
> len, ...)
> 
>   va_end(args);
>   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
> - par->info->device, u8, buf, len, "%s: ", __func__);
> - }
> +   par->info->device, u8, buf, len,
> +   "%s: ", __func__);
> +}

I don't think you did this correctly, do you?


Re: [PATCH] spi: rockchip: support "sleep" pin configuration

2016-12-17 Thread Caesar Wang

在 2016年12月17日 08:59, Brian Norris 写道:

In the pattern of many other devices, support a system-sleep pin
configuration.

Signed-off-by: Brian Norris 


Tested-by: Caesar Wang 


---
  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7 +++
  drivers/spi/spi-rockchip.c | 5 +
  2 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt 
b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index d2ca153614f9..83da4931d832 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -31,6 +31,10 @@ Optional Properties:
  - rx-sample-delay-ns: nanoseconds to delay after the SCLK edge before sampling
Rx data (may need to be fine tuned for high capacitance lines).
No delay (0) by default.
+- pinctrl-names: Names for the pin configuration(s); may be "default" or
+   "sleep", where the "sleep" configuration may describe the state
+   the pins should be in during system suspend. See also
+   pinctrl/pinctrl-bindings.txt.
  
  
  Example:

@@ -46,4 +50,7 @@ Example:
interrupts = ;
clocks = < SCLK_SPI0>, < PCLK_SPI0>;
clock-names = "spiclk", "apb_pclk";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep>;
+   pinctrl-names = "default", "sleep";
};
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 0f89c2169c24..acf31f36b898 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -843,6 +844,8 @@ static int rockchip_spi_suspend(struct device *dev)
clk_disable_unprepare(rs->apb_pclk);
}
  
+	pinctrl_pm_select_sleep_state(dev);

+
return ret;
  }
  
@@ -852,6 +855,8 @@ static int rockchip_spi_resume(struct device *dev)

struct spi_master *master = dev_get_drvdata(dev);
struct rockchip_spi *rs = spi_master_get_devdata(master);
  
+	pinctrl_pm_select_default_state(dev);

+
if (!pm_runtime_suspended(dev)) {
ret = clk_prepare_enable(rs->apb_pclk);
if (ret < 0)





Re: [PATCH] spi: rockchip: support "sleep" pin configuration

2016-12-17 Thread Caesar Wang

在 2016年12月17日 08:59, Brian Norris 写道:

In the pattern of many other devices, support a system-sleep pin
configuration.

Signed-off-by: Brian Norris 


Tested-by: Caesar Wang 


---
  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7 +++
  drivers/spi/spi-rockchip.c | 5 +
  2 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt 
b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index d2ca153614f9..83da4931d832 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -31,6 +31,10 @@ Optional Properties:
  - rx-sample-delay-ns: nanoseconds to delay after the SCLK edge before sampling
Rx data (may need to be fine tuned for high capacitance lines).
No delay (0) by default.
+- pinctrl-names: Names for the pin configuration(s); may be "default" or
+   "sleep", where the "sleep" configuration may describe the state
+   the pins should be in during system suspend. See also
+   pinctrl/pinctrl-bindings.txt.
  
  
  Example:

@@ -46,4 +50,7 @@ Example:
interrupts = ;
clocks = < SCLK_SPI0>, < PCLK_SPI0>;
clock-names = "spiclk", "apb_pclk";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep>;
+   pinctrl-names = "default", "sleep";
};
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 0f89c2169c24..acf31f36b898 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -843,6 +844,8 @@ static int rockchip_spi_suspend(struct device *dev)
clk_disable_unprepare(rs->apb_pclk);
}
  
+	pinctrl_pm_select_sleep_state(dev);

+
return ret;
  }
  
@@ -852,6 +855,8 @@ static int rockchip_spi_resume(struct device *dev)

struct spi_master *master = dev_get_drvdata(dev);
struct rockchip_spi *rs = spi_master_get_devdata(master);
  
+	pinctrl_pm_select_default_state(dev);

+
if (!pm_runtime_suspended(dev)) {
ret = clk_prepare_enable(rs->apb_pclk);
if (ret < 0)





Re: [PATCH] Input: mouse: synaptics - change msleep to usleep_range for small msecs

2016-12-17 Thread Igor Grinberg
Hi Aniroop Mathur,


On 12/04/16 15:05, Aniroop Mathur wrote:
> Hello Mr. Igor Grinberg
> 
> On Sun, Dec 4, 2016 at 1:32 PM, Igor Grinberg  wrote:
>> Hi Aniroop Mathur,
>>
>> On 11/29/16 23:02, Aniroop Mathur wrote:
>>> Dear Mike Rapoport, Igor Grinberg,
>>> Greetings!
>>>
>>> I am Aniroop Mathur from Samsung R Institute, India.
>>>
>>> I have submitted one patch as below for review to Linux Open Source.
>>> The problem is that we do not have the hardware available with us to
>>> test it and we would like to test it before actually applying it.
>>> As you are the author of this driver, I am contacting you to request you
>>> provide your feedback upon this patch.
>>>
>>> Also if you have the hardware available, could you please help to
>>> test this patch on your hardware? or could you provide contact points
>>> of individuals who could support to test it?
>>
>> This touchpad and the driver was used on an old PXA270 based PDA.
>> I currently don't have those at hand to test the patch.
>>
>>>
>>> Thank you!
>>>
>>> BR,
>>> Aniroop Mathur
>>>
>>> On Tue, Nov 29, 2016 at 1:25 AM, Aniroop Mathur  
>>> wrote:
 msleep(1~20) may not do what the caller intends, and will often sleep 
 longer.
 (~20 ms actual sleep for any value given in the 1~20ms range)
>>
>> Well, it should be at least 1ms as stated in my comment just before the 
>> define.
>> So, from the correctness perspective larger values will also do the job.
>> Additionally, since I've taken a spare 2ms, and you are making it even more
>> precise (3000us + 100us) - it will still do the job and stay correct.
>> So, there should be no issue from correctness POV.
>>
> 
> Alright, Thanks!
> 
 This is not the desired behaviour for many cases like device resume time,
 device suspend time, device enable time, retry logic, etc.
 Thus, change msleep to usleep_range for precise wakeups.
>>
>> This is a human interface touchpad device, even having 20ms soft reset
>> sleep time will not impact the responsiveness for humans.
>> IMHO, there is no need for precise wakeups for this device, so I wouldn't
>> bother.
>>
> 
> Well, from the point of view of device working and responsiveness for 
> "humans",
> I agree that it is okay to sleep for 20 / 40 ms or even 100 ms. However, this
> patch is not trying to solve any such issues. This patch is only trying to 
> make
> the process sleep for appropriate time as mentioned in the parameter and does
> not cause any harm here. I could see that this function is called during 
> device
> resume and device probe time. So this change will improve the resume and probe
> time for this device and doing the same change in other drivers will
> contribute to
> improvement in overall kernel resume and boot time a little bit so response 
> time
> increases a little bit. Plus, it is recommended and mentioned in kernel
> documentation to use usleep_range for delays between 1-10 ms.
> So usleep_range should serve better here.
> Explained originally here to why not use msleep for 1 - 20 ms:
> http://lkml.org/lkml/2007/8/3/250

I have absolutely 0 objections to this.
So, as I already have said, it will be hard for me to test it currently, but
if you want it and Dmitry wants to apply it, my ack is below.


 Signed-off-by: Aniroop Mathur 

Acked-by: Igor Grinberg 

 ---
  drivers/input/mouse/synaptics_i2c.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/input/mouse/synaptics_i2c.c 
 b/drivers/input/mouse/synaptics_i2c.c
 index aa7c5da..4d688a6 100644
 --- a/drivers/input/mouse/synaptics_i2c.c
 +++ b/drivers/input/mouse/synaptics_i2c.c
 @@ -29,7 +29,7 @@
   * after soft reset, we should wait for 1 ms
   * before the device becomes operational
   */
 -#define SOFT_RESET_DELAY_MS3
 +#define SOFT_RESET_DELAY_US3000
  /* and after hard reset, we should wait for max 500ms */
  #define HARD_RESET_DELAY_MS500

 @@ -311,7 +311,7 @@ static int synaptics_i2c_reset_config(struct 
 i2c_client *client)
 if (ret) {
 dev_err(>dev, "Unable to reset device\n");
 } else {
 -   msleep(SOFT_RESET_DELAY_MS);
 +   usleep_range(SOFT_RESET_DELAY_US, SOFT_RESET_DELAY_US + 
 100);
 ret = synaptics_i2c_config(client);
 if (ret)
 dev_err(>dev, "Unable to config device\n");
 --
 2.6.2

>>>
>>
>> --
>> Regards,
>> Igor.
> 

-- 
Regards,
Igor.


Re: [PATCH] Input: mouse: synaptics - change msleep to usleep_range for small msecs

2016-12-17 Thread Igor Grinberg
Hi Aniroop Mathur,


On 12/04/16 15:05, Aniroop Mathur wrote:
> Hello Mr. Igor Grinberg
> 
> On Sun, Dec 4, 2016 at 1:32 PM, Igor Grinberg  wrote:
>> Hi Aniroop Mathur,
>>
>> On 11/29/16 23:02, Aniroop Mathur wrote:
>>> Dear Mike Rapoport, Igor Grinberg,
>>> Greetings!
>>>
>>> I am Aniroop Mathur from Samsung R Institute, India.
>>>
>>> I have submitted one patch as below for review to Linux Open Source.
>>> The problem is that we do not have the hardware available with us to
>>> test it and we would like to test it before actually applying it.
>>> As you are the author of this driver, I am contacting you to request you
>>> provide your feedback upon this patch.
>>>
>>> Also if you have the hardware available, could you please help to
>>> test this patch on your hardware? or could you provide contact points
>>> of individuals who could support to test it?
>>
>> This touchpad and the driver was used on an old PXA270 based PDA.
>> I currently don't have those at hand to test the patch.
>>
>>>
>>> Thank you!
>>>
>>> BR,
>>> Aniroop Mathur
>>>
>>> On Tue, Nov 29, 2016 at 1:25 AM, Aniroop Mathur  
>>> wrote:
 msleep(1~20) may not do what the caller intends, and will often sleep 
 longer.
 (~20 ms actual sleep for any value given in the 1~20ms range)
>>
>> Well, it should be at least 1ms as stated in my comment just before the 
>> define.
>> So, from the correctness perspective larger values will also do the job.
>> Additionally, since I've taken a spare 2ms, and you are making it even more
>> precise (3000us + 100us) - it will still do the job and stay correct.
>> So, there should be no issue from correctness POV.
>>
> 
> Alright, Thanks!
> 
 This is not the desired behaviour for many cases like device resume time,
 device suspend time, device enable time, retry logic, etc.
 Thus, change msleep to usleep_range for precise wakeups.
>>
>> This is a human interface touchpad device, even having 20ms soft reset
>> sleep time will not impact the responsiveness for humans.
>> IMHO, there is no need for precise wakeups for this device, so I wouldn't
>> bother.
>>
> 
> Well, from the point of view of device working and responsiveness for 
> "humans",
> I agree that it is okay to sleep for 20 / 40 ms or even 100 ms. However, this
> patch is not trying to solve any such issues. This patch is only trying to 
> make
> the process sleep for appropriate time as mentioned in the parameter and does
> not cause any harm here. I could see that this function is called during 
> device
> resume and device probe time. So this change will improve the resume and probe
> time for this device and doing the same change in other drivers will
> contribute to
> improvement in overall kernel resume and boot time a little bit so response 
> time
> increases a little bit. Plus, it is recommended and mentioned in kernel
> documentation to use usleep_range for delays between 1-10 ms.
> So usleep_range should serve better here.
> Explained originally here to why not use msleep for 1 - 20 ms:
> http://lkml.org/lkml/2007/8/3/250

I have absolutely 0 objections to this.
So, as I already have said, it will be hard for me to test it currently, but
if you want it and Dmitry wants to apply it, my ack is below.


 Signed-off-by: Aniroop Mathur 

Acked-by: Igor Grinberg 

 ---
  drivers/input/mouse/synaptics_i2c.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/input/mouse/synaptics_i2c.c 
 b/drivers/input/mouse/synaptics_i2c.c
 index aa7c5da..4d688a6 100644
 --- a/drivers/input/mouse/synaptics_i2c.c
 +++ b/drivers/input/mouse/synaptics_i2c.c
 @@ -29,7 +29,7 @@
   * after soft reset, we should wait for 1 ms
   * before the device becomes operational
   */
 -#define SOFT_RESET_DELAY_MS3
 +#define SOFT_RESET_DELAY_US3000
  /* and after hard reset, we should wait for max 500ms */
  #define HARD_RESET_DELAY_MS500

 @@ -311,7 +311,7 @@ static int synaptics_i2c_reset_config(struct 
 i2c_client *client)
 if (ret) {
 dev_err(>dev, "Unable to reset device\n");
 } else {
 -   msleep(SOFT_RESET_DELAY_MS);
 +   usleep_range(SOFT_RESET_DELAY_US, SOFT_RESET_DELAY_US + 
 100);
 ret = synaptics_i2c_config(client);
 if (ret)
 dev_err(>dev, "Unable to config device\n");
 --
 2.6.2

>>>
>>
>> --
>> Regards,
>> Igor.
> 

-- 
Regards,
Igor.


Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64

2016-12-17 Thread Yury Norov
On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode, and as supporting work,
> introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> existing 32-bit architectures but disabled for new arches (so 64-bit
> off_t is is used by new userspace).
> 
> This version is based on kernel v4.9-rc1.  It works with glibc-2.24,
> and tested with LTP.
 
Hi Arnd, Catalin

For last few days I'm trying to rebase this series on current master,
and I see significant conflicts and regressions. In fact, every time
I rebase on next rc1, I feel like I play a roulette.

This is not a significant problem now because it's almost for sure
that this series will not get into 4.10, for reasons not related to
kernel code. And I have time to deal with regressions. But in general,
I'd like to try my patches on top of other candidates for next merge
window. I cannot read all emails in LKML, but I can easily detect
problems and join to the discussion at early stage if I see any problem.

This is probably a noob question, and there are well-known branches,
like Andrew Morton's one. But at this stage it's very important to
have this series prepared for merge, and I'd prefer to ask about it.

Yury.


Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64

2016-12-17 Thread Yury Norov
On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode, and as supporting work,
> introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> existing 32-bit architectures but disabled for new arches (so 64-bit
> off_t is is used by new userspace).
> 
> This version is based on kernel v4.9-rc1.  It works with glibc-2.24,
> and tested with LTP.
 
Hi Arnd, Catalin

For last few days I'm trying to rebase this series on current master,
and I see significant conflicts and regressions. In fact, every time
I rebase on next rc1, I feel like I play a roulette.

This is not a significant problem now because it's almost for sure
that this series will not get into 4.10, for reasons not related to
kernel code. And I have time to deal with regressions. But in general,
I'd like to try my patches on top of other candidates for next merge
window. I cannot read all emails in LKML, but I can easily detect
problems and join to the discussion at early stage if I see any problem.

This is probably a noob question, and there are well-known branches,
like Andrew Morton's one. But at this stage it's very important to
have this series prepared for merge, and I'd prefer to ask about it.

Yury.


[PATCH] staging: rtl8712: changed struct members to __le32

2016-12-17 Thread Jannik Becher
Fixed sparse warning "cast to restricted __le32".
struct recv_stat and struct phy_stat have always little endian members.

Signed-off-by: Jannik Becher 
---
 drivers/staging/rtl8712/rtl8712_recv.h | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.h 
b/drivers/staging/rtl8712/rtl8712_recv.h
index 0b0c273..0352e6f 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.h
+++ b/drivers/staging/rtl8712/rtl8712_recv.h
@@ -50,12 +50,12 @@
 #define REORDER_WAIT_TIME  30 /* (ms)*/
 
 struct recv_stat {
-   unsigned int rxdw0;
-   unsigned int rxdw1;
-   unsigned int rxdw2;
-   unsigned int rxdw3;
-   unsigned int rxdw4;
-   unsigned int rxdw5;
+   __le32 rxdw0;
+   __le32 rxdw1;
+   __le32 rxdw2;
+   __le32 rxdw3;
+   __le32 rxdw4;
+   __le32 rxdw5;
 };
 
 struct phy_cck_rx_status {
@@ -69,14 +69,14 @@ struct phy_cck_rx_status {
 };
 
 struct phy_stat {
-   unsigned int phydw0;
-   unsigned int phydw1;
-   unsigned int phydw2;
-   unsigned int phydw3;
-   unsigned int phydw4;
-   unsigned int phydw5;
-   unsigned int phydw6;
-   unsigned int phydw7;
+   __le32 phydw0;
+   __le32 phydw1;
+   __le32 phydw2;
+   __le32 phydw3;
+   __le32 phydw4;
+   __le32 phydw5;
+   __le32 phydw6;
+   __le32 phydw7;
 };
 #define PHY_STAT_GAIN_TRSW_SHT 0
 #define PHY_STAT_PWDB_ALL_SHT 4
-- 
2.7.4



[PATCH] staging: rtl8712: changed struct members to __le32

2016-12-17 Thread Jannik Becher
Fixed sparse warning "cast to restricted __le32".
struct recv_stat and struct phy_stat have always little endian members.

Signed-off-by: Jannik Becher 
---
 drivers/staging/rtl8712/rtl8712_recv.h | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.h 
b/drivers/staging/rtl8712/rtl8712_recv.h
index 0b0c273..0352e6f 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.h
+++ b/drivers/staging/rtl8712/rtl8712_recv.h
@@ -50,12 +50,12 @@
 #define REORDER_WAIT_TIME  30 /* (ms)*/
 
 struct recv_stat {
-   unsigned int rxdw0;
-   unsigned int rxdw1;
-   unsigned int rxdw2;
-   unsigned int rxdw3;
-   unsigned int rxdw4;
-   unsigned int rxdw5;
+   __le32 rxdw0;
+   __le32 rxdw1;
+   __le32 rxdw2;
+   __le32 rxdw3;
+   __le32 rxdw4;
+   __le32 rxdw5;
 };
 
 struct phy_cck_rx_status {
@@ -69,14 +69,14 @@ struct phy_cck_rx_status {
 };
 
 struct phy_stat {
-   unsigned int phydw0;
-   unsigned int phydw1;
-   unsigned int phydw2;
-   unsigned int phydw3;
-   unsigned int phydw4;
-   unsigned int phydw5;
-   unsigned int phydw6;
-   unsigned int phydw7;
+   __le32 phydw0;
+   __le32 phydw1;
+   __le32 phydw2;
+   __le32 phydw3;
+   __le32 phydw4;
+   __le32 phydw5;
+   __le32 phydw6;
+   __le32 phydw7;
 };
 #define PHY_STAT_GAIN_TRSW_SHT 0
 #define PHY_STAT_PWDB_ALL_SHT 4
-- 
2.7.4



Re: [PATCH v9 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

2016-12-17 Thread Ricky Liang
On Wed, Dec 14, 2016 at 4:04 PM, Rick Chang  wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang 
> Signed-off-by: Minghsiu Tsai 
> ---
>  drivers/media/platform/Kconfig   |   15 +
>  drivers/media/platform/Makefile  |2 +
>  drivers/media/platform/mtk-jpeg/Makefile |2 +
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1306 
> ++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  139 +++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
>  10 files changed, 2215 insertions(+)

Reviewed-by: Ricky Liang 
Tested-by: Ricky Liang 


Re: [PATCH v9 2/4] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

2016-12-17 Thread Ricky Liang
On Wed, Dec 14, 2016 at 4:04 PM, Rick Chang  wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang 
> Signed-off-by: Minghsiu Tsai 
> ---
>  drivers/media/platform/Kconfig   |   15 +
>  drivers/media/platform/Makefile  |2 +
>  drivers/media/platform/mtk-jpeg/Makefile |2 +
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1306 
> ++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  139 +++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
>  10 files changed, 2215 insertions(+)

Reviewed-by: Ricky Liang 
Tested-by: Ricky Liang 


RE: [PATCH] qed: fix memory leak of a qed_spq_entry on error failure paths

2016-12-17 Thread Mintz, Yuval
> From: Colin Ian King 
> 
> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd
> if an error occurs, causing a memory leak. Fix this by kfree'ing it and also
> setting *pp_ent to NULL to be safe.
> 
> Found with static analysis by CoverityScan, CIDs 1389468-1389470
> 
> Signed-off-by: Colin Ian King 
...
> +err:
> + kfree(*pp_ent);
> + *pp_ent = NULL;
> +
> + return rc;
>  }

Hi Colin - thanks for this.
It would have been preferable to return the previously allocated spq entry.
I.e., do:

+err:
+   qed_spq_return_entry(p_hwfn, *pp_ent);
+   *pp_ent = NULL;
+   return rc;

Thanks,
Yuval


RE: [PATCH] qed: fix memory leak of a qed_spq_entry on error failure paths

2016-12-17 Thread Mintz, Yuval
> From: Colin Ian King 
> 
> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd
> if an error occurs, causing a memory leak. Fix this by kfree'ing it and also
> setting *pp_ent to NULL to be safe.
> 
> Found with static analysis by CoverityScan, CIDs 1389468-1389470
> 
> Signed-off-by: Colin Ian King 
...
> +err:
> + kfree(*pp_ent);
> + *pp_ent = NULL;
> +
> + return rc;
>  }

Hi Colin - thanks for this.
It would have been preferable to return the previously allocated spq entry.
I.e., do:

+err:
+   qed_spq_return_entry(p_hwfn, *pp_ent);
+   *pp_ent = NULL;
+   return rc;

Thanks,
Yuval


[PATCH] serial: pic32_uart: Fix 'request_irq' and 'free_irq' inconsistancy

2016-12-17 Thread Christophe JAILLET
'request_irq' and 'free_irq' should have the same 'dev_id'.
Here one uses 'port', and the other one uses 'sport'.

Signed-off-by: Christophe JAILLET 
---
 drivers/tty/serial/pic32_uart.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/pic32_uart.c b/drivers/tty/serial/pic32_uart.c
index 7f8e99bbcb73..00a33eb859d3 100644
--- a/drivers/tty/serial/pic32_uart.c
+++ b/drivers/tty/serial/pic32_uart.c
@@ -495,13 +495,13 @@ static int pic32_uart_startup(struct uart_port *port)
 
 out_t:
kfree(sport->irq_tx_name);
-   free_irq(sport->irq_tx, sport);
+   free_irq(sport->irq_tx, port);
 out_r:
kfree(sport->irq_rx_name);
-   free_irq(sport->irq_rx, sport);
+   free_irq(sport->irq_rx, port);
 out_f:
kfree(sport->irq_fault_name);
-   free_irq(sport->irq_fault, sport);
+   free_irq(sport->irq_fault, port);
 out_done:
return ret;
 }
-- 
2.9.3



[PATCH] serial: pic32_uart: Fix 'request_irq' and 'free_irq' inconsistancy

2016-12-17 Thread Christophe JAILLET
'request_irq' and 'free_irq' should have the same 'dev_id'.
Here one uses 'port', and the other one uses 'sport'.

Signed-off-by: Christophe JAILLET 
---
 drivers/tty/serial/pic32_uart.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/pic32_uart.c b/drivers/tty/serial/pic32_uart.c
index 7f8e99bbcb73..00a33eb859d3 100644
--- a/drivers/tty/serial/pic32_uart.c
+++ b/drivers/tty/serial/pic32_uart.c
@@ -495,13 +495,13 @@ static int pic32_uart_startup(struct uart_port *port)
 
 out_t:
kfree(sport->irq_tx_name);
-   free_irq(sport->irq_tx, sport);
+   free_irq(sport->irq_tx, port);
 out_r:
kfree(sport->irq_rx_name);
-   free_irq(sport->irq_rx, sport);
+   free_irq(sport->irq_rx, port);
 out_f:
kfree(sport->irq_fault_name);
-   free_irq(sport->irq_fault, sport);
+   free_irq(sport->irq_fault, port);
 out_done:
return ret;
 }
-- 
2.9.3



[PATCH] staging: vc04_services: Fix bracing on single statement blocks

2016-12-17 Thread Aaron Moore
Fix coding style issue caught by checkpatch.pl relating to braces on
single statement blocks. This issue was corrected in 3 locations.

Signed-off-by: Aaron Moore 
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
index f76f4d7..e0ba0ed 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
@@ -80,9 +80,8 @@ void vchiu_queue_push(VCHIU_QUEUE_T *queue, VCHIQ_HEADER_T 
*header)
return;
 
while (queue->write == queue->read + queue->size) {
-   if (down_interruptible(>pop) != 0) {
+   if (down_interruptible(>pop) != 0)
flush_signals(current);
-   }
}
 
/*
@@ -107,9 +106,8 @@ void vchiu_queue_push(VCHIU_QUEUE_T *queue, VCHIQ_HEADER_T 
*header)
 VCHIQ_HEADER_T *vchiu_queue_peek(VCHIU_QUEUE_T *queue)
 {
while (queue->write == queue->read) {
-   if (down_interruptible(>push) != 0) {
+   if (down_interruptible(>push) != 0)
flush_signals(current);
-   }
}
 
up(>push); // We haven't removed anything from the queue.
@@ -128,9 +126,8 @@ VCHIQ_HEADER_T *vchiu_queue_pop(VCHIU_QUEUE_T *queue)
VCHIQ_HEADER_T *header;
 
while (queue->write == queue->read) {
-   if (down_interruptible(>push) != 0) {
+   if (down_interruptible(>push) != 0)
flush_signals(current);
-   }
}
 
/*
-- 
2.10.2



[PATCH] staging: vc04_services: Fix bracing on single statement blocks

2016-12-17 Thread Aaron Moore
Fix coding style issue caught by checkpatch.pl relating to braces on
single statement blocks. This issue was corrected in 3 locations.

Signed-off-by: Aaron Moore 
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
index f76f4d7..e0ba0ed 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
@@ -80,9 +80,8 @@ void vchiu_queue_push(VCHIU_QUEUE_T *queue, VCHIQ_HEADER_T 
*header)
return;
 
while (queue->write == queue->read + queue->size) {
-   if (down_interruptible(>pop) != 0) {
+   if (down_interruptible(>pop) != 0)
flush_signals(current);
-   }
}
 
/*
@@ -107,9 +106,8 @@ void vchiu_queue_push(VCHIU_QUEUE_T *queue, VCHIQ_HEADER_T 
*header)
 VCHIQ_HEADER_T *vchiu_queue_peek(VCHIU_QUEUE_T *queue)
 {
while (queue->write == queue->read) {
-   if (down_interruptible(>push) != 0) {
+   if (down_interruptible(>push) != 0)
flush_signals(current);
-   }
}
 
up(>push); // We haven't removed anything from the queue.
@@ -128,9 +126,8 @@ VCHIQ_HEADER_T *vchiu_queue_pop(VCHIU_QUEUE_T *queue)
VCHIQ_HEADER_T *header;
 
while (queue->write == queue->read) {
-   if (down_interruptible(>push) != 0) {
+   if (down_interruptible(>push) != 0)
flush_signals(current);
-   }
}
 
/*
-- 
2.10.2



[PATCH v10 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

2016-12-17 Thread Joel Holdsworth
This adds documentation of the device tree bindings of the Lattice iCE40
FPGA driver for the FPGA manager framework.

Signed-off-by: Joel Holdsworth 
Acked-by: Rob Herring 
Acked-by: Alan Tull 
Acked-by: Moritz Fischer 
Acked-by: Marek Vasut 
---
 .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt 
b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
new file mode 100644
index 000..7e7a78b
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
@@ -0,0 +1,21 @@
+Lattice iCE40 FPGA Manager
+
+Required properties:
+- compatible:  Should contain "lattice,ice40-fpga-mgr"
+- reg: SPI chip select
+- spi-max-frequency:   Maximum SPI frequency (>=100, <=2500)
+- cdone-gpios: GPIO input connected to CDONE pin
+- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
+   that unless the GPIO is held low during startup, the
+   FPGA will enter Master SPI mode and drive SCK with a
+   clock signal potentially jamming other devices on the
+   bus until the firmware is loaded.
+
+Example:
+   ice40: ice40@0 {
+   compatible = "lattice,ice40-fpga-mgr";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   cdone-gpios = < 24 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
-- 
2.7.4



[PATCH v10 3/3] fpga: Add support for Lattice iCE40 FPGAs

2016-12-17 Thread Joel Holdsworth
This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
UltraPlus devices, through slave SPI.

Signed-off-by: Joel Holdsworth 
Reviewed-by: Marek Vasut 
Reviewed-by: Moritz Fischer 
Acked-by: Alan Tull 
---
 drivers/fpga/Kconfig |   6 ++
 drivers/fpga/Makefile|   1 +
 drivers/fpga/ice40-spi.c | 219 +++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/fpga/ice40-spi.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..967cda4 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -20,6 +20,12 @@ config FPGA_REGION
  FPGA Regions allow loading FPGA images under control of
  the Device Tree.
 
+config FPGA_MGR_ICE40_SPI
+   tristate "Lattice iCE40 SPI"
+   depends on OF && SPI
+   help
+ FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bc..cc0d364 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_FPGA) += fpga-mgr.o
 
 # FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_ICE40_SPI)   += ice40-spi.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
new file mode 100644
index 000..16ea2c6
--- /dev/null
+++ b/drivers/fpga/ice40-spi.c
@@ -0,0 +1,219 @@
+/*
+ * FPGA Manager Driver for Lattice iCE40.
+ *
+ *  Copyright (c) 2016 Joel Holdsworth
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This driver adds support to the FPGA manager for configuring the SRAM of
+ * Lattice iCE40 FPGAs through slave SPI.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ICE40_SPI_MAX_SPEED 2500 /* Hz */
+#define ICE40_SPI_MIN_SPEED 100 /* Hz */
+
+#define ICE40_SPI_RESET_DELAY 1 /* us (>200ns) */
+#define ICE40_SPI_HOUSEKEEPING_DELAY 1200 /* us */
+
+#define ICE40_SPI_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
+
+struct ice40_fpga_priv {
+   struct spi_device *dev;
+   struct gpio_desc *reset;
+   struct gpio_desc *cdone;
+};
+
+static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+
+   return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
+   FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ice40_fpga_ops_write_init(struct fpga_manager *mgr,
+struct fpga_image_info *info,
+const char *buf, size_t count)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+   struct spi_device *dev = priv->dev;
+   struct spi_message message;
+   struct spi_transfer assert_cs_then_reset_delay = {
+   .cs_change   = 1,
+   .delay_usecs = ICE40_SPI_RESET_DELAY
+   };
+   struct spi_transfer housekeeping_delay_then_release_cs = {
+   .delay_usecs = ICE40_SPI_HOUSEKEEPING_DELAY
+   };
+   int ret;
+
+   if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
+   dev_err(>dev,
+   "Partial reconfiguration is not supported\n");
+   return -ENOTSUPP;
+   }
+
+   /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
+   spi_bus_lock(dev->master);
+
+   gpiod_set_value(priv->reset, 1);
+
+   spi_message_init();
+   spi_message_add_tail(_cs_then_reset_delay, );
+   ret = spi_sync_locked(dev, );
+
+   /* Come out of reset */
+   gpiod_set_value(priv->reset, 0);
+
+   /* Abort if the chip-select failed */
+   if (ret)
+   goto fail;
+
+   /* Check CDONE is de-asserted i.e. the FPGA is reset */
+   if (gpiod_get_value(priv->cdone)) {
+   dev_err(>dev, "Device reset failed, CDONE is asserted\n");
+   ret = -EIO;
+   goto fail;
+   }
+
+   /* Wait for the housekeeping to complete, and release SS_B */
+   spi_message_init();
+   spi_message_add_tail(_delay_then_release_cs, );
+   ret = spi_sync_locked(dev, );
+
+fail:
+   spi_bus_unlock(dev->master);
+
+   return ret;
+}
+
+static int ice40_fpga_ops_write(struct fpga_manager *mgr,
+   const char *buf, size_t count)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+
+   return spi_write(priv->dev, buf, count);
+}
+

[PATCH v10 1/3] of: Add vendor prefix for Lattice Semiconductor

2016-12-17 Thread Joel Holdsworth
Lattice Semiconductor Corporation is a manufacturer of integrated
circuits and IP products, including low-power FPGAs, video connectivity
devices and millimeter wave wireless products.

Website: http://latticesemi.com

Signed-off-by: Joel Holdsworth 
Acked-by: Rob Herring 
Acked-by: Alan Tull 
Acked-by: Moritz Fischer 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 64fdc8c..7a87932 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -158,6 +158,7 @@ kosagi  Sutajio Ko-Usagi PTE Ltd.
 kyoKyocera Corporation
 lacie  LaCie
 lantiq Lantiq Semiconductor
+latticeLattice Semiconductor
 lenovo Lenovo Group Ltd.
 lg LG Corporation
 linux  Linux-specific binding
-- 
2.7.4



[PATCH v10 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

2016-12-17 Thread Joel Holdsworth
This adds documentation of the device tree bindings of the Lattice iCE40
FPGA driver for the FPGA manager framework.

Signed-off-by: Joel Holdsworth 
Acked-by: Rob Herring 
Acked-by: Alan Tull 
Acked-by: Moritz Fischer 
Acked-by: Marek Vasut 
---
 .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt 
b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
new file mode 100644
index 000..7e7a78b
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
@@ -0,0 +1,21 @@
+Lattice iCE40 FPGA Manager
+
+Required properties:
+- compatible:  Should contain "lattice,ice40-fpga-mgr"
+- reg: SPI chip select
+- spi-max-frequency:   Maximum SPI frequency (>=100, <=2500)
+- cdone-gpios: GPIO input connected to CDONE pin
+- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
+   that unless the GPIO is held low during startup, the
+   FPGA will enter Master SPI mode and drive SCK with a
+   clock signal potentially jamming other devices on the
+   bus until the firmware is loaded.
+
+Example:
+   ice40: ice40@0 {
+   compatible = "lattice,ice40-fpga-mgr";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   cdone-gpios = < 24 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
-- 
2.7.4



[PATCH v10 3/3] fpga: Add support for Lattice iCE40 FPGAs

2016-12-17 Thread Joel Holdsworth
This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
UltraPlus devices, through slave SPI.

Signed-off-by: Joel Holdsworth 
Reviewed-by: Marek Vasut 
Reviewed-by: Moritz Fischer 
Acked-by: Alan Tull 
---
 drivers/fpga/Kconfig |   6 ++
 drivers/fpga/Makefile|   1 +
 drivers/fpga/ice40-spi.c | 219 +++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/fpga/ice40-spi.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..967cda4 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -20,6 +20,12 @@ config FPGA_REGION
  FPGA Regions allow loading FPGA images under control of
  the Device Tree.
 
+config FPGA_MGR_ICE40_SPI
+   tristate "Lattice iCE40 SPI"
+   depends on OF && SPI
+   help
+ FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bc..cc0d364 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_FPGA) += fpga-mgr.o
 
 # FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_ICE40_SPI)   += ice40-spi.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
new file mode 100644
index 000..16ea2c6
--- /dev/null
+++ b/drivers/fpga/ice40-spi.c
@@ -0,0 +1,219 @@
+/*
+ * FPGA Manager Driver for Lattice iCE40.
+ *
+ *  Copyright (c) 2016 Joel Holdsworth
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This driver adds support to the FPGA manager for configuring the SRAM of
+ * Lattice iCE40 FPGAs through slave SPI.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ICE40_SPI_MAX_SPEED 2500 /* Hz */
+#define ICE40_SPI_MIN_SPEED 100 /* Hz */
+
+#define ICE40_SPI_RESET_DELAY 1 /* us (>200ns) */
+#define ICE40_SPI_HOUSEKEEPING_DELAY 1200 /* us */
+
+#define ICE40_SPI_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
+
+struct ice40_fpga_priv {
+   struct spi_device *dev;
+   struct gpio_desc *reset;
+   struct gpio_desc *cdone;
+};
+
+static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+
+   return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
+   FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ice40_fpga_ops_write_init(struct fpga_manager *mgr,
+struct fpga_image_info *info,
+const char *buf, size_t count)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+   struct spi_device *dev = priv->dev;
+   struct spi_message message;
+   struct spi_transfer assert_cs_then_reset_delay = {
+   .cs_change   = 1,
+   .delay_usecs = ICE40_SPI_RESET_DELAY
+   };
+   struct spi_transfer housekeeping_delay_then_release_cs = {
+   .delay_usecs = ICE40_SPI_HOUSEKEEPING_DELAY
+   };
+   int ret;
+
+   if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
+   dev_err(>dev,
+   "Partial reconfiguration is not supported\n");
+   return -ENOTSUPP;
+   }
+
+   /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
+   spi_bus_lock(dev->master);
+
+   gpiod_set_value(priv->reset, 1);
+
+   spi_message_init();
+   spi_message_add_tail(_cs_then_reset_delay, );
+   ret = spi_sync_locked(dev, );
+
+   /* Come out of reset */
+   gpiod_set_value(priv->reset, 0);
+
+   /* Abort if the chip-select failed */
+   if (ret)
+   goto fail;
+
+   /* Check CDONE is de-asserted i.e. the FPGA is reset */
+   if (gpiod_get_value(priv->cdone)) {
+   dev_err(>dev, "Device reset failed, CDONE is asserted\n");
+   ret = -EIO;
+   goto fail;
+   }
+
+   /* Wait for the housekeeping to complete, and release SS_B */
+   spi_message_init();
+   spi_message_add_tail(_delay_then_release_cs, );
+   ret = spi_sync_locked(dev, );
+
+fail:
+   spi_bus_unlock(dev->master);
+
+   return ret;
+}
+
+static int ice40_fpga_ops_write(struct fpga_manager *mgr,
+   const char *buf, size_t count)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+
+   return spi_write(priv->dev, buf, count);
+}
+
+static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr,
+   

[PATCH v10 1/3] of: Add vendor prefix for Lattice Semiconductor

2016-12-17 Thread Joel Holdsworth
Lattice Semiconductor Corporation is a manufacturer of integrated
circuits and IP products, including low-power FPGAs, video connectivity
devices and millimeter wave wireless products.

Website: http://latticesemi.com

Signed-off-by: Joel Holdsworth 
Acked-by: Rob Herring 
Acked-by: Alan Tull 
Acked-by: Moritz Fischer 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 64fdc8c..7a87932 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -158,6 +158,7 @@ kosagi  Sutajio Ko-Usagi PTE Ltd.
 kyoKyocera Corporation
 lacie  LaCie
 lantiq Lantiq Semiconductor
+latticeLattice Semiconductor
 lenovo Lenovo Group Ltd.
 lg LG Corporation
 linux  Linux-specific binding
-- 
2.7.4



Re: OOM: Better, but still there on

2016-12-17 Thread Tetsuo Handa
Nils Holland wrote:
> On Sat, Dec 17, 2016 at 11:44:45PM +0900, Tetsuo Handa wrote:
> > On 2016/12/17 21:59, Nils Holland wrote:
> > > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
> > >> mount -t tracefs none /debug/trace
> > >> echo 1 > /debug/trace/events/vmscan/enable
> > >> cat /debug/trace/trace_pipe > trace.log
> > >>
> > >> should help
> > >> [...]
> > >
> > > No problem! I enabled writing the trace data to a file and then tried
> > > to trigger another OOM situation. That worked, this time without a
> > > complete kernel panic, but with only my processes being killed and the
> > > system becoming unresponsive.
> >
> > Under OOM situation, writing to a file on disk unlikely works. Maybe
> > logging via network ( "cat /debug/trace/trace_pipe > /dev/udp/$ip/$port"
> > if your are using bash) works better. (I wish we can do it from kernel
> > so that /bin/cat is not disturbed by delays due to page fault.)
> >
> > If you can configure netconsole for logging OOM killer messages and
> > UDP socket for logging trace_pipe messages, udplogger at
> > https://osdn.net/projects/akari/scm/svn/tree/head/branches/udplogger/
> > might fit for logging both output with timestamp into a single file.
>
> Actually, I decided to give this a try once more on machine #2, i.e.
> not the one that produced the previous trace, but the other one.
>
> I logged via netconsole as well as 'cat /debug/trace/trace_pipe' via
> the network to another machine running udplogger. After the machine
> had been frehsly booted and I had set up the logging, unpacking of the
> firefox source tarball started. After it had been unpacking for a
> while, the first load of trace messages started to appear. Some time
> later, OOMs started to appear - I've got quite a lot of them in my
> capture file this time.

Thank you for capturing. I think it worked well. Let's wait for Michal.

The first OOM killer invocation was

  2016-12-17 21:36:56 192.168.17.23:6665 [ 1276.828639] Killed process 3894 
(xz) total-vm:68640kB, anon-rss:65920kB, file-rss:1696kB, shmem-rss:0kB

and the last OOM killer invocation was

  2016-12-17 21:39:27 192.168.17.23:6665 [ 1426.800677] Killed process 3070 
(screen) total-vm:7440kB, anon-rss:960kB, file-rss:2360kB, shmem-rss:0kB

and trace output was sent until

  2016-12-17 21:37:07 192.168.17.23:48468 kworker/u4:4-3896  [000]   
1287.202958: mm_shrink_slab_start: super_cache_scan+0x0/0x170 f4436ed4: nid: 0 
objects to shrink 86 gfp_flags GFP_NOFS|__GFP_NOFAIL pgs_scanned 32 lru_pgs 
406078 cache items 412 delta 0 total_scan 86

which (I hope) should be sufficient for analysis.

>
> Unfortunately, the reclaim trace messages stopped a while after the first
> OOM messages show up - most likely my "cat" had been killed at that
> point or became unresponsive. :-/
>
> In the end, the machine didn't completely panic, but after nothing new
> showed up being logged via the network, I walked up to the
> machine and found it in a state where I couldn't really log in to it
> anymore, but all that worked was, as always, a magic SysRequest reboot.

There is a known issue (since Linux 2.6.32) that all memory allocation requests
get stuck due to kswapd v.s. shrink_inactive_list() livelock which occurs under
almost OOM situation ( http://lkml.kernel.org/r/20160211225929.GU14668@dastard 
).
If we hit it, even "page allocation stalls for " messages do not show up.

Even if we didn't hit it, although agetty and sshd were still alive

  2016-12-17 21:39:27 192.168.17.23:6665 [ 1426.800614] [ 2800] 0  2800 
1152  494   6   30 0 agetty
  2016-12-17 21:39:27 192.168.17.23:6665 [ 1426.800618] [ 2802] 0  2802 
1457 1055   6   30 -1000 sshd

memory allocation was delaying too much

  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034624] btrfs-transacti: page 
alloction stalls for 93995ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL)
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034628] CPU: 1 PID: 1949 Comm: 
btrfs-transacti Not tainted 4.9.0-gentoo #3
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034630] Hardware name: 
Hewlett-Packard Compaq 15 Notebook PC/21F7, BIOS F.22 08/06/2014
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034638]  f162f94c c142bd8e 
0001  f162f970 c110ad7e c1b58833 02400840
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034645]  f162f978 f162f980 
c1b55814 f162f960 0160 f162fa38 c110b78c 02400840
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034652]  c1b55814 00016f2b 
 0040  f21d f21d 0001
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034653] Call Trace:
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034660]  [] 
dump_stack+0x47/0x69
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034666]  [] 
warn_alloc+0xce/0xf0
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034671]  [] 
__alloc_pages_nodemask+0x97c/0xd30
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034678]  

Re: OOM: Better, but still there on

2016-12-17 Thread Tetsuo Handa
Nils Holland wrote:
> On Sat, Dec 17, 2016 at 11:44:45PM +0900, Tetsuo Handa wrote:
> > On 2016/12/17 21:59, Nils Holland wrote:
> > > On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
> > >> mount -t tracefs none /debug/trace
> > >> echo 1 > /debug/trace/events/vmscan/enable
> > >> cat /debug/trace/trace_pipe > trace.log
> > >>
> > >> should help
> > >> [...]
> > >
> > > No problem! I enabled writing the trace data to a file and then tried
> > > to trigger another OOM situation. That worked, this time without a
> > > complete kernel panic, but with only my processes being killed and the
> > > system becoming unresponsive.
> >
> > Under OOM situation, writing to a file on disk unlikely works. Maybe
> > logging via network ( "cat /debug/trace/trace_pipe > /dev/udp/$ip/$port"
> > if your are using bash) works better. (I wish we can do it from kernel
> > so that /bin/cat is not disturbed by delays due to page fault.)
> >
> > If you can configure netconsole for logging OOM killer messages and
> > UDP socket for logging trace_pipe messages, udplogger at
> > https://osdn.net/projects/akari/scm/svn/tree/head/branches/udplogger/
> > might fit for logging both output with timestamp into a single file.
>
> Actually, I decided to give this a try once more on machine #2, i.e.
> not the one that produced the previous trace, but the other one.
>
> I logged via netconsole as well as 'cat /debug/trace/trace_pipe' via
> the network to another machine running udplogger. After the machine
> had been frehsly booted and I had set up the logging, unpacking of the
> firefox source tarball started. After it had been unpacking for a
> while, the first load of trace messages started to appear. Some time
> later, OOMs started to appear - I've got quite a lot of them in my
> capture file this time.

Thank you for capturing. I think it worked well. Let's wait for Michal.

The first OOM killer invocation was

  2016-12-17 21:36:56 192.168.17.23:6665 [ 1276.828639] Killed process 3894 
(xz) total-vm:68640kB, anon-rss:65920kB, file-rss:1696kB, shmem-rss:0kB

and the last OOM killer invocation was

  2016-12-17 21:39:27 192.168.17.23:6665 [ 1426.800677] Killed process 3070 
(screen) total-vm:7440kB, anon-rss:960kB, file-rss:2360kB, shmem-rss:0kB

and trace output was sent until

  2016-12-17 21:37:07 192.168.17.23:48468 kworker/u4:4-3896  [000]   
1287.202958: mm_shrink_slab_start: super_cache_scan+0x0/0x170 f4436ed4: nid: 0 
objects to shrink 86 gfp_flags GFP_NOFS|__GFP_NOFAIL pgs_scanned 32 lru_pgs 
406078 cache items 412 delta 0 total_scan 86

which (I hope) should be sufficient for analysis.

>
> Unfortunately, the reclaim trace messages stopped a while after the first
> OOM messages show up - most likely my "cat" had been killed at that
> point or became unresponsive. :-/
>
> In the end, the machine didn't completely panic, but after nothing new
> showed up being logged via the network, I walked up to the
> machine and found it in a state where I couldn't really log in to it
> anymore, but all that worked was, as always, a magic SysRequest reboot.

There is a known issue (since Linux 2.6.32) that all memory allocation requests
get stuck due to kswapd v.s. shrink_inactive_list() livelock which occurs under
almost OOM situation ( http://lkml.kernel.org/r/20160211225929.GU14668@dastard 
).
If we hit it, even "page allocation stalls for " messages do not show up.

Even if we didn't hit it, although agetty and sshd were still alive

  2016-12-17 21:39:27 192.168.17.23:6665 [ 1426.800614] [ 2800] 0  2800 
1152  494   6   30 0 agetty
  2016-12-17 21:39:27 192.168.17.23:6665 [ 1426.800618] [ 2802] 0  2802 
1457 1055   6   30 -1000 sshd

memory allocation was delaying too much

  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034624] btrfs-transacti: page 
alloction stalls for 93995ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL)
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034628] CPU: 1 PID: 1949 Comm: 
btrfs-transacti Not tainted 4.9.0-gentoo #3
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034630] Hardware name: 
Hewlett-Packard Compaq 15 Notebook PC/21F7, BIOS F.22 08/06/2014
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034638]  f162f94c c142bd8e 
0001  f162f970 c110ad7e c1b58833 02400840
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034645]  f162f978 f162f980 
c1b55814 f162f960 0160 f162fa38 c110b78c 02400840
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034652]  c1b55814 00016f2b 
 0040  f21d f21d 0001
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034653] Call Trace:
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034660]  [] 
dump_stack+0x47/0x69
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034666]  [] 
warn_alloc+0xce/0xf0
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034671]  [] 
__alloc_pages_nodemask+0x97c/0xd30
  2016-12-17 21:41:03 192.168.17.23:6665 [ 1521.034678]  

Re: [git pull] vfs.git pile 2

2016-12-17 Thread Al Viro
On Sat, Dec 17, 2016 at 07:34:45PM -0800, Linus Torvalds wrote:
> > What else am I missing there?
> 
> I absolutely *abhor* this part:
> 
> *len = isize - pos_in;
> 
> because the whole code then depends on the overflow checking a few
> lines down, and it's not at all obvious. We have not tested that
> "pos_in" is smaller than "isize", even though the comment above the
> "isize == 0" test inplies we did some kind of "past the end check" (we
> did not).
> 
> The whole "depend on overflow checking" being nasty is particularly
> true when that checking itself is damn subtle, and depends deeply on
> the type of "*len" being unsigned and larger than "loff_t". Which in
> turn is true, but it's all really nasty, and it's subtle. "loff_t" is
> "long long", while "*len" is u64, and it's almost just luck that the
> comparison does in fact end up unsigned.

I agree, but that one is a straight move - exact same thing is there in
xfs_reflink.c counterpart in the current mainline.

> So I think that code really needs a fair amount of loving.

Indeed.  Darrick, would you add a followup cleaning that up?  It can be
done after the move to fs/read_write.c - no need to reorder/rebase that
thing.  While we are at it, it might be better to turn the return value
into -E.../0/1, 0 being "no error, but nothing to do" and 1 - the normal
success case.  That would get rid of using *len = 0 as signalling mechanism -
the caller would simply do
ret = vfs_..._inodes(.);
if (ret <= 0)
goto out_unlock;
/* returned positive, we have work to do */


Re: [git pull] vfs.git pile 2

2016-12-17 Thread Al Viro
On Sat, Dec 17, 2016 at 07:34:45PM -0800, Linus Torvalds wrote:
> > What else am I missing there?
> 
> I absolutely *abhor* this part:
> 
> *len = isize - pos_in;
> 
> because the whole code then depends on the overflow checking a few
> lines down, and it's not at all obvious. We have not tested that
> "pos_in" is smaller than "isize", even though the comment above the
> "isize == 0" test inplies we did some kind of "past the end check" (we
> did not).
> 
> The whole "depend on overflow checking" being nasty is particularly
> true when that checking itself is damn subtle, and depends deeply on
> the type of "*len" being unsigned and larger than "loff_t". Which in
> turn is true, but it's all really nasty, and it's subtle. "loff_t" is
> "long long", while "*len" is u64, and it's almost just luck that the
> comparison does in fact end up unsigned.

I agree, but that one is a straight move - exact same thing is there in
xfs_reflink.c counterpart in the current mainline.

> So I think that code really needs a fair amount of loving.

Indeed.  Darrick, would you add a followup cleaning that up?  It can be
done after the move to fs/read_write.c - no need to reorder/rebase that
thing.  While we are at it, it might be better to turn the return value
into -E.../0/1, 0 being "no error, but nothing to do" and 1 - the normal
success case.  That would get rid of using *len = 0 as signalling mechanism -
the caller would simply do
ret = vfs_..._inodes(.);
if (ret <= 0)
goto out_unlock;
/* returned positive, we have work to do */


Re: [PATCH 5/5] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation

2016-12-17 Thread Milo Kim

Hi Luis,

On 12/17/2016 01:14 AM, Luis R. Rodriguez wrote:

Milo if sysfs is used can't the old userspace be mapped to use the new
sysfs interface through a wrapper of some sort ? What exactly would be
needed to ensure old userspace will not break?


LP5521 and LP5523 have two ways to load hex code from the userspace - 
the sysfs and firmware I/F. So user program supports both interfaces. 
Even if the firmware I/F is not available, user can still run LED effect 
through the sysfs.


However, LP5562 and LP8501 support only single way which is the firmware 
I/F. So user-space program for LP5562/8501 should be modified if lp55xx 
removes the interface. My idea is


  Phase 1)
  - create sysfs in LP5562 and LP8501
  - use new sysfs inside the firmware I/F loading callback
  - mark the firmware callback as a deprecated interface

  Phase 2)
  - remove the firmware I/F after all user program fixes the interface
(but the problem is how can we get to know when this is done?)

> Why has no one cried
> after the v4.0 custom fallback mechanism breaking ?

Well, I don't know the reason exactly but my guess is they maybe still 
using old kernel.


> How wide spread is this custom userspace ?

Device manufactures in Asia & North America requested lp55xx drivers, 
but I don't know how many vendors uses the firmware I/F. Some vendors 
embeds the binary code inside the driver instead of using user-program.


I understood it's a kind of troublesome work in terms of the 
maintenance. Sorry for that. I hope we have a consensus to resolve it.

Thanks!

Best regards,
Milo


Re: [PATCH 5/5] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation

2016-12-17 Thread Milo Kim

Hi Luis,

On 12/17/2016 01:14 AM, Luis R. Rodriguez wrote:

Milo if sysfs is used can't the old userspace be mapped to use the new
sysfs interface through a wrapper of some sort ? What exactly would be
needed to ensure old userspace will not break?


LP5521 and LP5523 have two ways to load hex code from the userspace - 
the sysfs and firmware I/F. So user program supports both interfaces. 
Even if the firmware I/F is not available, user can still run LED effect 
through the sysfs.


However, LP5562 and LP8501 support only single way which is the firmware 
I/F. So user-space program for LP5562/8501 should be modified if lp55xx 
removes the interface. My idea is


  Phase 1)
  - create sysfs in LP5562 and LP8501
  - use new sysfs inside the firmware I/F loading callback
  - mark the firmware callback as a deprecated interface

  Phase 2)
  - remove the firmware I/F after all user program fixes the interface
(but the problem is how can we get to know when this is done?)

> Why has no one cried
> after the v4.0 custom fallback mechanism breaking ?

Well, I don't know the reason exactly but my guess is they maybe still 
using old kernel.


> How wide spread is this custom userspace ?

Device manufactures in Asia & North America requested lp55xx drivers, 
but I don't know how many vendors uses the firmware I/F. Some vendors 
embeds the binary code inside the driver instead of using user-program.


I understood it's a kind of troublesome work in terms of the 
maintenance. Sorry for that. I hope we have a consensus to resolve it.

Thanks!

Best regards,
Milo


STRICTLY CONFIDENTIAL

2016-12-17 Thread Acct. Dept.
I have important transaction for you as next of kin to claim US$18.37m  Mail me 
on my private email:   chimwia...@gmail.com
 so I can send you more details

Thanks

Mr.Chim Wai Kim










MOVE TO INBOX===

DISCLAIMER: This email and any files it contains are confidential and intended 
for the use of the recipient(s) only. If you are not the intended recipient you 
should notify the sender immediately and destroy the material from your system. 





STRICTLY CONFIDENTIAL

2016-12-17 Thread Acct. Dept.
I have important transaction for you as next of kin to claim US$18.37m  Mail me 
on my private email:   chimwia...@gmail.com
 so I can send you more details

Thanks

Mr.Chim Wai Kim










MOVE TO INBOX===

DISCLAIMER: This email and any files it contains are confidential and intended 
for the use of the recipient(s) only. If you are not the intended recipient you 
should notify the sender immediately and destroy the material from your system. 





Re: [git pull] vfs.git pile 2

2016-12-17 Thread Linus Torvalds
On Sat, Dec 17, 2016 at 7:26 PM, Al Viro  wrote:
>
> One, AFAICS - pointless *len = 0 in case of is_dedupe.

Yup.

That part made sense in the original code where len and ret were
different. Now it just looks like a five-year old has been eating
crayons and paste.

> What else am I missing there?

I absolutely *abhor* this part:

*len = isize - pos_in;

because the whole code then depends on the overflow checking a few
lines down, and it's not at all obvious. We have not tested that
"pos_in" is smaller than "isize", even though the comment above the
"isize == 0" test inplies we did some kind of "past the end check" (we
did not).

The whole "depend on overflow checking" being nasty is particularly
true when that checking itself is damn subtle, and depends deeply on
the type of "*len" being unsigned and larger than "loff_t". Which in
turn is true, but it's all really nasty, and it's subtle. "loff_t" is
"long long", while "*len" is u64, and it's almost just luck that the
comparison does in fact end up unsigned.

So I think that code really needs a fair amount of loving.

  Linus


Re: [git pull] vfs.git pile 2

2016-12-17 Thread Linus Torvalds
On Sat, Dec 17, 2016 at 7:26 PM, Al Viro  wrote:
>
> One, AFAICS - pointless *len = 0 in case of is_dedupe.

Yup.

That part made sense in the original code where len and ret were
different. Now it just looks like a five-year old has been eating
crayons and paste.

> What else am I missing there?

I absolutely *abhor* this part:

*len = isize - pos_in;

because the whole code then depends on the overflow checking a few
lines down, and it's not at all obvious. We have not tested that
"pos_in" is smaller than "isize", even though the comment above the
"isize == 0" test inplies we did some kind of "past the end check" (we
did not).

The whole "depend on overflow checking" being nasty is particularly
true when that checking itself is damn subtle, and depends deeply on
the type of "*len" being unsigned and larger than "loff_t". Which in
turn is true, but it's all really nasty, and it's subtle. "loff_t" is
"long long", while "*len" is u64, and it's almost just luck that the
comparison does in fact end up unsigned.

So I think that code really needs a fair amount of loving.

  Linus


Re: [git pull] vfs.git pile 2

2016-12-17 Thread Al Viro
[Darrick Cc'd]
On Sat, Dec 17, 2016 at 06:49:55PM -0800, Linus Torvalds wrote:
> On Fri, Dec 16, 2016 at 2:12 PM, Al Viro  wrote:
> > In this pile:
> > * autofs-namespace series
> > * dedupe stuff
> > * more struct path constification
> 
> When looking at the conflict, I looked at that part of
> vfs_clone_file_prep_inodes(), and reacted to the insanity.
> 
> WTF?
> 
> /* Zero length dedupe exits immediately; reflink goes to EOF. */
> if (*len == 0) {
> if (is_dedupe) {
> *len = 0;
> return 0;
> }
> *len = isize - pos_in;
> }
> 
> I'll just leave you to read through that part a bit more. Because
> there are two completely insane things going on in that code sequence.

One, AFAICS - pointless *len = 0 in case of is_dedupe.  That's a counterpart of
/* Zero length dedupe exits immediately; reflink goes to EOF. */
if (len == 0) {
if (is_dedupe) {
ret = 0;
goto out_unlock;
}
len = isize - pos_in;
}
in mainline xfs_reflink_remap_range().  What else am I missing there?
I'm not thrilled with the calling conventions they'd used, and that
*len = 0; shouldn't have been slapped there (at a guess, by inertia from
the conversion of the chunk right before that one -
/* Are we going all the way to the end? */
isize = i_size_read(inode_in);
if (isize == 0) {
ret = 0;
goto out_unlock;
}
in mainline, needing *len = 0; after conversion), but I don't see what else
are you refering to in that snippet...


Re: [GIT PULL (resend)] readlink cleanup

2016-12-17 Thread Linus Torvalds
On Sat, Dec 17, 2016 at 7:21 PM, Linus Torvalds
 wrote:
>
> I pulled the non-controversial part of this branch, and made myself a
> batch of popcorn for the rest of the discussion,

Side note: I was pretty close to just pulling it all.

Because  do think the rest of the patch series looks quite reasonable,
but I'll wait for Al to comment more.

   Linus


Re: [git pull] vfs.git pile 2

2016-12-17 Thread Al Viro
[Darrick Cc'd]
On Sat, Dec 17, 2016 at 06:49:55PM -0800, Linus Torvalds wrote:
> On Fri, Dec 16, 2016 at 2:12 PM, Al Viro  wrote:
> > In this pile:
> > * autofs-namespace series
> > * dedupe stuff
> > * more struct path constification
> 
> When looking at the conflict, I looked at that part of
> vfs_clone_file_prep_inodes(), and reacted to the insanity.
> 
> WTF?
> 
> /* Zero length dedupe exits immediately; reflink goes to EOF. */
> if (*len == 0) {
> if (is_dedupe) {
> *len = 0;
> return 0;
> }
> *len = isize - pos_in;
> }
> 
> I'll just leave you to read through that part a bit more. Because
> there are two completely insane things going on in that code sequence.

One, AFAICS - pointless *len = 0 in case of is_dedupe.  That's a counterpart of
/* Zero length dedupe exits immediately; reflink goes to EOF. */
if (len == 0) {
if (is_dedupe) {
ret = 0;
goto out_unlock;
}
len = isize - pos_in;
}
in mainline xfs_reflink_remap_range().  What else am I missing there?
I'm not thrilled with the calling conventions they'd used, and that
*len = 0; shouldn't have been slapped there (at a guess, by inertia from
the conversion of the chunk right before that one -
/* Are we going all the way to the end? */
isize = i_size_read(inode_in);
if (isize == 0) {
ret = 0;
goto out_unlock;
}
in mainline, needing *len = 0; after conversion), but I don't see what else
are you refering to in that snippet...


Re: [GIT PULL (resend)] readlink cleanup

2016-12-17 Thread Linus Torvalds
On Sat, Dec 17, 2016 at 7:21 PM, Linus Torvalds
 wrote:
>
> I pulled the non-controversial part of this branch, and made myself a
> batch of popcorn for the rest of the discussion,

Side note: I was pretty close to just pulling it all.

Because  do think the rest of the patch series looks quite reasonable,
but I'll wait for Al to comment more.

   Linus


Re: [GIT PULL (resend)] readlink cleanup

2016-12-17 Thread Linus Torvalds
On Fri, Dec 16, 2016 at 2:48 PM, Miklos Szeredi  wrote:
>
> Please consider pulling the following cleanup:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git readlink

I pulled the non-controversial part of this branch, and made myself a
batch of popcorn for the rest of the discussion,

   Linus


Re: [GIT PULL (resend)] readlink cleanup

2016-12-17 Thread Linus Torvalds
On Fri, Dec 16, 2016 at 2:48 PM, Miklos Szeredi  wrote:
>
> Please consider pulling the following cleanup:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git readlink

I pulled the non-controversial part of this branch, and made myself a
batch of popcorn for the rest of the discussion,

   Linus


Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

2016-12-17 Thread David Miller
From: Mike Kravetz 
Date: Fri, 16 Dec 2016 10:35:27 -0800

> In current code, only context ID register 0 is set and used by the MMU.
> On sun4v platforms that support MMU shared context, there is an additional
> context ID register: specifically context register 1.  When searching
> the TLB, the MMU will find a match if the virtual address matches and
> the ID contained in context register 0 -OR- context register 1 matches.
> 
> Load the shared context ID into context ID register 1.  Care must be
> taken to load register 1 after register 0, as loading register 0
> overwrites both register 0 and 1.  Modify code loading register 0 to
> also load register one if applicable.
> 
> Signed-off-by: Mike Kravetz 

You can't make these register accesses if the feature isn't being
used.

Considering the percentage of applications which will actually use
this thing, incuring the overhead of even loading the shared context
register is simply unacceptable.


Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

2016-12-17 Thread David Miller
From: Mike Kravetz 
Date: Fri, 16 Dec 2016 10:35:27 -0800

> In current code, only context ID register 0 is set and used by the MMU.
> On sun4v platforms that support MMU shared context, there is an additional
> context ID register: specifically context register 1.  When searching
> the TLB, the MMU will find a match if the virtual address matches and
> the ID contained in context register 0 -OR- context register 1 matches.
> 
> Load the shared context ID into context ID register 1.  Care must be
> taken to load register 1 after register 0, as loading register 0
> overwrites both register 0 and 1.  Modify code loading register 0 to
> also load register one if applicable.
> 
> Signed-off-by: Mike Kravetz 

You can't make these register accesses if the feature isn't being
used.

Considering the percentage of applications which will actually use
this thing, incuring the overhead of even loading the shared context
register is simply unacceptable.


Re: [RFC PATCH 05/14] sparc64: Add PAGE_SHR_CTX flag

2016-12-17 Thread David Miller
From: Mike Kravetz 
Date: Fri, 16 Dec 2016 10:35:28 -0800

> @@ -166,6 +166,7 @@ bool kern_addr_valid(unsigned long addr);
>  #define _PAGE_EXEC_4V  _AC(0x0080,UL) /* Executable Page 
>  */
>  #define _PAGE_W_4V _AC(0x0040,UL) /* Writable */
>  #define _PAGE_SOFT_4V  _AC(0x0030,UL) /* Software bits   
>  */
> +#define _PAGE_SHR_CTX_4V  _AC(0x0020,UL) /* Shared Context   
> */
>  #define _PAGE_PRESENT_4V  _AC(0x0010,UL) /* Present  
> */
>  #define _PAGE_RESV_4V  _AC(0x0008,UL) /* Reserved
>  */
>  #define _PAGE_SZ16GB_4V_AC(0x0007,UL) /* 16GB Page   
>  */

You really don't need this.

The VMA is available, and you can obtain the information you need
about whether this is a shared mapping or not from the. It just isn't
being passed down into things like set_huge_pte_at().  Simply make it
do so.


Re: [RFC PATCH 05/14] sparc64: Add PAGE_SHR_CTX flag

2016-12-17 Thread David Miller
From: Mike Kravetz 
Date: Fri, 16 Dec 2016 10:35:28 -0800

> @@ -166,6 +166,7 @@ bool kern_addr_valid(unsigned long addr);
>  #define _PAGE_EXEC_4V  _AC(0x0080,UL) /* Executable Page 
>  */
>  #define _PAGE_W_4V _AC(0x0040,UL) /* Writable */
>  #define _PAGE_SOFT_4V  _AC(0x0030,UL) /* Software bits   
>  */
> +#define _PAGE_SHR_CTX_4V  _AC(0x0020,UL) /* Shared Context   
> */
>  #define _PAGE_PRESENT_4V  _AC(0x0010,UL) /* Present  
> */
>  #define _PAGE_RESV_4V  _AC(0x0008,UL) /* Reserved
>  */
>  #define _PAGE_SZ16GB_4V_AC(0x0007,UL) /* 16GB Page   
>  */

You really don't need this.

The VMA is available, and you can obtain the information you need
about whether this is a shared mapping or not from the. It just isn't
being passed down into things like set_huge_pte_at().  Simply make it
do so.


Re: [RFC PATCH 03/14] sparc64: routines for basic mmu shared context structure management

2016-12-17 Thread David Miller
From: Mike Kravetz 
Date: Fri, 16 Dec 2016 10:35:26 -0800

> +void smp_flush_shared_tlb_mm(struct mm_struct *mm)
> +{
> + u32 ctx = SHARED_CTX_HWBITS(mm->context);
> +
> + (void)get_cpu();/* prevent preemption */

preempt_disable();

> +
> + smp_cross_call(_flush_tlb_mm, ctx, 0, 0);
> + __flush_tlb_mm(ctx, SECONDARY_CONTEXT);
> +
> + put_cpu();

preempt_enable();


Re: [RFC PATCH 03/14] sparc64: routines for basic mmu shared context structure management

2016-12-17 Thread David Miller
From: Mike Kravetz 
Date: Fri, 16 Dec 2016 10:35:26 -0800

> +void smp_flush_shared_tlb_mm(struct mm_struct *mm)
> +{
> + u32 ctx = SHARED_CTX_HWBITS(mm->context);
> +
> + (void)get_cpu();/* prevent preemption */

preempt_disable();

> +
> + smp_cross_call(_flush_tlb_mm, ctx, 0, 0);
> + __flush_tlb_mm(ctx, SECONDARY_CONTEXT);
> +
> + put_cpu();

preempt_enable();


Re: [PATCH v2 0/8] power: supply: tps65217: Support USB charger feature

2016-12-17 Thread Milo Kim

On 12/18/2016 01:24 AM, Sebastian Reichel wrote:

patches look fine, but these two patches must be reordered to fix
bisectability. Otherwise after patch 1 the thread is not properly
killed during driver removal.


Thanks for your guidelines. The v3 patchset has been sent.

Best regards,
Milo


Re: [PATCH v2 0/8] power: supply: tps65217: Support USB charger feature

2016-12-17 Thread Milo Kim

On 12/18/2016 01:24 AM, Sebastian Reichel wrote:

patches look fine, but these two patches must be reordered to fix
bisectability. Otherwise after patch 1 the thread is not properly
killed during driver removal.


Thanks for your guidelines. The v3 patchset has been sent.

Best regards,
Milo


[PATCH v3 1/7] power: supply: tps65217: Use 'poll_task' on unloading the module

2016-12-17 Thread Milo Kim
Use the task_struct variable for running polling thread. If polling task
is activated, then use it to stop running thread.
This is a preceding step of supporting two interrupts of TPS65217 charger,
so checking single IRQ number is not appropriate when the module is removed.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 9fd019f9b88c..4fe71abe1bd3 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -200,6 +200,7 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
struct tps65217_charger *charger;
struct power_supply_config cfg = {};
+   struct task_struct *poll_task;
int irq;
int ret;
 
@@ -250,14 +251,16 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
/* Check current state */
tps65217_charger_irq(irq, charger);
} else {
-   charger->poll_task = kthread_run(tps65217_charger_poll_task,
-   charger, "ktps65217charger");
-   if (IS_ERR(charger->poll_task)) {
-   ret = PTR_ERR(charger->poll_task);
+   poll_task = kthread_run(tps65217_charger_poll_task,
+   charger, "ktps65217charger");
+   if (IS_ERR(poll_task)) {
+   ret = PTR_ERR(poll_task);
dev_err(charger->dev,
"Unable to run kthread err %d\n", ret);
return ret;
}
+
+   charger->poll_task = poll_task;
}
 
return 0;
@@ -267,7 +270,7 @@ static int tps65217_charger_remove(struct platform_device 
*pdev)
 {
struct tps65217_charger *charger = platform_get_drvdata(pdev);
 
-   if (charger->irq == -ENXIO)
+   if (charger->poll_task)
kthread_stop(charger->poll_task);
 
return 0;
-- 
2.11.0



[PATCH v3 5/7] power: supply: tps65217: Use generic name for power supply property

2016-12-17 Thread Milo Kim
Replace 'ac_props' with 'charger_props'.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 5daf36192b8c..79afecafd945 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -50,7 +50,7 @@ struct tps65217_charger {
struct task_struct  *poll_task;
 };
 
-static enum power_supply_property tps65217_ac_props[] = {
+static enum power_supply_property tps65217_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
 };
 
@@ -191,8 +191,8 @@ static const struct power_supply_desc tps65217_charger_desc 
= {
.name   = "tps65217-ac",
.type   = POWER_SUPPLY_TYPE_MAINS,
.get_property   = tps65217_ac_get_property,
-   .properties = tps65217_ac_props,
-   .num_properties = ARRAY_SIZE(tps65217_ac_props),
+   .properties = tps65217_charger_props,
+   .num_properties = ARRAY_SIZE(tps65217_charger_props),
 };
 
 static int tps65217_charger_probe(struct platform_device *pdev)
-- 
2.11.0



[PATCH v3 1/7] power: supply: tps65217: Use 'poll_task' on unloading the module

2016-12-17 Thread Milo Kim
Use the task_struct variable for running polling thread. If polling task
is activated, then use it to stop running thread.
This is a preceding step of supporting two interrupts of TPS65217 charger,
so checking single IRQ number is not appropriate when the module is removed.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 9fd019f9b88c..4fe71abe1bd3 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -200,6 +200,7 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent);
struct tps65217_charger *charger;
struct power_supply_config cfg = {};
+   struct task_struct *poll_task;
int irq;
int ret;
 
@@ -250,14 +251,16 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
/* Check current state */
tps65217_charger_irq(irq, charger);
} else {
-   charger->poll_task = kthread_run(tps65217_charger_poll_task,
-   charger, "ktps65217charger");
-   if (IS_ERR(charger->poll_task)) {
-   ret = PTR_ERR(charger->poll_task);
+   poll_task = kthread_run(tps65217_charger_poll_task,
+   charger, "ktps65217charger");
+   if (IS_ERR(poll_task)) {
+   ret = PTR_ERR(poll_task);
dev_err(charger->dev,
"Unable to run kthread err %d\n", ret);
return ret;
}
+
+   charger->poll_task = poll_task;
}
 
return 0;
@@ -267,7 +270,7 @@ static int tps65217_charger_remove(struct platform_device 
*pdev)
 {
struct tps65217_charger *charger = platform_get_drvdata(pdev);
 
-   if (charger->irq == -ENXIO)
+   if (charger->poll_task)
kthread_stop(charger->poll_task);
 
return 0;
-- 
2.11.0



[PATCH v3 5/7] power: supply: tps65217: Use generic name for power supply property

2016-12-17 Thread Milo Kim
Replace 'ac_props' with 'charger_props'.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 5daf36192b8c..79afecafd945 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -50,7 +50,7 @@ struct tps65217_charger {
struct task_struct  *poll_task;
 };
 
-static enum power_supply_property tps65217_ac_props[] = {
+static enum power_supply_property tps65217_charger_props[] = {
POWER_SUPPLY_PROP_ONLINE,
 };
 
@@ -191,8 +191,8 @@ static const struct power_supply_desc tps65217_charger_desc 
= {
.name   = "tps65217-ac",
.type   = POWER_SUPPLY_TYPE_MAINS,
.get_property   = tps65217_ac_get_property,
-   .properties = tps65217_ac_props,
-   .num_properties = ARRAY_SIZE(tps65217_ac_props),
+   .properties = tps65217_charger_props,
+   .num_properties = ARRAY_SIZE(tps65217_charger_props),
 };
 
 static int tps65217_charger_probe(struct platform_device *pdev)
-- 
2.11.0



[GIT] Networking

2016-12-17 Thread David Miller

1) Revert bogus nla_ok() change, from Alexey Dobriyan.

2) Various bpf validator fixes from Daniel Borkmann.

3) Add some necessary SET_NETDEV_DEV() calls to hsis_femac and hip04
   drivers, from Dongpo Li.

4) Several ethtool ksettings conversions from Philippe Reynes.

5) Fix bugs in inet port management wrt. soreuseport, from Tom
   Herbert.

6) XDP support for virtio_net, from John Fastabend.

7) Fix NAT handling within a vrf, from David Ahern.

8) Endianness fixes in dpaa_eth driver, from Claudiu Manoil.

Please pull, thanks a lot!

The following changes since commit 8fa3b6f9392bf6d90cb7b908e07bd90166639f0a:

  Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris (2016-12-12 09:06:38 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 3e3397e7b11ce1b9526975ddfbe8dd569fc1f316:

  net: mv643xx_eth: fix build failure (2016-12-17 21:47:26 -0500)


Alexey Dobriyan (1):
  netlink: revert broken, broken "2-clause nla_ok()"

Andrew Lunn (1):
  net: dsa: mv88e6xxx: Fix opps when adding vlan bridge

Andy Lutomirski (1):
  cgroup: Fix CGROUP_BPF config

Arnd Bergmann (1):
  qed: fix old-style function definition

Bartosz Folta (1):
  net: macb: Added PCI wrapper for Platform Driver.

Ben Greear (1):
  mac80211: fix legacy and invalid rx-rate report

Cedric Izoard (1):
  mac80211: Ensure enough headroom when forwarding mesh pkt

Claudiu Manoil (1):
  dpaa_eth: use big endian accessors

Dan Carpenter (1):
  irda: w83977af_ir: cleanup an indent issue

Daniel Borkmann (5):
  bpf: fix regression on verifier pruning wrt map lookups
  bpf, test_verifier: fix a test case error result on unprivileged
  bpf: dynamically allocate digest scratch buffer
  bpf: fix overflow in prog accounting
  bpf: fix mark_reg_unknown_value for spilled regs on map value marking

Daniel Mack (1):
  bpf: cgroup: annotate pointers in struct cgroup_bpf with __rcu

David Ahern (2):
  net: vrf: Fix NAT within a VRF
  net: vrf: Drop conntrack data after pass through VRF device on Tx

David S. Miller (8):
  Merge branch 'hisilicon-netdev-dev'
  Merge branch 'cls_flower-mask'
  Merge branch 'inet_csk_get_port-and-soreusport-fixes'
  Merge branch 'dpaa_eth-fixes'
  Merge branch 'virtio_net-XDP'
  Merge branch 'gtp-fixes'
  Merge branch 'bpf-fixes'
  Merge tag 'mac80211-for-davem-2016-12-16' of 
git://git.kernel.org/.../jberg/mac80211

Dongpo Li (2):
  net: ethernet: hisi_femac: Call SET_NETDEV_DEV()
  net: ethernet: hip04: Call SET_NETDEV_DEV()

Emese Revfy (1):
  isdn: Constify some function parameters

Harald Welte (1):
  gtp: Fix initialization of Flags octet in GTPv1 header

Ido Schimmel (1):
  mlxsw: spectrum: Mark split ports as such

Jason Wang (1):
  virtio-net: correctly enable multiqueue

Jeroen De Wachter (2):
  encx24j600: bugfix - always move ERXTAIL to next packet in 
encx24j600_rx_packets
  encx24j600: Fix some checkstyle warnings

Johannes Berg (1):
  mac80211: don't call drv_set_default_unicast_key() for VLANs

John Fastabend (5):
  net: xdp: add invalid buffer warning
  virtio_net: Add XDP support
  virtio_net: add dedicated XDP transmit queues
  virtio_net: add XDP_TX support
  virtio_net: xdp, add slowpath case for non contiguous buffers

Kees Cook (7):
  isdn/gigaset: use designated initializers
  ATM: use designated initializers
  net: use designated initializers
  WAN: use designated initializers
  bna: use designated initializers
  isdn: use designated initializers
  net/x25: use designated initializers

LABBE Corentin (5):
  irda: irproc.c: Remove unneeded linux/miscdevice.h include
  irda: irnet: Move linux/miscdevice.h include
  irnet: ppp: move IRNET_MINOR to include/linux/miscdevice.h
  irda: irnet: Remove unused IRNET_MAJOR define
  irda: irnet: add member name to the miscdevice declaration

Lionel Gauthier (1):
  gtp: gtp_check_src_ms_ipv4() always return success

Madalin Bucur (2):
  dpaa_eth: remove redundant dependency on FSL_SOC
  MAINTAINERS: net: add entry for Freescale QorIQ DPAA Ethernet driver

Mantas M (1):
  net: ipv6: check route protocol when deleting routes

Manuel Bessler (1):
  r6040: move spinlock in r6040_close as SOFTIRQ-unsafe lock order detected

Paul Blakey (2):
  net/sched: cls_flower: Use mask for addr_type
  net/sched: cls_flower: Use masked key when calling HW offloads

Philippe Reynes (5):
  net: chelsio: cxgb2: use new api ethtool_{get|set}_link_ksettings
  net: chelsio: cxgb3: use new api ethtool_{get|set}_link_ksettings
  net: cirrus: ep93xx: use new api ethtool_{get|set}_link_ksettings
  net: davicom: dm9000: use new api ethtool_{get|set}_link_ksettings
   

[PATCH v3 7/7] power: supply: tps65217: Use generic charger name

2016-12-17 Thread Milo Kim
"tps65217-charger" is more appropriate name because the driver supports
not only AC but also USB charger.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 63c555601674..29b61e81b385 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -188,7 +188,7 @@ static int tps65217_charger_poll_task(void *data)
 }
 
 static const struct power_supply_desc tps65217_charger_desc = {
-   .name   = "tps65217-ac",
+   .name   = "tps65217-charger",
.type   = POWER_SUPPLY_TYPE_MAINS,
.get_property   = tps65217_charger_get_property,
.properties = tps65217_charger_props,
-- 
2.11.0



[PATCH v3 6/7] power: supply: tps65217: Use generic name for get_property()

2016-12-17 Thread Milo Kim
Rename it as tps65217_charger_get_property().

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 79afecafd945..63c555601674 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -115,9 +115,9 @@ static int tps65217_enable_charging(struct tps65217_charger 
*charger)
return 0;
 }
 
-static int tps65217_ac_get_property(struct power_supply *psy,
-   enum power_supply_property psp,
-   union power_supply_propval *val)
+static int tps65217_charger_get_property(struct power_supply *psy,
+enum power_supply_property psp,
+union power_supply_propval *val)
 {
struct tps65217_charger *charger = power_supply_get_drvdata(psy);
 
@@ -190,7 +190,7 @@ static int tps65217_charger_poll_task(void *data)
 static const struct power_supply_desc tps65217_charger_desc = {
.name   = "tps65217-ac",
.type   = POWER_SUPPLY_TYPE_MAINS,
-   .get_property   = tps65217_ac_get_property,
+   .get_property   = tps65217_charger_get_property,
.properties = tps65217_charger_props,
.num_properties = ARRAY_SIZE(tps65217_charger_props),
 };
-- 
2.11.0



[GIT] Networking

2016-12-17 Thread David Miller

1) Revert bogus nla_ok() change, from Alexey Dobriyan.

2) Various bpf validator fixes from Daniel Borkmann.

3) Add some necessary SET_NETDEV_DEV() calls to hsis_femac and hip04
   drivers, from Dongpo Li.

4) Several ethtool ksettings conversions from Philippe Reynes.

5) Fix bugs in inet port management wrt. soreuseport, from Tom
   Herbert.

6) XDP support for virtio_net, from John Fastabend.

7) Fix NAT handling within a vrf, from David Ahern.

8) Endianness fixes in dpaa_eth driver, from Claudiu Manoil.

Please pull, thanks a lot!

The following changes since commit 8fa3b6f9392bf6d90cb7b908e07bd90166639f0a:

  Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris (2016-12-12 09:06:38 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 3e3397e7b11ce1b9526975ddfbe8dd569fc1f316:

  net: mv643xx_eth: fix build failure (2016-12-17 21:47:26 -0500)


Alexey Dobriyan (1):
  netlink: revert broken, broken "2-clause nla_ok()"

Andrew Lunn (1):
  net: dsa: mv88e6xxx: Fix opps when adding vlan bridge

Andy Lutomirski (1):
  cgroup: Fix CGROUP_BPF config

Arnd Bergmann (1):
  qed: fix old-style function definition

Bartosz Folta (1):
  net: macb: Added PCI wrapper for Platform Driver.

Ben Greear (1):
  mac80211: fix legacy and invalid rx-rate report

Cedric Izoard (1):
  mac80211: Ensure enough headroom when forwarding mesh pkt

Claudiu Manoil (1):
  dpaa_eth: use big endian accessors

Dan Carpenter (1):
  irda: w83977af_ir: cleanup an indent issue

Daniel Borkmann (5):
  bpf: fix regression on verifier pruning wrt map lookups
  bpf, test_verifier: fix a test case error result on unprivileged
  bpf: dynamically allocate digest scratch buffer
  bpf: fix overflow in prog accounting
  bpf: fix mark_reg_unknown_value for spilled regs on map value marking

Daniel Mack (1):
  bpf: cgroup: annotate pointers in struct cgroup_bpf with __rcu

David Ahern (2):
  net: vrf: Fix NAT within a VRF
  net: vrf: Drop conntrack data after pass through VRF device on Tx

David S. Miller (8):
  Merge branch 'hisilicon-netdev-dev'
  Merge branch 'cls_flower-mask'
  Merge branch 'inet_csk_get_port-and-soreusport-fixes'
  Merge branch 'dpaa_eth-fixes'
  Merge branch 'virtio_net-XDP'
  Merge branch 'gtp-fixes'
  Merge branch 'bpf-fixes'
  Merge tag 'mac80211-for-davem-2016-12-16' of 
git://git.kernel.org/.../jberg/mac80211

Dongpo Li (2):
  net: ethernet: hisi_femac: Call SET_NETDEV_DEV()
  net: ethernet: hip04: Call SET_NETDEV_DEV()

Emese Revfy (1):
  isdn: Constify some function parameters

Harald Welte (1):
  gtp: Fix initialization of Flags octet in GTPv1 header

Ido Schimmel (1):
  mlxsw: spectrum: Mark split ports as such

Jason Wang (1):
  virtio-net: correctly enable multiqueue

Jeroen De Wachter (2):
  encx24j600: bugfix - always move ERXTAIL to next packet in 
encx24j600_rx_packets
  encx24j600: Fix some checkstyle warnings

Johannes Berg (1):
  mac80211: don't call drv_set_default_unicast_key() for VLANs

John Fastabend (5):
  net: xdp: add invalid buffer warning
  virtio_net: Add XDP support
  virtio_net: add dedicated XDP transmit queues
  virtio_net: add XDP_TX support
  virtio_net: xdp, add slowpath case for non contiguous buffers

Kees Cook (7):
  isdn/gigaset: use designated initializers
  ATM: use designated initializers
  net: use designated initializers
  WAN: use designated initializers
  bna: use designated initializers
  isdn: use designated initializers
  net/x25: use designated initializers

LABBE Corentin (5):
  irda: irproc.c: Remove unneeded linux/miscdevice.h include
  irda: irnet: Move linux/miscdevice.h include
  irnet: ppp: move IRNET_MINOR to include/linux/miscdevice.h
  irda: irnet: Remove unused IRNET_MAJOR define
  irda: irnet: add member name to the miscdevice declaration

Lionel Gauthier (1):
  gtp: gtp_check_src_ms_ipv4() always return success

Madalin Bucur (2):
  dpaa_eth: remove redundant dependency on FSL_SOC
  MAINTAINERS: net: add entry for Freescale QorIQ DPAA Ethernet driver

Mantas M (1):
  net: ipv6: check route protocol when deleting routes

Manuel Bessler (1):
  r6040: move spinlock in r6040_close as SOFTIRQ-unsafe lock order detected

Paul Blakey (2):
  net/sched: cls_flower: Use mask for addr_type
  net/sched: cls_flower: Use masked key when calling HW offloads

Philippe Reynes (5):
  net: chelsio: cxgb2: use new api ethtool_{get|set}_link_ksettings
  net: chelsio: cxgb3: use new api ethtool_{get|set}_link_ksettings
  net: cirrus: ep93xx: use new api ethtool_{get|set}_link_ksettings
  net: davicom: dm9000: use new api ethtool_{get|set}_link_ksettings
   

[PATCH v3 7/7] power: supply: tps65217: Use generic charger name

2016-12-17 Thread Milo Kim
"tps65217-charger" is more appropriate name because the driver supports
not only AC but also USB charger.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 63c555601674..29b61e81b385 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -188,7 +188,7 @@ static int tps65217_charger_poll_task(void *data)
 }
 
 static const struct power_supply_desc tps65217_charger_desc = {
-   .name   = "tps65217-ac",
+   .name   = "tps65217-charger",
.type   = POWER_SUPPLY_TYPE_MAINS,
.get_property   = tps65217_charger_get_property,
.properties = tps65217_charger_props,
-- 
2.11.0



[PATCH v3 6/7] power: supply: tps65217: Use generic name for get_property()

2016-12-17 Thread Milo Kim
Rename it as tps65217_charger_get_property().

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 79afecafd945..63c555601674 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -115,9 +115,9 @@ static int tps65217_enable_charging(struct tps65217_charger 
*charger)
return 0;
 }
 
-static int tps65217_ac_get_property(struct power_supply *psy,
-   enum power_supply_property psp,
-   union power_supply_propval *val)
+static int tps65217_charger_get_property(struct power_supply *psy,
+enum power_supply_property psp,
+union power_supply_propval *val)
 {
struct tps65217_charger *charger = power_supply_get_drvdata(psy);
 
@@ -190,7 +190,7 @@ static int tps65217_charger_poll_task(void *data)
 static const struct power_supply_desc tps65217_charger_desc = {
.name   = "tps65217-ac",
.type   = POWER_SUPPLY_TYPE_MAINS,
-   .get_property   = tps65217_ac_get_property,
+   .get_property   = tps65217_charger_get_property,
.properties = tps65217_charger_props,
.num_properties = ARRAY_SIZE(tps65217_charger_props),
 };
-- 
2.11.0



[PATCH v3 4/7] power: supply: tps65217: Use generic name for power supply structure

2016-12-17 Thread Milo Kim
Replace 'ac' of tps65217_charger structure with 'psy'.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 424a6d32bb6c..5daf36192b8c 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -42,7 +42,7 @@
 struct tps65217_charger {
struct tps65217 *tps;
struct device *dev;
-   struct power_supply *ac;
+   struct power_supply *psy;
 
int online;
int prev_online;
@@ -157,7 +157,7 @@ static irqreturn_t tps65217_charger_irq(int irq, void *dev)
}
 
if (charger->prev_online != charger->online)
-   power_supply_changed(charger->ac);
+   power_supply_changed(charger->psy);
 
ret = tps65217_reg_read(charger->tps, TPS65217_REG_CHGCONFIG0, );
if (ret < 0) {
@@ -218,12 +218,12 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
cfg.of_node = pdev->dev.of_node;
cfg.drv_data = charger;
 
-   charger->ac = devm_power_supply_register(>dev,
-_charger_desc,
-);
-   if (IS_ERR(charger->ac)) {
+   charger->psy = devm_power_supply_register(>dev,
+ _charger_desc,
+ );
+   if (IS_ERR(charger->psy)) {
dev_err(>dev, "failed: power supply register\n");
-   return PTR_ERR(charger->ac);
+   return PTR_ERR(charger->psy);
}
 
irq[0] = platform_get_irq_byname(pdev, "USB");
-- 
2.11.0



[PATCH v3 0/7] power: supply: tps65217: Support USB charger feature

2016-12-17 Thread Milo Kim
TPS65217 device supports two charger inputs - AC and USB.
Currently, only AC charger is supported. This patch-set adds USB charger 
feature. Tested on Beaglebone black.

Patch 1: Preceding step of the main patch
Patch 2: Main patch
Patch 3 ~ 7: Naming changes for generic power supply class structure

v3:
  Reorder the patches to avoid bisection issue

v2:
  Regenerate the patchset for better code review

Milo Kim (7):
  power: supply: tps65217: Use 'poll_task' on unloading the module
  power: supply: tps65217: Support USB charger interrupt
  power: supply: tps65217: Use generic name for charger online
  power: supply: tps65217: Use generic name for power supply structure
  power: supply: tps65217: Use generic name for power supply property
  power: supply: tps65217: Use generic name for get_property()
  power: supply: tps65217: Use generic charger name

 drivers/power/supply/tps65217_charger.c | 99 ++---
 1 file changed, 53 insertions(+), 46 deletions(-)

-- 
2.11.0



[PATCH v3 3/7] power: supply: tps65217: Use generic name for charger online

2016-12-17 Thread Milo Kim
This driver supports AC and USB chargers. Generic name is preferred.
Replace 'ac_online' with 'online'.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 482ee9f9edff..424a6d32bb6c 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -44,8 +44,8 @@ struct tps65217_charger {
struct device *dev;
struct power_supply *ac;
 
-   int ac_online;
-   int prev_ac_online;
+   int online;
+   int prev_online;
 
struct task_struct  *poll_task;
 };
@@ -95,7 +95,7 @@ static int tps65217_enable_charging(struct tps65217_charger 
*charger)
int ret;
 
/* charger already enabled */
-   if (charger->ac_online)
+   if (charger->online)
return 0;
 
dev_dbg(charger->dev, "%s: enable charging\n", __func__);
@@ -110,7 +110,7 @@ static int tps65217_enable_charging(struct tps65217_charger 
*charger)
return ret;
}
 
-   charger->ac_online = 1;
+   charger->online = 1;
 
return 0;
 }
@@ -122,7 +122,7 @@ static int tps65217_ac_get_property(struct power_supply 
*psy,
struct tps65217_charger *charger = power_supply_get_drvdata(psy);
 
if (psp == POWER_SUPPLY_PROP_ONLINE) {
-   val->intval = charger->ac_online;
+   val->intval = charger->online;
return 0;
}
return -EINVAL;
@@ -133,7 +133,7 @@ static irqreturn_t tps65217_charger_irq(int irq, void *dev)
int ret, val;
struct tps65217_charger *charger = dev;
 
-   charger->prev_ac_online = charger->ac_online;
+   charger->prev_online = charger->online;
 
ret = tps65217_reg_read(charger->tps, TPS65217_REG_STATUS, );
if (ret < 0) {
@@ -153,10 +153,10 @@ static irqreturn_t tps65217_charger_irq(int irq, void 
*dev)
return IRQ_HANDLED;
}
} else {
-   charger->ac_online = 0;
+   charger->online = 0;
}
 
-   if (charger->prev_ac_online != charger->ac_online)
+   if (charger->prev_online != charger->online)
power_supply_changed(charger->ac);
 
ret = tps65217_reg_read(charger->tps, TPS65217_REG_CHGCONFIG0, );
-- 
2.11.0



[PATCH v3 2/7] power: supply: tps65217: Support USB charger interrupt

2016-12-17 Thread Milo Kim
TPS65217 has two charger interrupts - AC and USB power status change.

Interrupt number in the TPS65217 driver data:
  IRQ number is only used on requesting the interrupt, so no need to keep
  it inside the driver data.

Interrupt handler:
  Check not only AC but also USB charger status.
  In both cases, enable charging operation.

Interrupt request:
  If an interrupt number is invalid, then use legacy polling thread.
  Otherwise, create IRQ threads to handle AC and USB charger event.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 52 ++---
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 4fe71abe1bd3..482ee9f9edff 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -35,6 +35,8 @@
 #include 
 #include 
 
+#define CHARGER_STATUS_PRESENT (TPS65217_STATUS_ACPWR | TPS65217_STATUS_USBPWR)
+#define NUM_CHARGER_IRQS   2
 #define POLL_INTERVAL  (HZ * 2)
 
 struct tps65217_charger {
@@ -46,8 +48,6 @@ struct tps65217_charger {
int prev_ac_online;
 
struct task_struct  *poll_task;
-
-   int irq;
 };
 
 static enum power_supply_property tps65217_ac_props[] = {
@@ -144,8 +144,8 @@ static irqreturn_t tps65217_charger_irq(int irq, void *dev)
 
dev_dbg(charger->dev, "%s: 0x%x\n", __func__, val);
 
-   /* check for AC status bit */
-   if (val & TPS65217_STATUS_ACPWR) {
+   /* check for charger status bit */
+   if (val & CHARGER_STATUS_PRESENT) {
ret = tps65217_enable_charging(charger);
if (ret) {
dev_err(charger->dev,
@@ -201,8 +201,9 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
struct tps65217_charger *charger;
struct power_supply_config cfg = {};
struct task_struct *poll_task;
-   int irq;
+   int irq[NUM_CHARGER_IRQS];
int ret;
+   int i;
 
dev_dbg(>dev, "%s\n", __func__);
 
@@ -225,10 +226,8 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
return PTR_ERR(charger->ac);
}
 
-   irq = platform_get_irq_byname(pdev, "AC");
-   if (irq < 0)
-   irq = -ENXIO;
-   charger->irq = irq;
+   irq[0] = platform_get_irq_byname(pdev, "USB");
+   irq[1] = platform_get_irq_byname(pdev, "AC");
 
ret = tps65217_config_charger(charger);
if (ret < 0) {
@@ -236,21 +235,8 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
return ret;
}
 
-   if (irq != -ENXIO) {
-   ret = devm_request_threaded_irq(>dev, irq, NULL,
-   tps65217_charger_irq,
-   0, "tps65217-charger",
-   charger);
-   if (ret) {
-   dev_err(charger->dev,
-   "Unable to register irq %d err %d\n", irq,
-   ret);
-   return ret;
-   }
-
-   /* Check current state */
-   tps65217_charger_irq(irq, charger);
-   } else {
+   /* Create a polling thread if an interrupt is invalid */
+   if (irq[0] < 0 || irq[1] < 0) {
poll_task = kthread_run(tps65217_charger_poll_task,
charger, "ktps65217charger");
if (IS_ERR(poll_task)) {
@@ -261,6 +247,24 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
}
 
charger->poll_task = poll_task;
+   return 0;
+   }
+
+   /* Create IRQ threads for charger interrupts */
+   for (i = 0; i < NUM_CHARGER_IRQS; i++) {
+   ret = devm_request_threaded_irq(>dev, irq[i], NULL,
+   tps65217_charger_irq,
+   0, "tps65217-charger",
+   charger);
+   if (ret) {
+   dev_err(charger->dev,
+   "Unable to register irq %d err %d\n", irq[i],
+   ret);
+   return ret;
+   }
+
+   /* Check current state */
+   tps65217_charger_irq(-1, charger);
}
 
return 0;
-- 
2.11.0



[PATCH v3 4/7] power: supply: tps65217: Use generic name for power supply structure

2016-12-17 Thread Milo Kim
Replace 'ac' of tps65217_charger structure with 'psy'.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 424a6d32bb6c..5daf36192b8c 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -42,7 +42,7 @@
 struct tps65217_charger {
struct tps65217 *tps;
struct device *dev;
-   struct power_supply *ac;
+   struct power_supply *psy;
 
int online;
int prev_online;
@@ -157,7 +157,7 @@ static irqreturn_t tps65217_charger_irq(int irq, void *dev)
}
 
if (charger->prev_online != charger->online)
-   power_supply_changed(charger->ac);
+   power_supply_changed(charger->psy);
 
ret = tps65217_reg_read(charger->tps, TPS65217_REG_CHGCONFIG0, );
if (ret < 0) {
@@ -218,12 +218,12 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
cfg.of_node = pdev->dev.of_node;
cfg.drv_data = charger;
 
-   charger->ac = devm_power_supply_register(>dev,
-_charger_desc,
-);
-   if (IS_ERR(charger->ac)) {
+   charger->psy = devm_power_supply_register(>dev,
+ _charger_desc,
+ );
+   if (IS_ERR(charger->psy)) {
dev_err(>dev, "failed: power supply register\n");
-   return PTR_ERR(charger->ac);
+   return PTR_ERR(charger->psy);
}
 
irq[0] = platform_get_irq_byname(pdev, "USB");
-- 
2.11.0



[PATCH v3 0/7] power: supply: tps65217: Support USB charger feature

2016-12-17 Thread Milo Kim
TPS65217 device supports two charger inputs - AC and USB.
Currently, only AC charger is supported. This patch-set adds USB charger 
feature. Tested on Beaglebone black.

Patch 1: Preceding step of the main patch
Patch 2: Main patch
Patch 3 ~ 7: Naming changes for generic power supply class structure

v3:
  Reorder the patches to avoid bisection issue

v2:
  Regenerate the patchset for better code review

Milo Kim (7):
  power: supply: tps65217: Use 'poll_task' on unloading the module
  power: supply: tps65217: Support USB charger interrupt
  power: supply: tps65217: Use generic name for charger online
  power: supply: tps65217: Use generic name for power supply structure
  power: supply: tps65217: Use generic name for power supply property
  power: supply: tps65217: Use generic name for get_property()
  power: supply: tps65217: Use generic charger name

 drivers/power/supply/tps65217_charger.c | 99 ++---
 1 file changed, 53 insertions(+), 46 deletions(-)

-- 
2.11.0



[PATCH v3 3/7] power: supply: tps65217: Use generic name for charger online

2016-12-17 Thread Milo Kim
This driver supports AC and USB chargers. Generic name is preferred.
Replace 'ac_online' with 'online'.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 482ee9f9edff..424a6d32bb6c 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -44,8 +44,8 @@ struct tps65217_charger {
struct device *dev;
struct power_supply *ac;
 
-   int ac_online;
-   int prev_ac_online;
+   int online;
+   int prev_online;
 
struct task_struct  *poll_task;
 };
@@ -95,7 +95,7 @@ static int tps65217_enable_charging(struct tps65217_charger 
*charger)
int ret;
 
/* charger already enabled */
-   if (charger->ac_online)
+   if (charger->online)
return 0;
 
dev_dbg(charger->dev, "%s: enable charging\n", __func__);
@@ -110,7 +110,7 @@ static int tps65217_enable_charging(struct tps65217_charger 
*charger)
return ret;
}
 
-   charger->ac_online = 1;
+   charger->online = 1;
 
return 0;
 }
@@ -122,7 +122,7 @@ static int tps65217_ac_get_property(struct power_supply 
*psy,
struct tps65217_charger *charger = power_supply_get_drvdata(psy);
 
if (psp == POWER_SUPPLY_PROP_ONLINE) {
-   val->intval = charger->ac_online;
+   val->intval = charger->online;
return 0;
}
return -EINVAL;
@@ -133,7 +133,7 @@ static irqreturn_t tps65217_charger_irq(int irq, void *dev)
int ret, val;
struct tps65217_charger *charger = dev;
 
-   charger->prev_ac_online = charger->ac_online;
+   charger->prev_online = charger->online;
 
ret = tps65217_reg_read(charger->tps, TPS65217_REG_STATUS, );
if (ret < 0) {
@@ -153,10 +153,10 @@ static irqreturn_t tps65217_charger_irq(int irq, void 
*dev)
return IRQ_HANDLED;
}
} else {
-   charger->ac_online = 0;
+   charger->online = 0;
}
 
-   if (charger->prev_ac_online != charger->ac_online)
+   if (charger->prev_online != charger->online)
power_supply_changed(charger->ac);
 
ret = tps65217_reg_read(charger->tps, TPS65217_REG_CHGCONFIG0, );
-- 
2.11.0



[PATCH v3 2/7] power: supply: tps65217: Support USB charger interrupt

2016-12-17 Thread Milo Kim
TPS65217 has two charger interrupts - AC and USB power status change.

Interrupt number in the TPS65217 driver data:
  IRQ number is only used on requesting the interrupt, so no need to keep
  it inside the driver data.

Interrupt handler:
  Check not only AC but also USB charger status.
  In both cases, enable charging operation.

Interrupt request:
  If an interrupt number is invalid, then use legacy polling thread.
  Otherwise, create IRQ threads to handle AC and USB charger event.

Signed-off-by: Milo Kim 
---
 drivers/power/supply/tps65217_charger.c | 52 ++---
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 4fe71abe1bd3..482ee9f9edff 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -35,6 +35,8 @@
 #include 
 #include 
 
+#define CHARGER_STATUS_PRESENT (TPS65217_STATUS_ACPWR | TPS65217_STATUS_USBPWR)
+#define NUM_CHARGER_IRQS   2
 #define POLL_INTERVAL  (HZ * 2)
 
 struct tps65217_charger {
@@ -46,8 +48,6 @@ struct tps65217_charger {
int prev_ac_online;
 
struct task_struct  *poll_task;
-
-   int irq;
 };
 
 static enum power_supply_property tps65217_ac_props[] = {
@@ -144,8 +144,8 @@ static irqreturn_t tps65217_charger_irq(int irq, void *dev)
 
dev_dbg(charger->dev, "%s: 0x%x\n", __func__, val);
 
-   /* check for AC status bit */
-   if (val & TPS65217_STATUS_ACPWR) {
+   /* check for charger status bit */
+   if (val & CHARGER_STATUS_PRESENT) {
ret = tps65217_enable_charging(charger);
if (ret) {
dev_err(charger->dev,
@@ -201,8 +201,9 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
struct tps65217_charger *charger;
struct power_supply_config cfg = {};
struct task_struct *poll_task;
-   int irq;
+   int irq[NUM_CHARGER_IRQS];
int ret;
+   int i;
 
dev_dbg(>dev, "%s\n", __func__);
 
@@ -225,10 +226,8 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
return PTR_ERR(charger->ac);
}
 
-   irq = platform_get_irq_byname(pdev, "AC");
-   if (irq < 0)
-   irq = -ENXIO;
-   charger->irq = irq;
+   irq[0] = platform_get_irq_byname(pdev, "USB");
+   irq[1] = platform_get_irq_byname(pdev, "AC");
 
ret = tps65217_config_charger(charger);
if (ret < 0) {
@@ -236,21 +235,8 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
return ret;
}
 
-   if (irq != -ENXIO) {
-   ret = devm_request_threaded_irq(>dev, irq, NULL,
-   tps65217_charger_irq,
-   0, "tps65217-charger",
-   charger);
-   if (ret) {
-   dev_err(charger->dev,
-   "Unable to register irq %d err %d\n", irq,
-   ret);
-   return ret;
-   }
-
-   /* Check current state */
-   tps65217_charger_irq(irq, charger);
-   } else {
+   /* Create a polling thread if an interrupt is invalid */
+   if (irq[0] < 0 || irq[1] < 0) {
poll_task = kthread_run(tps65217_charger_poll_task,
charger, "ktps65217charger");
if (IS_ERR(poll_task)) {
@@ -261,6 +247,24 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
}
 
charger->poll_task = poll_task;
+   return 0;
+   }
+
+   /* Create IRQ threads for charger interrupts */
+   for (i = 0; i < NUM_CHARGER_IRQS; i++) {
+   ret = devm_request_threaded_irq(>dev, irq[i], NULL,
+   tps65217_charger_irq,
+   0, "tps65217-charger",
+   charger);
+   if (ret) {
+   dev_err(charger->dev,
+   "Unable to register irq %d err %d\n", irq[i],
+   ret);
+   return ret;
+   }
+
+   /* Check current state */
+   tps65217_charger_irq(-1, charger);
}
 
return 0;
-- 
2.11.0



Re: [git pull] vfs.git pile 2

2016-12-17 Thread Linus Torvalds
On Fri, Dec 16, 2016 at 2:12 PM, Al Viro  wrote:
> In this pile:
> * autofs-namespace series
> * dedupe stuff
> * more struct path constification

When looking at the conflict, I looked at that part of
vfs_clone_file_prep_inodes(), and reacted to the insanity.

WTF?

/* Zero length dedupe exits immediately; reflink goes to EOF. */
if (*len == 0) {
if (is_dedupe) {
*len = 0;
return 0;
}
*len = isize - pos_in;
}

I'll just leave you to read through that part a bit more. Because
there are two completely insane things going on in that code sequence.

Linus


Re: [git pull] vfs.git pile 2

2016-12-17 Thread Linus Torvalds
On Fri, Dec 16, 2016 at 2:12 PM, Al Viro  wrote:
> In this pile:
> * autofs-namespace series
> * dedupe stuff
> * more struct path constification

When looking at the conflict, I looked at that part of
vfs_clone_file_prep_inodes(), and reacted to the insanity.

WTF?

/* Zero length dedupe exits immediately; reflink goes to EOF. */
if (*len == 0) {
if (is_dedupe) {
*len = 0;
return 0;
}
*len = isize - pos_in;
}

I'll just leave you to read through that part a bit more. Because
there are two completely insane things going on in that code sequence.

Linus


Re: [PATCH] net: mv643xx_eth: fix build failure

2016-12-17 Thread David Miller
From: Sudip Mukherjee 
Date: Sat, 17 Dec 2016 00:45:05 +

> The build of sparc allmodconfig fails with the error:
> "of_irq_to_resource" [drivers/net/ethernet/marvell/mv643xx_eth.ko]
>   undefined!
> 
> of_irq_to_resource() is defined when CONFIG_OF_IRQ is defined. And also
> CONFIG_OF_IRQ can only be defined if CONFIG_IRQ is defined. So we can
> safely use #if defined(CONFIG_OF_IRQ) in the code.
> 
> Signed-off-by: Sudip Mukherjee 

Applied, thanks.


Re: [PATCH] net: mv643xx_eth: fix build failure

2016-12-17 Thread David Miller
From: Sudip Mukherjee 
Date: Sat, 17 Dec 2016 00:45:05 +

> The build of sparc allmodconfig fails with the error:
> "of_irq_to_resource" [drivers/net/ethernet/marvell/mv643xx_eth.ko]
>   undefined!
> 
> of_irq_to_resource() is defined when CONFIG_OF_IRQ is defined. And also
> CONFIG_OF_IRQ can only be defined if CONFIG_IRQ is defined. So we can
> safely use #if defined(CONFIG_OF_IRQ) in the code.
> 
> Signed-off-by: Sudip Mukherjee 

Applied, thanks.


Re: [PATCH] isdn: Constify some function parameters

2016-12-17 Thread David Miller
From: Kees Cook 
Date: Fri, 16 Dec 2016 13:40:47 -0800

> From: Emese Revfy 
> 
> The coming initify gcc plugin expects const pointer types, and caught
> some __printf arguments that weren't const yet. This fixes those.
> 
> Signed-off-by: Emese Revfy 
> [kees: expanded commit message]
> Signed-off-by: Kees Cook 

Applied.


Re: [PATCH] isdn: Constify some function parameters

2016-12-17 Thread David Miller
From: Kees Cook 
Date: Fri, 16 Dec 2016 13:40:47 -0800

> From: Emese Revfy 
> 
> The coming initify gcc plugin expects const pointer types, and caught
> some __printf arguments that weren't const yet. This fixes those.
> 
> Signed-off-by: Emese Revfy 
> [kees: expanded commit message]
> Signed-off-by: Kees Cook 

Applied.


[PATCH] fix code alignment with open parenthesis in drivers/staging/fbtft/fb_agm1264k-fl.c

2016-12-17 Thread Scott Matheina
Signed-off-by: Scott Matheina 
---
 drivers/staging/fbtft/fb_agm1264k-fl.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index a6e3af7..4e371ed 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -186,8 +186,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)

va_end(args);
fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
-   par->info->device, u8, buf, len, "%s: ", __func__);
-   }
+ par->info->device, u8, buf, len,
+ "%s: ", __func__);
+}

va_start(args, len);

@@ -246,7 +247,7 @@ static void set_addr_win(struct fbtft_par *par, int xs, int 
ys, int xe, int ye)

 static void
 construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
-   int xs, int xe, int y)
+ int xs, int xe, int y)
 {
int x, i;

@@ -361,7 +362,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
/* left half of display */
if (addr_win.xs < par->info->var.xres / 2) {
construct_line_bitmap(par, buf, convert_buf,
-   addr_win.xs, par->info->var.xres / 2, y);
+ addr_win.xs,
+ par->info->var.xres / 2, y);

len = par->info->var.xres / 2 - addr_win.xs;

@@ -382,8 +384,9 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
/* right half of display */
if (addr_win.xe >= par->info->var.xres / 2) {
construct_line_bitmap(par, buf,
-   convert_buf, par->info->var.xres / 2,
-   addr_win.xe + 1, y);
+ convert_buf,
+ par->info->var.xres / 2,
+ addr_win.xe + 1, y);

len = addr_win.xe + 1 - par->info->var.xres / 2;

@@ -413,7 +416,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
 static int write(struct fbtft_par *par, void *buf, size_t len)
 {
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
-   "%s(len=%d): ", __func__, len);
+ "%s(len=%d): ", __func__, len);

gpio_set_value(par->RW, 0); /* set write mode */

--
2.7.4



[PATCH] fix code alignment with open parenthesis in drivers/staging/fbtft/fb_agm1264k-fl.c

2016-12-17 Thread Scott Matheina
Signed-off-by: Scott Matheina 
---
 drivers/staging/fbtft/fb_agm1264k-fl.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index a6e3af7..4e371ed 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -186,8 +186,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)

va_end(args);
fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
-   par->info->device, u8, buf, len, "%s: ", __func__);
-   }
+ par->info->device, u8, buf, len,
+ "%s: ", __func__);
+}

va_start(args, len);

@@ -246,7 +247,7 @@ static void set_addr_win(struct fbtft_par *par, int xs, int 
ys, int xe, int ye)

 static void
 construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
-   int xs, int xe, int y)
+ int xs, int xe, int y)
 {
int x, i;

@@ -361,7 +362,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
/* left half of display */
if (addr_win.xs < par->info->var.xres / 2) {
construct_line_bitmap(par, buf, convert_buf,
-   addr_win.xs, par->info->var.xres / 2, y);
+ addr_win.xs,
+ par->info->var.xres / 2, y);

len = par->info->var.xres / 2 - addr_win.xs;

@@ -382,8 +384,9 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
/* right half of display */
if (addr_win.xe >= par->info->var.xres / 2) {
construct_line_bitmap(par, buf,
-   convert_buf, par->info->var.xres / 2,
-   addr_win.xe + 1, y);
+ convert_buf,
+ par->info->var.xres / 2,
+ addr_win.xe + 1, y);

len = addr_win.xe + 1 - par->info->var.xres / 2;

@@ -413,7 +416,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
 static int write(struct fbtft_par *par, void *buf, size_t len)
 {
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
-   "%s(len=%d): ", __func__, len);
+ "%s(len=%d): ", __func__, len);

gpio_set_value(par->RW, 0); /* set write mode */

--
2.7.4



RE: [RFC 00/10] implement alternative and much simpler id allocator

2016-12-17 Thread Matthew Wilcox
From: Matthew Wilcox
> From: Matthew Wilcox
> > Heh, I was thinking about that too.  The radix tree supports "exceptional
> > entries" which have the bottom bit set.  On a 64-bit machine, we could use
> 62
> > of the bits in the radix tree root to store the ID bitmap.  I'm a little 
> > wary of
> the
> > potential complexity, but we should try it out.
> 
> Test patch here: http://git.infradead.org/users/willy/linux-
> dax.git/shortlog/refs/heads/idr-2016-12-16
> It passes the test suite ... which I actually had to adjust because it now 
> succeeds
> in cases where it hadn't (allocating ID 0 without preallocating), and it will 
> now
> fail in cases where it hadn't previously (assuming a single preallocation 
> would
> be enough).  There shouldn't be any examples of that in the kernel proper; it
> was simply me being lazy when I wrote the test suite.

Found a bug, committed a fix (and another test case).  It now no longer returns 
-EAGAIN in situations where it wouldn't have, so I've reverted that bit of the 
test suite change.  Still succeeds when it wouldn't have before, but I feel no 
pressure to change that ;-)


RE: [RFC 00/10] implement alternative and much simpler id allocator

2016-12-17 Thread Matthew Wilcox
From: Matthew Wilcox
> From: Matthew Wilcox
> > Heh, I was thinking about that too.  The radix tree supports "exceptional
> > entries" which have the bottom bit set.  On a 64-bit machine, we could use
> 62
> > of the bits in the radix tree root to store the ID bitmap.  I'm a little 
> > wary of
> the
> > potential complexity, but we should try it out.
> 
> Test patch here: http://git.infradead.org/users/willy/linux-
> dax.git/shortlog/refs/heads/idr-2016-12-16
> It passes the test suite ... which I actually had to adjust because it now 
> succeeds
> in cases where it hadn't (allocating ID 0 without preallocating), and it will 
> now
> fail in cases where it hadn't previously (assuming a single preallocation 
> would
> be enough).  There shouldn't be any examples of that in the kernel proper; it
> was simply me being lazy when I wrote the test suite.

Found a bug, committed a fix (and another test case).  It now no longer returns 
-EAGAIN in situations where it wouldn't have, so I've reverted that bit of the 
test suite change.  Still succeeds when it wouldn't have before, but I feel no 
pressure to change that ;-)


Re: [PATCH net] qed: fix old-style function definition

2016-12-17 Thread David Miller
From: Arnd Bergmann 
Date: Fri, 16 Dec 2016 09:47:41 +0100

> The newly added file causes a harmless warning, with "make W=1":
> 
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c: In function 'qed_get_iscsi_ops':
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c:1268:29: warning: old-style 
> function definition [-Wold-style-definition]
> 
> This makes it a proper prototype.
> 
> Fixes: fc831825f99e ("qed: Add support for hardware offloaded iSCSI.")
> Signed-off-by: Arnd Bergmann 

APplied.


Re: [PATCH net] qed: fix old-style function definition

2016-12-17 Thread David Miller
From: Arnd Bergmann 
Date: Fri, 16 Dec 2016 09:47:41 +0100

> The newly added file causes a harmless warning, with "make W=1":
> 
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c: In function 'qed_get_iscsi_ops':
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c:1268:29: warning: old-style 
> function definition [-Wold-style-definition]
> 
> This makes it a proper prototype.
> 
> Fixes: fc831825f99e ("qed: Add support for hardware offloaded iSCSI.")
> Signed-off-by: Arnd Bergmann 

APplied.


Re: [PATCH] net: ipv6: check route protocol when deleting routes

2016-12-17 Thread David Miller
From: Mantas Mikulėnas 
Date: Fri, 16 Dec 2016 10:30:59 +0200

> The protocol field is checked when deleting IPv4 routes, but ignored for
> IPv6, which causes problems with routing daemons accidentally deleting
> externally set routes (observed by multiple bird6 users).
> 
> This can be verified using `ip -6 route del  proto something`.
> 
> Signed-off-by: Mantas Mikulėnas 

Applied, thanks.


Re: [PATCH] net: ipv6: check route protocol when deleting routes

2016-12-17 Thread David Miller
From: Mantas Mikulėnas 
Date: Fri, 16 Dec 2016 10:30:59 +0200

> The protocol field is checked when deleting IPv4 routes, but ignored for
> IPv6, which causes problems with routing daemons accidentally deleting
> externally set routes (observed by multiple bird6 users).
> 
> This can be verified using `ip -6 route del  proto something`.
> 
> Signed-off-by: Mantas Mikulėnas 

Applied, thanks.


Re: [PATCH] net: sfc: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Thu, 15 Dec 2016 00:12:53 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH] net: sfc: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Thu, 15 Dec 2016 00:12:53 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH] net: chelsio: cxgb3: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Mon, 12 Dec 2016 00:27:49 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH] net: cirrus: ep93xx: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Mon, 12 Dec 2016 23:28:33 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH] net: chelsio: cxgb2: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Sun, 11 Dec 2016 22:47:50 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH] net: chelsio: cxgb2: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Sun, 11 Dec 2016 22:47:50 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH] net: chelsio: cxgb3: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Mon, 12 Dec 2016 00:27:49 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH] net: cirrus: ep93xx: use new api ethtool_{get|set}_link_ksettings

2016-12-17 Thread David Miller
From: Philippe Reynes 
Date: Mon, 12 Dec 2016 23:28:33 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


[PATCH] ALSA: snd-usb: fix IRQ triggered NULL pointer dereference

2016-12-17 Thread Ioan-Adrian Ratiu
Commit 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream")
fixes a race-codition but it also introduces another really nasty data race
regression which makes my usb sound card [1] completely useless, throwing
the kernel into a panic if anything from userspace tries to start playback.

The problem is this: ep->data_subs is now set to NULL every time inside
wait_clear_urbs(). ep->data_subs is initalized only in one place in
start_endpoints(), then it is immediately wiped by the pre-existing call to
wait_clear_urbs() inside snd_usb_endpoint_start().

To ilustrate, this is what happens in the non-irq part of the code:

Step 1 (inside start_endpoints): ep->data_subs = subs;
Step 2 (inside start_endpoints): snd_usb_endpoint_start(ep, can_sleep);
Step 3 (inside snd_usb_endpoint_start): wait_clear_urbs(ep);
Step 4 (inside wait_clear_urbs): ep->data_subs = NULL;

Here's a simplified call stack for the IRQ part (full one at the end):

(NULL dereference, param "subs" is passed NULL value of ep->data_subs)
retire_playback_urb
retire_outbound_urb
snd_complete_urb
(...)
xhci_irq

Looking at the git log there seems to be quite a lot of history in this
part of the codebase, dating back to 2012 or earlier. My fix is based on
015618b90 ("ALSA: snd-usb: Fix URB cancellation at stream start") and
e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture
stream") with a few modifications of my own. My idea is to do the
ep->data_subs wiping before endpoint initialization in a manner similar
to these older commits by using stop_endpoints() in snd_usb_pcm_prepare()
and at the same time keep the ep->data_subs = NULL in wait_clear_urbs() to
not trigger the recently fixed stream stopping race again.

Full call stack:

[  131.093240] BUG: unable to handle kernel NULL pointer dereference at 
0010
[  131.094313] IP: retire_playback_urb+0x1b/0x160 [snd_usb_audio]
[  131.095046] PGD 0
[  131.095047]
[  131.096509] Oops:  [#1] PREEMPT SMP
[  131.097255] Modules linked in: fuse snd_usb_audio snd_usbmidi_lib 
snd_rawmidi snd_seq_device ctr ccm arc4 ath9k intel_rapl ath9k_common 
x86_pkg_temp_thermal ath9k_hw intel_powerclamp coretemp joydev mousedev ath 
kvm_intel mac80211 kvm
 input_leds hid_generic psmouse irqbypass usbhid hid crct10dif_pclmul 
crc32_pclmul serio_raw crc32c_intel atkbd ghash_clmulni_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
pcbc aesni_intel libps2 cfg8
0211 aes_x86_64 crypto_simd dell_laptop glue_helper r8169 dell_smbios 
snd_hda_codec sr_mod cryptd led_class mii rfkill snd_hwdep cdrom snd_hda_core 
ac dcdbas i8042 xhci_pci serio xhci_hcd snd_pcm tpm_tis battery tpm_tis_core 
lpc_ich tpm
snd_timer evdev shpchp i2c_i801 sch_fq_codel
[  131.105551] CPU: 2 PID: 165 Comm: irq/29-xhci_hcd Not tainted 
4.9.0-gd824cdc58ba0 #10
[  131.107516] Hardware name: Dell Inc. Inspiron 3521/018DYG, BIOS A14 
07/31/2015
[  131.109592] task: 880154a7 task.stack: c9f48000
[  131.111746] RIP: 0010:retire_playback_urb+0x1b/0x160 [snd_usb_audio]
[  131.113899] RSP: 0018:c9f4bc10 EFLAGS: 00010082
[  131.116080] RAX: a04cabe0 RBX:  RCX: 
[  131.118284] RDX:  RSI: 8801435a4c00 RDI: 
[  131.120505] RBP: c9f4bc40 R08: 0001 R09: 0001
[  131.122807] R10: 0001 R11: 82f60d6d R12: 8801432a0238
[  131.125265] R13: 8801435a4c00 R14:  R15: 8801535c83b8
[  131.127723] FS:  () GS:88015a00() 
knlGS:
[  131.130217] CS:  0010 DS:  ES:  CR0: 80050033
[  131.132568] CR2: 0010 CR3: 01e0b000 CR4: 001406e0
[  131.135007] Call Trace:
[  131.137329]  snd_complete_urb+0x190/0x2b0 [snd_usb_audio]
[  131.139526]  __usb_hcd_giveback_urb+0x8e/0x160
[  131.141948]  usb_hcd_giveback_urb+0x43/0x110
[  131.144104]  xhci_giveback_urb_in_irq.isra.22+0x7d/0xb0 [xhci_hcd]
[  131.146521]  finish_td.constprop.38+0x1de/0x2f0 [xhci_hcd]
[  131.148736]  xhci_irq+0x13a2/0x1ca0 [xhci_hcd]
[  131.150972]  ? trace_hardirqs_on+0xd/0x10
[  131.153209]  ? _raw_spin_unlock_irq+0x2c/0x50
[  131.155390]  ? irq_thread+0xb5/0x1d0
[  131.157771]  xhci_msi_irq+0x11/0x20 [xhci_hcd]
[  131.159938]  irq_forced_thread_fn+0x2f/0x70
[  131.162072]  ? irq_thread+0xb5/0x1d0
[  131.164141]  irq_thread+0x149/0x1d0
[  131.166132]  ? irq_finalize_oneshot.part.2+0xe0/0xe0
[  131.168142]  ? wake_threads_waitq+0x30/0x30
[  131.170149]  kthread+0x10f/0x150
[  131.172144]  ? irq_thread_dtor+0xc0/0xc0
[  131.174139]  ? kthread_create_on_node+0x40/0x40
[  131.176116]  ret_from_fork+0x2a/0x40
[  131.178074] Code: 8b 77 64 4c 89 e7 e8 e5 fe ff ff eb c3 0f 1f 00 0f 1f 44 
00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 08 <48> 8b 
47 10 48 8b 4f 70 48 c7 c7 88 7b 4d a0 4c 8b a0 78 01 00
[  131.182382] RIP: retire_playback_urb+0x1b/0x160 

[PATCH] ALSA: snd-usb: fix IRQ triggered NULL pointer dereference

2016-12-17 Thread Ioan-Adrian Ratiu
Commit 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream")
fixes a race-codition but it also introduces another really nasty data race
regression which makes my usb sound card [1] completely useless, throwing
the kernel into a panic if anything from userspace tries to start playback.

The problem is this: ep->data_subs is now set to NULL every time inside
wait_clear_urbs(). ep->data_subs is initalized only in one place in
start_endpoints(), then it is immediately wiped by the pre-existing call to
wait_clear_urbs() inside snd_usb_endpoint_start().

To ilustrate, this is what happens in the non-irq part of the code:

Step 1 (inside start_endpoints): ep->data_subs = subs;
Step 2 (inside start_endpoints): snd_usb_endpoint_start(ep, can_sleep);
Step 3 (inside snd_usb_endpoint_start): wait_clear_urbs(ep);
Step 4 (inside wait_clear_urbs): ep->data_subs = NULL;

Here's a simplified call stack for the IRQ part (full one at the end):

(NULL dereference, param "subs" is passed NULL value of ep->data_subs)
retire_playback_urb
retire_outbound_urb
snd_complete_urb
(...)
xhci_irq

Looking at the git log there seems to be quite a lot of history in this
part of the codebase, dating back to 2012 or earlier. My fix is based on
015618b90 ("ALSA: snd-usb: Fix URB cancellation at stream start") and
e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture
stream") with a few modifications of my own. My idea is to do the
ep->data_subs wiping before endpoint initialization in a manner similar
to these older commits by using stop_endpoints() in snd_usb_pcm_prepare()
and at the same time keep the ep->data_subs = NULL in wait_clear_urbs() to
not trigger the recently fixed stream stopping race again.

Full call stack:

[  131.093240] BUG: unable to handle kernel NULL pointer dereference at 
0010
[  131.094313] IP: retire_playback_urb+0x1b/0x160 [snd_usb_audio]
[  131.095046] PGD 0
[  131.095047]
[  131.096509] Oops:  [#1] PREEMPT SMP
[  131.097255] Modules linked in: fuse snd_usb_audio snd_usbmidi_lib 
snd_rawmidi snd_seq_device ctr ccm arc4 ath9k intel_rapl ath9k_common 
x86_pkg_temp_thermal ath9k_hw intel_powerclamp coretemp joydev mousedev ath 
kvm_intel mac80211 kvm
 input_leds hid_generic psmouse irqbypass usbhid hid crct10dif_pclmul 
crc32_pclmul serio_raw crc32c_intel atkbd ghash_clmulni_intel 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
pcbc aesni_intel libps2 cfg8
0211 aes_x86_64 crypto_simd dell_laptop glue_helper r8169 dell_smbios 
snd_hda_codec sr_mod cryptd led_class mii rfkill snd_hwdep cdrom snd_hda_core 
ac dcdbas i8042 xhci_pci serio xhci_hcd snd_pcm tpm_tis battery tpm_tis_core 
lpc_ich tpm
snd_timer evdev shpchp i2c_i801 sch_fq_codel
[  131.105551] CPU: 2 PID: 165 Comm: irq/29-xhci_hcd Not tainted 
4.9.0-gd824cdc58ba0 #10
[  131.107516] Hardware name: Dell Inc. Inspiron 3521/018DYG, BIOS A14 
07/31/2015
[  131.109592] task: 880154a7 task.stack: c9f48000
[  131.111746] RIP: 0010:retire_playback_urb+0x1b/0x160 [snd_usb_audio]
[  131.113899] RSP: 0018:c9f4bc10 EFLAGS: 00010082
[  131.116080] RAX: a04cabe0 RBX:  RCX: 
[  131.118284] RDX:  RSI: 8801435a4c00 RDI: 
[  131.120505] RBP: c9f4bc40 R08: 0001 R09: 0001
[  131.122807] R10: 0001 R11: 82f60d6d R12: 8801432a0238
[  131.125265] R13: 8801435a4c00 R14:  R15: 8801535c83b8
[  131.127723] FS:  () GS:88015a00() 
knlGS:
[  131.130217] CS:  0010 DS:  ES:  CR0: 80050033
[  131.132568] CR2: 0010 CR3: 01e0b000 CR4: 001406e0
[  131.135007] Call Trace:
[  131.137329]  snd_complete_urb+0x190/0x2b0 [snd_usb_audio]
[  131.139526]  __usb_hcd_giveback_urb+0x8e/0x160
[  131.141948]  usb_hcd_giveback_urb+0x43/0x110
[  131.144104]  xhci_giveback_urb_in_irq.isra.22+0x7d/0xb0 [xhci_hcd]
[  131.146521]  finish_td.constprop.38+0x1de/0x2f0 [xhci_hcd]
[  131.148736]  xhci_irq+0x13a2/0x1ca0 [xhci_hcd]
[  131.150972]  ? trace_hardirqs_on+0xd/0x10
[  131.153209]  ? _raw_spin_unlock_irq+0x2c/0x50
[  131.155390]  ? irq_thread+0xb5/0x1d0
[  131.157771]  xhci_msi_irq+0x11/0x20 [xhci_hcd]
[  131.159938]  irq_forced_thread_fn+0x2f/0x70
[  131.162072]  ? irq_thread+0xb5/0x1d0
[  131.164141]  irq_thread+0x149/0x1d0
[  131.166132]  ? irq_finalize_oneshot.part.2+0xe0/0xe0
[  131.168142]  ? wake_threads_waitq+0x30/0x30
[  131.170149]  kthread+0x10f/0x150
[  131.172144]  ? irq_thread_dtor+0xc0/0xc0
[  131.174139]  ? kthread_create_on_node+0x40/0x40
[  131.176116]  ret_from_fork+0x2a/0x40
[  131.178074] Code: 8b 77 64 4c 89 e7 e8 e5 fe ff ff eb c3 0f 1f 00 0f 1f 44 
00 00 55 31 d2 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 08 <48> 8b 
47 10 48 8b 4f 70 48 c7 c7 88 7b 4d a0 4c 8b a0 78 01 00
[  131.182382] RIP: retire_playback_urb+0x1b/0x160 

Re: OOM: Better, but still there on

2016-12-17 Thread Xin Zhou
Hi,
The system supposes to have special memory reservation for coredump and other 
debug info when encountering panic,
the size seems configurable.
Thanks,
Xin
 
 

Sent: Saturday, December 17, 2016 at 6:44 AM
From: "Tetsuo Handa" 
To: "Nils Holland" , "Michal Hocko" 
Cc: linux-kernel@vger.kernel.org, linux...@kvack.org, "Chris Mason" 
, "David Sterba" , linux-bt...@vger.kernel.org
Subject: Re: OOM: Better, but still there on
On 2016/12/17 21:59, Nils Holland wrote:
> On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
>> mount -t tracefs none /debug/trace
>> echo 1 > /debug/trace/events/vmscan/enable
>> cat /debug/trace/trace_pipe > trace.log
>>
>> should help
>> [...]
>
> No problem! I enabled writing the trace data to a file and then tried
> to trigger another OOM situation. That worked, this time without a
> complete kernel panic, but with only my processes being killed and the
> system becoming unresponsive. When that happened, I let it run for
> another minute or two so that in case it was still logging something
> to the trace file, it could continue to do so some time longer. Then I
> rebooted with the only thing that still worked, i.e. by means of magic
> SysRequest.

Under OOM situation, writing to a file on disk unlikely works. Maybe
logging via network ( "cat /debug/trace/trace_pipe > /dev/udp/$ip/$port"
if your are using bash) works better. (I wish we can do it from kernel
so that /bin/cat is not disturbed by delays due to page fault.)

If you can configure netconsole for logging OOM killer messages and
UDP socket for logging trace_pipe messages, udplogger at
https://osdn.net/projects/akari/scm/svn/tree/head/branches/udplogger/
might fit for logging both output with timestamp into a single file.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at 
http://vger.kernel.org/majordomo-info.html[http://vger.kernel.org/majordomo-info.html]


Re: OOM: Better, but still there on

2016-12-17 Thread Xin Zhou
Hi,
The system supposes to have special memory reservation for coredump and other 
debug info when encountering panic,
the size seems configurable.
Thanks,
Xin
 
 

Sent: Saturday, December 17, 2016 at 6:44 AM
From: "Tetsuo Handa" 
To: "Nils Holland" , "Michal Hocko" 
Cc: linux-kernel@vger.kernel.org, linux...@kvack.org, "Chris Mason" 
, "David Sterba" , linux-bt...@vger.kernel.org
Subject: Re: OOM: Better, but still there on
On 2016/12/17 21:59, Nils Holland wrote:
> On Sat, Dec 17, 2016 at 01:02:03AM +0100, Michal Hocko wrote:
>> mount -t tracefs none /debug/trace
>> echo 1 > /debug/trace/events/vmscan/enable
>> cat /debug/trace/trace_pipe > trace.log
>>
>> should help
>> [...]
>
> No problem! I enabled writing the trace data to a file and then tried
> to trigger another OOM situation. That worked, this time without a
> complete kernel panic, but with only my processes being killed and the
> system becoming unresponsive. When that happened, I let it run for
> another minute or two so that in case it was still logging something
> to the trace file, it could continue to do so some time longer. Then I
> rebooted with the only thing that still worked, i.e. by means of magic
> SysRequest.

Under OOM situation, writing to a file on disk unlikely works. Maybe
logging via network ( "cat /debug/trace/trace_pipe > /dev/udp/$ip/$port"
if your are using bash) works better. (I wish we can do it from kernel
so that /bin/cat is not disturbed by delays due to page fault.)

If you can configure netconsole for logging OOM killer messages and
UDP socket for logging trace_pipe messages, udplogger at
https://osdn.net/projects/akari/scm/svn/tree/head/branches/udplogger/
might fit for logging both output with timestamp into a single file.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at 
http://vger.kernel.org/majordomo-info.html[http://vger.kernel.org/majordomo-info.html]


Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-17 Thread Francois Romieu
Pavel Machek  :
[...]
> Won't this up/down the interface, in a way userspace can observe?

It won't up/down the interface as it doesn't exactly mimic what the
network code does (there's more than rtnl_lock).

For the same reason it's broken if it races with the transmit path: it
can release driver resources while the transmit path uses these.

Btw the points below may not matter/hurt much for a proof a concept
but they would need to be addressed as well:
1) unchecked (and avoidable) extra error paths due to stmmac_release()
2) racy cancel_work_sync. Low probability as it is, an irq + error could
   take place right after cancel_work_sync

Lino, have you considered via-rhine.c since its "move work from irq to
workqueue context" changes that started in
7ab87ff4c770eed71e3777936299292739fcd0fe [*] ?

It's a shameless plug - originated in r8169.c - but it should be rather
close to what the sxgbe and friends require. Thought / opinion ?

[*] Including fixes/changes in:
- 3a5a883a8a663b930908cae4abe5ec913b9b2fd2
- e1efa87241272104d6a12c8b9fcdc4f62634d447
- 810f19bcb862f8889b27e0c9d9eceac9593925dd
- e45af497950a89459a0c4b13ffd91e1729fffef4
- a926592f5e4e900f3fa903298c4619a131e60963
- 559bcac35facfed49ab4f408e162971612dcfdf3

-- 
Ueimor


Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

2016-12-17 Thread Francois Romieu
Pavel Machek  :
[...]
> Won't this up/down the interface, in a way userspace can observe?

It won't up/down the interface as it doesn't exactly mimic what the
network code does (there's more than rtnl_lock).

For the same reason it's broken if it races with the transmit path: it
can release driver resources while the transmit path uses these.

Btw the points below may not matter/hurt much for a proof a concept
but they would need to be addressed as well:
1) unchecked (and avoidable) extra error paths due to stmmac_release()
2) racy cancel_work_sync. Low probability as it is, an irq + error could
   take place right after cancel_work_sync

Lino, have you considered via-rhine.c since its "move work from irq to
workqueue context" changes that started in
7ab87ff4c770eed71e3777936299292739fcd0fe [*] ?

It's a shameless plug - originated in r8169.c - but it should be rather
close to what the sxgbe and friends require. Thought / opinion ?

[*] Including fixes/changes in:
- 3a5a883a8a663b930908cae4abe5ec913b9b2fd2
- e1efa87241272104d6a12c8b9fcdc4f62634d447
- 810f19bcb862f8889b27e0c9d9eceac9593925dd
- e45af497950a89459a0c4b13ffd91e1729fffef4
- a926592f5e4e900f3fa903298c4619a131e60963
- 559bcac35facfed49ab4f408e162971612dcfdf3

-- 
Ueimor


Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-17 Thread Christian Kujau
On Thu, 15 Dec 2016, Jason A. Donenfeld wrote:
> > I'd still drop the "24" unless you really think we're going to have
> > multiple variants coming into the kernel.
> 
> Okay. I don't have a problem with this, unless anybody has some reason
> to the contrary.

What if the 2/4-round version falls and we need more rounds to withstand 
future cryptoanalysis? We'd then have siphash_ and siphash48_ functions, 
no? My amateurish bike-shedding argument would be "let's keep the 24 then" :-)

C.
-- 
BOFH excuse #354:

Chewing gum on /dev/sd3c


Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

2016-12-17 Thread Christian Kujau
On Thu, 15 Dec 2016, Jason A. Donenfeld wrote:
> > I'd still drop the "24" unless you really think we're going to have
> > multiple variants coming into the kernel.
> 
> Okay. I don't have a problem with this, unless anybody has some reason
> to the contrary.

What if the 2/4-round version falls and we need more rounds to withstand 
future cryptoanalysis? We'd then have siphash_ and siphash48_ functions, 
no? My amateurish bike-shedding argument would be "let's keep the 24 then" :-)

C.
-- 
BOFH excuse #354:

Chewing gum on /dev/sd3c


[PATCH v2] usb: musb: debugfs: allow forcing host mode together with speed in testmode

2016-12-17 Thread Pali Rohár
Based on the musb ug, force_host bit is allowed to be set along with
force_hs or force_fs bit.

It could help to implement forced host mode via testmode on Nokia N900.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Use == instead of & for comparison of testmode
---
 drivers/usb/musb/musb_debugfs.c |   44 +--
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 9b22d94..5308cea 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -147,28 +147,34 @@ static int musb_test_mode_show(struct seq_file *s, void 
*unused)
 
test = musb_readb(musb->mregs, MUSB_TESTMODE);
 
-   if (test & MUSB_TEST_FORCE_HOST)
+   if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
+   seq_printf(s, "force host full-speed\n");
+
+   else if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
+   seq_printf(s, "force host high-speed\n");
+
+   else if (test == MUSB_TEST_FORCE_HOST)
seq_printf(s, "force host\n");
 
-   if (test & MUSB_TEST_FIFO_ACCESS)
+   else if (test == MUSB_TEST_FIFO_ACCESS)
seq_printf(s, "fifo access\n");
 
-   if (test & MUSB_TEST_FORCE_FS)
+   else if (test == MUSB_TEST_FORCE_FS)
seq_printf(s, "force full-speed\n");
 
-   if (test & MUSB_TEST_FORCE_HS)
+   else if (test == MUSB_TEST_FORCE_HS)
seq_printf(s, "force high-speed\n");
 
-   if (test & MUSB_TEST_PACKET)
+   else if (test == MUSB_TEST_PACKET)
seq_printf(s, "test packet\n");
 
-   if (test & MUSB_TEST_K)
+   else if (test == MUSB_TEST_K)
seq_printf(s, "test K\n");
 
-   if (test & MUSB_TEST_J)
+   else if (test == MUSB_TEST_J)
seq_printf(s, "test J\n");
 
-   if (test & MUSB_TEST_SE0_NAK)
+   else if (test == MUSB_TEST_SE0_NAK)
seq_printf(s, "test SE0 NAK\n");
 
return 0;
@@ -206,30 +212,36 @@ static ssize_t musb_test_mode_write(struct file *file,
if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
return -EFAULT;
 
-   if (strstarts(buf, "force host"))
+   if (strstarts(buf, "force host full-speed"))
+   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
+
+   else if (strstarts(buf, "force host high-speed"))
+   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
+
+   else if (strstarts(buf, "force host"))
test = MUSB_TEST_FORCE_HOST;
 
-   if (strstarts(buf, "fifo access"))
+   else if (strstarts(buf, "fifo access"))
test = MUSB_TEST_FIFO_ACCESS;
 
-   if (strstarts(buf, "force full-speed"))
+   else if (strstarts(buf, "force full-speed"))
test = MUSB_TEST_FORCE_FS;
 
-   if (strstarts(buf, "force high-speed"))
+   else if (strstarts(buf, "force high-speed"))
test = MUSB_TEST_FORCE_HS;
 
-   if (strstarts(buf, "test packet")) {
+   else if (strstarts(buf, "test packet")) {
test = MUSB_TEST_PACKET;
musb_load_testpacket(musb);
}
 
-   if (strstarts(buf, "test K"))
+   else if (strstarts(buf, "test K"))
test = MUSB_TEST_K;
 
-   if (strstarts(buf, "test J"))
+   else if (strstarts(buf, "test J"))
test = MUSB_TEST_J;
 
-   if (strstarts(buf, "test SE0 NAK"))
+   else if (strstarts(buf, "test SE0 NAK"))
test = MUSB_TEST_SE0_NAK;
 
musb_writeb(musb->mregs, MUSB_TESTMODE, test);
-- 
1.7.9.5



[PATCH v2] usb: musb: debugfs: allow forcing host mode together with speed in testmode

2016-12-17 Thread Pali Rohár
Based on the musb ug, force_host bit is allowed to be set along with
force_hs or force_fs bit.

It could help to implement forced host mode via testmode on Nokia N900.

Signed-off-by: Pali Rohár 
---
Changes in v2:
* Use == instead of & for comparison of testmode
---
 drivers/usb/musb/musb_debugfs.c |   44 +--
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 9b22d94..5308cea 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -147,28 +147,34 @@ static int musb_test_mode_show(struct seq_file *s, void 
*unused)
 
test = musb_readb(musb->mregs, MUSB_TESTMODE);
 
-   if (test & MUSB_TEST_FORCE_HOST)
+   if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
+   seq_printf(s, "force host full-speed\n");
+
+   else if (test == (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
+   seq_printf(s, "force host high-speed\n");
+
+   else if (test == MUSB_TEST_FORCE_HOST)
seq_printf(s, "force host\n");
 
-   if (test & MUSB_TEST_FIFO_ACCESS)
+   else if (test == MUSB_TEST_FIFO_ACCESS)
seq_printf(s, "fifo access\n");
 
-   if (test & MUSB_TEST_FORCE_FS)
+   else if (test == MUSB_TEST_FORCE_FS)
seq_printf(s, "force full-speed\n");
 
-   if (test & MUSB_TEST_FORCE_HS)
+   else if (test == MUSB_TEST_FORCE_HS)
seq_printf(s, "force high-speed\n");
 
-   if (test & MUSB_TEST_PACKET)
+   else if (test == MUSB_TEST_PACKET)
seq_printf(s, "test packet\n");
 
-   if (test & MUSB_TEST_K)
+   else if (test == MUSB_TEST_K)
seq_printf(s, "test K\n");
 
-   if (test & MUSB_TEST_J)
+   else if (test == MUSB_TEST_J)
seq_printf(s, "test J\n");
 
-   if (test & MUSB_TEST_SE0_NAK)
+   else if (test == MUSB_TEST_SE0_NAK)
seq_printf(s, "test SE0 NAK\n");
 
return 0;
@@ -206,30 +212,36 @@ static ssize_t musb_test_mode_write(struct file *file,
if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
return -EFAULT;
 
-   if (strstarts(buf, "force host"))
+   if (strstarts(buf, "force host full-speed"))
+   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
+
+   else if (strstarts(buf, "force host high-speed"))
+   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
+
+   else if (strstarts(buf, "force host"))
test = MUSB_TEST_FORCE_HOST;
 
-   if (strstarts(buf, "fifo access"))
+   else if (strstarts(buf, "fifo access"))
test = MUSB_TEST_FIFO_ACCESS;
 
-   if (strstarts(buf, "force full-speed"))
+   else if (strstarts(buf, "force full-speed"))
test = MUSB_TEST_FORCE_FS;
 
-   if (strstarts(buf, "force high-speed"))
+   else if (strstarts(buf, "force high-speed"))
test = MUSB_TEST_FORCE_HS;
 
-   if (strstarts(buf, "test packet")) {
+   else if (strstarts(buf, "test packet")) {
test = MUSB_TEST_PACKET;
musb_load_testpacket(musb);
}
 
-   if (strstarts(buf, "test K"))
+   else if (strstarts(buf, "test K"))
test = MUSB_TEST_K;
 
-   if (strstarts(buf, "test J"))
+   else if (strstarts(buf, "test J"))
test = MUSB_TEST_J;
 
-   if (strstarts(buf, "test SE0 NAK"))
+   else if (strstarts(buf, "test SE0 NAK"))
test = MUSB_TEST_SE0_NAK;
 
musb_writeb(musb->mregs, MUSB_TESTMODE, test);
-- 
1.7.9.5



  1   2   3   4   >