On Fri, 2018-03-02 at 10:19 +0000, John Garry wrote: > On 01/03/2018 19:50, Andy Shevchenko wrote: > > On Tue, 2018-02-27 at 00:40 +0800, John Garry wrote: > > Ok, this needs to be thought about a bit more. > > > > I guess I understand what's is the problem with PNP IDs in the > > driver. > > > > You probe your LPC device quite late. > > One option is to move from classical probe to a event-driven model, > > i.e. > > via registering a notifier (see acpi_lpss.c), preparing necessary > > stuff > > at earlier stages and then register devices by their enumeration and > > appearance. > > > > Though, if I would be you I would seek a opinion from Rafael and > > Mika > > (maybe others as well). > > I would like to give a bit more background on this HW. This HW is now > for us a legacy device. It will be used in no more chipsets. It is > only > used in hip06 and hip07 chipsets on our D03 and D05 boards, > respectively. On these boards we have the following LPC slave devices > only: > D03: UART, IPMI > D05: IPMI > > Supporting IPMI for D05 is required. Supporting legacy D03 and the > UART > is a "nice-to-have". But it is definitely ok for us to not support > this > device. I see. But it raises another question to the whole series, why do we introduce a generic indirect IO for only two devices ever? Can't it be done in the (MFD) driver itself? Possible another option, is to introduce a specific regmap for that and use it in the drivers (though it might be not so trivial with existing ones). > Our previous ACPI support solution did use a scan handler for this > host, > but there was some sensible pushback on this - please check this if > not > familiar: https://lkml.org/lkml/2018/2/14/532 > Overall it does not make sense to try to move this back to > drivers/acpi > and receive more pushback from that direction, Ah, I think the ARM people just worried mostly about arm64 in the pathnames, though your case is very similar to our LPSS for only few SoCs. I would rather think if you move it directly to drivers/acpi it would be fine. > and only delay > indefinitely upstreaming this driver (which is now running at ~27 > months > since v1) to just support a PNP-compatible device which we don't care > too much about. Ouch! As I suggested before, you would better to get an input from maintainers. My personal opinion that the handler approach is cleaner, though it's still non-generic stuff. I think that this is what Mika referred to in his mail. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy
