From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 765F7C04A6A for ; Mon, 24 Jul 2023 07:09:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) id 39657C43215; Mon, 24 Jul 2023 07:09:25 +0000 (UTC) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.kernel.org (Postfix) with ESMTPS id C1B2EC433D9; Mon, 24 Jul 2023 07:09:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.kernel.org C1B2EC433D9 Authentication-Results: smtp.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.kernel.org; spf=pass smtp.mailfrom=bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 6C2E524000E; Mon, 24 Jul 2023 07:09:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1690182552; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0OTdgWQ6Vo/4tl1ZM7En0YdjITPLKGIP2IIxkkPFJRM=; b=iC5ZIY44VFrCSUNoeMIdYmOyqSrlrW7N4tyY+Hq53oXBVph3jCQ5ij8fsDynsYh6NybKfF 47iBUwR964ggu52YB13yaU1E18wok2aDQAXdbpXfZnCVzqeybMcvNBEm04M8MJv49vz912 60p20TKBhztddQMV6EZbSo0vTLzFb3Ok+FWErn92iDiDFjDyPmqRh1JKdYw5xT3hwpwVlV u4k2GthKUnBFuRNrRP/XoPSerupU1HIaiVySzO/QpWk35FaiLI3dwdIhQ2brWGTyOPPUCM 8E3/Ier83smwYkYCv/LsZ20OWFpB5I2g8A5epoX659Pa/Omr3Rckh60nqnZ+5A== Date: Mon, 24 Jul 2023 09:09:02 +0200 From: Miquel Raynal To: Andy Shevchenko List-Id: Cc: nikita.shubin@maquefel.me, Hartley Sweeten , Lennert Buytenhek , Alexander Sverdlin , Russell King , Lukasz Majewski , Linus Walleij , Bartosz Golaszewski , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michael Turquette , Stephen Boyd , Daniel Lezcano , Thomas Gleixner , Alessandro Zummo , Alexandre Belloni , Wim Van Sebroeck , Guenter Roeck , Sebastian Reichel , Thierry Reding , Uwe =?UTF-8?B?S2xlaW5lLUvDtm5pZw==?= , Mark Brown , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vinod Koul , Richard Weinberger , Vignesh Raghavendra , Damien Le Moal , Sergey Shtylyov , Dmitry Torokhov , Arnd Bergmann , Olof Johansson , soc@kernel.org, Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Michael Peters , Kris Bahnsen , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-rtc@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-pm@vger.kernel.org, linux-pwm@vger.kernel.org, linux-spi@vger.kernel.org, netdev@vger.kernel.org, dmaengine@vger.kernel.org, linux-mtd@lists.infradead.org, linux-ide@vger.kernel.org, linux-input@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [PATCH v3 24/42] mtd: nand: add support for ts72xx Message-ID: <20230724090902.679ea56d@xps-13> In-Reply-To: References: <20230605-ep93xx-v3-0-3d63a5f1103e@maquefel.me> <20230605-ep93xx-v3-24-3d63a5f1103e@maquefel.me> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Hi Andy, > > +static int ts72xx_nand_attach_chip(struct nand_chip *chip) > > +{ > > + switch (chip->ecc.engine_type) { > > + case NAND_ECC_ENGINE_TYPE_SOFT: > > + if (chip->ecc.algo =3D=3D NAND_ECC_ALGO_UNKNOWN) > > + chip->ecc.algo =3D NAND_ECC_ALGO_HAMMING; > > + break; > > + case NAND_ECC_ENGINE_TYPE_ON_HOST: > > + return -EINVAL; > > + default: =20 >=20 > > + break; =20 >=20 > Here it will return 0, is it a problem? Seems ok, there are two other situations: on-die ECC engine and no ECC engine, both do not require any specific handling on the controller side. >=20 > > + } > > + > > + return 0; > > +} =20 >=20 > ... >=20 > > +static void ts72xx_nand_remove(struct platform_device *pdev) > > +{ > > + struct ts72xx_nand_data *data =3D platform_get_drvdata(pdev); > > + struct nand_chip *chip =3D &data->chip; > > + int ret; > > + > > + ret =3D mtd_device_unregister(nand_to_mtd(chip)); =20 >=20 > > + WARN_ON(ret); =20 >=20 > Why?! Is it like this in other MTD drivers? Yes, we did not yet change the internal machinery to return void, and we don't want people to think getting errors there is normal. > > + nand_cleanup(chip); > > +} =20 >=20 Thanks, Miqu=C3=A8l