From: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
To: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
linux-kernel@vger.kernel.org,
"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
"Rob Herring" <robh+dt@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Aswath Govindraju" <a-govindraju@ti.com>,
"Vadym Kochan" <vadym.kochan@plvision.eu>,
devicetree@vger.kernel.org
Subject: Re: [PATCH 3/4] misc: eeprom_93xx46: Compute bits based on addrlen
Date: Sat, 24 Apr 2021 15:34:36 +0200 [thread overview]
Message-ID: <YIQebBIPJhivwhhv@latitude> (raw)
In-Reply-To: <20210424123034.11755-4-linkmauve@linkmauve.fr>
[-- Attachment #1: Type: text/plain, Size: 3790 bytes --]
> [PATCH 3/4] misc: eeprom_93xx46: Compute bits based on addrlen
It's not obvious what "bits" and "addrlen" mean, without reading the
code first — can you perhaps rephrase this in a more meaningful (to the
uninitiated) way?
Maybe: Compute command length based on address length
On Sat, Apr 24, 2021 at 02:30:32PM +0200, Emmanuel Gil Peyrot wrote:
> In the read case, this also moves it out of the loop.
I think this patch could use a slightly longer description:
- What's the rough aim of it?
- Is it purely a refactoring, or does it result in different observable
behavior?
>
> Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> ---
> drivers/misc/eeprom/eeprom_93xx46.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c b/drivers/misc/eeprom/eeprom_93xx46.c
> index 39375255e22a..2f4b39417873 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -86,6 +86,7 @@ static int eeprom_93xx46_read(void *priv, unsigned int off,
> struct eeprom_93xx46_dev *edev = priv;
> char *buf = val;
> int err = 0;
> + int bits;
>
> if (unlikely(off >= edev->size))
> return 0;
> @@ -99,21 +100,21 @@ static int eeprom_93xx46_read(void *priv, unsigned int off,
> if (edev->pdata->prepare)
> edev->pdata->prepare(edev);
>
> + /* The opcode in front of the address is three bits. */
> + bits = edev->addrlen + 3;
> +
> while (count) {
> struct spi_message m;
> struct spi_transfer t[2] = { { 0 } };
> u16 cmd_addr = OP_READ << edev->addrlen;
> size_t nbytes = count;
> - int bits;
>
> if (edev->addrlen == 7) {
> cmd_addr |= off & 0x7f;
> - bits = 10;
> if (has_quirk_single_word_read(edev))
> nbytes = 1;
> } else {
> cmd_addr |= (off >> 1) & 0x3f;
> - bits = 9;
> if (has_quirk_single_word_read(edev))
> nbytes = 2;
> }
The if/else looks bogus as there are now more than two different address
lengths. This if/else seems to conflate two things:
- how the command/address bits should be shifted around to form a proper
command
- whether we're dealing with 8-bit or 16-bit words (nbytes = ...)
> @@ -168,13 +169,14 @@ static int eeprom_93xx46_ew(struct eeprom_93xx46_dev *edev, int is_on)
> int bits, ret;
> u16 cmd_addr;
>
> + /* The opcode in front of the address is three bits. */
> + bits = edev->addrlen + 3;
> +
> cmd_addr = OP_START << edev->addrlen;
> if (edev->addrlen == 7) {
> cmd_addr |= (is_on ? ADDR_EWEN : ADDR_EWDS) << 1;
> - bits = 10;
> } else {
> cmd_addr |= (is_on ? ADDR_EWEN : ADDR_EWDS);
> - bits = 9;
> }
dito.
>
> if (has_quirk_instruction_length(edev)) {
> @@ -221,15 +223,16 @@ eeprom_93xx46_write_word(struct eeprom_93xx46_dev *edev,
> int bits, data_len, ret;
> u16 cmd_addr;
>
> + /* The opcode in front of the address is three bits. */
> + bits = edev->addrlen + 3;
> +
> cmd_addr = OP_WRITE << edev->addrlen;
>
> if (edev->addrlen == 7) {
> cmd_addr |= off & 0x7f;
> - bits = 10;
> data_len = 1;
> } else {
> cmd_addr |= (off >> 1) & 0x3f;
> - bits = 9;
> data_len = 2;
> }
dito.
>
> @@ -311,13 +314,14 @@ static int eeprom_93xx46_eral(struct eeprom_93xx46_dev *edev)
> int bits, ret;
> u16 cmd_addr;
>
> + /* The opcode in front of the address is three bits. */
> + bits = edev->addrlen + 3;
> +
> cmd_addr = OP_START << edev->addrlen;
> if (edev->addrlen == 7) {
> cmd_addr |= ADDR_ERAL << 1;
> - bits = 10;
> } else {
> cmd_addr |= ADDR_ERAL;
> - bits = 9;
> }
dito.
Thank you for cleaning up this driver!
Jonathan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-04-24 13:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-24 12:30 [PATCH 0/4] eeprom-93xx46: Add support for Atmel AT93C56 and AT93C66 Emmanuel Gil Peyrot
2021-04-24 12:30 ` [PATCH 1/4] misc: eeprom_93xx46: Add new at93c56 and at93c66 compatible strings Emmanuel Gil Peyrot
2021-04-24 13:02 ` Jonathan Neuschäfer
2021-04-24 12:30 ` [PATCH 2/4] misc: eeprom_93xx46: set size and addrlen according to the dts Emmanuel Gil Peyrot
2021-04-24 13:17 ` Jonathan Neuschäfer
2021-04-24 16:13 ` kernel test robot
2021-04-24 16:13 ` kernel test robot
2021-04-24 12:30 ` [PATCH 3/4] misc: eeprom_93xx46: Compute bits based on addrlen Emmanuel Gil Peyrot
2021-04-24 13:34 ` Jonathan Neuschäfer [this message]
2021-04-24 12:30 ` [PATCH 4/4] misc: eeprom_93xx46: Switch based on word size, not addrlen Emmanuel Gil Peyrot
2021-04-24 13:42 ` Jonathan Neuschäfer
2021-04-24 21:25 ` [PATCH v2 0/3] eeprom-93xx46: Add support for Atmel AT93C56 and AT93C66 Emmanuel Gil Peyrot
2021-04-24 21:25 ` [PATCH v2 1/3] misc: eeprom_93xx46: Remove hardcoded bit lengths Emmanuel Gil Peyrot
2021-04-26 7:46 ` Jonathan Neuschäfer
2021-04-24 21:25 ` [PATCH v2 2/3] misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings Emmanuel Gil Peyrot
2021-04-26 7:56 ` Jonathan Neuschäfer
2021-04-24 21:25 ` [PATCH v2 3/3] dts: eeprom-93xx46: Add support for 93C46, 93C56 and 93C66 Emmanuel Gil Peyrot
2021-04-26 8:02 ` Jonathan Neuschäfer
2021-05-03 18:56 ` Rob Herring
2021-05-11 21:07 ` [PATCH v3 0/3] eeprom-93xx46: Add support for Atmel AT93C56 and AT93C66 Emmanuel Gil Peyrot
2021-05-11 21:07 ` [PATCH v3 1/3] misc: eeprom_93xx46: Remove hardcoded bit lengths Emmanuel Gil Peyrot
2021-05-11 21:07 ` [PATCH v3 2/3] misc: eeprom_93xx46: Add new 93c56 and 93c66 compatible strings Emmanuel Gil Peyrot
2021-05-11 21:07 ` [PATCH v3 3/3] dt-bindings: eeprom-93xx46: Add support for 93C46, 93C56 and 93C66 Emmanuel Gil Peyrot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YIQebBIPJhivwhhv@latitude \
--to=j.neuschaefer@gmx.net \
--cc=a-govindraju@ti.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linkmauve@linkmauve.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=vadym.kochan@plvision.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.