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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <6dc36b74-6982-7fcf-a396-8977f1146c05@kernel.org> Date: Fri, 25 Nov 2022 10:41:58 +0200 From: Roger Quadros <rogerq@...nel.org> To: Andrew Lunn <andrew@...n.ch> Cc: davem@...emloft.net, maciej.fijalkowski@...el.com, kuba@...nel.org, edumazet@...gle.com, pabeni@...hat.com, vigneshr@...com, linux-omap@...r.kernel.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v3 net-next 4/6] net: ethernet: ti: am65-cpsw: Add suspend/resume support On 23/11/2022 19:42, Andrew Lunn wrote: >> +static int am65_cpsw_nuss_ndev_add_tx_napi(struct am65_cpsw_common *common); >> + > > Please move the code around so you don't need this. Ideally as a patch > which only does the move. It is then trivial to review. OK. > >> static void am65_cpsw_port_set_sl_mac(struct am65_cpsw_port *slave, >> const u8 *dev_addr) >> { >> @@ -555,11 +558,24 @@ static int am65_cpsw_nuss_ndo_slave_open(struct net_device *ndev) >> struct am65_cpsw_common *common = am65_ndev_to_common(ndev); >> struct am65_cpsw_port *port = am65_ndev_to_port(ndev); >> int ret, i; >> + u32 reg; >> >> ret = pm_runtime_resume_and_get(common->dev); >> if (ret < 0) >> return ret; >> >> + /* Idle MAC port */ >> + cpsw_sl_ctl_set(port->slave.mac_sl, CPSW_SL_CTL_CMD_IDLE); >> + cpsw_sl_wait_for_idle(port->slave.mac_sl, 100); >> + cpsw_sl_ctl_reset(port->slave.mac_sl); >> + >> + /* soft reset MAC */ >> + cpsw_sl_reg_write(port->slave.mac_sl, CPSW_SL_SOFT_RESET, 1); >> + mdelay(1); >> + reg = cpsw_sl_reg_read(port->slave.mac_sl, CPSW_SL_SOFT_RESET); >> + if (reg) >> + dev_info(common->dev, "mac reset not yet done\n"); > > Should that be dev_info()? dev_dbg() Do you think we should error out here as this might indicate some hardware malfunction and it is unlikely to work? In that case dev_err() seems more appropriate? > > Andrew cheers, -roger
Powered by blists - more mailing lists