[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEZbON5aC+iYzg58YH59rvfvcUYkjwQyjA9wAJstFEQvUei_-A@mail.gmail.com>
Date: Tue, 23 Jul 2019 09:56:55 -0700
From: Ravi Chandra Sadineni <ravisadineni@...omium.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Baoquan He <bhe@...hat.com>, Dave Young <dyoung@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux PM <linux-pm@...r.kernel.org>,
Todd Broch <tbroch@...omium.org>
Subject: Re: [PATCH 0/2] power: Refactor device level sysfs.
Hi Greg,
https://patchwork.kernel.org/patch/11045069/ seems to create a virtual
device under wakeup class with the same name as the actual device. I
don't see a way to reliably map these virtual devices to the actual
device sysfs node. For example if we have to know if a particular
input device has triggered a wake event, we have to look for a virtual
device under /sys/class/wakeup with the same name. I am afraid that
depending just on the name might be too risky as there can be multiple
devices under different buses with the same name. Am I missing
something?
Thanks,
Ravi
On Tue, Jul 23, 2019 at 12:44 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Tue, Jul 23, 2019 at 12:33 AM Ravi Chandra Sadineni
> <ravisadineni@...omium.org> wrote:
> >
> > wakeup_abort_count and wakeup_count attributes print the
> > same (wakeup_count) variable. Thus this patchset removes the
> > duplicate wakeup_abort_count sysfs attribute. This patchset also
> > exposes event_count as a sysfs attribute.
> >
> > Ravi Chandra Sadineni (2):
> > power: sysfs: Remove wakeup_abort_count attribute.
> > power:sysfs: Expose device wakeup_event_count.
>
> I don't think you need this at all, because
> https://patchwork.kernel.org/patch/11045069/ is exposing what you need
> already.
>
> Thanks!
Powered by blists - more mailing lists