devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2021-04-24 13:34 UTC|newest]

Thread overview: 22+ 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).