[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87mup36t8r.fsf@purkki.adurom.net>
Date: Tue, 18 Dec 2018 12:09:56 +0200
From: Kalle Valo <kvalo@...eaurora.org>
To: Marc Gonzalez <marc.w.gonzalez@...e.fr>
Cc: Amit Kucheria <amit.kucheria@...aro.org>,
LKML <linux-kernel@...r.kernel.org>,
MSM <linux-arm-msm@...r.kernel.org>,
Andy Gross <andy.gross@...aro.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"David S. Miller" <davem@...emloft.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v1 1/1] MAINTAINERS: update list of qcom drivers
Marc Gonzalez <marc.w.gonzalez@...e.fr> writes:
> On 18/12/2018 08:42, Kalle Valo wrote:
>
>> Amit Kucheria wrote:
>>
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1929,20 +1929,14 @@ M: Andy Gross <andy.gross@...aro.org>
>>> M: David Brown <david.brown@...aro.org>
>>> L: linux-arm-msm@...r.kernel.org
>>> S: Maintained
>>> -F: Documentation/devicetree/bindings/soc/qcom/
>>> -F: arch/arm/boot/dts/qcom-*.dts
>>> -F: arch/arm/boot/dts/qcom-*.dtsi
>>> -F: arch/arm/mach-qcom/
>>> -F: arch/arm64/boot/dts/qcom/*
>>> +N: qcom
>>> +N: msm
>>
>> IMHO this is pretty fragile in the long term. For example only due to
>> historical reasons qualcomm wireless drivers currently under ath
>> directory but who knows if at some point we switch using qcom (or
>> qualcomm) directory.
>
> I am failing to follow your logic.
>
> (IIUC, you are talking about drivers/net/wireless/ath/ath10k)
Yeah, my example was just about ath10k and wil6210 as they go through my
tree. But it can apply to any other driver and subsystem as well:
bluetooth, future drivers and what ever works with Qualcomm hardware.
> The fact that the "qcom" or "msm" nomenclature is not used for this driver now
> just means that an explicit F entry is required. The fact that it could be renamed
> in the future just means that the entry would need to be updated or folded into a
> more generic matching pattern. What am I missing?
Not sure, but maybe you are missing the point that keeping MAINTAINER's
file up-to-date is hard and having uncommon rules like Amit and you
propose makes it even harder. Yeah, it should be simple but in practise
it's not, people easily forget to update it.
>> Also the wireless drivers might easily have filenames containing
>> strings like "msm" or "qcom" (which I assume would match with "N"
>> rules above).
>
> Any driver (not just wireless) might match "msm" or "qcom". These could be excluded
> with an X directive (as the proposed patch does, in fact).
Nobody will remember, or even know (for example I saw Amit's patch by
accident), that when adding files with string "qcom" or "msm" in path
you also need to add an exclusion to "ARM/QUALCOMM SUPPORT". That won't
work so errors are likely. It's a much safer approach to use F: rules
just like Joe proposed, that way the risk of people submitting patches
to wrong lists is reduced.
--
Kalle Valo
Powered by blists - more mailing lists