Re: [PATCH 04/04] resource: add new IORESOURCE_CLK type

From: Andrew Morton
Date: Thu Jul 17 2008 - 19:21:53 EST


On Tue, 15 Jul 2008 17:19:24 +0900
"Magnus Damm" <magnus.damm@xxxxxxxxx> wrote:

> Hi Andrew,
>
> Thanks for picking up my patches.
>
> On Sat, Jul 12, 2008 at 4:18 AM, Andrew Morton
> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Wed, 09 Jul 2008 20:55:02 +0900 Magnus Damm <magnus.damm@xxxxxxxxx> wrote:
> >
> >> This patch rearranges the values of the IORESOURCE_TYPE_BITS from
> >> one bit per type to a 4-bit counter. Also, IORESOURCE_CLK is added.
> >> Not sure if it is better to start counting from 0 instead of 1.
> >>
> >
> > I don't believe this is an adequate changelog. It contains the "what" but
> > not the "why".
>
> Yeah, sorry about that. I should have been more clear.
>
> > Why did we switch from one-bit to four-bits?
>
> The 4-bit encoding is there because I thought it was a waste of bits
> to use one bit per type. =)
>
> I wanted to add IORESOURCE_CLK and while at it I was playing around
> with changing the code to use a 4-bit value for resource type. We may
> already have spare bits available that are more suitable for new types
> though.
>
> > Why did we add IORESOURCE_CLK?
>
> Currently we use struct resource with the types
> IORESOURCE_MEM/IORESOURCE_IO and IORESOUCE_IRQ to pass I/O and
> interrupt parameters to platform drivers. That works fine, but I'd
> like to extend this so we also pass clock information. Basically a
> string that tells the platform driver which clock that should be used
> with clk_get() for a certain driver instance.
>
> I'm sure there are other ways to do this, but I'd like to have a
> generic way to pass a clock string to platform devices. Using a hard
> coded string in the device driver won't do since we may have multiple
> instances of drivers that need to use different clocks. Extending
> struct resource seems to be the easiest way to do this IMO.

umm, has there been any comment on all of this yet?

Perhaps you should just send everything again with clearer/completer
descriptions.

> If people are happy with this idea then i'd be more than happy to fix
> up and resend this patch.

We're all asleep. Please do whatever you think is best and we'll merge
it - that'll wake 'em up.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/