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 1CBCEC6FD1F for ; Wed, 8 Mar 2023 19:33:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229720AbjCHTdz (ORCPT ); Wed, 8 Mar 2023 14:33:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbjCHTdu (ORCPT ); Wed, 8 Mar 2023 14:33:50 -0500 Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB754867CA for ; Wed, 8 Mar 2023 11:33:48 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id d7so16419577vsj.2 for ; Wed, 08 Mar 2023 11:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20210112.gappssmtp.com; s=20210112; t=1678304028; 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=elaSW8jK4c19wV80MgoUgZ3YhWwQARYHu+N4OavZYdI=; b=ZT7fEl+nYdAmg9IvsK09c/PS7bt1DvEk5pFH+d6EEBhGoTZvpc1KA7FFuDrDjTsc8a fAA2ZrH4gbwIrF+co/Stl8dTn4GhKT+0FBNAo88O+aWv1TYipAaJ5YLMq2igiwmto7W9 XWG7+ERZqapGkOs21b1AWRBw4kcJ1aZuvmvNj8tfZuxqbk0YbDjMDMDEX92ewIUzYTSh e1t3ZIyyly8r237SQDQJRfxVPu3h61N7SBpIbmX7ZrfnFYAF/0F/WWBp6VFcU3ORaCM3 4oK1SmkHjQeXY6VXDFuwsFOrmdG+I2VR6d1B3Mt+TNGKvFBRZ9yauHdY3E9IzZLsWSx/ vgfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678304028; 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=elaSW8jK4c19wV80MgoUgZ3YhWwQARYHu+N4OavZYdI=; b=ZmcrUakImmPZnV8RY/SauCBHZUQCiXJMyRUPmE2TWfK0sog4qegSznKEQ9lC7GTRg8 /JUPG8r6+5YjlOYdkb1TJkkpDPjwRaVJfjKg/nxx4kbG4AkbSi1fcK9sa/HFmWPZk0mE eYYMRMHoRgAzhTnVQCBeXTClOQz8722GH7c7nl5FEkMu2KI2d5J5Aqx0CHCEJMXPamMC fozEYslxWk5EozfjeKL9miVRPm5Sxs/3rCMg9y98xqKPxFHX794n1rCWech8iybnjS8U c5CFlDq4mi1Snlxm8Olo2hRh/PNXQoJXSlr18uAVfhfzHObtwtA0HiCcxBmkgUdXbzjk BXSg== X-Gm-Message-State: AO0yUKU1yRFOdKCGYm18JuJN88QoEu+hZu73vvgxeboP8t0UF8RVJcG5 uCaaA9ax7Krw5tymRkgxOduA5eXqifrxVoiJ0VOwKw== X-Google-Smtp-Source: AK7set//ZSmUJFzt7Xok9V0kaTPUAwP+t2ISSQ76Tcf33SidVGnU7PJ9KopuOK39cqAnuwfnhNU07V2i5mPO1ddZW5A= X-Received: by 2002:a67:f406:0:b0:414:48a5:473f with SMTP id p6-20020a67f406000000b0041448a5473fmr12895848vsn.0.1678304027775; Wed, 08 Mar 2023 11:33:47 -0800 (PST) MIME-Version: 1.0 References: <20221229160045.535778-1-brgl@bgdev.pl> <20221229160045.535778-2-brgl@bgdev.pl> In-Reply-To: From: Bartosz Golaszewski Date: Wed, 8 Mar 2023 20:33:36 +0100 Message-ID: Subject: Re: [PATCH v2 1/2] i2c: dev: fix notifier return values To: Geert Uytterhoeven Cc: Wolfram Sang , linux-i2c@vger.kernel.org, linux-kernel@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-kernel@vger.kernel.org On Wed, Mar 8, 2023 at 5:58=E2=80=AFPM Geert Uytterhoeven wrote: > > Hi Bartosz, > > On Thu, Dec 29, 2022 at 5:12=E2=80=AFPM Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > We have a set of return values that notifier callbacks can return. They > > should not return 0, error codes or anything other than those predefine= d > > values. Make the i2c character device's callback return NOTIFY_DONE or > > NOTIFY_OK depending on the situation. > > > > Signed-off-by: Bartosz Golaszewski > > Thanks for your patch, which is now commit cddf70d0bce71c2a ("i2c: > dev: fix notifier return values") in v6.3-rc1. > > On SH/R-Mobile platforms, this leads to missing /dev/i2c-* entries. > On R-Car Gen4, they are still present, as all I2C adapters are > initialized after i2cdev. > > > --- a/drivers/i2c/i2c-dev.c > > +++ b/drivers/i2c/i2c-dev.c > > @@ -653,12 +653,12 @@ static int i2cdev_attach_adapter(struct device *d= ev, void *dummy) > > int res; > > > > if (dev->type !=3D &i2c_adapter_type) > > - return 0; > > + return NOTIFY_DONE; > > adap =3D to_i2c_adapter(dev); > > > > i2c_dev =3D get_free_i2c_dev(adap); > > if (IS_ERR(i2c_dev)) > > - return PTR_ERR(i2c_dev); > > + return NOTIFY_DONE; > > > > cdev_init(&i2c_dev->cdev, &i2cdev_fops); > > i2c_dev->cdev.owner =3D THIS_MODULE; > > @@ -678,11 +678,11 @@ static int i2cdev_attach_adapter(struct device *d= ev, void *dummy) > > goto err_put_i2c_dev; > > > > pr_debug("adapter [%s] registered as minor %d\n", adap->name, a= dap->nr); > > - return 0; > > + return NOTIFY_OK; > > Unfortunately i2cdev_{at,de}tach_adapter() are not only used as > notifiers (called from i2cdev_notifier_call()), but also called from > i2c_dev_init(): > > /* Bind to already existing adapters right away */ > i2c_for_each_dev(NULL, i2cdev_attach_adapter); > > and i2c_dev_exit(): > > i2c_for_each_dev(NULL, i2cdev_detach_adapter); > > As soon i2c_dev_{at,de}tach_adapter() returns a non-zero > value (e.g. NOTIFY_OK), {i2c,bus}_for_each_dev() aborts > processing. > > In i2c_dev_init(), this leads to a failure in registering any > already existing i2c adapters after the first one, causing missing > /dev/i2c-* entries. > > In i2c_dev_exit(), this leads to a failure unregistering any but the > first i2c adapter. > > As there is no one-to-one mapping from error codes to notify codes, > I think this cannot just be handled inside i2cdev_notifier_call() :-( > Would wrapping i2c_a/detach_adapter() in a notifier callback work? So that SH can call it directly while notifiers would call it indirectly through the wrapper? Bart