On Wed, 2 Dec 2020 at 14:09, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > 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. Sorry, but I don't quite follow, what is *not* a pinctrl? According to the information I have received from the previous discussions [1], it's clear to me that the ARM SMC call ends up changing settings for the I/O-pads. Or did I get that wrong? > And in that case you will need to mock up (what exactly?) and update > the MMC driver. > > -- > With Best Regards, > Andy Shevchenko Kind regards Uffe [1] https://lkml.org/lkml/2020/10/8/320
