linux-kernel - Re: [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161216191951.GC44199@f23x64.localdomain>
Date:   Fri, 16 Dec 2016 11:19:51 -0800
From:   Darren Hart <dvhart@...radead.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Irina Tirdea <irina.tirdea@...el.com>,
        linux-clk@...r.kernel.org, "x86@...nel.org" <x86@...nel.org>,
        platform-driver-x86@...r.kernel.org,
        Stephen Boyd <sboyd@...eaurora.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Michael Turquette <mturquette@...libre.com>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        ALSA Development Mailing List <alsa-devel@...a-project.org>,
        Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...el.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On Fri, Dec 16, 2016 at 08:49:13PM +0200, Andy Shevchenko wrote:
> On Fri, Dec 16, 2016 at 8:36 PM, Darren Hart <dvhart@...radead.org> wrote:
> > On Tue, Dec 13, 2016 at 02:26:21AM +0200, Andy Shevchenko wrote:
> >> On Tue, Dec 13, 2016 at 2:15 AM, Pierre-Louis Bossart
> >> <pierre-louis.bossart@...ux.intel.com> wrote:
> 
> >> For clock I would suggest include/linux/clk/ with x86_ prefix.
> >> For the rest I have no strong opinion except trying to avoid
> >> platform_data wording in the path as much as possible.
> >>
> >> As an example I could recall DMA engine subsystem where we have
> >>
> >> include/linux/platform_data/dma-*.h
> >>
> >> and
> >>
> >> include/linux/dma/*.h
> >>
> >> So, this sounds more to me as
> >>
> >> include/linux/x86/pmc_atom.h
> >
> > There should really be some Documentation about how to choose an include
> > directory :-)
> 
> So true!
> 
> > My understanding is include/linux should be more generic, rather than platform
> > specific headers. So while platform_data may refer specifically to the platform
> > bus drivers, it's the closest thing we have to include/platform, which would be
> > ideal. I would prefer to stick with include/platform_data because:
> >
> > 1) Semantically, it's the closest thing there is
> > 2) include/linux should be for more generic headers related to the OS or
> >    subsystems

Scratch #2 from the arguments since it's include/linux/platform_data that we're
talking about here.

> > 3) It doesn't make sense to create a separate include/platform directory for a
> >    single header.
> > 4) We don't want to rename platform_data to platform now and change all the
> >    drivers, but it could be changed later.
> 
> My understanding that part like P-Unit, PMIC, PMC, SCU, whatever we
> have inside SoC is platform from hardware prospective, but from
> software (driver) it doesn't use platform data since it's quite SoC
> specific (like CPU model to differentiate). That's why something in
> the middle between arch/x86/include/asm and
> include/linux/platform_data.
> 
> I assume I would be not good in naming schemes, though platform_data
> for file which doesn't contain platform data for platform device
> sounds a bit confusing to me. Like someone already noticed
> include/platform_data is already messy. This might just add another
> level of it.
> 
> So, what is exactly confuses me is mixing data for *platform devices*
> (as represented via *platform driver* -- struct platform_driver)  and
> for SoC devices (no struct platform_driver per se).
> Maybe I misunderstood something...

You're understanding is correct. We're just applying different values to the
respective merits of each argument.

The options are:

a) include/linux/x86
b) include/linux/platform_data/x86

In my opinion, a) looks like architecture and would be difficult to distinguish
from arch/x86/include. b) on the other hand clearly notes that it is for
platform specific information. If it was platform instead of platform_data, that
would be even better, but that could be a later change. But I think the
confusion over x86 arch in a) is worse than the more subtle (in my opinion)
distinction between "platform" and "platform_data".

I would want x86 maintainer approval before adding a), while b) I'm happy to add
ourselves - and we already have agreement from tglx on that.

To move forward, let's go with b). The new x86 directory clearly separates out
content which will make it trivial to move later if the need arises.

-- 
Darren Hart
Intel Open Source Technology Center