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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ