linux-kernel - Re: [PATCH 10/11] acpi: Export acpi_bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1453107660.10582.31.camel@ankitprasad-desktop>
Date:	Mon, 18 Jan 2016 14:31:00 +0530
From:	Ankitprasad Sharma <ankitprasad.r.sharma@...el.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	intel-gfx@...ts.freedesktop.org, akash.goel@...el.com,
	shashidhar.hiremath@...el.com, tvrtko.ursulin@...ux.intel.com,
	Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/11] acpi: Export acpi_bus_type

On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sharma@...el.com wrote:
> > From: Ankitprasad Sharma <ankitprasad.r.sharma@...el.com>
> > 
> > Some modules, like i915.ko, needs to detect when certain ACPI features
> > are active inorder to prevent corruption on contended resources.
> > In particular, use of BIOS RapidStart Technology may corrupt the contents
> > of the reserved graphics memory, due to unalarmed hibernation. In which
> > case i915.ko cannot assume that it (reserved gfx memory) remains
> > unmodified and must recreate teh contents and importantly not use it to
> > store unrecoverable user data.
> > 
> > Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@...el.com>
> > Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>
> > Cc: Len Brown <lenb@...nel.org>
> > Cc: linux-acpi@...r.kernel.org
> > Cc: linux-kernel@...r.kernel.org
> > ---
> >  drivers/acpi/bus.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > index a212cef..69509c7 100644
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -814,6 +814,7 @@ struct bus_type acpi_bus_type = {
> >  	.remove		= acpi_device_remove,
> >  	.uevent		= acpi_device_uevent,
> >  };
> > +EXPORT_SYMBOL_GPL(acpi_bus_type);
> >  
> >  /* --------------------------------------------------------------------------
> >                               Initialization/Cleanup
> > 
> 
> No.
> 
> I see no reason whatsoever for doing this.
> 
> Thanks,
> Rafael
Hi Rafael,

Thanks for the response.

Can you please help me with, how to detect the presence of a certain
acpi device using its id (for example, INT3392 for Intel RST device)? 

As you might have seen (in the next patch in this series), that we use
this symbol (acpi_bus_type) to iterate over all the devices registered
on acpi bus, to check if there is a device with id INT3392 present or
not.

Thanks,
Ankit