lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 1 Aug 2022 13:02:31 +0000 From: "Pandey, Radhey Shyam" <radhey.shyam.pandey@....com> To: "Claudiu.Beznea@...rochip.com" <Claudiu.Beznea@...rochip.com>, "michal.simek@...inx.com" <michal.simek@...inx.com>, "Nicolas.Ferre@...rochip.com" <Nicolas.Ferre@...rochip.com>, "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>, "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org> CC: "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "git (AMD-Xilinx)" <git@....com>, "git@...inx.com" <git@...inx.com> Subject: RE: [PATCH v2 net-next 2/2] net: macb: Add zynqmp SGMII dynamic configuration support > -----Original Message----- > From: Claudiu.Beznea@...rochip.com <Claudiu.Beznea@...rochip.com> > Sent: Monday, August 1, 2022 5:06 PM > To: Pandey, Radhey Shyam <radhey.shyam.pandey@....com>; > michal.simek@...inx.com; Nicolas.Ferre@...rochip.com; > davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org; > pabeni@...hat.com; gregkh@...uxfoundation.org > Cc: linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; > netdev@...r.kernel.org; git (AMD-Xilinx) <git@....com>; git@...inx.com > Subject: Re: [PATCH v2 net-next 2/2] net: macb: Add zynqmp SGMII dynamic > configuration support > > On 29.07.2022 22:35, Radhey Shyam Pandey wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know > > the content is safe > > > > Add support for the dynamic configuration which takes care of > > configuring the GEM secure space configuration registers using EEMI > > APIs. High level sequence is to: > > - Check for the PM dynamic configuration support, if no error proceed with > > GEM dynamic configurations(next steps) otherwise skip the dynamic > > configuration. > > - Configure GEM Fixed configurations. > > - Configure GEM_CLK_CTRL (gemX_sgmii_mode). > > - Trigger GEM reset. > > > > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@....com> > > Reviewed-by: Andrew Lunn <andrew@...n.ch> > > Tested-by: Conor Dooley <conor.dooley@...rochip.com> (for MPFS) > > --- > > Changes for v2: > > - Add phy_exit() in error return paths. > > --- > > drivers/net/ethernet/cadence/macb_main.c | 25 > > +++++++++++++++++++++++++ > > 1 file changed, 25 insertions(+) > > > > diff --git a/drivers/net/ethernet/cadence/macb_main.c > > b/drivers/net/ethernet/cadence/macb_main.c > > index 4cd4f57ca2aa..517b40ff098b 100644 > > --- a/drivers/net/ethernet/cadence/macb_main.c > > +++ b/drivers/net/ethernet/cadence/macb_main.c > > @@ -38,6 +38,7 @@ > > #include <linux/pm_runtime.h> > > #include <linux/ptp_classify.h> > > #include <linux/reset.h> > > +#include <linux/firmware/xlnx-zynqmp.h> > > #include "macb.h" > > > > /* This structure is only used for MACB on SiFive FU540 devices */ @@ > > -4621,6 +4622,30 @@ static int init_reset_optional(struct platform_device > *pdev) > > "failed to init SGMII PHY\n"); > > } > > > > + ret = zynqmp_pm_is_function_supported(PM_IOCTL, > IOCTL_SET_GEM_CONFIG); > > + if (!ret) { > > + u32 pm_info[2]; > > + > > + ret = of_property_read_u32_array(pdev->dev.of_node, "power- > domains", > > + pm_info, ARRAY_SIZE(pm_info)); > > + if (ret < 0) { > > + phy_exit(bp->sgmii_phy); > > Could you move this to a single exit point and jump in there with goto? > Same for the rest of occurencies. Ok, will make to use of common exit path and send out a new version. > > Also, I notice just now that phy_init() is done only if bp->phy_interface == > PHY_INTERFACE_MODE_SGMII, phy_exit() should be handled only if this is > true, too. If phy interface is not SGMII bp->sgmii_phy would be NULL and calling phy_exit should still be fine as these phy APIs has already a NULL check. > > > + dev_err(&pdev->dev, "Failed to read power management > information\n"); > > + return ret; > > + } > > + ret = zynqmp_pm_set_gem_config(pm_info[1], > GEM_CONFIG_FIXED, 0); > > + if (ret < 0) { > > + phy_exit(bp->sgmii_phy); > > + return ret; > > + } > > + > > + ret = zynqmp_pm_set_gem_config(pm_info[1], > GEM_CONFIG_SGMII_MODE, 1); > > + if (ret < 0) { > > + phy_exit(bp->sgmii_phy); > > + return ret; > > + } > > + } > > + > > /* Fully reset controller at hardware level if mapped in device tree */ > > ret = device_reset_optional(&pdev->dev); > > if (ret) { > > -- > > 2.1.1 > >
Powered by blists - more mailing lists