On 6/17/24 18:02, Andrew Lunn wrote: > [Some people who received this message don't often get email from > and...@lunn.ch. Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > > On Mon, Jun 17, 2024 at 04:05:57PM +0200, Markus Elfring wrote: >> … >>> +++ b/drivers/net/ethernet/intel/hbl_cn/common/hbl_cn.c >>> @@ -0,0 +1,5954 @@ >> … >>> +int hbl_cn_read_spmu_counters(struct hbl_cn_port *cn_port, u64 out_data[], >>> u32 *num_out_data) >>> +{ >> … >>> + mutex_lock(&cn_port->cnt_lock); >>> + rc = port_funcs->spmu_sample(cn_port, *num_out_data, out_data); >>> + mutex_unlock(&cn_port->cnt_lock); >>> + >>> + return rc; >>> +} >> … >> >> Would you become interested to apply a statement like >> “guard(mutex)(&cn_port->cnt_lock);”? >> https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/mutex.h#L196 > > Hi Markus > > We decided for netdev that guard() was too magical, at least for the > moment. Lets wait a few years to see how it pans out. scoped_guard() > is however O.K. > > Andrew
Thanks for the reference. I don't see any other Ethernet driver that uses these so let me first handle the necessary changes and later on I'll check optional enhancements. But yeah, we are always open to improve the code.
