Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Quentin Schulz <quentin.schulz@cherry.de>,
	Guenter Roeck <linux@roeck-us.net>,
	Farouk Bouabid <farouk.bouabid@cherry.de>
Cc: Andi Shyti <andi.shyti@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Peter Rosin <peda@axentia.se>,
	Jean Delvare <jdelvare@suse.com>,
	Heiko Stuebner <heiko@sntech.de>,
	linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v6 4/8] hwmon: (amc6821) add support for tsd,mule
Date: Mon, 12 Aug 2024 15:10:52 +0200	[thread overview]
Message-ID: <fa54c691-467f-4b9e-b483-023dfeb8d32b@kernel.org> (raw)
In-Reply-To: <bd70a54a-ea41-44cc-a971-e9a764a4212c@cherry.de>

On 12/08/2024 13:58, Quentin Schulz wrote:
> Hi Krzysztof,
> 
> On 8/12/24 1:38 PM, Krzysztof Kozlowski wrote:
>> [Some people who received this message don't often get email from krzk@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> On 31/07/2024 17:12, Guenter Roeck wrote:
>>> On Thu, Jul 25, 2024 at 03:27:50PM +0200, Farouk Bouabid wrote:
>>>> Theobroma Systems Mule is an MCU that emulates a set of I2C devices,
>>>> among which is an amc6821 and other devices that are reachable through
>>>> an I2C-mux.
>>>>
>>>> The devices on the mux can be selected by writing the appropriate device
>>>> number to an I2C config register (amc6821: reg 0xff)
>>>>
>>>> Implement "tsd,mule" compatible to instantiate the I2C-mux platform device
>>>> when probing the amc6821.
>>>>
>>>> Signed-off-by: Farouk Bouabid <farouk.bouabid@cherry.de>
>>>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>>>
>>> Applied.
>>
>> Eh, there is undocumented dependency on I2C here. Next has warning
>> because of this.
>>
> 
> I think you meant to comment this on 
> https://lore.kernel.org/linux-i2c/20240725-dev-mule-i2c-mux-v6-0-f9f6d7b60fb2@cherry.de/T/#mdb7976f1dc16fce0b7db9abee6fd0b1fd0a2e2ba 
> (patch 3 and not 4 of the series). This patch (4) is fine on its own I 
> believe, no dependency on anything else. (well, except if we expect 
> bindings to be absolutely merged before the drivers? I think what 
> matters is the Device Tree changes making use of the new binding be 
> merged after dt-binding changes?).

Yeah, this was about DT binding.

> 
> I agree that there's a somewhat non-obvious dependency between patch 1 
> and 3 (the dt-bindings) and 5-8 with everything before, we could have 
> made this more explicit.
> 
>> Farouk, please *always mention* the dependencies between patches.
>>
> 
> I wasn't aware of that rule, my apologies for not catching this before 
> upstream submission.
> 
> For anyone wondering the rule is made explicit here:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes
> 
> "If one patch depends on another patch in order for a change to be 
> complete, that is OK. Simply note “this patch depends on patch X” in 
> your patch description."
> 
> Question about b4 workflow though. I encourage using b4 to avoid as many 
> mistakes as possible and make the workflow as painless as possible. I 
> believe b4 doesn't allow you to have per-patch notes, only in the 
> cover-letter.

"Patch description" or "per patch notes" is whatever you write in
changelog, so under ---.


> a) is this dependency list in cover-letter acceptable, or
> b) need to add it to the patch note (below the ---), or

One of above should be enough, both are more welcomed because many
maintainers ignore completely cover letters.

> c) can add it to the patch commit log

No, if patches go through separate trees then it would be just confusing
and not helping at all.

Best regards,
Krzysztof


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2024-08-12 13:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25 13:27 [PATCH v6 0/8] Add tsd,mule-i2c-mux support Farouk Bouabid
2024-07-25 13:27 ` [PATCH v6 1/8] dt-bindings: i2c: add support for tsd,mule-i2c-mux Farouk Bouabid
2024-08-31 21:05   ` Wolfram Sang
2024-07-25 13:27 ` [PATCH v6 2/8] i2c: muxes: add support for tsd,mule-i2c multiplexer Farouk Bouabid
2024-08-12  9:24   ` Quentin Schulz
2024-08-12  9:29     ` Krzysztof Kozlowski
2024-08-12 10:06       ` Wolfram Sang
2024-08-12 11:37         ` Krzysztof Kozlowski
2024-08-12 12:21           ` Wolfram Sang
2024-08-12 13:13             ` Krzysztof Kozlowski
2024-08-12 13:28               ` Guenter Roeck
2024-08-12 17:37               ` Wolfram Sang
2024-08-31 20:57   ` Wolfram Sang
2024-07-25 13:27 ` [PATCH v6 3/8] dt-bindings: hwmon: add support for ti,amc6821 Farouk Bouabid
2024-07-30 16:10   ` Rob Herring (Arm)
2024-07-31 15:11   ` Guenter Roeck
2024-07-25 13:27 ` [PATCH v6 4/8] hwmon: (amc6821) add support for tsd,mule Farouk Bouabid
2024-07-25 14:02   ` Guenter Roeck
2024-07-31 15:12   ` Guenter Roeck
2024-08-12 11:38     ` Krzysztof Kozlowski
2024-08-12 11:58       ` Quentin Schulz
2024-08-12 13:10         ` Krzysztof Kozlowski [this message]
2024-08-12 13:21       ` Guenter Roeck
2024-08-12 13:24         ` Krzysztof Kozlowski
2024-07-25 13:27 ` [PATCH v6 5/8] arm64: dts: rockchip: add tsd,mule-i2c-mux on rk3588-jaguar Farouk Bouabid
2024-07-25 13:27 ` [PATCH v6 6/8] arm64: dts: rockchip: add tsd,mule-i2c-mux on rk3399-puma Farouk Bouabid
2024-07-25 13:27 ` [PATCH v6 7/8] arm64: dts: rockchip: add tsd,mule-i2c-mux on rk3588-tiger Farouk Bouabid
2024-07-25 13:27 ` [PATCH v6 8/8] arm64: dts: rockchip: add tsd,mule-i2c-mux on px30-ringneck Farouk Bouabid

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=fa54c691-467f-4b9e-b483-023dfeb8d32b@kernel.org \
    --to=krzk@kernel.org \
    --cc=andi.shyti@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=farouk.bouabid@cherry.de \
    --cc=heiko@sntech.de \
    --cc=jdelvare@suse.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@roeck-us.net \
    --cc=peda@axentia.se \
    --cc=quentin.schulz@cherry.de \
    --cc=robh@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