All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Saravana Kannan <saravanak@google.com>, nuno.sa@analog.com
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	 Jonathan Cameron <jic23@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Olivier Moysan <olivier.moysan@foss.st.com>
Subject: Re: [PATCH v7 4/9] driver: core: allow modifying device_links flags
Date: Thu, 25 Jan 2024 16:34:41 +0100	[thread overview]
Message-ID: <ef59aaa2a251e92d463d8983ab6eec459298c102.camel@gmail.com> (raw)
In-Reply-To: <8eae083af481441d83df02a1880e2aedf99efdfb.camel@gmail.com>

On Thu, 2024-01-25 at 09:14 +0100, Nuno Sá wrote:
> 
> Hi Saravana,
> 
> Thanks for your feedback,
> 
> On Wed, 2024-01-24 at 19:21 -0800, Saravana Kannan wrote:
> > On Tue, Jan 23, 2024 at 7:14 AM Nuno Sa via B4 Relay
> > <devnull+nuno.sa.analog.com@kernel.org> wrote:
> > > 
> > > From: Nuno Sa <nuno.sa@analog.com>
> > > 
> > > If a device_link is previously created (eg: via
> > > fw_devlink_create_devlink()) before the supplier + consumer are both
> > > present and bound to their respective drivers, there's no way to set
> > > DL_FLAG_AUTOREMOVE_CONSUMER anymore while one can still set
> > > DL_FLAG_AUTOREMOVE_SUPPLIER. Hence, rework the flags checks to allow
> > > for DL_FLAG_AUTOREMOVE_CONSUMER in the same way
> > > DL_FLAG_AUTOREMOVE_SUPPLIER is done.
> > 
> > Curious, why do you want to set DL_FLAG_AUTOREMOVE_CONSUMER?
> > Especially if fw_devlink already created the link? You are effectively
> > trying to delete the link fw_devlink created if any of your devices
> > unbind.
> > 
> 
> Well, this is still useful in the modules case as the link will be relaxed
> after
> all devices are initialized and that will already clear AUTOPROBE_CONSUMER
> AFAIU. But, more importantly, if I'm not missing anything, in [1], fw_devlinks
> will be dropped after the consumer + supplier are bound which means I
> definitely
> want to create a link between my consumer and supplier. 
> 

Ok, so to add a bit more on this, there are two cases:

1) Both sup and con are modules and after boot up, the link is relaxed and thus
turned into a sync_state_only link. That means the link will be deleted anyways
and AUTOPROBE_CONSUMER is already cleared by the time we try to change the link.

2) The built-in case where the link is kept as created by fw_devlink and this
patch effectively clears AUTOPROBE_CONSUMER.

Given the above, not sure what's the best option. I can think of 4:

1) Drop this patch and leave things as they are. DL_FLAG_AUTOREMOVE_CONSUMER is
pretty much ignored in my call but it will turn the link in a MANAGED one and
clear SYNC_STATE_ONLY. I could very well just pass 0 in the flags as
DL_FLAG_AUTOREMOVE_CONSUMER is always ignored;

2) Rework this patch so we can still change an existing link to accept
DL_FLAG_AUTOREMOVE_CONSUMER (in the modules case for example).

However, instead of clearing AUTOPROBE_CONSUMER, I would add some checks so if
flags have one of DL_FLAG_AUTOREMOVE_SUPPLIER or DL_FLAG_AUTOREMOVE_CONSUMER and
AUTOPROBE_CONSUMER is already set, we ignore them. In fact, right now, I think
one could pass DL_FLAG_AUTOREMOVE_SUPPLIER and link->flags ends ups with
AUTOREMOVE_SUPPLIER | AUTOPROBE_CONSUMER which in theory is not allowed...

3) Keep it as-is... This one is likely a NACK as I'm getting the feeling that
clearing stuff that might have been created by fw_devlinks is probably a no-go.

Let me know your thoughts...

- Nuno Sá


  reply	other threads:[~2024-01-25 15:31 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 15:14 [PATCH v7 0/9] iio: add new backend framework Nuno Sa
2024-01-23 15:14 ` Nuno Sa via B4 Relay
2024-01-23 15:14 ` [PATCH v7 1/9] of: property: fix typo in io-channels Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-25  3:14   ` Saravana Kannan
2024-01-27 15:07     ` Jonathan Cameron
2024-01-27 15:16       ` Jonathan Cameron
2024-01-29  8:18       ` Nuno Sá
2024-01-29 22:33         ` Saravana Kannan
2024-01-30 10:32           ` Nuno Sá
2024-01-30 20:54             ` Rob Herring
2024-01-30 20:54   ` Rob Herring
2024-01-31  8:55     ` Nuno Sá
2024-01-23 15:14 ` [PATCH v7 2/9] dt-bindings: adc: ad9467: add new io-backend property Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-23 15:14 ` [PATCH v7 3/9] dt-bindings: adc: axi-adc: update bindings for backend framework Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-23 16:36   ` Rob Herring
2024-01-23 15:14 ` [PATCH v7 4/9] driver: core: allow modifying device_links flags Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-25  3:21   ` Saravana Kannan
2024-01-25  8:14     ` Nuno Sá
2024-01-25 15:34       ` Nuno Sá [this message]
2024-01-25 16:57         ` Rafael J. Wysocki
2024-01-26  8:04           ` Nuno Sá
2024-01-26 14:26             ` Nuno Sá
2024-01-27 15:15               ` Jonathan Cameron
2024-01-29  8:29                 ` Nuno Sá
2024-01-29 22:31                   ` Saravana Kannan
2024-01-30 10:54                     ` Nuno Sá
2024-01-26  0:57         ` Saravana Kannan
2024-01-26  8:05           ` Nuno Sá
2024-01-26  0:50       ` Saravana Kannan
2024-01-26  8:13         ` Nuno Sá
2024-01-26 14:27           ` Nuno Sá
2024-01-26 18:09             ` Saravana Kannan
2024-01-27  8:43               ` Nuno Sá
2024-01-23 15:14 ` [PATCH v7 5/9] of: property: add device link support for io-backends Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-23 15:14 ` [PATCH v7 6/9] iio: buffer-dmaengine: export buffer alloc and free functions Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-23 15:14 ` [PATCH v7 7/9] iio: add the IIO backend framework Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-23 15:14 ` [PATCH v7 8/9] iio: adc: ad9467: convert to " Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-23 15:14 ` [PATCH v7 9/9] iio: adc: adi-axi-adc: move " Nuno Sa
2024-01-23 15:14   ` Nuno Sa via B4 Relay
2024-01-27 15:20   ` Jonathan Cameron
2024-01-28 21:27     ` David Lechner
2024-01-29  8:15       ` Nuno Sá

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=ef59aaa2a251e92d463d8983ab6eec459298c102.camel@gmail.com \
    --to=noname.nuno@gmail.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=olivier.moysan@foss.st.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.