From: Ivan Vecera <ivecera@redhat.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Eric Dumazet <edumazet@google.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
Rob Herring <robh@kernel.org>, Leon Romanovsky <leon@kernel.org>,
"Lobakin, Aleksander" <aleksander.lobakin@intel.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>,
"Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Jiri Pirko <jiri@resnulli.us>,
Richard Cochran <richardcochran@gmail.com>,
Prathosh Satish <Prathosh.Satish@microchip.com>,
Willem de Bruijn <willemb@google.com>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Mark Bloch <mbloch@nvidia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tariq Toukan <tariqt@nvidia.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Stefan Wahren <wahrenst@gmx.net>, Simon Horman <horms@kernel.org>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH RFC net-next v2 12/12] ice: dpll: Support E825-C SyncE and dynamic pin discovery
Date: Tue, 16 Dec 2025 17:49:52 +0100 [thread overview]
Message-ID: <2a50d5a3-3116-43e6-ada7-d6c02c483708@redhat.com> (raw)
In-Reply-To: <IA3PR11MB8986B2F4DBD3CDBAE5753C8AE5AAA@IA3PR11MB8986.namprd11.prod.outlook.com>
On 12/16/25 2:28 PM, Loktionov, Aleksandr wrote:
>
>
>> -----Original Message-----
>> ...
>> + /* Register rclk pin */
>> + pin = &pf->dplls.rclk;
>> + dpll_pin_on_pin_unregister(parent->pin, pin->pin,
>> + &ice_dpll_rclk_ops, pin);
>> +
>> + /* Drop fwnode pin reference */
>> + dpll_pin_put(parent->pin, &parent->tracker);
>> + parent->pin = NULL;
>> + break;
>> + default:
>> + break;
>> + }
>> +out:
>> + kfree(work);
> It looks like you free the embedded work_struct pointer instead of the allocated ice_dpll_pin_work container @ice_dpll_pin_notify().
> Isn't it?
You are right, will fix this in non-RFC submission.
>> +}
>> +
>> ...
>> +static int ice_dpll_init_info_e825c(struct ice_pf *pf)
>> +{
>> + struct ice_dplls *d = &pf->dplls;
>> + int ret = 0;
>> + int i;
>> +
>> + d->clock_id = ice_generate_clock_id(pf);
>> + d->num_inputs = ICE_SYNCE_CLK_NUM;
>> +
>> + d->inputs = kcalloc(d->num_inputs, sizeof(*d->inputs),
>> GFP_KERNEL);
> It looks like for E825-C the allocated pin info (d->inputs and related fields) is never freed:
> error paths in ice_dpll_init_info_e825c() return after kcalloc() without cleanup, and ice_dpll_deinit() explicitly skips ice_dpll_deinit_info() for this MAC.
You are right, this is Arek's code part. I don't see any problem to call
ice_dpll_deinit_info() also for this MAC (.outputs, .pps.input_prio and
.eec.input_prio should be NULL for e825c so it is safe to kfree them).
Will add correct cleanup into ice_dpll_init_info_e825c() and call
ice_dpll_deinit_info() also for this MAC.
> With the best regards
> Alex
>
>> + if (!d->inputs)
>> + return -ENOMEM;
>> +
>> + ret = ice_get_cgu_rclk_pin_info(&pf->hw, &d->base_rclk_idx,
>> + &pf->dplls.rclk.num_parents);
>> + if (ret)
>> + return ret;
>> +
>> + for (i = 0; i < pf->dplls.rclk.num_parents; i++)
>> + pf->dplls.rclk.parent_idx[i] = d->base_rclk_idx + i;
>> +
>> + if (ice_pf_src_tmr_owned(pf)) {
>> + d->base_1588_idx = ICE_E825_1588_BASE_IDX;
>> + pf->dplls.pin_1588.num_parents = pf-
>>> dplls.rclk.num_parents;
>> + for (i = 0; i < pf->dplls.pin_1588.num_parents; i++)
>> + pf->dplls.pin_1588.parent_idx[i] = d-
>>> base_1588_idx + i;
>> + }
>> + ret = ice_dpll_init_pins_info(pf,
>> ICE_DPLL_PIN_TYPE_RCLK_INPUT);
>> + if (ret)
>> + return ret;
>> + dev_dbg(ice_pf_to_dev(pf),
>> + "%s - success, inputs: %u, outputs: %u, rclk-parents:
>> %u, pin_1588-parents: %u\n",
>> + __func__, d->num_inputs, d->num_outputs, d-
>>> rclk.num_parents,
>> + d->pin_1588.num_parents);
>> + return 0;
>> +}
>> +
>> ...
>> +int ice_tspll_bypass_mux_active_e825c(struct ice_hw *hw, u8 port,
>> bool *active,
>> + enum ice_synce_clk output)
>> +{
>> + u8 active_clk;
>> + u32 val;
>> +
>> + switch (output) {
>> + case ICE_SYNCE_CLK0:
>> + ice_read_cgu_reg(hw, ICE_CGU_R10, &val);
>> + active_clk = FIELD_GET(ICE_CGU_R10_SYNCE_S_REF_CLK,
>> val);
>> + break;
>> + case ICE_SYNCE_CLK1:
>> + ice_read_cgu_reg(hw, ICE_CGU_R11, &val);
>> + active_clk = FIELD_GET(ICE_CGU_R11_SYNCE_S_BYP_CLK,
>> val);
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
> ice_read_cgu_reg() return codes are ignored, can you explain why?
Arek's code... will fix in the non-RFC submission.
Thanks a lot Alex for your sharp eyes. ;-)
Ivan
prev parent reply other threads:[~2025-12-16 16:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-15 20:30 [PATCH RFC net-next v2 00/13] dpll: Core improvements and ice E825-C SyncE support Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 01/12] dt-bindings: net: ethernet-controller: Add DPLL pin properties Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 02/12] dpll: Allow associating dpll pin with a firmware node Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 03/12] net: eth: Add helpers to find DPLL pin " Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 04/12] dpll: zl3073x: Associate pin with fwnode handle Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 05/12] dpll: Add notifier chain for dpll events Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 06/12] dpll: Support dynamic pin index allocation Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 07/12] dpll: zl3073x: Add support for mux pin type Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 08/12] dpll: Enhance and consolidate reference counting logic Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 09/12] dpll: Prevent duplicate registrations Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 10/12] dpll: Add reference count tracking support Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 11/12] drivers: Add support for DPLL reference count tracking Ivan Vecera
2025-12-15 20:30 ` [PATCH RFC net-next v2 12/12] ice: dpll: Support E825-C SyncE and dynamic pin discovery Ivan Vecera
2025-12-16 13:28 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-12-16 16:49 ` Ivan Vecera [this message]
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=2a50d5a3-3116-43e6-ada7-d6c02c483708@redhat.com \
--to=ivecera@redhat.com \
--cc=Prathosh.Satish@microchip.com \
--cc=aleksander.lobakin@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jiri@resnulli.us \
--cc=jonathan.lemon@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=vadim.fedorenko@linux.dev \
--cc=wahrenst@gmx.net \
--cc=willemb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®