From: Quentin Schulz <quentin.schulz@cherry.de>
To: Peter Rosin <peda@axentia.se>,
Farouk Bouabid <farouk.bouabid@cherry.de>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Andi Shyti <andi.shyti@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Quentin Schulz <quentin.schulz@theobroma-systems.com>,
Heiko Stuebner <heiko@sntech.de>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 1/7] i2c: mux: add the ability to share mux-address with child nodes
Date: Fri, 3 May 2024 18:20:10 +0200 [thread overview]
Message-ID: <8506322f-bfbf-4582-a88b-b300cad2d344@cherry.de> (raw)
In-Reply-To: <c5e375a0-8c64-f244-a5e6-bfcb3400d05a@axentia.se>
Hi Peter,
On 5/3/24 7:30 AM, Peter Rosin wrote:
> Hi!
>
> 2024-05-02 at 17:01, Farouk Bouabid wrote:
>> Hi Peter,
>>
>> On 29.04.24 17:46, Peter Rosin wrote:
>>> Hi!
>>>
>>> 2024-04-26 at 18:49, Farouk Bouabid wrote:
>>>> Allow the mux to have the same address as a child device. This is useful
>>>> when the mux can only use an i2c-address that is used by a child device
>>>> because no other addresses are free to use. eg. the mux can only use
>>>> address 0x18 which is used by amc6821 connected to the mux.
>>>>
>>>> Signed-off-by: Farouk Bouabid <farouk.bouabid@theobroma-systems.com>
>>>> ---
>>>> drivers/i2c/i2c-mux.c | 10 +++++++++-
>>>> include/linux/i2c-mux.h | 1 +
>>>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
>>>> index 57ff09f18c37..f5357dff8cc5 100644
>>>> --- a/drivers/i2c/i2c-mux.c
>>>> +++ b/drivers/i2c/i2c-mux.c
>>>> @@ -331,7 +331,6 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
>>>> priv->adap.owner = THIS_MODULE;
>>>> priv->adap.algo = &priv->algo;
>>>> priv->adap.algo_data = priv;
>>>> - priv->adap.dev.parent = &parent->dev;
>>>> priv->adap.retries = parent->retries;
>>>> priv->adap.timeout = parent->timeout;
>>>> priv->adap.quirks = parent->quirks;
>>>> @@ -348,6 +347,15 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
>>>> else
>>>> priv->adap.class = class;
>>>> + /*
>>>> + * When creating the adapter, the node devices are checked for i2c address
>>>> + * match with other devices on the parent adapter, among which is the mux itself.
>>>> + * If a match is found the node device is not probed successfully.
>>>> + * Allow the mux to have the same address as a child device by skipping this check.
>>>> + */
>>>> + if (!(muxc->share_addr_with_children))
>>>> + priv->adap.dev.parent = &parent->dev;
>>> This is a dirty hack that will not generally do the right thing.
>>>
>>> The adapter device parent is not there solely for the purpose of
>>> detecting address clashes, so the above has other implications
>>> that are not desirable.
>>>
>>> Therefore, NACK on this approach. It simply needs to be more involved.
>>> Sorry.
>>>
>>> Cheers,
>>> Peter
>>>
>>
>> Another way to approach this is by implementing this flag as a quirk for the added adapter:
>>
>> (tested but not cleaned up)
>
> Yes, good idea, this is much more targeted and generally feels a lot
> better.
>
>>
>> """
>>
>> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
>> index ff5c486a1dbb..6a0237f750db 100644
>> --- a/drivers/i2c/i2c-core-base.c
>> +++ b/drivers/i2c/i2c-core-base.c
>> @@ -821,9 +821,21 @@ static int i2c_check_mux_children(struct device *dev, void *addrp)
>> static int i2c_check_addr_busy(struct i2c_adapter *adapter, int addr)
>> {
>> struct i2c_adapter *parent = i2c_parent_is_i2c_adapter(adapter);
>> + bool skip_check = false;
>> int result = 0;
>>
>> - if (parent)
>> + if (adapter->quirks) {
>> + if (adapter->quirks->flags & I2C_AQ_SHARE_ADDR) {
>> + struct i2c_client *client = of_find_i2c_device_by_node(adapter->dev.of_node->parent);
>> +
>> + if (client) {
>> + skip_check = client->addr == addr;
>> + put_device(&client->dev);
>> + }
>> + }
>> + }
>> +
>> + if (parent && !skip_check)
>> result = i2c_check_mux_parents(parent, addr);
>>
>> if (!result)
>> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
>> index 57ff09f18c37..e87cb0e43725 100644
>> --- a/drivers/i2c/i2c-mux.c
>> +++ b/drivers/i2c/i2c-mux.c
>> @@ -334,7 +334,26 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
>> priv->adap.dev.parent = &parent->dev;
>> priv->adap.retries = parent->retries;
>> priv->adap.timeout = parent->timeout;
>> - priv->adap.quirks = parent->quirks;
>> + /*
>> + * When creating the adapter, the node devices are checked for i2c address
>> + * match with other devices on the parent adapter, among which is the mux itself.
>> + * If a match is found the node device is not probed successfully.
>> + * Allow the mux to have the same address as a child device by skipping this check.
>> + */
>> + if (!muxc->share_addr_with_children)
>> + priv->adap.quirks = parent->quirks;
>> + else {
>> + struct i2c_adapter_quirks *quirks = kzalloc(sizeof(*quirks), GFP_KERNEL);
>
> This leaks, dev_kzalloc?
>
Quick questions about this though.
priv is allocated with kzalloc and not devm_kzalloc and is then manually
kfree'd either as part of the error path or in i2c_del_mux_adapters. Is
there a reason for this? Shouldn't we migrate this to devm allocation as
well?
Similarly, I was wondering if we couldn't add a devm_add_action_or_reset
for i2c_del_mux_adapters in i2c_add_mux_adapter? Is there something that
prevents us from doing this?
Cheers,
Quentin
next prev parent reply other threads:[~2024-05-03 16:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 16:49 [PATCH 0/7] Add Mule I2C multiplexer support Farouk Bouabid
2024-04-26 16:49 ` [PATCH 1/7] i2c: mux: add the ability to share mux-address with child nodes Farouk Bouabid
2024-04-29 15:46 ` Peter Rosin
2024-05-02 15:01 ` Farouk Bouabid
2024-05-03 5:30 ` Peter Rosin
2024-05-03 16:20 ` Quentin Schulz [this message]
2024-04-26 16:49 ` [PATCH 2/7] dt-bindings: i2c: mux: mule: add dt-bindings for mule i2c multiplexer Farouk Bouabid
2024-04-26 18:22 ` Rob Herring
2024-05-02 12:21 ` Farouk Bouabid
2024-04-29 6:27 ` Krzysztof Kozlowski
2024-04-29 13:56 ` Rob Herring
2024-05-02 12:14 ` Farouk Bouabid
2024-04-26 16:49 ` [PATCH 3/7] i2c: muxes: add support " Farouk Bouabid
2024-04-29 6:33 ` Krzysztof Kozlowski
2024-05-02 12:31 ` Farouk Bouabid
2024-04-26 16:49 ` [PATCH 4/7] arm64: dts: rockchip: add mule i2c mux (0x18) on rk3399-puma Farouk Bouabid
2024-04-26 16:49 ` [PATCH 5/7] arm64: dts: rockchip: add mule i2c mux (0x18) on rk3588-tiger Farouk Bouabid
2024-04-26 16:49 ` [PATCH 6/7] arm64: dts: rockchip: add mule i2c mux (0x18) on px30-ringneck Farouk Bouabid
2024-04-26 16:49 ` [PATCH 7/7] arm64: dts: rockchip: add mule i2c mux (0x18) on rk3588-jaguar Farouk Bouabid
2024-04-29 14:41 ` [PATCH 0/7] Add Mule I2C multiplexer support Rob Herring
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=8506322f-bfbf-4582-a88b-b300cad2d344@cherry.de \
--to=quentin.schulz@cherry.de \
--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=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=peda@axentia.se \
--cc=quentin.schulz@theobroma-systems.com \
--cc=robh@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).