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 2B7D2C761AF for ; Thu, 30 Mar 2023 08:05:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230110AbjC3IFI (ORCPT ); Thu, 30 Mar 2023 04:05:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230008AbjC3IFF (ORCPT ); Thu, 30 Mar 2023 04:05:05 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7AAF61B4 for ; Thu, 30 Mar 2023 01:04:56 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id c9so13019655lfb.1 for ; Thu, 30 Mar 2023 01:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680163495; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=AlXibMxlWDb3fE7PPlx7SqRIaOU+iY/my4CtWS+AFz0=; b=gOm82s6MR20hI+r3IB7/L5e+uq1Zz3OLh840E7iYyoP2gDecLH48lajqbgYV8NVJvN xPEboB8255TuCoxzCDS2+FESyUM8H0DhzpSgt6mSkF1+zD57sDtkfqqKjdz5imIVuC6f 7Du2uERLeJwYowtYMBIhB9Hcua+RgXPLS7WipJy2D7Lb3gVmOeNQ4r5787/YFt6FiewJ 0x1mjZQeTGeal2MrM9jN8pYGDKU7wrfJZNIizTJnKnAa3SNiPQ5NSgA+SkXVNpxh8rn+ jCOjqHT2gK8MX4yF5DZaiUk4FAGkQARmVJdKtMKnj2vzq9ClK5XtNHyzUvItu1Lj3z2o 3AyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680163495; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AlXibMxlWDb3fE7PPlx7SqRIaOU+iY/my4CtWS+AFz0=; b=Jgdc4Ba6tZXoW0sKldScly0DVxsv7EOW2TiSoVx2kQhaRzlmT2SSMbk8QqAQzLIYus wd1FuBOSFl+8Np/wf7KwlyMtdU5FpbZ9wx1rRWMfqFVf0Ix9Q9dJAHQJyD1OvwTW5KrB wAq8L419I3zWt9s1/l2OEPEbbDCgkEvg2HpRQaqpOWr8vYXrvpsC72ykZ/Tj2GQGqH5T u+LU3vYTXAbAtnKkDIcCn0/w/9viAcPgk+w8maAtQOyKteINeiEX4/mrELabD8eGocEn oOIXeTIQFjnqzLpJ8zd87Q14OwqzIxORQCD7USFKXYhwznGc1llbffcc6PZtuKW5/uAn 3SGA== X-Gm-Message-State: AAQBX9c8ZGOwdKaZZCvBRTpWv6yIz2FjEOTils/Ck/O0p6853TCUKDgT sfrRXuWA5YP7X7nZzZUn40Iwrg== X-Google-Smtp-Source: AKy350Zv08/gNl3jEoV0yNCaazw9HNMb60MNBg0qFkoa7eUW7f3+7ydFURsCh+73MMnQG62wHJ3aMA== X-Received: by 2002:ac2:4db7:0:b0:4e8:3d0:84b4 with SMTP id h23-20020ac24db7000000b004e803d084b4mr1673498lfe.24.1680163495153; Thu, 30 Mar 2023 01:04:55 -0700 (PDT) Received: from [192.168.0.21] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id q17-20020ac25151000000b004d5a6dcb94fsm5810324lfd.33.2023.03.30.01.04.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Mar 2023 01:04:54 -0700 (PDT) Message-ID: Date: Thu, 30 Mar 2023 10:04:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v6 5/5] mfd: max77541: Add ADI MAX77541/MAX77540 PMIC Support Content-Language: en-US To: Lee Jones , Andy Shevchenko Cc: "Sahin, Okan" , Rob Herring , Krzysztof Kozlowski , Liam Girdwood , Mark Brown , Jonathan Cameron , Lars-Peter Clausen , Cosmin Tanislav , Stephen Boyd , Caleb Connolly , Lad Prabhakar , "Bolboaca, Ramona" , ChiYuan Huang , "Tilki, Ibrahim" , William Breathitt Gray , Arnd Bergmann , ChiaEn Wu , Haibo Chen , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-iio@vger.kernel.org" References: <20230307112835.81886-1-okan.sahin@analog.com> <20230307112835.81886-6-okan.sahin@analog.com> <20230315175223.GI9667@google.com> <20230315175257.GJ9667@google.com> <20230329143615.GS2673958@google.com> <20230329145636.GV2673958@google.com> <20230329150605.GW2673958@google.com> From: Krzysztof Kozlowski In-Reply-To: <20230329150605.GW2673958@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On 29/03/2023 17:06, Lee Jones wrote: > On Wed, 29 Mar 2023, Lee Jones wrote: > >> On Wed, 29 Mar 2023, Andy Shevchenko wrote: >> >>> On Wed, Mar 29, 2023 at 03:36:15PM +0100, Lee Jones wrote: >>>> On Tue, 28 Mar 2023, Sahin, Okan wrote: >>>>>> On Wed, 15 Mar 2023, Lee Jones wrote: >>>>>>> On Tue, 07 Mar 2023, Okan Sahin wrote: >>> >>> ... >>> >>>>> +static const struct i2c_device_id max77541_i2c_id[] = { >>>>> + { "max77540", (kernel_ulong_t)&chip[MAX77540] }, >>>>> + { "max77541", (kernel_ulong_t)&chip[MAX77541] }, >>>> >>>> Just 'MAX77540' is fine. >>> >>> I tend to disagree. >>> >>> There is an error prone approach esp. when we talk with some functions >>> that unifies OF/ACPI driver data retrieval with legacy ID tables. >>> In such a case the 0 from enum is hard to distinguish from NULL when >>> the driver data is not set or not found. On top of that the simple integer >>> in the legacy driver data will require additional code to be added in >>> the ->probe(). >> >> Use a !0 enum? >> >> The extra handling is expected and normal. > > I've always disliked mixing platform initialisation strategies. Passing > pointers to MFD structs through I2C/Device Tree registration opens the > doors to all sorts of funky interlaced nonsense. > > Pass the device ID and then match in C-code please. I agree. Especially that casting through ulong_t drops the const, so the cast back needs const which can be forgotten. The patch already makes here mistake! Best regards, Krzysztof