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... > Could we reach an agreement about the 'optional' or not 'optional'? ...but I am fine with the current approach as well, as long as my recent comments gets addressed. Let's make it optional. Address Scott's and my review-comments, get other peoples ack for the non-mmc parts, then I will happily pick up the patches. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
