> -----Original Message----- > From: Yangbo Lu > Sent: Wednesday, January 06, 2016 2:58 PM > To: Scott Wood; Ulf Hansson > Cc: Lu Yangbo-B47093; linux-mmc; Xie Xiaobo-R63061; Leo li > Subject: RE: [v4, 5/6] mmc: kconfig: select FSL_GUTS for > MMC_SDHCI_OF_ESDHC > > > -----Original Message----- > > From: Scott Wood [mailto:scottwood@xxxxxxxxxxxxx] > > Sent: Tuesday, December 29, 2015 3:10 AM > > To: Ulf Hansson; Yangbo Lu > > Cc: Lu Yangbo-B47093; linux-mmc; Xie Xiaobo-R63061; Leo li > > Subject: Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for > > MMC_SDHCI_OF_ESDHC > > > > On Mon, 2015-12-28 at 13:10 +0100, Ulf Hansson wrote: > > > On 28 December 2015 at 11:26, Yangbo Lu <yangbo.lu@xxxxxxx> wrote: > > > > > -----Original Message----- > > > > > From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx] > > > > > Sent: Thursday, December 17, 2015 7:31 PM > > > > > To: Scott Wood > > > > > Cc: Lu Yangbo-B47093; linux-mmc; Xie Xiaobo-R63061; Leo li > > > > > Subject: Re: [v4, 5/6] mmc: kconfig: select FSL_GUTS for > > > > > MMC_SDHCI_OF_ESDHC > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > And I think stubs for reading SVR is quite a bad idea. > > > > > > > It'll make the driver build but it will silently not be able > > > > > > > to apply SVR-based > > > > > workarounds. > > > > > > > > > > > > It doesn't have to be "silent", the driver can return an error > > > > > > (and print error messages) from its ->probe() method, if the > > > > > > calls to the GUTS driver fails. > > > > > > > > > > > > Anyway, I mentioned this idea only to understand the need for > > > > > > *optional* GUTS supports. Perhaps there is a cross SOC drivers > > > > > > that for some platforms depends on GUTS but on others it > doesn't. > > > > > > > > > > > > Maybe that isn't case then!? > > > > > > > > > > Can you please answer this question!? > > > > > > > > > > According to the earlier versions of this patchset and from your > > > > > comments [1], it *do* seems like the GUTS driver may be optional > > > > > and thus stubs could address this. > > > > > > > > > > Kind regards > > > > > Uffe > > > > > > > > > > [1] > > > > > http://www.spinics.net/lists/linux-mmc/msg34412.html > > > > > > > > [Lu Yangbo-B47093] Hi Scott and Uffe, In the earlier version, I'd > > > > like to use syscon support and only add 'syscon' compatible in the > > > > dts whose eSDHC needs to use it to get SVR. > > > > But I never thought this had caused so much discussion... :( > > > > > > Sorry, I understand your frustration but that's life sometimes. :-) > > > > > > To me, the syscon solution is more elegant... > > > > The syscon patch was terrible. It would have accessed a certain > > location in any node labelled "syscon" whether it was guts or not, in > > addition to the other complaints. > > > > -Scott > > [Lu Yangbo-B47093] As my understand, the syscon APIs would just check > whether there is a 'syscon' compatible. > If no, the APIs return. We still could maintain a list of compatibles for > guts if using syscon. [Lu Yangbo-B47093] It's ok to use a compatible name that is not 'syscon' as the parameter of the APIs. The node needs just to contain 'syscon'. > In my opinion, syscon and guts driver are just two method to get SVR. > > I agree with Uffe, because I think syscon is really designed for this > situation and many arm platforms are using it. > Of course, I still would like to try guts driver if you insist on it. > > > > > ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
