linux-kernel - Re: [PATCH 05/11] spi/pxa2xx: make clock rate configurable from platform data

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 09 Jan 2013 23:07:26 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, eric.y.miao@...il.com,
	linux@....linux.org.uk, haojian.zhuang@...il.com,
	chao.bi@...el.com, "H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH 05/11] spi/pxa2xx: make clock rate configurable from platform data

On Wednesday, January 09, 2013 12:25:50 PM Mark Brown wrote:
> On Tue, Jan 08, 2013 at 10:33:55PM +0100, Rafael J. Wysocki wrote:
> > On 1/8/2013 2:10 PM, Mark Brown wrote:
> > >On Tue, Jan 08, 2013 at 02:41:53PM +0200, Mika Westerberg wrote:
> 
> > >>Do you mean enabling CONFIG_COMMON_CLK on x86?
> 
> > >Yes.
> 
> > Why so?  x86 doesn't have a notion of direct clock control, at least
> > not on the ACPI systems.
> 
> So, a couple of things here.  One is that your SFI systems *do* have
> user controllable clocks so they really should be using the clock API.

Well, fair enough.

> The other is that even if the CPU doesn't want to use clocks off-CPU
> devices may wish to - for example, a PCI card using off the shelf
> components or in this case a device on the SPI bus on the laptop which
> requires a clock and wants to manage it at runtime if possible.  We
> should be able to arrange things so that drivers can work with clocks
> using the standard clock API.  I'm really hopinng that having the clock
> API will eventually enable us to work with clocks in off-SoC devices but
> right now the only option is open coding.
> 
> > >I'm sure it's not beyond the bounds of possibility that we could solve
> > >this problem...
> 
> > No, it isn't.  Any suggestions?
> 
> Well, the most obvious solution would be to just hard code this
> information in the kernel and set it up based on what you do know.  For
> example if this is a SoC-internal clock then set it up based on knowing
> the SoC (this seems to be basically what Mika is suggesting).

Yes, it seems that we just happen to know the right value.  Sigh.

> > >It is something that needs to be resolved for your smartphone SoCs for
> 
> > We're not talking about smartphones and even not about SoCs here, sorry.
> 
> > This is a laptop CPU that happens to have an SPI controller integrated.
> 
> These are still x86 systems so are part of why it seems like a good idea
> to make the clock API available on x86.
> 
> > >this and for other things like platform data for external chips, what's
> > >actually happening in practical systems here is that people are just
> > >hacking the arch code as there's no mechanism for providing
> > >configuration at present.
> 
> > I'm not sure what you're referring to, but here we have ACPI as a
> > configuration mechanism.
> 
> > Which doesn't allow us to control clocks directly.
> 
> Right, and because the BIOS guys don't provide any mechanism for
> handling this stuff using the BIOS information what people actually
> deploying systems are doing is just hacking the arch code which gets us
> the worst of both worlds - we have to put things into the BIOS but we
> then have to put extra information into the kernel to actually make
> things functional.

We hardcode different kinds of information into the kernel anyway, but it
would be good to be able to use some criteria to decide whether or not we need
that information on the given system.

In this particular case, we'll only need the fixed clock rate for the SPI
which is not present on other x86 systems to date.

Mika, do you have any idea what checks to apply to figure out whether or not
the SPI clock will be necessary?

Perhaps we can add a check into acpi_create_platform_device()?  Something like
"if the device ID is present in table X, then run function Y for the device"
where Y will configure the clock if the SPI is matched?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/