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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.20.1609290925480.21836@nanos>
Date:   Thu, 29 Sep 2016 09:29:09 -0400 (EDT)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Darren Hart <dvhart@...radead.org>
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 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.
 
> 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.
 
> 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.

Thanks,

	tglx