Hi,
On 11/09/2016 01:38 PM, Pavel Machek wrote:
Hi!
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
The claim was probably wrong from the day one, unless
Hi,
On 11/09/2016 01:38 PM, Pavel Machek wrote:
Hi!
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
The claim was probably wrong from the day one, unless
Hi,
On 11/09/2016 09:26 PM, Pavel Machek wrote:
Hi!
Thanks for the analysis. Either way, this patch, with the modification
I mentioned in my previous message is required to assure proper
LED sysfs locking.
Regarding the races between user and atomic context, I think that
it should be system
Hi,
On 11/09/2016 09:26 PM, Pavel Machek wrote:
Hi!
Thanks for the analysis. Either way, this patch, with the modification
I mentioned in my previous message is required to assure proper
LED sysfs locking.
Regarding the races between user and atomic context, I think that
it should be system
Hi!
> > Thanks for the analysis. Either way, this patch, with the modification
> > I mentioned in my previous message is required to assure proper
> > LED sysfs locking.
> >
> > Regarding the races between user and atomic context, I think that
> > it should be system root's responsibility to
Hi!
> > Thanks for the analysis. Either way, this patch, with the modification
> > I mentioned in my previous message is required to assure proper
> > LED sysfs locking.
> >
> > Regarding the races between user and atomic context, I think that
> > it should be system root's responsibility to
Hi!
> Initially the claim about no need for lock in brightness_show()
> was valid as the function was just returning unchanged
> LED brightness. After the addition of led_update_brightness() this
The claim was probably wrong from the day one, unless brightness is of
type "atomic_t".
Hi!
> Initially the claim about no need for lock in brightness_show()
> was valid as the function was just returning unchanged
> LED brightness. After the addition of led_update_brightness() this
The claim was probably wrong from the day one, unless brightness is of
type "atomic_t".
Hi!
> On 04-11-16 08:52, Jacek Anaszewski wrote:
> >Initially the claim about no need for lock in brightness_show()
> >was valid as the function was just returning unchanged
> >LED brightness. After the addition of led_update_brightness() this
> >is no longer true, as the
Hi!
> On 04-11-16 08:52, Jacek Anaszewski wrote:
> >Initially the claim about no need for lock in brightness_show()
> >was valid as the function was just returning unchanged
> >LED brightness. After the addition of led_update_brightness() this
> >is no longer true, as the
Hi,
On 11/06/2016 03:52 PM, Hans de Goede wrote:
Hi,
On 04-11-16 17:46, Hans de Goede wrote:
Hi,
On 04-11-16 17:06, Jacek Anaszewski wrote:
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in
Hi,
On 11/06/2016 03:52 PM, Hans de Goede wrote:
Hi,
On 04-11-16 17:46, Hans de Goede wrote:
Hi,
On 04-11-16 17:06, Jacek Anaszewski wrote:
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in
Hi,
On 04-11-16 17:46, Hans de Goede wrote:
Hi,
On 04-11-16 17:06, Jacek Anaszewski wrote:
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was
Hi,
On 04-11-16 17:46, Hans de Goede wrote:
Hi,
On 04-11-16 17:06, Jacek Anaszewski wrote:
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was
Hi,
On 04-11-16 17:06, Jacek Anaszewski wrote:
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After
Hi,
On 04-11-16 17:06, Jacek Anaszewski wrote:
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
is no
Hi Hans,
On 11/04/2016 12:53 PM, Hans de Goede wrote:
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
is no
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
is no longer true, as the function can change the brightness
Hi,
On 04-11-16 08:52, Jacek Anaszewski wrote:
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
is no longer true, as the function can change the brightness
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
is no longer true, as the function can change the brightness if
a LED class driver implements brightness_get op.
Initially the claim about no need for lock in brightness_show()
was valid as the function was just returning unchanged
LED brightness. After the addition of led_update_brightness() this
is no longer true, as the function can change the brightness if
a LED class driver implements brightness_get op.
22 matches
Mail list logo