[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZGSp/XRLExRqOKQs@nanopsycho>
Date: Wed, 17 May 2023 12:18:37 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Vadim Fedorenko <vadfed@...a.com>,
Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Jonathan Lemon <jonathan.lemon@...il.com>,
Paolo Abeni <pabeni@...hat.com>,
Milena Olech <milena.olech@...el.com>,
Michal Michalik <michal.michalik@...el.com>,
linux-arm-kernel@...ts.infradead.org,
Vadim Fedorenko <vadim.fedorenko@...ux.dev>, poros@...hat.com,
mschmidt@...hat.com, netdev@...r.kernel.org,
linux-clk@...r.kernel.org
Subject: Re: [RFC PATCH v7 0/8] Create common DPLL configuration API
Let me summarize the outcome of the discussion between me and Jakub
regarding attributes, handles and ID lookups in the RFCv7 thread:
--------------------------------------------------------------
** Needed changes for RFCv8 **
1) No scoped indexes.
The indexes passed from driver to dpll core during call of:
dpll_device_get() - device_idx
dpll_pin_get() - pin_idx
should be for INTERNAL kernel use only and NOT EXPOSED over uapi.
Therefore following attributes need to be removed:
DPLL_A_PIN_IDX
DPLL_A_PIN_PARENT_IDX
2) For device, the handle will be DPLL_A_ID == dpll->id.
This will be the only handle for device for every
device related GET, SET command and every device related notification.
Note: this ID is not deterministing and may be different depending on
order of device probes etc.
3) For pin, the handle will be DPLL_A_PIN_ID == pin->id
This will be the only handle for pin for every
pin related GET, SET command and every pin related notification.
Note: this ID is not deterministing and may be different depending on
order of device probes etc.
4) Remove attribute:
DPLL_A_PIN_LABEL
and replace it with:
DPLL_A_PIN_PANEL_LABEL (string)
DPLL_A_PIN_XXX (string)
where XXX is a label type, like for example:
DPLL_A_PIN_BOARD_LABEL
DPLL_A_PIN_BOARD_TRACE
DPLL_A_PIN_PACKAGE_PIN
5) Make sure you expose following attributes for every device and
pin GET/DUMP command reply message:
DPLL_A_MODULE_NAME
DPLL_A_CLOCK_ID
6) Remove attributes:
DPLL_A_DEV_NAME
DPLL_A_BUS_NAME
as they no longer have any value and do no make sense (even in RFCv7)
--------------------------------------------------------------
** Lookup commands **
Basically these would allow user to query DEVICE_ID and PIN_ID
according to provided atributes (see examples below).
These would be from my perspective optional for this patchsets.
I believe we can do it as follow-up if needed. For example for mlx5
I don't have usecase for it, since I can consistently get PIN_ID
using RT netlink for given netdev. But I can imagine that for non-SyncE
dpll driver this would make sense to have.
1) Introduce CMD_GET_ID - query the kernel for a dpll device
specified by given attrs
Example:
-> DPLL_A_MODULE_NAME
DPLL_A_CLOCK_ID
DPLL_A_TYPE
<- DPLL_A_ID
Example:
-> DPLL_A_MODULE_NAME
DPLL_A_CLOCK_ID
<- DPLL_A_ID
Example:
-> DPLL_A_MODULE_NAME
<- -EINVAL (Extack: "multiple devices matched")
If user passes a subset of attrs which would not result in
a single match, kernel returns -EINVAL and proper extack message.
2) Introduce CMD_GET_PIN_ID - query the kernel for a dpll pin
specified by given attrs
Example:
-> DPLL_A_MODULE_NAME
DPLL_A_CLOCK_ID
DPLL_A_PIN_TYPE
DPLL_A_PIN_PANEL_LABEL
<- DPLL_A_PIN_ID
Example:
-> DPLL_A_MODULE_NAME
DPLL_A_CLOCK_ID
<- DPLL_A_PIN_ID (There was only one pin for given module/clock_id)
Example:
-> DPLL_A_MODULE_NAME
DPLL_A_CLOCK_ID
<- -EINVAL (Extack: "multiple pins matched")
If user passes a subset of attrs which would not result in
a single match, kernel returns -EINVAL and proper extack message.
Powered by blists - more mailing lists