| Message ID | 1403558626-13422-2-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | New |
| Headers | show |
On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > This branch moves code related to the Tegra fuses out of arch/arm and > into a centralized location which could be shared with ARM64. It also > adds support for reading the fuse data through sysfs. The new/moved misc driver isn't acked by any misc maintainer, so I can't take this branch. I saw no indication from searching the mailing list of that either, so it wasn't just a missed acked-by. I wonder if this code should go under drivers/soc/ instead? -Olof
On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > > This branch moves code related to the Tegra fuses out of arch/arm and > > into a centralized location which could be shared with ARM64. It also > > adds support for reading the fuse data through sysfs. > > The new/moved misc driver isn't acked by any misc maintainer, so I can't > take this branch. > > I saw no indication from searching the mailing list of that either, > so it wasn't just a missed acked-by. > > I wonder if this code should go under drivers/soc/ instead? It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. Originally this driver was also in drivers/misc/eeprom/, but Stephen objected and therefore it was moved to drivers/misc/fuse. I think that's the right place still. We anyway need this driver for sata and xhci. Cheers, Peter.
On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver <pdeschrijver@nvidia.com> wrote: > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >> > This branch moves code related to the Tegra fuses out of arch/arm and >> > into a centralized location which could be shared with ARM64. It also >> > adds support for reading the fuse data through sysfs. >> >> The new/moved misc driver isn't acked by any misc maintainer, so I can't >> take this branch. >> >> I saw no indication from searching the mailing list of that either, >> so it wasn't just a missed acked-by. >> >> I wonder if this code should go under drivers/soc/ instead? > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > and therefore it was moved to drivers/misc/fuse. I think that's the right > place still. I disagree, I think this belongs under drivers/soc. Especially since you're adding dependencies on this misc driver from other parts of the kernel / other drivers. I also don't like seeing init calls form platform code down into drivers/misc like you're adding here. Can you please look at doing that as a regular init call setup? The fact that you provide data to the rest of the kernel again really says drivers/soc to me, not drivers/misc. > We anyway need this driver for sata and xhci. Yes? -Olof
On Tue, Jul 08, 2014 at 07:47:16PM +0200, Olof Johansson wrote: > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > <pdeschrijver@nvidia.com> wrote: > > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > >> > This branch moves code related to the Tegra fuses out of arch/arm and > >> > into a centralized location which could be shared with ARM64. It also > >> > adds support for reading the fuse data through sysfs. > >> > >> The new/moved misc driver isn't acked by any misc maintainer, so I can't > >> take this branch. > >> > >> I saw no indication from searching the mailing list of that either, > >> so it wasn't just a missed acked-by. > >> > >> I wonder if this code should go under drivers/soc/ instead? > > > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > > and therefore it was moved to drivers/misc/fuse. I think that's the right > > place still. > > I disagree, I think this belongs under drivers/soc. Especially since > you're adding dependencies on this misc driver from other parts of the > kernel / other drivers. > There are several other drivers doing that already, eg: drivers/misc/eeprom/eeprom_93cx6.c drivers/misc/atmel-ssc.c drivers/misc/atmel_pwm.c > I also don't like seeing init calls form platform code down into > drivers/misc like you're adding here. Can you please look at doing > that as a regular init call setup? > Tegra has always avoided using the init calls and from previous versions of this patchset it's clear changing the init order is not an option for backwards compatibility reasons. Given that it seems to be impossible to reach consensus on what the exact behaviour should be, consider this patchset to be abandoned. Cheers, Peter.
On Wednesday 09 July 2014, Peter De Schrijver wrote: > On Tue, Jul 08, 2014 at 07:47:16PM +0200, Olof Johansson wrote: > > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > > <pdeschrijver@nvidia.com> wrote: > > > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > > >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > > >> > This branch moves code related to the Tegra fuses out of arch/arm and > > >> > into a centralized location which could be shared with ARM64. It also > > >> > adds support for reading the fuse data through sysfs. > > >> > > >> The new/moved misc driver isn't acked by any misc maintainer, so I can't > > >> take this branch. > > >> > > >> I saw no indication from searching the mailing list of that either, > > >> so it wasn't just a missed acked-by. > > >> > > >> I wonder if this code should go under drivers/soc/ instead? > > > > > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > > > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > > > and therefore it was moved to drivers/misc/fuse. I think that's the right > > > place still. > > > > I disagree, I think this belongs under drivers/soc. Especially since > > you're adding dependencies on this misc driver from other parts of the > > kernel / other drivers. > > > > There are several other drivers doing that already, eg: > > drivers/misc/eeprom/eeprom_93cx6.c > drivers/misc/atmel-ssc.c > drivers/misc/atmel_pwm.c I believe we have plans to remove the latter two. I don't know about the eeprom one. Arnd
On Tue, Jul 08, 2014 at 10:47:16AM -0700, Olof Johansson wrote: > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > <pdeschrijver@nvidia.com> wrote: > > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > >> > This branch moves code related to the Tegra fuses out of arch/arm and > >> > into a centralized location which could be shared with ARM64. It also > >> > adds support for reading the fuse data through sysfs. > >> > >> The new/moved misc driver isn't acked by any misc maintainer, so I can't > >> take this branch. > >> > >> I saw no indication from searching the mailing list of that either, > >> so it wasn't just a missed acked-by. > >> > >> I wonder if this code should go under drivers/soc/ instead? > > > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > > and therefore it was moved to drivers/misc/fuse. I think that's the right > > place still. > > I disagree, I think this belongs under drivers/soc. Especially since > you're adding dependencies on this misc driver from other parts of the > kernel / other drivers. > > I also don't like seeing init calls form platform code down into > drivers/misc like you're adding here. Can you please look at doing > that as a regular init call setup? > > The fact that you provide data to the rest of the kernel again really > says drivers/soc to me, not drivers/misc. Hi Olof, I just sent a patch series that addresses your comments: [PATCH 00/12] Add NVIDIA Tegra FUSE driver That contains a lot of the cleanup that I've been doing to get things ready for 64-bit. It's essentially what this pull request contained, with a couple of other patches on top to untangle the init sequence so that these can all go into regular init calls. I've tested on all four Tegra generations supported upstream. While there's possibly more that we can do I think it is a reasonable first step and I'd like to get this into 3.17 so that we can start moving out other things after the merge window. It would be great if you could have a look, and if there aren't any objections I'll send out another pull request. Thierry
On 07/08/2014 07:43 AM, Peter De Schrijver wrote: > On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>> This branch moves code related to the Tegra fuses out of arch/arm and >>> into a centralized location which could be shared with ARM64. It also >>> adds support for reading the fuse data through sysfs. >> >> The new/moved misc driver isn't acked by any misc maintainer, so I can't >> take this branch. >> >> I saw no indication from searching the mailing list of that either, >> so it wasn't just a missed acked-by. >> >> I wonder if this code should go under drivers/soc/ instead? > > It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > and therefore it was moved to drivers/misc/fuse. I think that's the right > place still. We anyway need this driver for sata and xhci. Sigh. This is exactly why (a) I suggested during that thread that the driver should be in drivers/soc not drivers/misc and (b) I sent the pull requests early enough so I could deal with any objections before my vacation:-( I wish people would just respond to my review comments by implementing them rather than persuading me to do the wrong thing. Since this is all a dependency for pretty much everything for Tegra for 3.17, I guess we should just drop all the Tegra pull requests for 3.17 and we'll have to redo all the patches for 3.18:-( But if Thierry can (or already has in another thread I haven't seen while on vacation) sort this out be redoing all the Tegra branches, that might be fine too.
On 07/08/2014 11:47 AM, Olof Johansson wrote: > On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > <pdeschrijver@nvidia.com> wrote: >> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>> into a centralized location which could be shared with ARM64. It also >>>> adds support for reading the fuse data through sysfs. >>> >>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>> take this branch. >>> >>> I saw no indication from searching the mailing list of that either, >>> so it wasn't just a missed acked-by. >>> >>> I wonder if this code should go under drivers/soc/ instead? >> >> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >> and therefore it was moved to drivers/misc/fuse. I think that's the right >> place still. > > I disagree, I think this belongs under drivers/soc. Especially since > you're adding dependencies on this misc driver from other parts of the > kernel / other drivers. > > I also don't like seeing init calls form platform code down into > drivers/misc like you're adding here. Can you please look at doing > that as a regular init call setup? I strongly disagree with using init calls for this kind of thing. There are ordering dependencies between the initialization code that can only be sanely managed by explicitly calling functions in a particular order; there's simply no way to manage this using initcalls. This is exactly why the hooks in the ARM machine descriptors exist...
On Thu, Jul 17, 2014 at 7:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/08/2014 07:43 AM, Peter De Schrijver wrote: >> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>> into a centralized location which could be shared with ARM64. It also >>>> adds support for reading the fuse data through sysfs. >>> >>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>> take this branch. >>> >>> I saw no indication from searching the mailing list of that either, >>> so it wasn't just a missed acked-by. >>> >>> I wonder if this code should go under drivers/soc/ instead? >> >> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >> and therefore it was moved to drivers/misc/fuse. I think that's the right >> place still. We anyway need this driver for sata and xhci. > > Sigh. This is exactly why (a) I suggested during that thread that the > driver should be in drivers/soc not drivers/misc and (b) I sent the pull > requests early enough so I could deal with any objections before my > vacation:-( I wish people would just respond to my review comments by > implementing them rather than persuading me to do the wrong thing. Since > this is all a dependency for pretty much everything for Tegra for 3.17, > I guess we should just drop all the Tegra pull requests for 3.17 and > we'll have to redo all the patches for 3.18:-( But if Thierry can (or > already has in another thread I haven't seen while on vacation) sort > this out be redoing all the Tegra branches, that might be fine too. Thierry has been following up on it, I don't think we're too late for 3.17 yet. -Olof
On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/08/2014 11:47 AM, Olof Johansson wrote: >> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >> <pdeschrijver@nvidia.com> wrote: >>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>> into a centralized location which could be shared with ARM64. It also >>>>> adds support for reading the fuse data through sysfs. >>>> >>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>> take this branch. >>>> >>>> I saw no indication from searching the mailing list of that either, >>>> so it wasn't just a missed acked-by. >>>> >>>> I wonder if this code should go under drivers/soc/ instead? >>> >>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>> place still. >> >> I disagree, I think this belongs under drivers/soc. Especially since >> you're adding dependencies on this misc driver from other parts of the >> kernel / other drivers. >> >> I also don't like seeing init calls form platform code down into >> drivers/misc like you're adding here. Can you please look at doing >> that as a regular init call setup? > > I strongly disagree with using init calls for this kind of thing. There > are ordering dependencies between the initialization code that can only > be sanely managed by explicitly calling functions in a particular order; > there's simply no way to manage this using initcalls. This is exactly > why the hooks in the ARM machine descriptors exist... Right, but there are non on 64-bit, so you need to solve it for there anyway. And once it's solved there, you might as well keep it common with 32-bit. -Olof
On 07/17/2014 11:33 PM, Olof Johansson wrote: > On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >> On 07/08/2014 11:47 AM, Olof Johansson wrote: >>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >>> <pdeschrijver@nvidia.com> wrote: >>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>>> into a centralized location which could be shared with ARM64. It also >>>>>> adds support for reading the fuse data through sysfs. >>>>> >>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>>> take this branch. >>>>> >>>>> I saw no indication from searching the mailing list of that either, >>>>> so it wasn't just a missed acked-by. >>>>> >>>>> I wonder if this code should go under drivers/soc/ instead? >>>> >>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>>> place still. >>> >>> I disagree, I think this belongs under drivers/soc. Especially since >>> you're adding dependencies on this misc driver from other parts of the >>> kernel / other drivers. >>> >>> I also don't like seeing init calls form platform code down into >>> drivers/misc like you're adding here. Can you please look at doing >>> that as a regular init call setup? >> >> I strongly disagree with using init calls for this kind of thing. There >> are ordering dependencies between the initialization code that can only >> be sanely managed by explicitly calling functions in a particular order; >> there's simply no way to manage this using initcalls. This is exactly >> why the hooks in the ARM machine descriptors exist... > > Right, but there are non on 64-bit, so you need to solve it for there > anyway. And once it's solved there, you might as well keep it common > with 32-bit. My assertion is that we should just do it directly on 64-bit too. There's no reason for arm64 to deviate from what arch/arm does already.
On Mon, Jul 21, 2014 at 09:06:00AM -0600, Stephen Warren wrote: > On 07/17/2014 11:33 PM, Olof Johansson wrote: > > On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > >> On 07/08/2014 11:47 AM, Olof Johansson wrote: > >>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver > >>> <pdeschrijver@nvidia.com> wrote: > >>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: > >>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: > >>>>>> This branch moves code related to the Tegra fuses out of arch/arm and > >>>>>> into a centralized location which could be shared with ARM64. It also > >>>>>> adds support for reading the fuse data through sysfs. > >>>>> > >>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't > >>>>> take this branch. > >>>>> > >>>>> I saw no indication from searching the mailing list of that either, > >>>>> so it wasn't just a missed acked-by. > >>>>> > >>>>> I wonder if this code should go under drivers/soc/ instead? > >>>> > >>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. > >>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected > >>>> and therefore it was moved to drivers/misc/fuse. I think that's the right > >>>> place still. > >>> > >>> I disagree, I think this belongs under drivers/soc. Especially since > >>> you're adding dependencies on this misc driver from other parts of the > >>> kernel / other drivers. > >>> > >>> I also don't like seeing init calls form platform code down into > >>> drivers/misc like you're adding here. Can you please look at doing > >>> that as a regular init call setup? > >> > >> I strongly disagree with using init calls for this kind of thing. There > >> are ordering dependencies between the initialization code that can only > >> be sanely managed by explicitly calling functions in a particular order; > >> there's simply no way to manage this using initcalls. This is exactly > >> why the hooks in the ARM machine descriptors exist... > > > > Right, but there are non on 64-bit, so you need to solve it for there > > anyway. And once it's solved there, you might as well keep it common > > with 32-bit. > > My assertion is that we should just do it directly on 64-bit too. > There's no reason for arm64 to deviate from what arch/arm does already. On arm64, I really want to get away from any SoC specific early initcall. One of the main reason is for things like SCU, interconnects, system cache configurations (even certain clocks) to be enabled in firmware before Linux starts (it's an education process but that's a way for example to prevent people sending patches to enable SoC coherency because they haven't thought about it before upstreaming). It would be nice to be able to initialise SoC stuff at device_initcall() level (and even keep such code as modules in initramfs) but one of the problems we have is dependency on clocks (and the clock model which doesn't follow the device/driver model). The of_platform_populate() is called at arch_initcall_sync (after arch_initcall to still allow some SoC code, if needed, to run at arch_initcall). We have a similar issue with arm64 vexpress (well, just on the model) where vexpress_sysreg_init() is a core_initcall (should be fine as arch_initcall) as it needs to be done before of_platform_populate(). Pawel on cc should know more of the history here. I recall there were also some discussions about a SoC driver model which hangs off the top compatible string in the DT (e.g. "arm,vexpress") and allow (minimal) code to be run slightly earlier, though still not earlier than arch_initcall.
On Mon, 2014-07-21 at 16:54 +0100, Catalin Marinas wrote: > We have a similar issue with arm64 vexpress (well, just on the model) > where vexpress_sysreg_init() is a core_initcall (should be fine as > arch_initcall) as it needs to be done before of_platform_populate(). > Pawel on cc should know more of the history here. In case of vexpress the trick was to squeeze everything into the device model. Once this was done, there was enough initcall levels to get all dependencies sorted. The device model is good. We seemed to have learned to abuse it claiming that "things must be initialised early", while in 9 out of 10 cases they don't have to be "that early"... > I recall there were also some discussions about a SoC driver model which > hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > allow (minimal) code to be run slightly earlier, though still not > earlier than arch_initcall. This was just a loose idea: http://thread.gmane.org/gmane.linux.ports.arm.kernel/204361/focus=204843 I still like it, and it seems logical to me. We've got a platform. It's got a compatible string. We can write a driver for this platform that does all magic at appropriate initcall level. Paweł
On 07/21/2014 09:54 AM, Catalin Marinas wrote: > On Mon, Jul 21, 2014 at 09:06:00AM -0600, Stephen Warren wrote: >> On 07/17/2014 11:33 PM, Olof Johansson wrote: >>> On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>> On 07/08/2014 11:47 AM, Olof Johansson wrote: >>>>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >>>>> <pdeschrijver@nvidia.com> wrote: >>>>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>>>>> into a centralized location which could be shared with ARM64. It also >>>>>>>> adds support for reading the fuse data through sysfs. >>>>>>> >>>>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>>>>> take this branch. >>>>>>> >>>>>>> I saw no indication from searching the mailing list of that either, >>>>>>> so it wasn't just a missed acked-by. >>>>>>> >>>>>>> I wonder if this code should go under drivers/soc/ instead? >>>>>> >>>>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>>>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>>>>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>>>>> place still. >>>>> >>>>> I disagree, I think this belongs under drivers/soc. Especially since >>>>> you're adding dependencies on this misc driver from other parts of the >>>>> kernel / other drivers. >>>>> >>>>> I also don't like seeing init calls form platform code down into >>>>> drivers/misc like you're adding here. Can you please look at doing >>>>> that as a regular init call setup? >>>> >>>> I strongly disagree with using init calls for this kind of thing. There >>>> are ordering dependencies between the initialization code that can only >>>> be sanely managed by explicitly calling functions in a particular order; >>>> there's simply no way to manage this using initcalls. This is exactly >>>> why the hooks in the ARM machine descriptors exist... >>> >>> Right, but there are non on 64-bit, so you need to solve it for there >>> anyway. And once it's solved there, you might as well keep it common >>> with 32-bit. >> >> My assertion is that we should just do it directly on 64-bit too. >> There's no reason for arm64 to deviate from what arch/arm does already. > > On arm64, I really want to get away from any SoC specific early > initcall. One of the main reason is for things like SCU, interconnects, > system cache configurations (even certain clocks) to be enabled in > firmware before Linux starts (it's an education process but that's a way > for example to prevent people sending patches to enable SoC coherency > because they haven't thought about it before upstreaming). > > It would be nice to be able to initialise SoC stuff at device_initcall() > level (and even keep such code as modules in initramfs) but one of the > problems we have is dependency on clocks (and the clock model which > doesn't follow the device/driver model). The of_platform_populate() is > called at arch_initcall_sync (after arch_initcall to still allow some > SoC code, if needed, to run at arch_initcall). The main thing I want to avoid is a ton of separate drivers that all rely on each-other getting resolved by deferred probe. While that might work out, it seems pointless to make the kernel try and probe a bunch of stuff just to have it fail and get repeated, when we know exactly which order everything should get initialized in. Another issue is that we have SoCs which only differ in the CPU. I want the code to work identically on both SoCs so the CPU has limited affect on the low-level IO code. If we're going to enforce a "no machine descriptors" rule on arch/arm64, I think we should do the same thing in arch/arm for consistency. > We have a similar issue with arm64 vexpress (well, just on the model) > where vexpress_sysreg_init() is a core_initcall (should be fine as > arch_initcall) as it needs to be done before of_platform_populate(). > Pawel on cc should know more of the history here. > > I recall there were also some discussions about a SoC driver model which > hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > allow (minimal) code to be run slightly earlier, though still not > earlier than arch_initcall. I guess that would work out OK; if we force the driver that binds to a top-level compatible value of "nvidia,tegraNNN" to probe first, and it then calls out to all the low-level init code in a sane order, that would solve the problem. I'm not sure that's any better than having a machine descriptor with an "init" function though; wrapping all this in a driver just seems like overhead, but it would work out OK.
On Mon, Jul 21, 2014 at 9:38 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/21/2014 09:54 AM, Catalin Marinas wrote: >> On Mon, Jul 21, 2014 at 09:06:00AM -0600, Stephen Warren wrote: >>> On 07/17/2014 11:33 PM, Olof Johansson wrote: >>>> On Thu, Jul 17, 2014 at 7:45 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: >>>>> On 07/08/2014 11:47 AM, Olof Johansson wrote: >>>>>> On Tue, Jul 8, 2014 at 6:43 AM, Peter De Schrijver >>>>>> <pdeschrijver@nvidia.com> wrote: >>>>>>> On Mon, Jul 07, 2014 at 02:44:17AM +0200, Olof Johansson wrote: >>>>>>>> On Mon, Jun 23, 2014 at 03:23:45PM -0600, Stephen Warren wrote: >>>>>>>>> This branch moves code related to the Tegra fuses out of arch/arm and >>>>>>>>> into a centralized location which could be shared with ARM64. It also >>>>>>>>> adds support for reading the fuse data through sysfs. >>>>>>>> >>>>>>>> The new/moved misc driver isn't acked by any misc maintainer, so I can't >>>>>>>> take this branch. >>>>>>>> >>>>>>>> I saw no indication from searching the mailing list of that either, >>>>>>>> so it wasn't just a missed acked-by. >>>>>>>> >>>>>>>> I wonder if this code should go under drivers/soc/ instead? >>>>>>> >>>>>>> It's modelled after sunxi_sid.c which lives in drivers/misc/eeprom/. >>>>>>> Originally this driver was also in drivers/misc/eeprom/, but Stephen objected >>>>>>> and therefore it was moved to drivers/misc/fuse. I think that's the right >>>>>>> place still. >>>>>> >>>>>> I disagree, I think this belongs under drivers/soc. Especially since >>>>>> you're adding dependencies on this misc driver from other parts of the >>>>>> kernel / other drivers. >>>>>> >>>>>> I also don't like seeing init calls form platform code down into >>>>>> drivers/misc like you're adding here. Can you please look at doing >>>>>> that as a regular init call setup? >>>>> >>>>> I strongly disagree with using init calls for this kind of thing. There >>>>> are ordering dependencies between the initialization code that can only >>>>> be sanely managed by explicitly calling functions in a particular order; >>>>> there's simply no way to manage this using initcalls. This is exactly >>>>> why the hooks in the ARM machine descriptors exist... >>>> >>>> Right, but there are non on 64-bit, so you need to solve it for there >>>> anyway. And once it's solved there, you might as well keep it common >>>> with 32-bit. >>> >>> My assertion is that we should just do it directly on 64-bit too. >>> There's no reason for arm64 to deviate from what arch/arm does already. >> >> On arm64, I really want to get away from any SoC specific early >> initcall. One of the main reason is for things like SCU, interconnects, >> system cache configurations (even certain clocks) to be enabled in >> firmware before Linux starts (it's an education process but that's a way >> for example to prevent people sending patches to enable SoC coherency >> because they haven't thought about it before upstreaming). >> >> It would be nice to be able to initialise SoC stuff at device_initcall() >> level (and even keep such code as modules in initramfs) but one of the >> problems we have is dependency on clocks (and the clock model which >> doesn't follow the device/driver model). The of_platform_populate() is >> called at arch_initcall_sync (after arch_initcall to still allow some >> SoC code, if needed, to run at arch_initcall). > > The main thing I want to avoid is a ton of separate drivers that all > rely on each-other getting resolved by deferred probe. While that might > work out, it seems pointless to make the kernel try and probe a bunch of > stuff just to have it fail and get repeated, when we know exactly which > order everything should get initialized in. > > Another issue is that we have SoCs which only differ in the CPU. I want > the code to work identically on both SoCs so the CPU has limited affect > on the low-level IO code. If we're going to enforce a "no machine > descriptors" rule on arch/arm64, I think we should do the same thing in > arch/arm for consistency. > >> We have a similar issue with arm64 vexpress (well, just on the model) >> where vexpress_sysreg_init() is a core_initcall (should be fine as >> arch_initcall) as it needs to be done before of_platform_populate(). >> Pawel on cc should know more of the history here. >> >> I recall there were also some discussions about a SoC driver model which >> hangs off the top compatible string in the DT (e.g. "arm,vexpress") and >> allow (minimal) code to be run slightly earlier, though still not >> earlier than arch_initcall. > > I guess that would work out OK; if we force the driver that binds to a > top-level compatible value of "nvidia,tegraNNN" to probe first, and it > then calls out to all the low-level init code in a sane order, that > would solve the problem. I'm not sure that's any better than having a > machine descriptor with an "init" function though; wrapping all this in > a driver just seems like overhead, but it would work out OK. This is exactly the same as having a machine descriptor, but the arch/arm64 maintainers don't have to look at it so they don't think it is one. So now we need to find a place for machine descriptors somewhere under drivers/* too. Sigh. Agreed, this is nothing but overhead and overabstraction. -Olof
On Mon, Jul 21, 2014 at 05:46:02PM +0100, Olof Johansson wrote: > On Mon, Jul 21, 2014 at 9:38 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > > On 07/21/2014 09:54 AM, Catalin Marinas wrote: > >> We have a similar issue with arm64 vexpress (well, just on the model) > >> where vexpress_sysreg_init() is a core_initcall (should be fine as > >> arch_initcall) as it needs to be done before of_platform_populate(). > >> Pawel on cc should know more of the history here. > >> > >> I recall there were also some discussions about a SoC driver model which > >> hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > >> allow (minimal) code to be run slightly earlier, though still not > >> earlier than arch_initcall. > > > > I guess that would work out OK; if we force the driver that binds to a > > top-level compatible value of "nvidia,tegraNNN" to probe first, and it > > then calls out to all the low-level init code in a sane order, that > > would solve the problem. I'm not sure that's any better than having a > > machine descriptor with an "init" function though; wrapping all this in > > a driver just seems like overhead, but it would work out OK. > > This is exactly the same as having a machine descriptor, but the > arch/arm64 maintainers don't have to look at it so they don't think it > is one. > > So now we need to find a place for machine descriptors somewhere under > drivers/* too. Sigh. Agreed, this is nothing but overhead and > overabstraction. You are missing the point. It's not the machine descriptor (or mach-* directories) I want to hide but rather the need for early SoC specific initialisation. Always providing a machine descriptor with hooks for early SoC initialisation does not provide any incentive for people to think properly about what's early hardware configuration (usually done by firmware), what's actually needed for CPU booting (SoC-independent with a secondary booting protocol selectable from a small set) and how the rest of the SoC fits with the Linux device model. It's also aimed at pushing back on hardware people who think they can mess up, for example, a GIC implementation because the rest is just software and you can always add #ifdefs. On 32-bit ARM this was not always possible (non-standard essential peripherals like IRQ controller, timers) but with arm64 we have the things needed to be able to boot an SoC to arch_initcall level without any early hooks. I agree that on occasion we may need some early SoC code just because of some (bad) hardware design or simply to work around firmware/hardware bugs (and Pawel's patch is a nice approach). But this should definitely not be the norm and I disagree with moving entire arch/arm/mach-* code to drivers/soc just because one can't decide where early SoC initialisation belongs to. Also the legacy firmware argument doesn't hold for ARMv8/arm64 since the CPU now starts at EL3 in AArch64 mode and you need code there before Linux is invoked (at EL2 or EL1). In the Tegra fuse case, it's not actually some hardware configuration that needs to be set up early but rather a driver dependency initialisation which is not (cannot be) handled by the DT. This is not that different from the vexpress sysregs mfd where we worked around using an initcall. It's not ideal, I would prefer something simpler like sibling DT node sorting during unflattening (or maybe addressing issues with deferred probing if there are any) rather than working around it using machine_desc.
On Mon, Jul 21, 2014 at 05:38:25PM +0100, Stephen Warren wrote: > On 07/21/2014 09:54 AM, Catalin Marinas wrote: > > On arm64, I really want to get away from any SoC specific early > > initcall. One of the main reason is for things like SCU, interconnects, > > system cache configurations (even certain clocks) to be enabled in > > firmware before Linux starts (it's an education process but that's a way > > for example to prevent people sending patches to enable SoC coherency > > because they haven't thought about it before upstreaming). > > > > It would be nice to be able to initialise SoC stuff at device_initcall() > > level (and even keep such code as modules in initramfs) but one of the > > problems we have is dependency on clocks (and the clock model which > > doesn't follow the device/driver model). The of_platform_populate() is > > called at arch_initcall_sync (after arch_initcall to still allow some > > SoC code, if needed, to run at arch_initcall). > > The main thing I want to avoid is a ton of separate drivers that all > rely on each-other getting resolved by deferred probe. While that might > work out, it seems pointless to make the kernel try and probe a bunch of > stuff just to have it fail and get repeated, when we know exactly which > order everything should get initialized in. So of_platform_populate() is called at arch_initcall_sync() level on arm64. This allows at least two levels of probing separation before (e.g. drivers registered as arch_initcall) and after (device_initcall). If you register a driver earlier than arch_initcall_sync (see for example vexpress_osc_init), it will get probed when the platform devices are populated. Any later device_initcalls will get probed when the corresponding drivers are registered. If you need ordering between device_initcalls, I would recommend deferred probing. The tricky part is if you need more drivers to be initialised at arch_initcall_sync() in a specific order. Here it looks like the node ordering in DT has an effect on probing. I don't say the DT should list them in the order they should be probed but maybe we can improve the model and do some sorting during unflattening (as I suggested in my reply to Olof). In the meantime, for vexpress we worked around it by explicitly checking the compatible node during a pre-arch_initcall. > Another issue is that we have SoCs which only differ in the CPU. Do you mean ARMv7 vs ARMv8 CPUs? > I want > the code to work identically on both SoCs so the CPU has limited affect > on the low-level IO code. If we're going to enforce a "no machine > descriptors" rule on arch/arm64, I think we should do the same thing in > arch/arm for consistency. We've done this with vexpress thanks to Pawel. As he said, the difficult part was converting the existing code to the Linux device model. The 32-bit v2m_dt_init() function simply calls of_platform_populate(). If you don't have a machine_desc at all, this would be the default (see customize_machine()). If you use PSCI, there is no need for SoC specific smp_ops either. So you basically get the same code base with no additional arch/arm/mach-* machine_desc. > > We have a similar issue with arm64 vexpress (well, just on the model) > > where vexpress_sysreg_init() is a core_initcall (should be fine as > > arch_initcall) as it needs to be done before of_platform_populate(). > > Pawel on cc should know more of the history here. > > > > I recall there were also some discussions about a SoC driver model which > > hangs off the top compatible string in the DT (e.g. "arm,vexpress") and > > allow (minimal) code to be run slightly earlier, though still not > > earlier than arch_initcall. > > I guess that would work out OK; if we force the driver that binds to a > top-level compatible value of "nvidia,tegraNNN" to probe first, and it > then calls out to all the low-level init code in a sane order, that > would solve the problem. I'm not sure that's any better than having a > machine descriptor with an "init" function though; wrapping all this in > a driver just seems like overhead, but it would work out OK. Looking at the tegra_init_early(), I think for arm64 as pre-arch_initcall_sync you would only need: tegra_init_fuse(); tegra_powergate_init(); (I'm not sure about trusted foundations but that's a 32-bit only project for the time being) >From tegra_dt_init() you need clocks but isn't CLK_OF_DECLARE enough? You also have PMC code and I'm not familiar with your implementation. A lot of the functionality could be moved to PSCI-capable firmware.
On 07/22/2014 05:26 AM, Catalin Marinas wrote: > On Mon, Jul 21, 2014 at 05:38:25PM +0100, Stephen Warren wrote: >> On 07/21/2014 09:54 AM, Catalin Marinas wrote: >>> On arm64, I really want to get away from any SoC specific early >>> initcall. One of the main reason is for things like SCU, interconnects, >>> system cache configurations (even certain clocks) to be enabled in >>> firmware before Linux starts (it's an education process but that's a way >>> for example to prevent people sending patches to enable SoC coherency >>> because they haven't thought about it before upstreaming). >>> >>> It would be nice to be able to initialise SoC stuff at device_initcall() >>> level (and even keep such code as modules in initramfs) but one of the >>> problems we have is dependency on clocks (and the clock model which >>> doesn't follow the device/driver model). The of_platform_populate() is >>> called at arch_initcall_sync (after arch_initcall to still allow some >>> SoC code, if needed, to run at arch_initcall). >> >> The main thing I want to avoid is a ton of separate drivers that all >> rely on each-other getting resolved by deferred probe. While that might >> work out, it seems pointless to make the kernel try and probe a bunch of >> stuff just to have it fail and get repeated, when we know exactly which >> order everything should get initialized in. > > So of_platform_populate() is called at arch_initcall_sync() level on > arm64. This allows at least two levels of probing separation before > (e.g. drivers registered as arch_initcall) and after (device_initcall). > If you register a driver earlier than arch_initcall_sync (see for > example vexpress_osc_init), it will get probed when the platform devices > are populated. Any later device_initcalls will get probed when the > corresponding drivers are registered. If you need ordering between > device_initcalls, I would recommend deferred probing. > > The tricky part is if you need more drivers to be initialised at > arch_initcall_sync() in a specific order. I believe relying on initcall ordering, even in the case where there are enough initcall levels to achieve a particular SoC's needs, is completely and utterly the wrong way to go. Or at least, that's what the mantra has been for arch/arm for the last few years. There's been plenty of active work to get away from initcalls. Why should arch/arm64 be any different? Some consistency of maintainer viewpoints would be nice. (Note that I'm talking here about lots of separate initcalls that only work in the right order due to manually assigning them initcall levels that happen to work in the right order. Having a single initcall function that explicitly calls all other initialization functions in the right order is entirely different) Disadvantages of using initcalls are: * Not enough levels, so it's not generic/scalable. * If you need to re-order things, you need to change the initcall level of a bunch of stuff before/after it. This isn't scalable. * It's hard to track them all down. Admittedly grep works, but that's a lot more painful than just reading a function that calls other functions explicitly. * Each initcall has to determine if it's running on the correct HW or not, rather than doing it once in a single top-level initcall, or in a hook that only gets called at the right time. ... >> Another issue is that we have SoCs which only differ in the CPU. > > Do you mean ARMv7 vs ARMv8 CPUs? Yes.
On 07/22/2014 04:27 AM, Catalin Marinas wrote: ... > ...It's also aimed at > pushing back on hardware people who think they can mess up, for example, > a GIC implementation because the rest is just software and you can > always add #ifdefs. I'm very concerned about this statement. Yes, it would be nice if all HW was sanely designed, but it's not always. The time to push back on bad HW design is during IP licensing agreements or HW design reviews, not upstreaming. Any pushback during SW upstreaming simply serves to make it difficult for the SW people doing the upstreaming. It has zero impact on the current HW design (it's already shipped). It probably has zero impact on the next N revisions of the HW (they're already baked). It's possible it has zero-to-minimal impact on any future HW (end-user product requirements are what matter most).
On Tue, Jul 22, 2014 at 05:27:25PM +0100, Stephen Warren wrote: > On 07/22/2014 04:27 AM, Catalin Marinas wrote: > ... > > ...It's also aimed at > > pushing back on hardware people who think they can mess up, for example, > > a GIC implementation because the rest is just software and you can > > always add #ifdefs. > > I'm very concerned about this statement. > > Yes, it would be nice if all HW was sanely designed, but it's not > always. The time to push back on bad HW design is during IP licensing > agreements or HW design reviews, not upstreaming. I agree about the HW design reviews. But I suspect some software people in such companies, concerned with upstreaming Linux support, are allowed to give feedback. And the feedback could be something like (just an example) "if we use a standard GIC and the architected timer, sane (!PL310-like) system caches, we get the benefit of no additional upstream work, better virtualisation support etc". I hope someone in the HW team would take such feedback into account rather than assume that software and upstreaming comes for free. Of course, we've never rejected Linux upstreaming because of the hardware design (well, as long as Linux could reliably run on it) and I don't plan to do this in the future, but just show that there are clear benefits in doing something in a more standardised way (e.g. SBSA for servers). Even though ARM licenses the architecture, there is no way to enforce a HW design as part of the agreement (or risk not licensing the IP at all). But there is effort to standardise things like SBSA, Trusted Firmware. > Any pushback during SW upstreaming simply serves to make it difficult > for the SW people doing the upstreaming. It has zero impact on the > current HW design (it's already shipped). It probably has zero impact on > the next N revisions of the HW (they're already baked). It's possible it > has zero-to-minimal impact on any future HW (end-user product > requirements are what matter most). I agree that pushing back during SW upstreaming is very late. But I hope to raise the awareness earlier for ARMv8 hardware.
On Tue, Jul 22, 2014 at 05:22:09PM +0100, Stephen Warren wrote: > On 07/22/2014 05:26 AM, Catalin Marinas wrote: > > On Mon, Jul 21, 2014 at 05:38:25PM +0100, Stephen Warren wrote: > >> On 07/21/2014 09:54 AM, Catalin Marinas wrote: > >>> On arm64, I really want to get away from any SoC specific early > >>> initcall. One of the main reason is for things like SCU, interconnects, > >>> system cache configurations (even certain clocks) to be enabled in > >>> firmware before Linux starts (it's an education process but that's a way > >>> for example to prevent people sending patches to enable SoC coherency > >>> because they haven't thought about it before upstreaming). > >>> > >>> It would be nice to be able to initialise SoC stuff at device_initcall() > >>> level (and even keep such code as modules in initramfs) but one of the > >>> problems we have is dependency on clocks (and the clock model which > >>> doesn't follow the device/driver model). The of_platform_populate() is > >>> called at arch_initcall_sync (after arch_initcall to still allow some > >>> SoC code, if needed, to run at arch_initcall). > >> > >> The main thing I want to avoid is a ton of separate drivers that all > >> rely on each-other getting resolved by deferred probe. While that might > >> work out, it seems pointless to make the kernel try and probe a bunch of > >> stuff just to have it fail and get repeated, when we know exactly which > >> order everything should get initialized in. > > > > So of_platform_populate() is called at arch_initcall_sync() level on > > arm64. This allows at least two levels of probing separation before > > (e.g. drivers registered as arch_initcall) and after (device_initcall). > > If you register a driver earlier than arch_initcall_sync (see for > > example vexpress_osc_init), it will get probed when the platform devices > > are populated. Any later device_initcalls will get probed when the > > corresponding drivers are registered. If you need ordering between > > device_initcalls, I would recommend deferred probing. > > > > The tricky part is if you need more drivers to be initialised at > > arch_initcall_sync() in a specific order. > > I believe relying on initcall ordering, even in the case where there are > enough initcall levels to achieve a particular SoC's needs, is > completely and utterly the wrong way to go. I don't like it either and I agree that there may not be enough initcalls. But I'm ok with using two levels like arch_initcall() for something like fuse and device_initcall() for the rest. If that's not enough (I haven't looked in detail at Tegra), with Pawel's patch you can get a SoC specific probe where you can call the initialisation in the right order. Tegra is not the first nor the last platform with such issue. Is there anything we could do better at the DT or driver registration level (other than introducing machine_desc)?
This branch moves code related to the Tegra fuses out of arch/arm and into a centralized location which could be shared with ARM64. It also adds support for reading the fuse data through sysfs. This is a separate branch because it will be a dependency for the upcoming XUSB padctrl driver, which is in turn a dependency for Tegra124 SATA, XHCI, and PCIe support. ---------------------------------------------------------------- The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tegra-for-3.17-fuse-move for you to fetch changes up to d97f79366c566b2986cf6a142eb4d04a6eb4e970: misc: fuse: fix dummy functions ---------------------------------------------------------------- Peter De Schrijver (6): ARM: tegra: export apb dma readl/writel ARM: tegra: move fuse exports to tegra-soc.h misc: fuse: Add efuse driver for Tegra ARM: tegra: Add efuse and apbmisc bindings ARM: tegra: build new fuse driver in drivers/misc misc: fuse: move APB DMA into Tegra20 fuse driver Stephen Warren (1): misc: fuse: fix dummy functions .../ABI/testing/sysfs-driver-tegra-fuse | 11 + .../bindings/fuse/nvidia,tegra20-fuse.txt | 40 +++ .../bindings/misc/nvidia,tegra20-apbmisc.txt | 13 + arch/arm/boot/dts/tegra114.dtsi | 15 ++ arch/arm/boot/dts/tegra124.dtsi | 15 ++ arch/arm/boot/dts/tegra20.dtsi | 15 ++ arch/arm/boot/dts/tegra30.dtsi | 15 ++ arch/arm/mach-tegra/Makefile | 5 - arch/arm/mach-tegra/apbio.c | 206 --------------- arch/arm/mach-tegra/apbio.h | 22 -- arch/arm/mach-tegra/cpuidle.c | 2 +- arch/arm/mach-tegra/flowctrl.c | 2 +- arch/arm/mach-tegra/fuse.c | 252 ------------------- arch/arm/mach-tegra/fuse.h | 79 ------ arch/arm/mach-tegra/hotplug.c | 2 +- arch/arm/mach-tegra/platsmp.c | 2 +- arch/arm/mach-tegra/pm.c | 2 +- arch/arm/mach-tegra/pmc.c | 2 +- arch/arm/mach-tegra/powergate.c | 2 +- arch/arm/mach-tegra/reset-handler.S | 2 +- arch/arm/mach-tegra/reset.c | 2 +- arch/arm/mach-tegra/sleep-tegra30.S | 2 +- arch/arm/mach-tegra/tegra.c | 7 +- drivers/misc/Makefile | 1 + drivers/misc/fuse/Makefile | 1 + drivers/misc/fuse/tegra/Makefile | 8 + drivers/misc/fuse/tegra/fuse-tegra.c | 154 ++++++++++++ drivers/misc/fuse/tegra/fuse-tegra20.c | 214 ++++++++++++++++ drivers/misc/fuse/tegra/fuse-tegra30.c | 223 ++++++++++++++++ drivers/misc/fuse/tegra/fuse.h | 71 ++++++ .../misc/fuse/tegra/speedo-tegra114.c | 53 ++-- drivers/misc/fuse/tegra/speedo-tegra124.c | 167 ++++++++++++ .../misc/fuse/tegra/speedo-tegra20.c | 42 ++-- .../misc/fuse/tegra/speedo-tegra30.c | 173 +++++++------ drivers/misc/fuse/tegra/tegra-apbmisc.c | 110 ++++++++ include/linux/tegra-soc.h | 42 ++++ 36 files changed, 1262 insertions(+), 712 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-driver-tegra-fuse create mode 100644 Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt delete mode 100644 arch/arm/mach-tegra/apbio.c delete mode 100644 arch/arm/mach-tegra/apbio.h delete mode 100644 arch/arm/mach-tegra/fuse.c delete mode 100644 arch/arm/mach-tegra/fuse.h create mode 100644 drivers/misc/fuse/Makefile create mode 100644 drivers/misc/fuse/tegra/Makefile create mode 100644 drivers/misc/fuse/tegra/fuse-tegra.c create mode 100644 drivers/misc/fuse/tegra/fuse-tegra20.c create mode 100644 drivers/misc/fuse/tegra/fuse-tegra30.c create mode 100644 drivers/misc/fuse/tegra/fuse.h rename arch/arm/mach-tegra/tegra114_speedo.c => drivers/misc/fuse/tegra/speedo-tegra114.c (55%) create mode 100644 drivers/misc/fuse/tegra/speedo-tegra124.c rename arch/arm/mach-tegra/tegra20_speedo.c => drivers/misc/fuse/tegra/speedo-tegra20.c (67%) rename arch/arm/mach-tegra/tegra30_speedo.c => drivers/misc/fuse/tegra/speedo-tegra30.c (52%) create mode 100644 drivers/misc/fuse/tegra/tegra-apbmisc.c