On Thu, Jul 29, 2021 at 10:52:06AM -0500, Ian Pilcher wrote:
> On 7/28/21 10:09 PM, Valdis Klētnieks wrote:
> > > + # cat /sys/class/block/led_trigger_list
> > > + baz: 0
> > > + bar: 0
> > > + foo: 0
> >
> > This looks like an abuse of the "one entry one value" rule for sysfs.
> > Perhaps this sh
On 7/29/21 1:35 PM, Pavel Machek wrote:
Yes, and I'd like to have that functionality, but I believe userland
API should be similar to what we do elsewhere. Marek described it in
more details.
On 7/29/21 6:59 AM, Marek Behún wrote:
...
> - only one trigger, with name "blkdev"
I guess I'm missin
On Thu 2021-07-29 12:03:04, Ian Pilcher wrote:
> On 7/29/21 3:54 AM, Pavel Machek wrote:
> > We normally have a trigger ("block device activity") which can then
> > expose parameters ("I watch for read" and "I monitor sda1").
> >
> > Is there a reason normal solution can not be used?
>
> This big
On 7/29/21 6:59 AM, Marek Behún wrote:
I don't really see the purpose for having multiple different block
device LED triggers.
Is there a different/better way to control per-device LEDs? (I'm
thinking of something like my NAS, which has 5 drive bays, each with
its own activity LED.)
Moreove
On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia
wrote:
>
> On Thu, 29 Jul 2021 at 08:45, Richard Weinberger wrote:
> >
> > Ezequiel,
> >
> > - Ursprüngliche Mail -
> > > [snip]
> > >
> > > Ouch, so surprised that after all these years someone is doing
> > > squashfs/mtdblock
> > > instead
On 7/29/21 3:54 AM, Pavel Machek wrote:
We normally have a trigger ("block device activity") which can then
expose parameters ("I watch for read" and "I monitor sda1").
Is there a reason normal solution can not be used?
This big difference is that this allows different devices to drive
differe
On 7/28/21 10:45 PM, Valdis Klētnieks wrote:
Is pr_warn() the right level for this stuff? I'd think this sort of pilot error
should
be pr_info() or even pr_debug(), if mentioned at all. pr_warn() would be for
something like an unexpected situation like trying to blink an LED but failing.
Simple
On 7/28/21 10:14 PM, Valdis Klētnieks wrote:
Is this bisect-clean (as in "will it build properly with that config option
set after each of the succeeding patches")? Usually, the config option
is added in the *last* patch, so that even if you have a bisect issue
it won't manifest because it's wra
On 7/28/21 10:09 PM, Valdis Klētnieks wrote:
+ # cat /sys/class/block/led_trigger_list
+ baz: 0
+ bar: 0
+ foo: 0
This looks like an abuse of the "one entry one value" rule for sysfs.
Perhaps this should be a directory /sys/class/block/defined_triggers/
and separate file
On Thu, 29 Jul 2021 12:57:03 -, Jorge Fernandez Monteagudo said:
> Event: time 1627381396.770902, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value
> 35023100
> Event: time 1627381396.770902, -- SYN_REPORT
> Event: time 1627381396.780891, type 4 (EV_MSC), code 5 (MSC_TIM
Hi all,
I'm using a 5.8.x kernel and an USB multitouch device is reporting a weird
response in some situations. I put a coin or some object in the left edge of
the touch without entering the working area and then the next taps to the touch
are ignored.
With the evtest tool to get all the messa
Ezequiel,
- Ursprüngliche Mail -
> [snip]
>
> Ouch, so surprised that after all these years someone is doing
> squashfs/mtdblock
> instead of using ubiblock :-)
>
> Can we patch either Kconfig or add some warn_once on mtdblock
> usage, suggesting to use ubiblock instead?
a hint in Kcon
Hi!
> This patch series adds configurable (i.e. user-defined) block device LED
> triggers.
>
> * Triggers can be created, listed, and deleted via sysfs block class
> attributes (led_trigger_{new,list,del}).
>
> * Once created, block device LED triggers are associated with LEDs just
> like an
13 matches
Mail list logo
