On 05/04/2019 19:29, Guenter Roeck wrote:
On Fri, Apr 05, 2019 at 01:06:15PM -0500, Bjorn Helgaas wrote:
On Fri, Apr 05, 2019 at 09:10:27AM +0100, John Garry wrote:
On 04/04/2019 19:58, Bjorn Helgaas wrote:
On Thu, Apr 04, 2019 at 10:43:36AM -0700, Guenter Roeck wrote:
On Thu, Apr 04, 2019 at 05:52:35PM +0100, John Garry wrote:
Note that the f71805f driver does not call
request_{muxed_}region(), as it should.
... which is the real problem, one that is not solved by this
patch. This may result in parallel and descructive accesses if
there is another device on the LPC bus, and another driver
accessing that device. Personally I'd rather have
request_muxed_region() added to the f71805f driver.
Right, we should and will still fix f71805f. If you recall, I did
have the f71805f fix in the v1 series, but you committed that it
was orthogonal, so I decided to take it out of this work for now.
And even if we fix up f71805f and other known drivers which don't
call request_muxed_region(), we still need to police against these
rogue accesses, which is what this patch attempts to do.
Do we ? I am personally not convinced that LPC accesses _have_ to
occur through PCI on any given system.
On current systems, I suspect ISA/LPC devices are typically connected
via a PCI-to-ISA/LPC bridge. But AFAIK there's no actual requirement
for that bridge, and there certainly *were* systems with ISA devices
but no PCI at all.
IMO, if you want to build ISA drivers on your arch, you need to make
sure the inb() probing done by those drivers works like it does on
x86. If there's no device there, the inb() should return 0xff with no
fuss and no crash.
Right, and this is what I am attempting to do here.
So today a call to request_muxed_region() can still succeed even if no IO
space mapped.
As such, even well-behaved drivers like f71882fg can still crash the system,
as noted in RFC patch 1/4 ("resource: Request IO port regions from children
of ioport_resource").
Maybe I'm missing something, but on x86, drivers like f71882fg do not
crash the system because inb() *never* causes a crash.
If you want to build that driver for ARM, I think you need to make
sure that inb() on ARM also *never* causes a crash. I don't think
changing f71882fg and all the similar drivers is the right answer.
Agreed. As I had mentioned earlier, the driver changes are orthogonal:
the drivers should request the IO region before accessing it, primarily
to avoid conflicting accesses by multiple drivers in parallel. For
example, the f71882fg driver supports chips which implement hardware
monitoring as well as watchdog functionality, and both the hwmon
and the watchdog driver may try to access the io space.
If and how the system ensures that the IO region exists and/or that
inb() always succeeds is a different question. I would prefer a less
complex solution than the one suggested here, but that is my personal
opionion.
Hi Guenter,
I have a question about these super-IO accesses:
To me, it's not good that these hwmon, watchdog, gpio, etc drivers make
unconstrained accesses to 0x2e and 0x4e ports (ignoring the
request_muxed_region() call).
The issue I see is that on an arm, IO space for some other device may be
mapped in this region, so it would not be right for these drivers to
access those same regions.
Is there any other platform check which can be made to ensure that
accesses these super-IO ports is appropriate?
Thanks,
John
Guenter
.
