Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-21 Thread Sebastian Reichel
Hi,

On Tue, May 19, 2015 at 04:13:00PM +0900, Krzysztof Kozlowski wrote:
> Changes since v1:
> =
> 1. Patch 2: fix invalid member used for container_of().
> 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
>if parent is missing.
> 
> 
> Description:
> 
> This is an idea to fix issue in bq27x00 driver (and probably in others)
> reported by H. Nikolaus Schaller [0].
> 
> The fixes are marked RFC/RFT because:
> 1. I do not have bq27x00-like device. I confirmed this and tested on
>modified drivers (max77693, ACPI AC). These drivers are not
>impacted by the issue but one can easily adjust them to reproduce
>the problem.
> 2. The first uevent coming from power_supply_register() is now
>different because it won't contain device properties. I am
>not sure how this impacts userspace.
> 
> Comments are welcomed.

Queued to for-next and fixes. I will not sent it to Torvalds before
Sunday, so that it gets some testing in next.

-- Sebastian


signature.asc
Description: Digital signature


Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-21 Thread Sebastian Reichel
Hi,

On Tue, May 19, 2015 at 04:13:00PM +0900, Krzysztof Kozlowski wrote:
 Changes since v1:
 =
 1. Patch 2: fix invalid member used for container_of().
 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
if parent is missing.
 
 
 Description:
 
 This is an idea to fix issue in bq27x00 driver (and probably in others)
 reported by H. Nikolaus Schaller [0].
 
 The fixes are marked RFC/RFT because:
 1. I do not have bq27x00-like device. I confirmed this and tested on
modified drivers (max77693, ACPI AC). These drivers are not
impacted by the issue but one can easily adjust them to reproduce
the problem.
 2. The first uevent coming from power_supply_register() is now
different because it won't contain device properties. I am
not sure how this impacts userspace.
 
 Comments are welcomed.

Queued to for-next and fixes. I will not sent it to Torvalds before
Sunday, so that it gets some testing in next.

-- Sebastian


signature.asc
Description: Digital signature


Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-20 Thread Dr. H. Nikolaus Schaller

Am 21.05.2015 um 00:20 schrieb Sebastian Reichel :

> Hi,
> 
> On Tue, May 19, 2015 at 10:28:39AM +0200, Dr. H. Nikolaus Schaller wrote:
>> Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski :
>>> Changes since v1:
>>> =
>>> 1. Patch 2: fix invalid member used for container_of().
>>> 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
>>>  if parent is missing.
>>> 
>>> 
>>> Description:
>>> 
>>> This is an idea to fix issue in bq27x00 driver (and probably in others)
>>> reported by H. Nikolaus Schaller [0].
>>> 
>>> The fixes are marked RFC/RFT because:
>>> 1. I do not have bq27x00-like device. I confirmed this and tested on
>>>  modified drivers (max77693, ACPI AC). These drivers are not
>>>  impacted by the issue but one can easily adjust them to reproduce
>>>  the problem.
>>> 2. The first uevent coming from power_supply_register() is now
>>>  different because it won't contain device properties. I am
>>>  not sure how this impacts userspace.
>>> 
>>> Comments are welcomed.
>> 
>> appears to work! bq27000 is coming up now without hickups.
>> 
>> What I can’t test is if the uevent is reasonable because we do not
>> have a specific rule triggered by it in our system.
>> 
>> So from my side we are now happy with the solution.
> 
> So you would be ok with the following added to the patches?
> 
> Tested-By: Dr. H. Nikolaus Schaller 

Yes, please add.

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-20 Thread Sebastian Reichel
Hi,

On Tue, May 19, 2015 at 10:28:39AM +0200, Dr. H. Nikolaus Schaller wrote:
> Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski :
> > Changes since v1:
> > =
> > 1. Patch 2: fix invalid member used for container_of().
> > 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
> >   if parent is missing.
> > 
> > 
> > Description:
> > 
> > This is an idea to fix issue in bq27x00 driver (and probably in others)
> > reported by H. Nikolaus Schaller [0].
> > 
> > The fixes are marked RFC/RFT because:
> > 1. I do not have bq27x00-like device. I confirmed this and tested on
> >   modified drivers (max77693, ACPI AC). These drivers are not
> >   impacted by the issue but one can easily adjust them to reproduce
> >   the problem.
> > 2. The first uevent coming from power_supply_register() is now
> >   different because it won't contain device properties. I am
> >   not sure how this impacts userspace.
> > 
> > Comments are welcomed.
> 
> appears to work! bq27000 is coming up now without hickups.
> 
> What I can’t test is if the uevent is reasonable because we do not
> have a specific rule triggered by it in our system.
> 
> So from my side we are now happy with the solution.

So you would be ok with the following added to the patches?

Tested-By: Dr. H. Nikolaus Schaller 

-- Sebastian


signature.asc
Description: Digital signature


Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-20 Thread Sebastian Reichel
Hi,

On Tue, May 19, 2015 at 10:28:39AM +0200, Dr. H. Nikolaus Schaller wrote:
 Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com:
  Changes since v1:
  =
  1. Patch 2: fix invalid member used for container_of().
  2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
if parent is missing.
  
  
  Description:
  
  This is an idea to fix issue in bq27x00 driver (and probably in others)
  reported by H. Nikolaus Schaller [0].
  
  The fixes are marked RFC/RFT because:
  1. I do not have bq27x00-like device. I confirmed this and tested on
modified drivers (max77693, ACPI AC). These drivers are not
impacted by the issue but one can easily adjust them to reproduce
the problem.
  2. The first uevent coming from power_supply_register() is now
different because it won't contain device properties. I am
not sure how this impacts userspace.
  
  Comments are welcomed.
 
 appears to work! bq27000 is coming up now without hickups.
 
 What I can’t test is if the uevent is reasonable because we do not
 have a specific rule triggered by it in our system.
 
 So from my side we are now happy with the solution.

So you would be ok with the following added to the patches?

Tested-By: Dr. H. Nikolaus Schaller h...@goldelico.com

-- Sebastian


signature.asc
Description: Digital signature


Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-20 Thread Dr. H. Nikolaus Schaller

Am 21.05.2015 um 00:20 schrieb Sebastian Reichel s...@kernel.org:

 Hi,
 
 On Tue, May 19, 2015 at 10:28:39AM +0200, Dr. H. Nikolaus Schaller wrote:
 Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com:
 Changes since v1:
 =
 1. Patch 2: fix invalid member used for container_of().
 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
  if parent is missing.
 
 
 Description:
 
 This is an idea to fix issue in bq27x00 driver (and probably in others)
 reported by H. Nikolaus Schaller [0].
 
 The fixes are marked RFC/RFT because:
 1. I do not have bq27x00-like device. I confirmed this and tested on
  modified drivers (max77693, ACPI AC). These drivers are not
  impacted by the issue but one can easily adjust them to reproduce
  the problem.
 2. The first uevent coming from power_supply_register() is now
  different because it won't contain device properties. I am
  not sure how this impacts userspace.
 
 Comments are welcomed.
 
 appears to work! bq27000 is coming up now without hickups.
 
 What I can’t test is if the uevent is reasonable because we do not
 have a specific rule triggered by it in our system.
 
 So from my side we are now happy with the solution.
 
 So you would be ok with the following added to the patches?
 
 Tested-By: Dr. H. Nikolaus Schaller h...@goldelico.com

Yes, please add.

BR,
Nikolaus

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-19 Thread Dr. H. Nikolaus Schaller
Hi,

Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski :

> Hi,
> 
> 
> Changes since v1:
> =
> 1. Patch 2: fix invalid member used for container_of().
> 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
>   if parent is missing.
> 
> 
> Description:
> 
> This is an idea to fix issue in bq27x00 driver (and probably in others)
> reported by H. Nikolaus Schaller [0].
> 
> The fixes are marked RFC/RFT because:
> 1. I do not have bq27x00-like device. I confirmed this and tested on
>   modified drivers (max77693, ACPI AC). These drivers are not
>   impacted by the issue but one can easily adjust them to reproduce
>   the problem.
> 2. The first uevent coming from power_supply_register() is now
>   different because it won't contain device properties. I am
>   not sure how this impacts userspace.
> 
> Comments are welcomed.

appears to work! bq27000 is coming up now without hickups.

What I can’t test is if the uevent is reasonable because we do not
have a specific rule triggered by it in our system.

So from my side we are now happy with the solution.

Thanks and BR,
Nikolaus

> 
> 
> [0] https://lkml.org/lkml/2015/5/18/152
> 
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (2):
>  power_supply: Fix NULL pointer dereference during bq27x00_battery
>probe
>  power_supply: Fix possible NULL pointer dereference on early uevent
> 
> drivers/power/power_supply_core.c | 61 +++
> include/linux/power_supply.h  |  1 +
> 2 files changed, 56 insertions(+), 6 deletions(-)
> 
> -- 
> 1.9.1
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent

2015-05-19 Thread Dr. H. Nikolaus Schaller
Hi,

Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com:

 Hi,
 
 
 Changes since v1:
 =
 1. Patch 2: fix invalid member used for container_of().
 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register()
   if parent is missing.
 
 
 Description:
 
 This is an idea to fix issue in bq27x00 driver (and probably in others)
 reported by H. Nikolaus Schaller [0].
 
 The fixes are marked RFC/RFT because:
 1. I do not have bq27x00-like device. I confirmed this and tested on
   modified drivers (max77693, ACPI AC). These drivers are not
   impacted by the issue but one can easily adjust them to reproduce
   the problem.
 2. The first uevent coming from power_supply_register() is now
   different because it won't contain device properties. I am
   not sure how this impacts userspace.
 
 Comments are welcomed.

appears to work! bq27000 is coming up now without hickups.

What I can’t test is if the uevent is reasonable because we do not
have a specific rule triggered by it in our system.

So from my side we are now happy with the solution.

Thanks and BR,
Nikolaus

 
 
 [0] https://lkml.org/lkml/2015/5/18/152
 
 
 Best regards,
 Krzysztof
 
 Krzysztof Kozlowski (2):
  power_supply: Fix NULL pointer dereference during bq27x00_battery
probe
  power_supply: Fix possible NULL pointer dereference on early uevent
 
 drivers/power/power_supply_core.c | 61 +++
 include/linux/power_supply.h  |  1 +
 2 files changed, 56 insertions(+), 6 deletions(-)
 
 -- 
 1.9.1
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/