Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
In-Reply-To: <YzXdhVN/Zp7DDIzB@google.com>
References: <YsLhxx+L3+GJDRyO@google.com> <Ys1tYAO39LKzEAOE@google.com>
 <dc737abb-041b-491a-14f1-a584f9e64a3d@quicinc.com> <CAE-0n528QaTtZFp=WAaHShegFRpKVN_67jQfUJTtsRPr6s--zA@mail.gmail.com>
 <52039cd1-4390-7abb-d296-0eb7ac0c3b15@quicinc.com> <Yuz2O+lZ5W7RviuA@google.com>
 <CAE-0n507SLeYB7XVzGFk=RO6YjOPoGpux+_N2AyrmL354mQJ-g@mail.gmail.com>
 <YzQf7hf15vvLeGse@google.com> <CAE-0n50cX5ky3By976RTecKkpeMoAjoBA4tYuWSZ150JfS9wiQ@mail.gmail.com>
 <YzXdhVN/Zp7DDIzB@google.com>
From:   Stephen Boyd <swboyd@chromium.org>
User-Agent: alot/0.10
Date:   Mon, 3 Oct 2022 11:47:01 -0700
Message-ID: <CAE-0n53q-8u16_7KGZ0jbm9ES=dsSJL7rbGdz6hzLWf3xvm=bQ@mail.gmail.com>
Subject: Re: [PATCH V15 6/9] mfd: pm8008: Use i2c_new_dummy_device() API
To:     Lee Jones <lee@kernel.org>
Cc:     Lee Jones <lee.jones@linaro.org>,
        Satya Priya Kakitapalli <quic_c_skakit@quicinc.com>,
        Mark Brown <broonie@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, quic_collinsd@quicinc.com,
        quic_subbaram@quicinc.com, quic_jprakash@quicinc.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Quoting Lee Jones (2022-09-29 11:01:41)
> On Wed, 28 Sep 2022, Stephen Boyd wrote:
>
> > Quoting Lee Jones (2022-09-28 03:20:30)
> > > Wouldn't it make more sense to simply separate the instantiation of
> > > the 2 I2C devices?  Similar to what you suggested [0] in v9.  That way
> > > they can handle their own resources and we can avoid all of the I2C
> > > dummy / shared Regmap passing faff.
> > >
> > > [0] https://lore.kernel.org/all/CAE-0n53G-atsuwqcgNvi3nvWyiO3P=pSj5zDUMYj0ELVYJE54Q@mail.gmail.com/
> > >
> >
> > You can continue reading the thread[1]. My understanding is it's one
> > chip that responds on two i2c addresses, thus we don't describe that as
> > two i2c device nodes in DT. Instead we describe one node and use the
> > dummy API to make the second i2c device.
> >
> > [1] https://lore.kernel.org/all/Yk3NkNK3e+fgj4eG@sirena.org.uk/
>
> As Mark says, it's probably 2 separate dies that have been encased in
> the same IC and are otherwise unconnected.  Not sure I understand the
> comment about not requiring another 'struct device'.  It will still
> require that whether it's a platform device or an I2C device, right?
>

Yes a 'struct device' will be required for each i2c address no matter
what happens.

It is also useful to describe the hardware as one device node in case
there is a shared reset signal or power supply. That allows us to have
one driver probe the DT node and deassert the reset/power the chip on. I
think this device has one reset signal, so we really need to do this and
not treat them as completely independent i2c devices (the 0x8 and 0x9
addresses).

Can we move forward with my plan to have another i2c device made for
'pm8008-regulators' and have that driver be an i2c driver that probes an
i2c device manually created in the pm8008 driver? I think that would
handle the reset ordering problem because the pm8008 driver can deassert
the reset and also handle the regmap passing stuff by letting the i2c
device at 0x9 make its own regmap.