Re: [tip:x86/platform] x86/platform/mellanox: Introduce support for Mellanox systems platform
From: Darren Hart
Date: Thu Sep 29 2016 - 20:06:46 EST
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
> > 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:
Architectural support for x86 CPUs
End-product platform support, such as laptops, datacenter
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
Is this consistent with how you see the two subsystems?
Intel Open Source Technology Center