From: Vadim Fedorenko <vadim.fedorenko@linux•dev>
To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel•com>,
Jiri Pirko <jiri@resnulli•us>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"Michalik, Michal" <michal.michalik@intel•com>,
"Olech, Milena" <milena.olech@intel•com>,
"pabeni@redhat•com" <pabeni@redhat•com>,
"kuba@kernel•org" <kuba@kernel•org>
Subject: Re: [PATCH net 3/3] dpll: fix register pin with unregistered parent pin
Date: Thu, 9 Nov 2023 10:56:26 +0000 [thread overview]
Message-ID: <8b6e3211-3f03-4c17-b0cb-26175bf42213@linux.dev> (raw)
In-Reply-To: <DM6PR11MB46572BD8C43DACA0FF15C2CF9BAFA@DM6PR11MB4657.namprd11.prod.outlook.com>
On 09/11/2023 09:59, Kubalewski, Arkadiusz wrote:
>> From: Jiri Pirko <jiri@resnulli•us>
>> Sent: Wednesday, November 8, 2023 4:08 PM
>>
>> Wed, Nov 08, 2023 at 11:32:26AM CET, arkadiusz.kubalewski@intel•com wrote:
>>> In case of multiple kernel module instances using the same dpll device:
>>> if only one registers dpll device, then only that one can register
>>
>> They why you don't register in multiple instances? See mlx5 for a
>> reference.
>>
>
> Every registration requires ops, but for our case only PF0 is able to
> control dpll pins and device, thus only this can provide ops.
> Basically without PF0, dpll is not able to be controlled, as well
> as directly connected pins.
>
But why do you need other pins then, if FP0 doesn't exist?
>>
>>> directly connected pins with a dpll device. If unregistered parent
>>> determines if the muxed pin can be register with it or not, it forces
>>> serialized driver load order - first the driver instance which
>>> registers the direct pins needs to be loaded, then the other instances
>>> could register muxed type pins.
>>>
>>> Allow registration of a pin with a parent even if the parent was not
>>> yet registered, thus allow ability for unserialized driver instance
>>
>> Weird.
>>
>
> Yeah, this is issue only for MUX/parent pin part, couldn't find better
> way, but it doesn't seem to break things around..
>
I just wonder how do you see the registration procedure? How can parent
pin exist if it's not registered? I believe you cannot get it through
DPLL API, then the only possible way is to create it within the same
driver code, which can be simply re-arranged. Am I wrong here?
> Thank you!
> Arkadiusz
>
>>
>>> load order.
>>> Do not WARN_ON notification for unregistered pin, which can be invoked
>>> for described case, instead just return error.
>>>
>>> Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions")
>>> Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base
>>> functions")
>>> Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel•com>
>>> ---
>>> drivers/dpll/dpll_core.c | 4 ----
>>> drivers/dpll/dpll_netlink.c | 2 +-
>>> 2 files changed, 1 insertion(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c index
>>> 4077b562ba3b..ae884b92d68c 100644
>>> --- a/drivers/dpll/dpll_core.c
>>> +++ b/drivers/dpll/dpll_core.c
>>> @@ -28,8 +28,6 @@ static u32 dpll_xa_id;
>>> WARN_ON_ONCE(!xa_get_mark(&dpll_device_xa, (d)->id, DPLL_REGISTERED))
>>> #define ASSERT_DPLL_NOT_REGISTERED(d) \
>>> WARN_ON_ONCE(xa_get_mark(&dpll_device_xa, (d)->id, DPLL_REGISTERED))
>>> -#define ASSERT_PIN_REGISTERED(p) \
>>> - WARN_ON_ONCE(!xa_get_mark(&dpll_pin_xa, (p)->id, DPLL_REGISTERED))
>>>
>>> struct dpll_device_registration {
>>> struct list_head list;
>>> @@ -641,8 +639,6 @@ int dpll_pin_on_pin_register(struct dpll_pin *parent,
>> struct dpll_pin *pin,
>>> WARN_ON(!ops->state_on_pin_get) ||
>>> WARN_ON(!ops->direction_get))
>>> return -EINVAL;
>>> - if (ASSERT_PIN_REGISTERED(parent))
>>> - return -EINVAL;
>>>
>>> mutex_lock(&dpll_lock);
>>> ret = dpll_xa_ref_pin_add(&pin->parent_refs, parent, ops, priv); diff
>>> --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c index
>>> 963bbbbe6660..ff430f43304f 100644
>>> --- a/drivers/dpll/dpll_netlink.c
>>> +++ b/drivers/dpll/dpll_netlink.c
>>> @@ -558,7 +558,7 @@ dpll_pin_event_send(enum dpll_cmd event, struct
>> dpll_pin *pin)
>>> int ret = -ENOMEM;
>>> void *hdr;
>>>
>>> - if (WARN_ON(!xa_get_mark(&dpll_pin_xa, pin->id, DPLL_REGISTERED)))
>>> + if (!xa_get_mark(&dpll_pin_xa, pin->id, DPLL_REGISTERED))
>>> return -ENODEV;
>>>
>>> msg = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
>>> --
>>> 2.38.1
>>>
next prev parent reply other threads:[~2023-11-09 10:56 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 10:32 [PATCH net 0/3] dpll: fix unordered unbind/bind registerer issues Arkadiusz Kubalewski
2023-11-08 10:32 ` [PATCH net 1/3] dpll: fix pin dump crash after module unbind Arkadiusz Kubalewski
2023-11-08 11:36 ` Przemek Kitszel
2023-11-08 12:08 ` Kubalewski, Arkadiusz
2023-11-08 15:08 ` Jiri Pirko
2023-11-09 9:49 ` Kubalewski, Arkadiusz
2023-11-09 13:18 ` Jiri Pirko
2023-11-09 16:33 ` Kubalewski, Arkadiusz
2023-11-08 10:32 ` [PATCH net 2/3] dpll: fix pin dump crash for rebound module Arkadiusz Kubalewski
2023-11-08 14:30 ` Jiri Pirko
2023-11-09 12:20 ` Kubalewski, Arkadiusz
2023-11-09 13:19 ` Jiri Pirko
2023-11-09 16:30 ` Kubalewski, Arkadiusz
2023-11-09 18:06 ` Jiri Pirko
2023-11-09 23:32 ` Kubalewski, Arkadiusz
2023-11-10 6:45 ` Jiri Pirko
2023-11-10 9:01 ` Kubalewski, Arkadiusz
2023-11-10 10:06 ` Jiri Pirko
2023-11-10 11:18 ` Kubalewski, Arkadiusz
2023-11-10 11:44 ` Jiri Pirko
2023-11-10 14:11 ` Kubalewski, Arkadiusz
2023-11-08 10:32 ` [PATCH net 3/3] dpll: fix register pin with unregistered parent pin Arkadiusz Kubalewski
2023-11-08 15:07 ` Jiri Pirko
2023-11-09 9:59 ` Kubalewski, Arkadiusz
2023-11-09 10:56 ` Vadim Fedorenko [this message]
2023-11-09 16:02 ` Kubalewski, Arkadiusz
2023-11-09 18:04 ` Jiri Pirko
2023-11-09 23:21 ` Kubalewski, Arkadiusz
2023-11-10 6:48 ` Jiri Pirko
2023-11-10 8:50 ` Kubalewski, Arkadiusz
2023-11-10 10:07 ` Jiri Pirko
2023-11-10 11:19 ` Kubalewski, Arkadiusz
2023-11-09 13:20 ` Jiri Pirko
2023-11-09 16:13 ` Kubalewski, Arkadiusz
2023-11-09 10:50 ` [PATCH net 0/3] dpll: fix unordered unbind/bind registerer issues Vadim Fedorenko
2023-11-09 17:20 ` Kubalewski, Arkadiusz
2023-11-09 18:07 ` Jiri Pirko
2023-11-09 23:35 ` Kubalewski, Arkadiusz
2023-11-10 6:48 ` Jiri Pirko
2023-11-10 9:06 ` Kubalewski, Arkadiusz
2023-11-10 10:09 ` Jiri Pirko
2023-11-10 11:22 ` Kubalewski, Arkadiusz
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=8b6e3211-3f03-4c17-b0cb-26175bf42213@linux.dev \
--to=vadim.fedorenko@linux$(echo .)dev \
--cc=arkadiusz.kubalewski@intel$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=kuba@kernel$(echo .)org \
--cc=michal.michalik@intel$(echo .)com \
--cc=milena.olech@intel$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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