[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200803165914.GB1094@kunai>
Date: Mon, 3 Aug 2020 18:59:14 +0200
From: <wsa@...nel.org>
To: <Codrin.Ciubotariu@...rochip.com>
Cc: <linux-i2c@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <robh+dt@...nel.org>,
<Ludovic.Desroches@...rochip.com>, <Nicolas.Ferre@...rochip.com>,
<alexandre.belloni@...tlin.com>, <linux@...linux.org.uk>,
<kamel.bouhara@...tlin.com>
Subject: Re: Re: [RFC PATCH 3/4] i2c: core: treat EPROBE_DEFER when acquiring
SCL/SDA GPIOs
> > This is correct but I think the code flow is/was confusing. Can you drop
> > this 'return' and use 'else if' for the next code block? I think this is
> > more readable.
>
> Ok, it makes sense. Should I make a separate patch for this only?
I am fine if this is included in this change.
> One more question, should we keep:
> if (!bri->set_sda && !bri->get_sda) {
> err_str = "either get_sda() or set_sda() needed";
> goto err;
> }
> ?
> Without {get/set}_sda we won't be able to generate stop commands and
> possibly check if the bus is free, but we can still generate the SCL
> clock pulses.
My gut feeling says we need to keep it. I can't recall the reason now
and want to send out this answer ASAP. Anyhow, this definately would be
a seperate patch. If you really want to, send a patch, and then I have
to think why we still need it ;)
> Ok. Perhaps I should also move the debug print with the registered
> adapter after calling i2c_init_recovery().
Yes, makes sense.
> Do you want me to integrate this patch in the previous one?
Nope, please keep it seperate.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists