From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Parker Newman <parker@finest.io>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
Parker Newman <pnewman@connecttech.com>
Subject: Re: [PATCH v1 1/6] misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle
Date: Fri, 13 Sep 2024 20:48:03 +0300 [thread overview]
Message-ID: <ZuR600QgWi6oQcau@smile.fi.intel.com> (raw)
In-Reply-To: <d0818651c4a58d0162a898c3ba3dd8abf9f95272.1726237379.git.pnewman@connecttech.com>
On Fri, Sep 13, 2024 at 10:55:38AM -0400, Parker Newman wrote:
> From: Parker Newman <pnewman@connecttech.com>
>
> This patch adds a quirk similar to eeprom_93xx46 to add an extra clock
> cycle before reading data from the EEPROM.
>
> The 93Cx6 family of EEPROMs output a "dummy 0 bit" between the writing
> of the op-code/address from the host to the EEPROM and the reading of
> the actual data from the EEPROM.
>
> More info can be found on page 6 of the AT93C46 datasheet. Similar notes
> are found in other 93xx6 datasheets.
> Link: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-5193-SEEPROM-AT93C46D-Datasheet.pdf
Make it a tag (i.e. locate just above your SoB tag)
> In summary the read operation for a 93Cx6 EEPROM is:
> Write to EEPROM : 110[A5-A0] (9 bits)
> Read from EEPROM: 0[D15-D0] (17 bits)
The mixed TABs/space here (one extra space after :)
> Where:
> 110 is the start bit and READ OpCode
> [A5-A0] is the address to read from
> 0 is a "dummy bit" preceding the actual data
> [D15-D0] is the actual data.
Also leading spaces, please remove them and use TAB, or use spaces only.
> Looking at the READ timing diagrams in the 93Cx6 datasheets the dummy
> bit should be clocked out on the last address bit clock cycle meaning it
> should be discarded naturally.
>
> However, depending on the hardware configuration sometimes this dummy
> bit is not discarded. This is the case with Exar PCI UARTs which require
> an extra clock cycle between sending the address and reading the data.
...
> +static inline bool has_quirk_extra_read_cycle(struct eeprom_93cx6 *eeprom)
> +{
> + return eeprom->quirks & PCI_EEPROM_QUIRK_EXTRA_READ_CYCLE;
> +}
So, this makes sense to be in a header since everything else related to that
also in the header already.
...
> + if (has_quirk_extra_read_cycle(eeprom)) {
> + eeprom_93cx6_pulse_high(eeprom);
No additional delay is needed?
> + eeprom_93cx6_pulse_low(eeprom);
> + }
> + if (has_quirk_extra_read_cycle(eeprom)) {
> + eeprom_93cx6_pulse_high(eeprom);
Ditto.
> + eeprom_93cx6_pulse_low(eeprom);
> + }
...
> +/* Some EEPROMs require an extra clock cycle before reading */
> +#define PCI_EEPROM_QUIRK_EXTRA_READ_CYCLE BIT(0)
I would move it directly into the structure definitions, just after quirk
field (the same way it's done in the other driver)...
...
> int width;
> + unsigned int quirks;
...somewhere here.
> char drive_data;
> char reg_data_in;
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-09-13 17:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 14:55 [PATCH v1 0/6] serial: 8250_exar: Replace custom EEPROM code with eeprom_93cx6 Parker Newman
2024-09-13 14:55 ` [PATCH v1 1/6] misc: eeprom: eeprom_93cx6: Add quirk for extra read clock cycle Parker Newman
2024-09-13 17:48 ` Andy Shevchenko [this message]
2024-09-13 18:24 ` Parker Newman
2024-09-13 18:32 ` Andy Shevchenko
2024-09-13 14:55 ` [PATCH v1 2/6] misc: eeprom: eeprom_93cx6: Switch to BIT() macro Parker Newman
2024-09-13 17:48 ` Andy Shevchenko
2024-09-13 14:55 ` [PATCH v1 3/6] misc: eeprom: eeprom_93cx6: Replace printk(KERN_ERR ...) with pr_err() Parker Newman
2024-09-13 17:54 ` Andy Shevchenko
2024-09-13 19:12 ` Parker Newman
2024-09-13 19:26 ` Andy Shevchenko
2024-09-14 18:58 ` Greg Kroah-Hartman
2024-09-16 9:55 ` Andy Shevchenko
2024-09-16 10:25 ` Greg Kroah-Hartman
2024-09-16 10:32 ` Andy Shevchenko
2024-09-16 12:04 ` Parker Newman
2024-09-16 12:18 ` Andy Shevchenko
2024-09-16 15:20 ` Parker Newman
2024-09-16 15:27 ` Andy Shevchenko
2024-09-13 14:55 ` [PATCH v1 4/6] serial: 8250_exar: Replace custom EEPROM read with eeprom_93cx6 Parker Newman
2024-09-13 18:06 ` Andy Shevchenko
2024-09-14 13:26 ` kernel test robot
2024-09-16 10:09 ` Andy Shevchenko
2024-09-13 14:55 ` [PATCH v1 5/6] serial: 8250_exar: Remove old exar_ee_read() and other unneeded code Parker Newman
2024-09-13 18:07 ` Andy Shevchenko
2024-09-13 14:55 ` [PATCH v1 6/6] serial: 8250_exar: Add select EEPROM_93CX6 in Kconfig Parker Newman
2024-09-13 18:08 ` Andy Shevchenko
2024-09-13 18:10 ` [PATCH v1 0/6] serial: 8250_exar: Replace custom EEPROM code with eeprom_93cx6 Andy Shevchenko
2024-09-13 18:50 ` Parker Newman
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=ZuR600QgWi6oQcau@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=parker@finest.io \
--cc=pnewman@connecttech.com \
/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
all inboxes | Powered by JetHome®