Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Thomas,

On 8/22/2012 2:04 AM, Thomas Abraham wrote:
> On 22 August 2012 16:38, Chris Ball <cjb@xxxxxxxxxx> wrote:
>> Hi Thomas,
>>
>> On Wed, Aug 22 2012, Thomas Abraham wrote:
>>>> This matches Mitch's last suggestion exactly -- I think we're all agreed
>>>> on these properties now.  The only remaining question is how to handle
>>>> the pinctrl for CD in Thomas's case.
>>>
>>> Hi Chris,
>>>
>>> For sdhci-s3c driver, the 'broken-cd' and 'cd-gpios' bindings are
>>> sufficient. But, are drivers free to use implementation specific
>>> behavior when using these bindings. Or do we strictly adhere to the
>>> table which Shawn has listed. For sdhci-s3c driver, I would like to
>>> deviate from the "implication" column listed above.
>>
>> I'd rather you use the implications described above for the names
>> described above; there's not much point in defining named behaviors
>> across the subsystem if they're actually different in each driver.
> 
> Ok.
> 
>>
>> But I think you can still use driver-internal properties that change the
>> interpretation of those names in a documented way.  If the meaning of
>> cd-gpios is modified when coupled with your "samsung,sdhci-cd-external",
>> that's okay with me.  That should cover all the cases you need until you
>> migrate to using pinctrl, right?  So, you could immediately support:
>>
>> none          -> currently "samsung,sdhci-cd-internal"
>> broken-cd     -> currently "samsung,sdhci-cd-none"
>> cd-gpios      -> currently "samsung,sdhci-cd-gpios"
>> non-removable -> currently "samsung,sdhci-cd-permanent"
>> cd-gpios + samsung,sdhci-cd-external -> currently "samsung,sdhci-cd-external"
>>
>> How does that sound?
> 
> Not quite there yet. It is not possible to leave out cd-gpios for
> "samsung,sdhci-cd-internal" since the current Samsung pinmux
> configuration piggybacks on gpio dt binding.


Sorry to interject on a topic that seems to have already been decided,
but I'm confused by one thing and would like clarification.  I
understand that you need to use a GPIO-style specifier as a surrogate
for a pinmux specification - that much is clear.  What is not clear is
why it's necessary to (ab)use the name "cd-gpios" for it.

Why not use a different property name, e.g. "samsung,cd-pinmux-gpio =
<gpio-specifier>" for the "cd-gpios + samsung,sdhci-cd-internal" case?
Then both "samsung,sdhci-cdi-internal" and "samsung,sdhci-cd-external"
could go away.  There would only be one system-dependent property
"samsung,cd-pinmux-gpio" whose name would make it clear that it's
conflating pinmuxing and gpios.

I think the scheme I propose would be clearer, less likely to confuse
other people who try to use the driver as a model, require less
hand-waving in the documentation, and easier to change to a proper
pinmuxing scheme should that become available later.


 Can we use the following
> instead.
> 
> none               -> currently "samsung,sdhci-cd-none"
> broken-cd        -> currently "samsung,sdhci-cd-none"
> cd-gpios          -> currently "samsung,sdhci-cd-gpios"
> non-removable -> currently "samsung,sdhci-cd-permanent"
> cd-gpios + samsung,sdhci-cd-internal -> currently "samsung,sdhci-cd-internal"
> 
> Thanks Chris.
> 
> Regards,
> Thomas.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@xxxxxxxxxxxxxxxx
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux