On Fri, Jun 26, 2015 at 2:19 AM, Geert Uytterhoeven
wrote:
> On Tue, Jun 9, 2015 at 12:55 AM, Kees Cook wrote:
>>> commit 95420c349194d1b570270ba1b1567d85461761c3
>>> Author: Kees Cook
>>> AuthorDate: Mon Sep 16 11:15:54 2013 -0700
>>> Commit: Kees Cook
>>> CommitDate: Wed Mar 4
On Tue, Jun 9, 2015 at 12:55 AM, Kees Cook wrote:
>> commit 95420c349194d1b570270ba1b1567d85461761c3
>> Author: Kees Cook
>> AuthorDate: Mon Sep 16 11:15:54 2013 -0700
>> Commit: Kees Cook
>> CommitDate: Wed Mar 4 14:07:18 2015 -0800
>>
>> Make all format string problems fail the
On Fri, Jun 26, 2015 at 2:19 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Tue, Jun 9, 2015 at 12:55 AM, Kees Cook keesc...@chromium.org wrote:
commit 95420c349194d1b570270ba1b1567d85461761c3
Author: Kees Cook keesc...@chromium.org
AuthorDate: Mon Sep 16 11:15:54 2013 -0700
On Tue, Jun 9, 2015 at 12:55 AM, Kees Cook keesc...@chromium.org wrote:
commit 95420c349194d1b570270ba1b1567d85461761c3
Author: Kees Cook keesc...@chromium.org
AuthorDate: Mon Sep 16 11:15:54 2013 -0700
Commit: Kees Cook keesc...@chromium.org
CommitDate: Wed Mar 4 14:07:18 2015 -0800
On Fri, Mar 27, 2015 at 6:07 PM, Fengguang Wu wrote:
> + Kees Cook
>
> On Fri, Mar 27, 2015 at 10:24:53AM -0700, Bryan Wu wrote:
>> On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado
>> wrote:
>> > Hi Sakari
>> >
>> > cc: adding Greg (core and FormatGuard) and Chistopher (sparse)
>> >>
>>
On Fri, Mar 27, 2015 at 6:07 PM, Fengguang Wu fengguang...@intel.com wrote:
+ Kees Cook
On Fri, Mar 27, 2015 at 10:24:53AM -0700, Bryan Wu wrote:
On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hi Sakari
cc: adding Greg (core and FormatGuard)
Hi Ricardo,
I forgot one thing:
On Sat, Mar 14, 2015 at 12:05 AM, Ricardo Ribalda Delgado
wrote:
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -212,6 +212,26 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
> .resume = led_resume,
> };
>
>
Hello Geert:
Thanks for your comments!
On Mon, Mar 30, 2015 at 9:59 AM, Geert Uytterhoeven
wrote:
>
> What's the maximum length of init_name?
It is "driver defined", this is why the initial patch used kasprintf,
but the Maintainer preferred to avoid the memory handling.
> strncpy() is _not_
On Sat, Mar 14, 2015 at 12:05 AM, Ricardo Ribalda Delgado
wrote:
> The current code expected that every LED had an unique name. This is a
> legit expectation when the device tree can no be modified or extended.
> But with device tree overlays this requirement can be easily broken.
>
> This patch
Hi Ricardo,
I forgot one thing:
On Sat, Mar 14, 2015 at 12:05 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -212,6 +212,26 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
.resume =
On Sat, Mar 14, 2015 at 12:05 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
The current code expected that every LED had an unique name. This is a
legit expectation when the device tree can no be modified or extended.
But with device tree overlays this requirement can be easily
Hello Geert:
Thanks for your comments!
On Mon, Mar 30, 2015 at 9:59 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
What's the maximum length of init_name?
It is driver defined, this is why the initial patch used kasprintf,
but the Maintainer preferred to avoid the memory handling.
+ Kees Cook
On Fri, Mar 27, 2015 at 10:24:53AM -0700, Bryan Wu wrote:
> On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado
> wrote:
> > Hi Sakari
> >
> > cc: adding Greg (core and FormatGuard) and Chistopher (sparse)
> >>
> >> I just realised there was another issue --- the name is now
On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado
wrote:
> Hi Sakari
>
> cc: adding Greg (core and FormatGuard) and Chistopher (sparse)
>>
>> I just realised there was another issue --- the name is now interpreted as
>> format string. Bad things will happen if there's e.g. %s in the name
Hi Sakari
cc: adding Greg (core and FormatGuard) and Chistopher (sparse)
>
> I just realised there was another issue --- the name is now interpreted as
> format string. Bad things will happen if there's e.g. %s in the name itself
> --- perhaps unlikely, but possible.
Good catch!
Would it be
Hi Sakari
cc: adding Greg (core and FormatGuard) and Chistopher (sparse)
I just realised there was another issue --- the name is now interpreted as
format string. Bad things will happen if there's e.g. %s in the name itself
--- perhaps unlikely, but possible.
Good catch!
Would it be
On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hi Sakari
cc: adding Greg (core and FormatGuard) and Chistopher (sparse)
I just realised there was another issue --- the name is now interpreted as
format string. Bad things will happen if there's e.g.
+ Kees Cook
On Fri, Mar 27, 2015 at 10:24:53AM -0700, Bryan Wu wrote:
On Fri, Mar 27, 2015 at 1:09 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hi Sakari
cc: adding Greg (core and FormatGuard) and Chistopher (sparse)
I just realised there was another issue --- the name
Hi Ricardo,
On Sat, Mar 14, 2015 at 12:05:39AM +0100, Ricardo Ribalda Delgado wrote:
> @@ -219,12 +239,19 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
> */
> int led_classdev_register(struct device *parent, struct led_classdev
> *led_cdev)
> {
> + char name[64];
> +
Hi Ricardo,
On Sat, Mar 14, 2015 at 12:05:39AM +0100, Ricardo Ribalda Delgado wrote:
@@ -219,12 +239,19 @@ static const struct dev_pm_ops leds_class_dev_pm_ops = {
*/
int led_classdev_register(struct device *parent, struct led_classdev
*led_cdev)
{
+ char name[64];
+ int ret;
On Wed, Mar 25, 2015 at 6:53 AM, Sakari Ailus wrote:
> On Wed, Mar 25, 2015 at 02:22:53PM +0100, Ricardo Ribalda Delgado wrote:
>> Hi Sakari!
>> >> Regarding s/dev_info/dev_warn : Do you want to send the patch or I should
>> >> do it?
>> >
>> > Is this one merged already? If yes, sure I can.
On Wed, Mar 25, 2015 at 02:22:53PM +0100, Ricardo Ribalda Delgado wrote:
> Hi Sakari!
> >> Regarding s/dev_info/dev_warn : Do you want to send the patch or I should
> >> do it?
> >
> > Is this one merged already? If yes, sure I can. Otherwise a new version
> > would be nice.
> It is at least here
Hi Sakari!
>> Regarding s/dev_info/dev_warn : Do you want to send the patch or I should do
>> it?
>
> Is this one merged already? If yes, sure I can. Otherwise a new version
> would be nice.
It is at least here
Hi Ricardo,
On Wed, Mar 25, 2015 at 10:20:59AM +0100, Ricardo Ribalda Delgado wrote:
> Hi Sakari
>
> On Wed, Mar 25, 2015 at 1:54 AM, Sakari Ailus wrote:
> > I'd use dev_warn() or even WARN_ON(ret). This is a rather serious issue as
> > now the probe order defines the name of the device. There
Hi Sakari
On Wed, Mar 25, 2015 at 1:54 AM, Sakari Ailus wrote:
> I'd use dev_warn() or even WARN_ON(ret). This is a rather serious issue as
> now the probe order defines the name of the device. There might be something
> better such as the I2C bus/address.
I have no problem in sending a
Hi Sakari
On Wed, Mar 25, 2015 at 1:54 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
I'd use dev_warn() or even WARN_ON(ret). This is a rather serious issue as
now the probe order defines the name of the device. There might be something
better such as the I2C bus/address.
I have no problem in
Hi Ricardo,
On Wed, Mar 25, 2015 at 10:20:59AM +0100, Ricardo Ribalda Delgado wrote:
Hi Sakari
On Wed, Mar 25, 2015 at 1:54 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
I'd use dev_warn() or even WARN_ON(ret). This is a rather serious issue as
now the probe order defines the name of the
On Wed, Mar 25, 2015 at 02:22:53PM +0100, Ricardo Ribalda Delgado wrote:
Hi Sakari!
Regarding s/dev_info/dev_warn : Do you want to send the patch or I should
do it?
Is this one merged already? If yes, sure I can. Otherwise a new version
would be nice.
It is at least here
Hi Sakari!
Regarding s/dev_info/dev_warn : Do you want to send the patch or I should do
it?
Is this one merged already? If yes, sure I can. Otherwise a new version
would be nice.
It is at least here
On Wed, Mar 25, 2015 at 6:53 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
On Wed, Mar 25, 2015 at 02:22:53PM +0100, Ricardo Ribalda Delgado wrote:
Hi Sakari!
Regarding s/dev_info/dev_warn : Do you want to send the patch or I should
do it?
Is this one merged already? If yes, sure I can.
Hi Ricardo,
(Cc Jacek.)
I had similar thoughts when reviewing Jacek's V4L2 flash API patches. See
below.
On Sat, Mar 14, 2015 at 12:05:39AM +0100, Ricardo Ribalda Delgado wrote:
> The current code expected that every LED had an unique name. This is a
> legit expectation when the device tree can
Hi Ricardo,
(Cc Jacek.)
I had similar thoughts when reviewing Jacek's V4L2 flash API patches. See
below.
On Sat, Mar 14, 2015 at 12:05:39AM +0100, Ricardo Ribalda Delgado wrote:
The current code expected that every LED had an unique name. This is a
legit expectation when the device tree can
The current code expected that every LED had an unique name. This is a
legit expectation when the device tree can no be modified or extended.
But with device tree overlays this requirement can be easily broken.
This patch finds out if the name is already in use and adds the suffix
_1, _2... if
The current code expected that every LED had an unique name. This is a
legit expectation when the device tree can no be modified or extended.
But with device tree overlays this requirement can be easily broken.
This patch finds out if the name is already in use and adds the suffix
_1, _2... if
34 matches
Mail list logo
