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 14:07:1
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 bui
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)
>> >>
>> >
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,
> };
>
> +st
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_ gu
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 f
+ 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 inte
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 it
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 poss
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
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. Othe
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
https://git.kernel.org/cgit/linux/kernel/git/cooloney/linux-leds.git/commit/?h=devel&i
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 m
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 dev_warn
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
16 matches
Mail list logo
