On Tue, Jun 25, 2019 at 1:08 PM Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote: > > On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@xxxxxxxxxxxx> wrote: > > > > > > On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko > > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > > > > > Usually to check this is better to run > > > > grep -H 15 /sys/bus/acpi/devices/*/status > > > > which return you the list of *present and available* ACPI devices. > > > > > > > > > It looks like INT344B device is neither present nor available. This > > > device isn't in the list returned by above grep. > > > Its status actually returns 0. What could be reasons for that? > > > > > > > Any idea why would otherwise 'visible' [1] device appear unavailable and not present [2]? > > I cannot see anything obviously wrong in kernel traces either. > > > > > > [1] # tree /sys/bus/acpi/devices/INT344B\:00/ > > /sys/bus/acpi/devices/INT344B:00/ > > ├── hid > > ├── modalias > > ├── path > > ├── power > > │ ├── autosuspend_delay_ms > > │ ├── control > > │ ├── runtime_active_time > > │ ├── runtime_status > > │ └── runtime_suspended_time > > ├── status > > ├── subsystem -> ../../../../../bus/acpi > > └── uevent > > > > [2] # cat /sys/bus/acpi/devices/INT344B\:00/status > > 0 > > There is no issue with kernel. ACPI tables provided by firmware, so, > vendor of your firmware decided to turn off this device. In Linux we usually respect users and contributors more than vendors, so if there are users that need to access this device and the firmware doesn't let them, but there is a way for us to fix that, then we should provide the tools. But I guess that would happen in the ACPI core? Yours, Linus Walleij _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
