On Wed, Dec 2, 2020 at 2:44 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > On Wed, 2 Dec 2020 at 13:24, Shevchenko, Andriy > <andriy.shevchenko@xxxxxxxxx> wrote: > > On Wed, Dec 02, 2020 at 11:53:42AM +0100, Ulf Hansson wrote: > > > On Wed, 2 Dec 2020 at 08:02, <muhammad.husaini.zulkifli@xxxxxxxxx> wrote: > > > > ... > > > > > > Kindly help to review this patch set. > > > > > > This version looks a lot better to me, but I am still requesting you > > > to model the pinctrl correctly. I don't see a reason not to, but I may > > > have overlooked some things. > > > > I'm wondering why we need to mock up a pin control from something which has no > > pin control interface. It's rather communication with firmware that does pin > > control under the hood, but it also may be different hardware in the other / > > future generations. Would you accept mocking up the same calls over the kernel > > as pin control, as something else? > > Well, my point is that modeling this a pinctrl would keep the mmc > driver portable. Additionally, it's very common to manage pinctrls in > mmc drivers, so it's not like this is an entirely new thing that I > propose. > > If/when it turns out that there is a new HW having a different pinctrl > interface, it would just mean that we need a new pinctrl driver, but > can leave the mmc driver as is. My point is that it may be *not* a pin control at all. And in that case you will need to mock up (what exactly?) and update the MMC driver. -- With Best Regards, Andy Shevchenko
