lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 17 Jul 2008 16:20:32 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Magnus Damm" <magnus.damm@...il.com>
Cc:	linux-kernel@...r.kernel.org, gregkh@...e.de
Subject: Re: [PATCH 04/04] resource: add new IORESOURCE_CLK type

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

> Hi Andrew,
> 
> Thanks for picking up my patches.
> 
> On Sat, Jul 12, 2008 at 4:18 AM, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
> > On Wed, 09 Jul 2008 20:55:02 +0900 Magnus Damm <magnus.damm@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ