linux-kernel - Re: [tip:x86/platform] x86/platform/mellanox: Introduce support for Mellanox systems platform

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

Message-ID: <20160930000621.GA24642@f23x64.localdomain>
Date:   Thu, 29 Sep 2016 17:06:21 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     hpa@...or.com, vadimp@...lanox.com, linux-kernel@...r.kernel.org,
        mingo@...nel.org, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/platform] x86/platform/mellanox: Introduce support for
 Mellanox systems platform

On Thu, Sep 29, 2016 at 09:29:09AM -0400, Thomas Gleixner wrote:
> On Wed, 28 Sep 2016, Darren Hart wrote:
> > This through me as I was trying to reconcile this series with another mellanox
> > platform driver from Vadim to the drivers/platform/x86 tree as this one also
> > came to the platform-driver-x86 mailing list.
> > 
> > There are no other entries in MAINTAINERS that use this list without files under
> > drivers/platform/x86.
> > 
> > Thomas, HPA, Ingo, do you also use the platform-driver-x86 mailing list for
> > arch/x86/platform? I had assumed this was only for drivers/platform/x86.
> 
> No. This came in via LKML.

Right, understood. I was referring to the platform-driver-x86 list being
referenced in the MAINTAINERS file. If it lives in arch/platform/x86, it
shouldn't list platform-driver-x86 in the MAINTAINER file then. I just
wanted to confirm this was the case, sounds like it is, and this was an
oversight.

>  
> > I can definitely understand how contributors might get confused.... I think I
> > may have confused myself actually :-)
> > 
> > My two cents too late, this driver seems like it would better placed in
> > drivers/platform/x86 as it isn't architectural (or SoC specific) in the same way
> > most of the others in arch/x86/platform are, but instead is more akin to the
> > end-product laptop drivers and such in drivers/platform/x86 which build platform
> > data from DMI strings, ACPI HIDs, etc.
> 
> We still can zap it from tip/x86/platform if you want to take it through
> your tree, but OTOH the merge window is close so it might be better to move
> it afterwards. Either way works for me.

Happy to follow your lead and do it afterward if you agree on the distinction
between the two subsystems, that's the issue I really care about resolving :-)

>  
> > If this isn't the right distinction between the two similarly named trees ...
> > how would you like to distinguish them? I'll volunteer to get that documented
> > someplace convenient to make it easier to decide what goes where.
> 
> Yes please. Documentation is always a good thing ot have.
> 

OK, so let's nail down the distinction. Here's a first pass strawman:

arch/platform/x86:
	Architectural support for x86 CPUs

drivers/platform/x86:
	End-product platform support, such as laptops, datacenter
		products, etc.
	Drivers for companion devices, power control, or ACPI drivers that
		are specific to x86 CPUs and end products

I added the second class to cover oddities in drivers/platform/x86 like the
following:

	intel_menlow
	intel_pmc*
	intel_pmic*
	intel_punit*
	intel_scu*
	intel_telemetry*

Is this consistent with how you see the two subsystems?


-- 
Darren Hart
Intel Open Source Technology Center