From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ABA872DC34E; Tue, 27 Jan 2026 16:07:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769530046; cv=none; b=JCQ3W3E29+k8g3IgyWC6qzV5WdhCjgs6HV/Ius3J9yd0GdWI51S2DDCtzuVAF2/rTv1lekw0AkfLKtWPPMBKOph259htJOtsQoNVbqRlhj7/G+JGiGaVsx50XNYkMIYwOYr/e/spkvKp24X6isCgmPR0wzyaV3L8SSuBp4oKZj8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769530046; c=relaxed/simple; bh=NY9cb+akJlTJ+NzsdrBYWtGImGb9ceHiU09JJg2Gbts=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DX+lfxYf7vKx74xvLgPH4PqMs8WGEcmDdZZEQuA38sYHL6Qr9ncUy2VwtyAkDUCtOoMrYG7lc1O6KjUqh8Ps0dJUNBIB0GlFxY9HiTX1X49dCLJlmDANYcRt9FR2ZcslO5NshZ5O3JgMXEfyQshTmEbMOPCv8mfznlNMvLRz58s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.99) (envelope-from ) id 1vklb1-000000001UI-27PD; Tue, 27 Jan 2026 16:07:15 +0000 Date: Tue, 27 Jan 2026 16:07:10 +0000 From: Daniel Golle To: Andrew Lunn Cc: Paolo Abeni , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiner Kallweit , Russell King , Simon Horman , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Frank Wunderlich , Chad Monroe , Cezary Wilmanski , Avinash Jayaraman , Bing tao Xu , Liang Xu , Juraj Povazanec , "Fanni (Fang-Yi) Chan" , "Benny (Ying-Tsan) Weng" , "Livia M. Rosu" , John Crispin Subject: Re: [PATCH net-next v8 4/4] net: dsa: add basic initial driver for MxL862xx switches Message-ID: References: <18c6a24eef8617abb5073569fee162f1aa1c06ea.1769053079.git.daniel@makrotopia.org> <5e7c2f9c-bf49-4564-91b3-a639ef1c97d8@lunn.ch> <8f267321-25fc-447f-8ff3-5d5b2d844d30@lunn.ch> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f267321-25fc-447f-8ff3-5d5b2d844d30@lunn.ch> On Tue, Jan 27, 2026 at 04:04:10PM +0100, Andrew Lunn wrote: > > > int mxl862xx_to_zephyr_errno(u16 reg) > > so that would then just be > > return (s16)reg; > > right? > > Yes. +1 Maybe better to check if bit 16~31 is actually zero as well, so int mxl862xx_to_zephyr_errno(int reg) { if (reg >= 0 && reg <= U16_MAX) return (s16)reg; return 0; } or int mxl862xx_to_zephyr_errno(int reg) { if (!(reg & GENMASK(31, 16)) return (s16)reg; return 0; } or something like that. Let me know what you prefer. > > > > > Or did you think to include the handling of the error __mdiodev_c45_read() > > would return, ie. > > int mxl862xx_to_zephyr_errno(int reg) > > { > > if (reg < 0) > > return reg; > > No, that mixes up real linux error codes and Zephyr OS error codes. I thought of that 'int reg' to be the return value of __mdiodev_c45_read(), so if that 32-bit signed int < 0 that means what you get is the error returned from __mdiodev_c45_read(). > > If the MDIO operation fails, you have a real error code you can > return. If the firmware fails, you will want to netdev_err() the > Zephyr error code to aid debug, and then return -EIO. +1 > > > Or actually translating the actual errno to a Linux error code? > > Is it worth the effort? How many times have you seen the firmware > fail? During debugging, it might be useful, but in production? Some of the error values are useful, it *is* good to know whether eg. a bridge cannot be allocated because (for what ever reason) of resource exhaustion (-ENOMEM) or because of otherwise invalid settings (-EINVAL). However, it is true that in production none of that should ever happen. The driver will be able to predict and manage the resources of the switch without ever hitting -ENOMEM, and make sure parameters are valid before passing anything to the firmware. And even during development it is good enough to see the error number in the netdev_err() output.