On Monday 09 August 2021 20:56:33 Marek Behún wrote:
> Hello Ian,
>
> thank you for your proposal. Some comments below:
>
> On Sun, 8 Aug 2021 22:32:07 -0500
> Ian Pilcher wrote:
>
> > One thing that has not changed is that associations between block
> > devices and LEDs are still set via an
On Wed, 11 Aug 2021 08:26:42 +0200
Christoph Hellwig wrote:
> On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:
> > On 8/9/21 5:43 PM, Marek Behún wrote:
> >> I confess that I am not very familiar with internal blkdev API.
> >
> > It's mainly a matter of symbol visibility. See
On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:
> On 8/9/21 5:43 PM, Marek Behún wrote:
>> I confess that I am not very familiar with internal blkdev API.
>
> It's mainly a matter of symbol visibility. See this thread from a few
> months ago:
>
>
On 8/10/21 11:24 AM, Greg KH wrote:
There should not be anything "odd" about block devices here, just do
whatever all other LED drivers do when referencing a device.
AFAIK, the only LED trigger that does anything similar is the netdev
trigger. It uses dev_get_by_name(), which is specific to
On Tue, 10 Aug 2021 18:24:12 +0200
Greg KH wrote:
> > Sounds good. I'll work something up. (I'm actually thinking that
> > class_find_device() may be the best way to go, as it grabs a reference
> > to the device.)
>
> There should not be anything "odd" about block devices here, just do
>
On Tue, Aug 10, 2021 at 10:55:33AM -0500, Ian Pilcher wrote:
> On 8/10/21 9:48 AM, Greg KH wrote:
> > But what about when the device is removed from the system first? Be
> > careful about that...
> >
> > Anyway, sure, try those functions, I really do not know, all I
> > originally complained
On 8/10/21 9:48 AM, Greg KH wrote:
But what about when the device is removed from the system first? Be
careful about that...
Anyway, sure, try those functions, I really do not know, all I
originally complained about was those exports which did not need to be
exported.
Sounds good. I'll work
On Tue, Aug 10, 2021 at 03:38:40PM +0200, Marek Behún wrote:
> On Tue, 10 Aug 2021 08:35:08 +0200
> Greg KH wrote:
>
> > On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:
> > > On 8/9/21 5:43 PM, Marek Behún wrote:
> > > > I confess that I am not very familiar with internal blkdev
On Tue, 10 Aug 2021 08:35:08 +0200
Greg KH wrote:
> On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:
> > On 8/9/21 5:43 PM, Marek Behún wrote:
> > > I confess that I am not very familiar with internal blkdev API.
> >
> > It's mainly a matter of symbol visibility. See this
On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:
> On 8/9/21 5:43 PM, Marek Behún wrote:
> > I confess that I am not very familiar with internal blkdev API.
>
> It's mainly a matter of symbol visibility. See this thread from a few
> months ago:
>
>
On 8/9/21 5:43 PM, Marek Behún wrote:
I confess that I am not very familiar with internal blkdev API.
It's mainly a matter of symbol visibility. See this thread from a few
months ago:
https://www.spinics.net/lists/linux-leds/msg18244.html
Now ... my code currently lives in block/, so
On Mon, 9 Aug 2021 14:54:26 -0500
Ian Pilcher wrote:
> I'm not unalterably opposed to the idea, but I don't currently see a way
> to do that without resolving block devices (struct gendisk) by name, and
> that seems to be a no-no.
So a name like "sda1" is not viable? Why? What about
Marek -
Thanks for taking the time to look at this.
On 8/9/21 1:56 PM, Marek Behún wrote:
It may be simpler, but it is in contrast to how the netdev trigger
works, which already is in upstream for many years. I really think we
should try to have similar sysfs ABIs here. (I understand that the
Hello Ian,
thank you for your proposal. Some comments below:
On Sun, 8 Aug 2021 22:32:07 -0500
Ian Pilcher wrote:
> One thing that has not changed is that associations between block
> devices and LEDs are still set via an attribute on the device, rather
> than the LED. This is much simpler,
This is a significant rewrite of the patchset that I originally posted
back on 28 July. It incorporates almost all of the suggestions that I
received as feedback to my original patchset (largely because I was
finally able to wrap my head around how complex LED triggers work).
One thing that has
15 matches
Mail list logo
