On Wed, Mar 10, 2021 at 6:55 PM Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > On Wed 10 Mar 06:09 CST 2021, Andy Shevchenko wrote: > > On Wed, Mar 10, 2021 at 07:12:10PM +0800, Shawn Guo wrote: > > > It adds ACPI probe support for pinctrl-sc8180x driver. We have one > > > problem with ACPI table, i.e. GIO0 (TLMM) block has one single memory > > > resource to cover 3 tiles defined by SC8180X. To follow the hardware > > > layout of 3 tiles which is already supported DT probe, it adds one > > > function to replace the original single memory resource with 3 named > > > ones for tiles. With that, We can map memory for ACPI in the same way > > > as DT. > > > > You are reinventing a wheel, i.e. MFD framework. Can you simple utilize > > devm_mfd_add_devices()? > > > > But wouldn't such driver need to do exactly this, and then set up the > mfd cell and register it? So the new wheel would still be there, just > wrapped in more code? Are you sure it will take more code? > > Basically you may write an new pure MFD driver (drivers/mfd) that will > > instantiate properly the pin control driver. > > > > In contrast to typical MFDs this would still be a single mfd_cell, just > with different set of resources, derived from the mfd device itself. Yes, I understand the current case, but in my proposal you will have a separate driver for all quirks needed for this ACPI HID implementation. In any case, I just pointed out that MFD is worth considering. -- With Best Regards, Andy Shevchenko
