[PATCH 1/2] ohci-platform: Add support for devicetree instantiation

Alan Stern stern at rowland.harvard.edu
Wed Jan 8 11:59:14 EST 2014


On Tue, 7 Jan 2014, Hans de Goede wrote:

> Hi,
> 
> On 01/07/2014 10:16 PM, Arnd Bergmann wrote:
> > On Tuesday 07 January 2014 22:03:11 Hans de Goede wrote:
> >>>> +
> >>>> +Optional properties:
> >>>> + - clocks: array of clocks
> >>>> + - clock-names: clock names "ahb" and/or "ohci"
> >>>
> >>> Where does "ahb" come from, what does it mean, and how is it relevant
> >>> to generic platforms?
> >>
> >> ahb is an ARM specific thing, so your right it does not belong in a
> >> generic driver. I'll use clk1 and clk2 as names in my next version.
> >
> > While AHB is a bus created by ARM Ltd, it's not actually specific
> > to the ARM architecture. My guess is that it is in fact used on 95%
> > of all SoCs, so I would leave it at that. For the other clock, I
> > think that's actually the bus clock for the USB interface, so I would
> > not call it "ohci" but rather just "usb" or "phy".
> >
> > I think it's important to distinguish the names and not just use
> > "clk1" and "clk2", because the driver may actually want to access
> > a particular clock in some scenario.
> 
> The idea here is to have a generic driver, if a driver needs to know
> about a specific clock, it will likely be another device specific
> driver and it can use its own dt-bindings and clock names. I believe
> that for a generic driver meant to cover common hardware configs,
> simply having X clks and then on power_on enabling clk1, then clk2,
> then clk3, etc. and on power off do the same in reverse other is
> a good approach.

I agree.

Alan Stern





More information about the linux-arm-kernel mailing list