Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Nikita Travkin <nikita@trvn.ru>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: "Hans de Goede" <hdegoede@redhat.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	cros-qcom-dts-watchers@chromium.org,
	"Andy Gross" <agross@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH v4 2/4] platform: Add ARM64 platform directory
Date: Tue, 12 Mar 2024 16:55:58 +0500	[thread overview]
Message-ID: <7ecbcea00a4b59d7afdb529dce12801b@trvn.ru> (raw)
In-Reply-To: <5d4434fc-862e-4430-a2a0-758887d7596d@linaro.org>

Bryan O'Donoghue писал(а) 12.03.2024 16:36:
> On 12/03/2024 08:42, Nikita Travkin wrote:
>> Some ARM64 based laptops and computers require vendor/board specific
>> drivers for their embedded controllers. Even though usually the most
>> important functionality of those devices is implemented inside ACPI,
>> unfortunately Linux doesn't currently have great support for ACPI on
>> platforms like Qualcomm Snapdragon that are used in most ARM64 laptops
>> today. Instead Linux relies on Device Tree for Qualcomm based devices
>> and it's significantly easier to reimplement the EC functionality in
>> a dedicated driver than to make use of ACPI code.
>>
>> This commit introduces a new platform/arm64 subdirectory to give a
>> place to such drivers for EC-like devices.
>>
>> A new MAINTAINERS entry is added for this directory. Patches to files in
>> this directory will be taken up by the platform-drivers-x86 team (i.e.
>> Hans de Goede and Mark Gross).
>>
>> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
>> ---
>>   MAINTAINERS                     |  9 +++++++++
>>   drivers/platform/Kconfig        |  2 ++
>>   drivers/platform/Makefile       |  1 +
>>   drivers/platform/arm64/Kconfig  | 19 +++++++++++++++++++
>>   drivers/platform/arm64/Makefile |  6 ++++++
>>   5 files changed, 37 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index b43102ca365d..ec8d706a99aa 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3050,6 +3050,15 @@ F:	drivers/mmc/host/sdhci-of-arasan.c
>>   N:	zynq
>>   N:	xilinx
>>   +ARM64 PLATFORM DRIVERS
>> +M:	Hans de Goede <hdegoede@redhat.com>
>> +M:	Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>> +L:	platform-driver-x86@vger.kernel.org
>> +S:	Maintained
>> +Q:	https://patchwork.kernel.org/project/platform-driver-x86/list/
>> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git
> 
> Surely some sort of Arm specific mailing list should be added here ? platform-drivers-x86 for arm64 platform drivers standalone, makes little sense.
> 

We agreed with Hans that pdx86 list/tree can work for EC drivers for
other platforms because many maintainers familiar with ECs through x86
are already there.

> Perhaps for each new SoC class added - you could add the appropriate mailing list linux-arm-msm is suspiciously missing from the list even though the only driver that will live in this directory after this series is a qcom based device.
> 
> And if tomorrow someone added a Rockchip based EC controller then you'd assume the rockchip mailing list should get a ping.

I believe that even though those drivers are "board specific" (Hans
asked to only include EC drivers here, and we have soc/ for other things
anyway) they are not at all "platform"/"soc" specific, so I'm not sure
adding arm lists here is a great idea:

I don't think these drivers would be too specific to the SoC given it's
just an i2c peripheral most of the time, and considering that it seems
there soon will be many WoA devices with socs from many vendors, we would
just have a collection of all the arm platform lists here...

So even if for now, while all existing WoA devices use Snapdragon chips,
we could get away with adding linux-arm-msm, it may end up just spamming
all the platform lists for no reason when the list grows...

I think it's better for the contributors to CC the relevant list for
their board themselves, which is easily done implicitly by adding dts
changes along the way, like in this series.

Of course if you and other people on linux-arm-msm are fine with that
possibility, we could add an extra list there and see if it gets out of
hand.

Nikita

> 
> ---
> bod

  parent reply	other threads:[~2024-03-12 11:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12  8:42 [PATCH v4 0/4] platform: arm64: Acer Aspire 1 embedded controller Nikita Travkin
2024-03-12  8:42 ` [PATCH v4 1/4] dt-bindings: platform: Add Acer Aspire 1 EC Nikita Travkin
2024-03-12 14:39   ` Rob Herring
2024-03-12  8:42 ` [PATCH v4 2/4] platform: Add ARM64 platform directory Nikita Travkin
2024-03-12 11:36   ` Bryan O'Donoghue
2024-03-12 11:45     ` Ilpo Järvinen
2024-03-12 11:55     ` Nikita Travkin [this message]
2024-03-12 11:40   ` Ilpo Järvinen
2024-03-12 12:00     ` Nikita Travkin
2024-03-12 12:03     ` Bryan O'Donoghue
2024-03-12  8:42 ` [PATCH v4 3/4] platform: arm64: Add Acer Aspire 1 embedded controller driver Nikita Travkin
2024-03-12 11:58   ` Bryan O'Donoghue
2024-03-12 12:23     ` Nikita Travkin
2024-03-12 12:44       ` Bryan O'Donoghue
2024-03-12 14:09         ` Nikita Travkin
2024-03-12 12:31   ` Ilpo Järvinen
2024-03-12 14:03     ` Nikita Travkin
2024-03-12  8:42 ` [PATCH v4 4/4] arm64: dts: qcom: acer-aspire1: Add embedded controller Nikita Travkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ecbcea00a4b59d7afdb529dce12801b@trvn.ru \
    --to=nikita@trvn.ru \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=cros-qcom-dts-watchers@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox