From: Jiri Pirko <jiri@resnulli.us> To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com> Cc: Vadim Fedorenko <vadfed@meta.com>, Jakub Kicinski <kuba@kernel.org>, Jonathan Lemon <jonathan.lemon@gmail.com>, Paolo Abeni <pabeni@redhat.com>, "Olech, Milena" <milena.olech@intel.com>, "Michalik, Michal" <michal.michalik@intel.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, poros <poros@redhat.com>, mschmidt <mschmidt@redhat.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org> Subject: Re: [RFC PATCH v7 5/8] ice: implement dpll interface to control cgu Date: Tue, 16 May 2023 08:26:27 +0200 [thread overview] Message-ID: <ZGMiE1ByArIr8ARB@nanopsycho> (raw) In-Reply-To: <DM6PR11MB4657EAF163220617A94154A39B789@DM6PR11MB4657.namprd11.prod.outlook.com> Tue, May 16, 2023 at 12:07:57AM CEST, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko <jiri@resnulli.us> >>Sent: Wednesday, May 3, 2023 2:19 PM >> >>Fri, Apr 28, 2023 at 02:20:06AM CEST, vadfed@meta.com wrote: >>>From: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> [...] >>>+ * ice_dpll_frequency_set - wrapper for pin callback for set frequency >>>+ * @pin: pointer to a pin >>>+ * @pin_priv: private data pointer passed on pin registration >>>+ * @dpll: pointer to dpll >>>+ * @frequency: frequency to be set >>>+ * @extack: error reporting >>>+ * @pin_type: type of pin being configured >>>+ * >>>+ * Wraps internal set frequency command on a pin. >>>+ * >>>+ * Return: >>>+ * * 0 - success >>>+ * * negative - error pin not found or couldn't set in hw */ static >>>+int ice_dpll_frequency_set(const struct dpll_pin *pin, void *pin_priv, >>>+ const struct dpll_device *dpll, >>>+ const u32 frequency, >>>+ struct netlink_ext_ack *extack, >>>+ const enum ice_dpll_pin_type pin_type) { >>>+ struct ice_pf *pf = pin_priv; >>>+ struct ice_dpll_pin *p; >>>+ int ret = -EINVAL; >>>+ >>>+ if (!pf) >>>+ return ret; >>>+ if (ice_dpll_cb_lock(pf)) >>>+ return -EBUSY; >>>+ p = ice_find_pin(pf, pin, pin_type); >> >>This does not make any sense to me. You should avoid the lookups and remove >>ice_find_pin() function entirely. The purpose of having pin_priv is to >>carry the struct ice_dpll_pin * directly. You should pass it down during >>pin register. >> >>pf pointer is stored in dpll_priv. >> > >In this case dpll_priv is not passed, so cannot use it. It should be passed. In general to every op where *dpll is passed, the dpll_priv pointer should be passed along. Please, fix this. >But in general it makes sense I will hold pf inside of ice_dpll_pin >and fix this. Nope, just use dpll_priv. That's why we have it. [...] >>>+/** >>>+ * ice_dpll_pin_state_set - set pin's state on dpll >>>+ * @dpll: dpll being configured >>>+ * @pin: pointer to a pin >>>+ * @pin_priv: private data pointer passed on pin registration >>>+ * @state: state of pin to be set >>>+ * @extack: error reporting >>>+ * @pin_type: type of a pin >>>+ * >>>+ * Set pin state on a pin. >>>+ * >>>+ * Return: >>>+ * * 0 - OK or no change required >>>+ * * negative - error >>>+ */ >>>+static int >>>+ice_dpll_pin_state_set(const struct dpll_device *dpll, >>>+ const struct dpll_pin *pin, void *pin_priv, >>>+ const enum dpll_pin_state state, >> >>Why you use const with enums? >> > >Just show usage intention explicitly. Does not make any sense what so ever. Please avoid it. >>>+static int ice_dpll_rclk_state_on_pin_get(const struct dpll_pin *pin, >>>+ void *pin_priv, >>>+ const struct dpll_pin *parent_pin, >>>+ enum dpll_pin_state *state, >>>+ struct netlink_ext_ack *extack) { >>>+ struct ice_pf *pf = pin_priv; >>>+ u32 parent_idx, hw_idx = ICE_DPLL_PIN_IDX_INVALID, i; >> >>Reverse christmas tree ordering please. > >Fixed. > >> >> >>>+ struct ice_dpll_pin *p; >>>+ int ret = -EFAULT; >>>+ >>>+ if (!pf) >> >>How exacly this can happen. My wild guess is it can't. Don't do such >>pointless checks please, confuses the reader. >> > >From driver perspective the pf pointer value is given by external entity, >why shouldn't it be valdiated? What? You pass it during register, you get it back here. Nothing to check. Please drop it. Non-sense checks like this have no place in kernel, they only confuse reader as he/she assumes it is a valid case. [...] >> >> >>>+ pins[i].pin = NULL; >>>+ return -ENOMEM; >>>+ } >>>+ if (cgu) { >>>+ ret = dpll_pin_register(pf->dplls.eec.dpll, >>>+ pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >>>+ ret = dpll_pin_register(pf->dplls.pps.dpll, >>>+ pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >> >>You have to call dpll_pin_unregister(pf->dplls.eec.dpll, pins[i].pin, ..) >>here. >> > >No, in case of error, the caller releases everything ice_dpll_release_all(..). How does ice_dpll_release_all() where you failed? If you need to unregister one or both or none? I know that in ice you have odd ways to handle error paths in general, but this one clearly seems to be broken. > >> >>>+ } >>>+ } >>>+ if (cgu) { >>>+ ops = &ice_dpll_output_ops; >>>+ pins = pf->dplls.outputs; >>>+ for (i = 0; i < pf->dplls.num_outputs; i++) { >>>+ pins[i].pin = dpll_pin_get(pf->dplls.clock_id, >>>+ i + pf->dplls.num_inputs, >>>+ THIS_MODULE, &pins[i].prop); >>>+ if (IS_ERR_OR_NULL(pins[i].pin)) { >>>+ pins[i].pin = NULL; >>>+ return -ENOMEM; >> >>Don't make up error values when you get them from the function you call: >> return PTR_ERR(pins[i].pin); > >Fixed. > >> >>>+ } >>>+ ret = dpll_pin_register(pf->dplls.eec.dpll, pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >>>+ ret = dpll_pin_register(pf->dplls.pps.dpll, pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >> >>You have to call dpll_pin_unregister(pf->dplls.eec.dpll, pins[i].pin, ..) >>here. >> > >As above, in case of error, the caller releases everything. As above, I don't think it works. [...] >>>+ } >>>+ >>>+ if (cgu) { >>>+ ret = dpll_device_register(pf->dplls.eec.dpll, DPLL_TYPE_EEC, >>>+ &ice_dpll_ops, pf, dev); >>>+ if (ret) >>>+ goto put_pps; >>>+ ret = dpll_device_register(pf->dplls.pps.dpll, DPLL_TYPE_PPS, >>>+ &ice_dpll_ops, pf, dev); >>>+ if (ret) >> >>You are missing call to dpll_device_unregister(pf->dplls.eec.dpll, >>DPLL_TYPE_EEC here. Fix the error path. >> > >The caller shall do the clean up, but yeah will fix this as here clean up >is not expected. :) Just make your error paths obvious and easy to follow to not to confuse anybody, you included. > >> >>>+ goto put_pps; >>>+ } >>>+ >>>+ return 0; >>>+ >>>+put_pps: >>>+ dpll_device_put(pf->dplls.pps.dpll); >>>+ pf->dplls.pps.dpll = NULL; >>>+put_eec: >>>+ dpll_device_put(pf->dplls.eec.dpll); >>>+ pf->dplls.eec.dpll = NULL; >>>+ >>>+ return ret; >>>+} [...]
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Pirko <jiri@resnulli.us> To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com> Cc: Vadim Fedorenko <vadfed@meta.com>, Jakub Kicinski <kuba@kernel.org>, Jonathan Lemon <jonathan.lemon@gmail.com>, Paolo Abeni <pabeni@redhat.com>, "Olech, Milena" <milena.olech@intel.com>, "Michalik, Michal" <michal.michalik@intel.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, poros <poros@redhat.com>, mschmidt <mschmidt@redhat.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org> Subject: Re: [RFC PATCH v7 5/8] ice: implement dpll interface to control cgu Date: Tue, 16 May 2023 08:26:27 +0200 [thread overview] Message-ID: <ZGMiE1ByArIr8ARB@nanopsycho> (raw) In-Reply-To: <DM6PR11MB4657EAF163220617A94154A39B789@DM6PR11MB4657.namprd11.prod.outlook.com> Tue, May 16, 2023 at 12:07:57AM CEST, arkadiusz.kubalewski@intel.com wrote: >>From: Jiri Pirko <jiri@resnulli.us> >>Sent: Wednesday, May 3, 2023 2:19 PM >> >>Fri, Apr 28, 2023 at 02:20:06AM CEST, vadfed@meta.com wrote: >>>From: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> [...] >>>+ * ice_dpll_frequency_set - wrapper for pin callback for set frequency >>>+ * @pin: pointer to a pin >>>+ * @pin_priv: private data pointer passed on pin registration >>>+ * @dpll: pointer to dpll >>>+ * @frequency: frequency to be set >>>+ * @extack: error reporting >>>+ * @pin_type: type of pin being configured >>>+ * >>>+ * Wraps internal set frequency command on a pin. >>>+ * >>>+ * Return: >>>+ * * 0 - success >>>+ * * negative - error pin not found or couldn't set in hw */ static >>>+int ice_dpll_frequency_set(const struct dpll_pin *pin, void *pin_priv, >>>+ const struct dpll_device *dpll, >>>+ const u32 frequency, >>>+ struct netlink_ext_ack *extack, >>>+ const enum ice_dpll_pin_type pin_type) { >>>+ struct ice_pf *pf = pin_priv; >>>+ struct ice_dpll_pin *p; >>>+ int ret = -EINVAL; >>>+ >>>+ if (!pf) >>>+ return ret; >>>+ if (ice_dpll_cb_lock(pf)) >>>+ return -EBUSY; >>>+ p = ice_find_pin(pf, pin, pin_type); >> >>This does not make any sense to me. You should avoid the lookups and remove >>ice_find_pin() function entirely. The purpose of having pin_priv is to >>carry the struct ice_dpll_pin * directly. You should pass it down during >>pin register. >> >>pf pointer is stored in dpll_priv. >> > >In this case dpll_priv is not passed, so cannot use it. It should be passed. In general to every op where *dpll is passed, the dpll_priv pointer should be passed along. Please, fix this. >But in general it makes sense I will hold pf inside of ice_dpll_pin >and fix this. Nope, just use dpll_priv. That's why we have it. [...] >>>+/** >>>+ * ice_dpll_pin_state_set - set pin's state on dpll >>>+ * @dpll: dpll being configured >>>+ * @pin: pointer to a pin >>>+ * @pin_priv: private data pointer passed on pin registration >>>+ * @state: state of pin to be set >>>+ * @extack: error reporting >>>+ * @pin_type: type of a pin >>>+ * >>>+ * Set pin state on a pin. >>>+ * >>>+ * Return: >>>+ * * 0 - OK or no change required >>>+ * * negative - error >>>+ */ >>>+static int >>>+ice_dpll_pin_state_set(const struct dpll_device *dpll, >>>+ const struct dpll_pin *pin, void *pin_priv, >>>+ const enum dpll_pin_state state, >> >>Why you use const with enums? >> > >Just show usage intention explicitly. Does not make any sense what so ever. Please avoid it. >>>+static int ice_dpll_rclk_state_on_pin_get(const struct dpll_pin *pin, >>>+ void *pin_priv, >>>+ const struct dpll_pin *parent_pin, >>>+ enum dpll_pin_state *state, >>>+ struct netlink_ext_ack *extack) { >>>+ struct ice_pf *pf = pin_priv; >>>+ u32 parent_idx, hw_idx = ICE_DPLL_PIN_IDX_INVALID, i; >> >>Reverse christmas tree ordering please. > >Fixed. > >> >> >>>+ struct ice_dpll_pin *p; >>>+ int ret = -EFAULT; >>>+ >>>+ if (!pf) >> >>How exacly this can happen. My wild guess is it can't. Don't do such >>pointless checks please, confuses the reader. >> > >From driver perspective the pf pointer value is given by external entity, >why shouldn't it be valdiated? What? You pass it during register, you get it back here. Nothing to check. Please drop it. Non-sense checks like this have no place in kernel, they only confuse reader as he/she assumes it is a valid case. [...] >> >> >>>+ pins[i].pin = NULL; >>>+ return -ENOMEM; >>>+ } >>>+ if (cgu) { >>>+ ret = dpll_pin_register(pf->dplls.eec.dpll, >>>+ pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >>>+ ret = dpll_pin_register(pf->dplls.pps.dpll, >>>+ pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >> >>You have to call dpll_pin_unregister(pf->dplls.eec.dpll, pins[i].pin, ..) >>here. >> > >No, in case of error, the caller releases everything ice_dpll_release_all(..). How does ice_dpll_release_all() where you failed? If you need to unregister one or both or none? I know that in ice you have odd ways to handle error paths in general, but this one clearly seems to be broken. > >> >>>+ } >>>+ } >>>+ if (cgu) { >>>+ ops = &ice_dpll_output_ops; >>>+ pins = pf->dplls.outputs; >>>+ for (i = 0; i < pf->dplls.num_outputs; i++) { >>>+ pins[i].pin = dpll_pin_get(pf->dplls.clock_id, >>>+ i + pf->dplls.num_inputs, >>>+ THIS_MODULE, &pins[i].prop); >>>+ if (IS_ERR_OR_NULL(pins[i].pin)) { >>>+ pins[i].pin = NULL; >>>+ return -ENOMEM; >> >>Don't make up error values when you get them from the function you call: >> return PTR_ERR(pins[i].pin); > >Fixed. > >> >>>+ } >>>+ ret = dpll_pin_register(pf->dplls.eec.dpll, pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >>>+ ret = dpll_pin_register(pf->dplls.pps.dpll, pins[i].pin, >>>+ ops, pf, NULL); >>>+ if (ret) >>>+ return ret; >> >>You have to call dpll_pin_unregister(pf->dplls.eec.dpll, pins[i].pin, ..) >>here. >> > >As above, in case of error, the caller releases everything. As above, I don't think it works. [...] >>>+ } >>>+ >>>+ if (cgu) { >>>+ ret = dpll_device_register(pf->dplls.eec.dpll, DPLL_TYPE_EEC, >>>+ &ice_dpll_ops, pf, dev); >>>+ if (ret) >>>+ goto put_pps; >>>+ ret = dpll_device_register(pf->dplls.pps.dpll, DPLL_TYPE_PPS, >>>+ &ice_dpll_ops, pf, dev); >>>+ if (ret) >> >>You are missing call to dpll_device_unregister(pf->dplls.eec.dpll, >>DPLL_TYPE_EEC here. Fix the error path. >> > >The caller shall do the clean up, but yeah will fix this as here clean up >is not expected. :) Just make your error paths obvious and easy to follow to not to confuse anybody, you included. > >> >>>+ goto put_pps; >>>+ } >>>+ >>>+ return 0; >>>+ >>>+put_pps: >>>+ dpll_device_put(pf->dplls.pps.dpll); >>>+ pf->dplls.pps.dpll = NULL; >>>+put_eec: >>>+ dpll_device_put(pf->dplls.eec.dpll); >>>+ pf->dplls.eec.dpll = NULL; >>>+ >>>+ return ret; >>>+} [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-05-16 6:26 UTC|newest] Thread overview: 149+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-28 0:20 [RFC PATCH v7 0/8] Create common DPLL configuration API Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-04-28 0:20 ` [RFC PATCH v7 1/8] dpll: spec: Add Netlink spec in YAML Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-05-04 12:02 ` Jiri Pirko 2023-05-04 12:02 ` Jiri Pirko 2023-05-04 21:24 ` Jakub Kicinski 2023-05-04 21:24 ` Jakub Kicinski 2023-05-05 10:29 ` Jiri Pirko 2023-05-05 10:29 ` Jiri Pirko 2023-05-11 7:44 ` Kubalewski, Arkadiusz 2023-05-11 8:00 ` Jiri Pirko 2023-05-11 14:55 ` Jakub Kicinski 2023-05-11 7:40 ` Kubalewski, Arkadiusz 2023-05-11 7:59 ` Jiri Pirko 2023-05-11 20:51 ` Kubalewski, Arkadiusz 2023-05-15 9:30 ` Jiri Pirko 2023-05-15 9:30 ` Jiri Pirko 2023-05-16 12:05 ` Kubalewski, Arkadiusz 2023-05-16 12:05 ` Kubalewski, Arkadiusz 2023-05-16 14:33 ` Jiri Pirko 2023-05-16 14:33 ` Jiri Pirko 2023-05-18 13:24 ` Kubalewski, Arkadiusz 2023-05-18 13:24 ` Kubalewski, Arkadiusz 2023-05-18 14:02 ` Jiri Pirko 2023-05-18 14:02 ` Jiri Pirko 2023-05-11 15:20 ` Jakub Kicinski 2023-05-11 20:53 ` Kubalewski, Arkadiusz 2023-05-11 23:29 ` Jakub Kicinski 2023-05-16 12:15 ` Kubalewski, Arkadiusz 2023-05-16 12:15 ` Kubalewski, Arkadiusz 2023-05-11 7:38 ` Kubalewski, Arkadiusz 2023-05-11 8:14 ` Jiri Pirko 2023-05-11 20:53 ` Kubalewski, Arkadiusz 2023-05-11 15:26 ` Jakub Kicinski 2023-05-11 20:54 ` Kubalewski, Arkadiusz 2023-04-28 0:20 ` [RFC PATCH v7 2/8] dpll: Add DPLL framework base functions Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-05-02 15:38 ` Jiri Pirko 2023-05-02 15:38 ` Jiri Pirko 2023-06-06 18:47 ` Kubalewski, Arkadiusz 2023-06-06 18:47 ` Kubalewski, Arkadiusz 2023-05-03 8:09 ` Jiri Pirko 2023-05-03 8:09 ` Jiri Pirko 2023-06-06 18:50 ` Kubalewski, Arkadiusz 2023-06-06 18:50 ` Kubalewski, Arkadiusz 2023-05-04 11:18 ` Jiri Pirko 2023-05-04 11:18 ` Jiri Pirko 2023-05-04 20:27 ` Jakub Kicinski 2023-05-04 20:27 ` Jakub Kicinski 2023-06-06 18:55 ` Kubalewski, Arkadiusz 2023-06-06 18:55 ` Kubalewski, Arkadiusz 2023-05-04 21:21 ` Jakub Kicinski 2023-05-04 21:21 ` Jakub Kicinski 2023-06-09 12:54 ` Kubalewski, Arkadiusz 2023-06-09 12:54 ` Kubalewski, Arkadiusz 2023-05-09 13:40 ` Jiri Pirko 2023-06-09 12:53 ` Kubalewski, Arkadiusz 2023-06-09 12:53 ` Kubalewski, Arkadiusz 2023-06-13 13:49 ` Jiri Pirko 2023-06-13 13:49 ` Jiri Pirko 2023-05-22 14:45 ` Paolo Abeni 2023-05-22 14:45 ` Paolo Abeni 2023-06-09 12:51 ` Kubalewski, Arkadiusz 2023-06-09 12:51 ` Kubalewski, Arkadiusz 2023-04-28 0:20 ` [RFC PATCH v7 3/8] dpll: documentation on DPLL subsystem interface Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-05-02 7:50 ` kernel test robot 2023-05-04 19:04 ` Jakub Kicinski 2023-05-04 19:04 ` Jakub Kicinski 2023-05-05 13:16 ` Vadim Fedorenko 2023-05-05 13:16 ` Vadim Fedorenko 2023-05-05 15:29 ` Jakub Kicinski 2023-05-05 15:29 ` Jakub Kicinski 2023-05-11 10:23 ` Kubalewski, Arkadiusz 2023-04-28 0:20 ` [RFC PATCH v7 4/8] ice: add admin commands to access cgu configuration Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-04-28 3:20 ` kernel test robot 2023-04-28 17:53 ` kernel test robot 2023-04-28 0:20 ` [RFC PATCH v7 5/8] ice: implement dpll interface to control cgu Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-04-28 6:05 ` kernel test robot 2023-04-28 8:18 ` kernel test robot 2023-05-03 12:18 ` Jiri Pirko 2023-05-03 12:18 ` Jiri Pirko 2023-05-15 22:07 ` Kubalewski, Arkadiusz 2023-05-15 22:07 ` Kubalewski, Arkadiusz 2023-05-16 6:26 ` Jiri Pirko [this message] 2023-05-16 6:26 ` Jiri Pirko 2023-05-18 16:06 ` Kubalewski, Arkadiusz 2023-05-18 16:06 ` Kubalewski, Arkadiusz 2023-05-19 6:15 ` Jiri Pirko 2023-05-19 6:15 ` Jiri Pirko 2023-05-25 9:01 ` Kubalewski, Arkadiusz 2023-05-25 9:01 ` Kubalewski, Arkadiusz 2023-05-19 6:47 ` Paolo Abeni 2023-05-19 6:47 ` Paolo Abeni 2023-05-25 9:05 ` Kubalewski, Arkadiusz 2023-05-25 9:05 ` Kubalewski, Arkadiusz 2023-05-15 17:12 ` Jiri Pirko 2023-05-15 17:12 ` Jiri Pirko 2023-05-16 9:22 ` Kubalewski, Arkadiusz 2023-05-16 9:22 ` Kubalewski, Arkadiusz 2023-05-16 11:46 ` Jiri Pirko 2023-05-16 11:46 ` Jiri Pirko 2023-05-18 16:07 ` Kubalewski, Arkadiusz 2023-05-18 16:07 ` Kubalewski, Arkadiusz 2023-05-19 6:15 ` Jiri Pirko 2023-05-19 6:15 ` Jiri Pirko 2023-04-28 0:20 ` [RFC PATCH v7 6/8] ptp_ocp: implement DPLL ops Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-04-28 6:36 ` kernel test robot 2023-05-04 9:27 ` Jiri Pirko 2023-05-04 9:27 ` Jiri Pirko 2023-05-05 13:43 ` Vadim Fedorenko 2023-05-05 13:43 ` Vadim Fedorenko 2023-05-06 12:42 ` Jiri Pirko 2023-05-06 12:42 ` Jiri Pirko 2023-04-28 0:20 ` [RFC PATCH v7 7/8] netdev: expose DPLL pin handle for netdevice Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-04-28 2:36 ` Stephen Hemminger 2023-04-28 2:36 ` Stephen Hemminger 2023-04-28 10:00 ` Vadim Fedorenko 2023-04-28 10:00 ` Vadim Fedorenko 2023-04-28 2:49 ` kernel test robot 2023-04-28 3:09 ` kernel test robot 2023-05-04 20:31 ` Jakub Kicinski 2023-05-04 20:31 ` Jakub Kicinski 2023-05-05 10:32 ` Jiri Pirko 2023-05-05 10:32 ` Jiri Pirko 2023-04-28 0:20 ` [RFC PATCH v7 8/8] mlx5: Implement SyncE support using DPLL infrastructure Vadim Fedorenko 2023-04-28 0:20 ` Vadim Fedorenko 2023-05-02 8:55 ` [RFC PATCH v7 0/8] Create common DPLL configuration API Jiri Pirko 2023-05-02 8:55 ` Jiri Pirko 2023-05-02 13:04 ` Jiri Pirko 2023-05-02 13:04 ` Jiri Pirko 2023-05-25 12:52 ` Kubalewski, Arkadiusz 2023-05-25 12:52 ` Kubalewski, Arkadiusz 2023-05-11 7:52 ` Jiri Pirko 2023-05-25 13:01 ` Kubalewski, Arkadiusz 2023-05-25 13:01 ` Kubalewski, Arkadiusz 2023-05-17 10:18 ` Jiri Pirko 2023-05-17 10:18 ` Jiri Pirko 2023-05-26 10:14 ` Kubalewski, Arkadiusz 2023-05-26 10:14 ` Kubalewski, Arkadiusz 2023-05-26 10:39 ` Jiri Pirko 2023-05-26 10:39 ` Jiri Pirko 2023-06-05 10:07 ` Kubalewski, Arkadiusz 2023-06-05 10:07 ` 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=ZGMiE1ByArIr8ARB@nanopsycho \ --to=jiri@resnulli.us \ --cc=arkadiusz.kubalewski@intel.com \ --cc=jonathan.lemon@gmail.com \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=michal.michalik@intel.com \ --cc=milena.olech@intel.com \ --cc=mschmidt@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=poros@redhat.com \ --cc=vadfed@meta.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: linkBe 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.