Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 18 Mar 2021 06:59:36 +0100
From:   Wolfram Sang <wsa@kernel.org>
To:     Bence =?utf-8?B?Q3PDs2vDoXM=?= <bence98@sch.bme.hu>
Cc:     linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Adding i2c-cp2615: i2c support for Silicon Labs'
 CP2615 Digital Audio Bridge
Message-ID: <20210318055936.GD1053@kunai>
Mail-Followup-To: Wolfram Sang <wsa@kernel.org>,
        Bence =?utf-8?B?Q3PDs2vDoXM=?= <bence98@sch.bme.hu>,
        linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20210317103021.1913858-1-bence98@sch.bme.hu>
 <20210317123344.GD1315@ninjato>
 <CACCVKEF-R1zvr2=AKf_a0vxQodbT0_CFnu0pWMrBZ3EjxteL5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs"
Content-Disposition: inline
In-Reply-To: <CACCVKEF-R1zvr2=AKf_a0vxQodbT0_CFnu0pWMrBZ3EjxteL5g@mail.gmail.com>
Precedence: bulk


--eheScQNz3K90DVRs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Bence,

> You are right, sorry, I am still familiarizing myself with `git send-emai=
l`

No worries, the progress from your first to your second version was
really great! You can add such information e.g. using the "--annotate"
parameter og git-send-email.

> GPLv2 or later is fine by me. If I change this to "//
> SPDX-License-Identifier: GPL-2.0-or-later", is that OK?

Yes, also perfect.

> > > + * FIXME: There in no quirk flag for specifying that the adapter
> > > + * does not support empty transfers, or that it cannot emit a
> >
> > Can't we use I2C_AQ_NO_ZERO_LEN here?
>=20
> I thought that meant the adapter cannot handle NEITHER zero-length
> reads NOR writes, but the CP2615 can do a zero read combined with a
> non-zero write or the other way around, just both cannot be zero. If
> both are zero, the chip just ignores the request, as I've learned from
> a very confusing situation with `i2cdetect`.

I think we still should use I2C_AQ_NO_ZERO_LEN. The almost only use case
is a standalone zero-len read or write. This is not supported by your
adapter as you found out.

> > True! But it makes sense, so we can fix that. We just need to add
> > I2C_AQ_NO_REP_START and a short explanation to i2c.h. If you want, you
> > can do it in a seperate patch. I can do it, too, if you prefer.
>=20
> Sure! I should just define it as BIT(7) or something, right? Should I
> do it in a completely different patchset, or is it OK if I submit it
> as the 2/2 of PATCH v3? Are there maybe other adapters that would be

Yes, BIT(7) and same patchset please. But you need to make it 1/2
because you will use it in you driver which is then 2/2.

> affected?

Maybe, but we can fix them later incrementally. Currently, there is also
no client testing the flag, so we have a bit of time here.

> > Maybe skip the defines for VID and PID and use the values directly?
> > I am not a USB expert, not really sure what the consistent way is.
>=20
> I think this is how they usually do it, or at least from what I've seen.

Then keep it.

All the best and happy hacking,

   Wolfram


--eheScQNz3K90DVRs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmBS7EgACgkQFA3kzBSg
KbbuGA/+KaucbDtzrYePhtEGS3aTaStyBejDo54Aj9uA/tFEVQtcrdMAB5rtqueV
//CAwia6o17aBI6m8AOpzE2xzuQtoEBCHTGjzS3/89ze1c5KM6c/rgxVWvwn5jP1
YioB4WK/2Xn2w5Z2yYbC1Mt/39RJ57RrYVXoVs496g0ZLWvtMWLGiv2BBy7pm+jm
hpcBBRT82WAI9hzSL29DG6rbAGqJBBCXdPpmFs5qz5ggZJlnUYGhlTawFnaBpj1D
QMSt0jFN/H4mJ5eIxJY5l9lQpEVYP/ByFjBfALS9jT/UrqiLhevhhMjoPQdSgGhQ
GaUbGseDOwEcAumluTcxxZD5upocjevwAUC75w0GbQ2GhNmE88cHT/oAeta9wAPl
H/UioCX+3NYFlRGLhM8KWKfIKDnyawpg0JBjl/SjbknSbdG/1RWMwyg7+JokUOuc
SQEIYgSpErVJvNrsBC9Vluwjvyqki/WBln4k1Lxh5xJHub6LO6mwU6U3ah4HRNFf
ZRFBxB0Y38fteY0li7e8ib2jpJm3+6o2EoMuA5/gzZGJGs5nV226cl4QSZQ6bGPq
c3PFDQveTnEXhk7nIOCd1yN7QX/BezDtg8e3aVIiKn3xwzcZxvLs5RE31chtn0VJ
26Bz2r0gd8l2ovxRNbsMqKp+jTKp168HQ/IMHuntvNys7RWLClE=
=+myQ
-----END PGP SIGNATURE-----

--eheScQNz3K90DVRs--