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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 273BFC77B7D for ; Mon, 15 May 2023 21:33:34 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 242BE86074; Mon, 15 May 2023 23:33:32 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=amarulasolutions.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=amarulasolutions.com header.i=@amarulasolutions.com header.b="lYsojbw2"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 16123857D5; Mon, 15 May 2023 23:33:31 +0200 (CEST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 193CF86615 for ; Mon, 15 May 2023 23:33:26 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=amarulasolutions.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@amarulasolutions.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-966287b0f72so2040654466b.0 for ; Mon, 15 May 2023 14:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; t=1684186405; x=1686778405; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/X2/EVQ5ef5KWbAkh3KDsKgIu6UQHfYuCXupZpqLKlk=; b=lYsojbw2vfjekuzUg8cHkY8UAIeweacHzsHTU1+wg921Jd9dU4+qeGads61G0YYal3 YJVEBfCv1QjWL4fjHhfJZOIOBjemQRNsZrNLY2bwlvycPfZn9j5RxM84VHfUL8WoH32x OYTTbu6T0d+hj5P/z7I+XQZ7It5uNnRb2CuyY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684186405; x=1686778405; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/X2/EVQ5ef5KWbAkh3KDsKgIu6UQHfYuCXupZpqLKlk=; b=DHVtkoGnhuJAGiwxbAPcEqw5zpXE4tNz8Wz4QSyEw5If0el8Dsu4cssZS9VydNghRu a/oJyUccDIiMxsOG8CbvyFoCk5EFk1iIOfj0crEXL2NnkyKrF1feJTma/H35icjqoMzJ RN7XlxE9T4AP4m7D1fuf9gjJBfhdYJKAVxe0smnx2ADkBmb+Yt4xXQkI0dY5BUl46OX1 EQpA3kV9oXxmT6f0ZsT/KGtNzTFiiYu37jggu/tljNlNYv5usuQ1a5cXOPW1WtMvivNC 8xkbt19/f6y2WHS1sTNl5dNyfWhJ5I1EFaeyE3fHv/FT+shBMChDFpdcSq15WougLkse lfbw== X-Gm-Message-State: AC+VfDzENL5F+KNuVdvdbo34UjN6wIYy2i/pMc10laO1BZVXdD0Q40Nh xZpWsqcXC51zY3gzuRPmspgiSm4mWCTRtgWES3KO5w== X-Google-Smtp-Source: ACHHUZ5yrHorUsg2nhz2o9otT+cQVVPdy/BlH3HDJJWX29vPy0e8UqpFXbtopjcfGruu0sMADGciZAEaHKqIj4iZMVo= X-Received: by 2002:a17:906:9b8f:b0:96a:6c3:5e72 with SMTP id dd15-20020a1709069b8f00b0096a06c35e72mr21343212ejc.10.1684186405529; Mon, 15 May 2023 14:33:25 -0700 (PDT) MIME-Version: 1.0 References: <20230110115843.391630-1-frieder@fris.de> <9d83d7ae-a69c-1584-fabf-c2dd0e1d1b67@kontron.de> <20230515211227.GP2398826@bill-the-cat> In-Reply-To: <20230515211227.GP2398826@bill-the-cat> From: Michael Nazzareno Trimarchi Date: Mon, 15 May 2023 23:33:12 +0200 Message-ID: Subject: Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation To: Tom Rini Cc: Frieder Schrempf , Dario Binacchi , Frieder Schrempf , U-Boot-Denx , Jagan Teki , Mikhail Kshevetskiy , Miquel Raynal , Simon Glass , Stefan Roese Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.39 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean Hi Il lun 15 mag 2023, 23:12 Tom Rini ha scritto: > On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote: > > Hi Michael, hi Dario, > > > > On 18.04.23 15:46, Frieder Schrempf wrote: > > > Hi Michael, Dario, > > > > > > On 28.03.23 09:57, Frieder Schrempf wrote: > > >> Hi Michael, > > >> > > >> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote: > > >>> Hi > > >>> > > >>> I will review > > >>> > > >>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini wrote: > > >>>> > > >>>> On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote: > > >>>>> Hi, > > >>>>> > > >>>>> On 10.01.23 12:58, Frieder Schrempf wrote: > > >>>>>> From: Mikhail Kshevetskiy > > >>>>>> > > >>>>>> Currently there are 3 different variants of read_id > implementation: > > >>>>>> 1. opcode only. Found in GD5FxGQ4xF. > > >>>>>> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E > > >>>>>> 3. opcode + 1 dummy byte. Found in other currently supported > chips. > > >>>>>> > > >>>>>> Original implementation was for variant 1 and let detect function > > >>>>>> of chips with variant 2 and 3 to ignore the first byte. This isn't > > >>>>>> robust: > > >>>>>> > > >>>>>> 1. For chips of variant 2, if SPI master doesn't keep MOSI low > > >>>>>> during read, chip will get a random id offset, and the entire id > > >>>>>> buffer will shift by that offset, causing detect failure. > > >>>>>> > > >>>>>> 2. For chips of variant 1, if it happens to get a devid that > equals > > >>>>>> to manufacture id of variant 2 or 3 chips, it'll get incorrectly > > >>>>>> detected. > > >>>>>> > > >>>>>> This patch reworks detect procedure to address problems above. New > > >>>>>> logic do detection for all variants separatedly, in 1-2-3 order. > > >>>>>> Since all current detect methods do exactly the same id matching > > >>>>>> procedure, unify them into core.c and remove detect method from > > >>>>>> manufacture_ops. > > >>>>>> > > >>>>>> This is a rework of Chuanhong Guo patch > > >>>>>> submitted to linux kernel > > >>>>>> > > >>>>>> Signed-off-by: Mikhail Kshevetskiy > > > >>>>>> Signed-off-by: Frieder Schrempf > > >>>>> > > >>>>> +Cc: Jagan, Tom > > >>>>> > > >>>>> Who is supposed to pick up these patches? Some of them have been > around > > >>>>> for some months (before I resent them). > > >>>>> > > >>>>> There is no maintainer for drivers/mtd/spinand/ and no maintainer > for > > >>>>> drivers/mtd/ in general. > > >>>>> > > >>>>> In Patchwork Jagan got assigned, but the get_maintainer.pl script > didn't > > >>>>> even add him to Cc, of course. > > >>>>> > > >>>>> Any ideas how to proceed? > > >>>> > > >>>> We don't have anyone dedicated to that area, yes, sadly. I've added > > >>>> Michael and Dario as they've also been doing mtd-but-not-spi work of > > >>>> late to see if they're interested. Or since you've long been working > > >>>> here, would you like to more formally maintain the area? Thanks! > > >>> > > >>> They can come from our tree. I will try to sort out all my duties > weeked > > >> > > >> Any news regarding reviewing/picking these patches? > > > > > > Ping! > > > > > > Can you please apply these patches, that have been waiting for so long? > > > > I still can't see this applied anywhere. You already told me to take > > care of it multiple times. Can you please get it done? > > Yes, I'd really like to see a PR at least vs -next at this point so > things aren't lost, thanks! > I think that we pick already it so it will happen. Michael > > -- > Tom >