linux-kernel - Re: [PATCH V3 1/3] vfio, platform: add support for ACPI while detecting the reset driver

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]

Date:	Tue, 29 Mar 2016 14:44:20 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	okaya@...eaurora.org
Cc:	linux-arm-kernel@...ts.infradead.org, kvm@...r.kernel.org,
	timur@...eaurora.org, cov@...eaurora.org, jcm@...hat.com,
	eric.auger@...aro.org, mark.rutland@....com,
	devicetree@...r.kernel.org,
	Baptiste Reynal <b.reynal@...tualopensystems.com>,
	vikrams@...eaurora.org, marc.zyngier@....com,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	vinod.koul@...el.com, Alex Williamson <alex.williamson@...hat.com>,
	agross@...eaurora.org, Dan Carpenter <dan.carpenter@...cle.com>,
	shankerd@...eaurora.org
Subject: Re: [PATCH V3 1/3] vfio, platform: add support for ACPI while detecting the reset driver

On Tuesday 29 March 2016 08:15:42 okaya@...eaurora.org wrote:
> >> >
> >> > * If there is indeed a requirement for ACPI to handle something like
> >> > this,
> >> >   it should be part of the ACPI spec, with a well-defined method of
> >> > handling
> >> >   reset, rather than having to add a device specific hack for each
> >> >   device separately.
> >> >
> >> 
> >> I see. Normally, this is done by calling _rst method. AFAIK, Linux
> >> doesn’t support _rst. I can check its presence and call it if it is
> >> there.
> > 
> > Yes, that sounds reasonable: In patch 2 where you check for the
> > presence of the reset method, just keep the existing logic for
> > DT based systems, and use _rst on ACPI based systems instead,
> > then you can drop both patches 1 and 3.
> > 
> 
> I can certainly drop patch #3 and push the reset responsibility to acpi.
> 
> I never liked having a fragmented sw design across multiple drivers.
> 
> I need something for patch #1. Compatible is a DT property not ACPI.but 
> then, I won't have a reset driver anymore.
> 
> If we think about how vfio pci works, we pass the pci vendor and device 
> id to new_id file to find out which pci device needs to be pass thru.
> 
> I can go to a similar route. This time we pass the object id through 
> new_id and I call reset method on this object.
> 
> Let me know what you think?

It would certainly be nice to make it work more like PCI VFIO does
here, where you can assign any device as long as it has an IOMMU
(and a _rst method in this case).

	Arnd