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 7B3D3CA0FE1 for ; Fri, 1 Sep 2023 07:40:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348492AbjIAHk1 (ORCPT ); Fri, 1 Sep 2023 03:40:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237769AbjIAHk0 (ORCPT ); Fri, 1 Sep 2023 03:40:26 -0400 Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DF0610D5 for ; Fri, 1 Sep 2023 00:40:23 -0700 (PDT) Received: by mail-vk1-xa2e.google.com with SMTP id 71dfb90a1353d-48d2e2e05e7so604930e0c.3 for ; Fri, 01 Sep 2023 00:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1693554022; x=1694158822; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GdSEnSSizczTE8HJIRHe+3r0VQs218gZ30sV8UlBVvo=; b=yZA8qyctQFfw3y8c3bJ/tEmiiWf7nsBvhdEKU8qSr1pvETfeX53fx1Bi8QUCXvz8mj c/m9YJZk/vvWIDLpDyDzs+qfQGC+eksxmZISEU5l32P5BRP99YCNjfzyvEHOAD1GCIXl js9MWZMHU4KDcdtPkoEqel2t+QNHdRCfq6fyUvTxomKHDRqjMcHC7YR3P4rOwhlyuqaJ OAp7gHf6OedwMF28BRAeagTHzSyLtbc+pWGCi1EkSQQjDC1rXNrj8jb/LhITyfxAPXLQ FUKiLC3Qrow90wTEV9nrPIzXcxb9AuA7/jRhGOW/Hpq6WgA4bXvoIbuA6TUNIi8P+Xim lYrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693554022; x=1694158822; h=content-transfer-encoding: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=GdSEnSSizczTE8HJIRHe+3r0VQs218gZ30sV8UlBVvo=; b=RVpLBarG1bwiYRhaiRT19BLSwy8+5kyeA2dEUmFWD1TQlaHHzXNWqCeQrH0NFQFT3i xdZiool2FWI4Obq4kJV6BKFQ4u+FHxFXVJhMj10DylxDgFo3KFMy87BhBBFwWp2+wVEz In0tsK7olydf3+uupK6nHo/yfn2+SR6L1koCHSJbKFLYq8OleS5bMYge2lKa7vKGo3KD nNKzug5gJJ4ewk46zWjT/KVwI8iaYLLq+sxIbVUwuv5GG0pCbZ+p41ah5dH+tfdNGFGP X+8LCjZwUbRVsXaTUkDeNVhJWgmrLAwYk7DXKqL6v0HyGOpPYB/xlmPvYXqfDpBhq+xC kwtQ== X-Gm-Message-State: AOJu0YyUCrgq03MPt6wi5tQ8VxlAbfRwiMhclGwyZo9U1PnxGs5XXODw 1WH+05oOno006GuOlr6axSd/fVJfDZoaIf5WukCngg== X-Google-Smtp-Source: AGHT+IF4/dIUb/yBKlSH666awkw3CGUYKSZGAkFwNTY7ILWywn+c24x4A5D+cmyWsgAnTqUbFGhsKHxztcUzGlh/8wc= X-Received: by 2002:a1f:df01:0:b0:48d:bdd:9913 with SMTP id w1-20020a1fdf01000000b0048d0bdd9913mr2102598vkg.12.1693554022565; Fri, 01 Sep 2023 00:40:22 -0700 (PDT) MIME-Version: 1.0 References: <20230831194934.19628-1-brgl@bgdev.pl> In-Reply-To: From: Bartosz Golaszewski Date: Fri, 1 Sep 2023 09:40:11 +0200 Message-ID: Subject: Re: [RFT PATCH] spi: bcm2835: reduce the abuse of the GPIO API To: Andy Shevchenko Cc: Mark Brown , Florian Fainelli , Linus Walleij , Ray Jui , Scott Branden , Broadcom internal kernel review list , linux-spi@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Sep 1, 2023 at 1:25=E2=80=AFAM Andy Shevchenko wrote: > > On Thu, Aug 31, 2023 at 09:49:34PM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Currently the bcm2835 SPI driver uses functions meant for GPIO provider= s > > exclusively to locate the GPIO chip it gets its CS pins from and reques= t > > the relevant pin. I don't know the background and what bug forced this. > > ... > > > /* > > + * TODO: The code below is a slightly better alternative to the u= tter > > + * abuse of the GPIO API that I found here before. It creates a > > + * temporary lookup table, assigns it to the SPI device, gets the= GPIO > > + * descriptor and then releases the lookup table. > > * > > + * Still the real problem is unsolved. Looks like the cs_gpiods t= able > > + * is not assigned correctly from DT? > > */ > > I'm not sure why this quirk is here. AFAIR the SPI CS quirks are located = in > gpiolib-of.c. > I'm not sure this is a good candidate for the GPIOLIB quirks. This is the SPI setup callback (which makes me think - I should have used gpiod_get(), not devm_gpiod_get() and then put the descriptor in .cleanup()) and not probe. It would be great to get some background on why this is even needed in the first place. The only reason I see is booting the driver with an invalid device-tree that doesn't assign the GPIO to the SPI controller. Bart