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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5F156C04FE2 for ; Mon, 24 Jul 2023 07:09:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230301AbjGXHJV (ORCPT ); Mon, 24 Jul 2023 03:09:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbjGXHJT (ORCPT ); Mon, 24 Jul 2023 03:09:19 -0400 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::221]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B22C6138; Mon, 24 Jul 2023 00:09:14 -0700 (PDT) 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 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 Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org 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