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

Hi, On 12/21/2016 07:49 PM, Pavel Machek wrote: > Hi! > > 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

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

Hi, On 12/21/2016 07:49 PM, Pavel Machek wrote: > Hi! > > 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

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

Hi! > >>> 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 >

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

Hi! > >>> 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 >

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

On 12/19/2016 09:08 PM, Pavel Machek wrote: > Hi! > >> 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

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

On 12/19/2016 09:08 PM, Pavel Machek wrote: > Hi! > >> 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

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

Hi! > 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

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

Hi! > 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

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

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

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

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

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

On Fri, Dec 16, 2016 at 05:10:18PM +0100, Luis R. Rodriguez wrote: > Ah, well Milo Kim replied and described that the custom fallback is used as to > help load LED effect manually, and suggested a sysfs interface is more ideal > [0]. I > agree however its also may be too late, and it depends how

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

On Fri, Dec 16, 2016 at 05:10:18PM +0100, Luis R. Rodriguez wrote: > Ah, well Milo Kim replied and described that the custom fallback is used as to > help load LED effect manually, and suggested a sysfs interface is more ideal > [0]. I > agree however its also may be too late, and it depends how

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

On Fri, Dec 16, 2016 at 12:27:00PM +0100, Pavel Machek wrote: > On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote: > > On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: > > > > > > Well, I was asking if the above snipped looks like valid use. Because > > > AFAICT, the "custom

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

On Fri, Dec 16, 2016 at 12:27:00PM +0100, Pavel Machek wrote: > On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote: > > On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: > > > > > > Well, I was asking if the above snipped looks like valid use. Because > > > AFAICT, the "custom

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

On Fri, Dec 16, 2016 at 5:27 AM, Pavel Machek wrote: > On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote: >> On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: >> > >> > Well, I was asking if the above snipped looks like valid use. Because >> > AFAICT, the "custom

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

On Fri, Dec 16, 2016 at 5:27 AM, Pavel Machek wrote: > On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote: >> On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: >> > >> > Well, I was asking if the above snipped looks like valid use. Because >> > AFAICT, the "custom fallback" is just

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

On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote: > On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: > > > > Well, I was asking if the above snipped looks like valid use. Because > > AFAICT, the "custom fallback" is just dev_err(), see above. Coccinelle > > rules don't help me...

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

On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote: > On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: > > > > Well, I was asking if the above snipped looks like valid use. Because > > AFAICT, the "custom fallback" is just dev_err(), see above. Coccinelle > > rules don't help me...

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

On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: > > Well, I was asking if the above snipped looks like valid use. Because > AFAICT, the "custom fallback" is just dev_err(), see above. Coccinelle > rules don't help me... Its not. Its when you ask for no uevent. Only 2 drivers do

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

On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote: > > Well, I was asking if the above snipped looks like valid use. Because > AFAICT, the "custom fallback" is just dev_err(), see above. Coccinelle > rules don't help me... Its not. Its when you ask for no uevent. Only 2 drivers do

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

On Fri 2016-12-16 10:59:06, Luis R. Rodriguez wrote: > On Fri, Dec 16, 2016 at 10:29:20AM +0100, Pavel Machek wrote: > > On Fri 2016-12-16 10:22:41, Luis R. Rodriguez wrote: > > > On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > > > > Hi! > > > > > > > > > We need to ensure that

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

On Fri 2016-12-16 10:59:06, Luis R. Rodriguez wrote: > On Fri, Dec 16, 2016 at 10:29:20AM +0100, Pavel Machek wrote: > > On Fri 2016-12-16 10:22:41, Luis R. Rodriguez wrote: > > > On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > > > > Hi! > > > > > > > > > We need to ensure that

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

On Fri, Dec 16, 2016 at 10:29:20AM +0100, Pavel Machek wrote: > On Fri 2016-12-16 10:22:41, Luis R. Rodriguez wrote: > > On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > > > Hi! > > > > > > > We need to ensure that when driver developers use the custom firmware > > > > fallback

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

On Fri, Dec 16, 2016 at 10:29:20AM +0100, Pavel Machek wrote: > On Fri 2016-12-16 10:22:41, Luis R. Rodriguez wrote: > > On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > > > Hi! > > > > > > > We need to ensure that when driver developers use the custom firmware > > > > fallback

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

On Fri 2016-12-16 10:22:41, Luis R. Rodriguez wrote: > On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > > Hi! > > > > > We need to ensure that when driver developers use the custom firmware > > > fallback mechanism it was not a copy and paste bug. These use cases on > > > upstream

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

On Fri 2016-12-16 10:22:41, Luis R. Rodriguez wrote: > On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > > Hi! > > > > > We need to ensure that when driver developers use the custom firmware > > > fallback mechanism it was not a copy and paste bug. These use cases on > > > upstream

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

On Thu, Dec 15, 2016 at 10:32:12AM +0100, Jacek Anaszewski wrote: > > diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst > > b/Documentation/driver-api/firmware/fallback-mechanisms.rst > > index 955c11d6ff9d..b51673e40439 100644 > > ---

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

On Thu, Dec 15, 2016 at 10:32:12AM +0100, Jacek Anaszewski wrote: > > diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst > > b/Documentation/driver-api/firmware/fallback-mechanisms.rst > > index 955c11d6ff9d..b51673e40439 100644 > > ---

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

On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > Hi! > > > We need to ensure that when driver developers use the custom firmware > > fallback mechanism it was not a copy and paste bug. These use cases on > > upstream drivers are rare, we only have 2 upstream users and its for > >

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

On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote: > Hi! > > > We need to ensure that when driver developers use the custom firmware > > fallback mechanism it was not a copy and paste bug. These use cases on > > upstream drivers are rare, we only have 2 upstream users and its for > >

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

Hi Luis, Thanks for the patch. On 12/13/2016 04:08 AM, Luis R. Rodriguez wrote: We need to ensure that when driver developers use the custom firmware fallback mechanism it was not a copy and paste bug. These use cases on upstream drivers are rare, we only have 2 upstream users and its for

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

Hi Luis, Thanks for the patch. On 12/13/2016 04:08 AM, Luis R. Rodriguez wrote: We need to ensure that when driver developers use the custom firmware fallback mechanism it was not a copy and paste bug. These use cases on upstream drivers are rare, we only have 2 upstream users and its for

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

Hi! > We need to ensure that when driver developers use the custom firmware > fallback mechanism it was not a copy and paste bug. These use cases on > upstream drivers are rare, we only have 2 upstream users and its for > really old drivers. Since valid uses are rare but possible enable a >

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

Hi! > We need to ensure that when driver developers use the custom firmware > fallback mechanism it was not a copy and paste bug. These use cases on > upstream drivers are rare, we only have 2 upstream users and its for > really old drivers. Since valid uses are rare but possible enable a >

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

We need to ensure that when driver developers use the custom firmware fallback mechanism it was not a copy and paste bug. These use cases on upstream drivers are rare, we only have 2 upstream users and its for really old drivers. Since valid uses are rare but possible enable a white-list for its

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

We need to ensure that when driver developers use the custom firmware fallback mechanism it was not a copy and paste bug. These use cases on upstream drivers are rare, we only have 2 upstream users and its for really old drivers. Since valid uses are rare but possible enable a white-list for its