Thread (27 messages) read the whole thread 27 messages, 2 authors, 2015-02-24

[PATCH v3 08/13] mtd: st_spi_fsm: Update the JEDEC probe to handle extended READIDs

From: computersforpeace@gmail.com (Brian Norris)
Date: 2015-02-06 02:11:34
Also in: lkml

On Wed, Jan 21, 2015 at 01:02:04PM +0000, Lee Jones wrote:
On Mon, 12 Jan 2015, Brian Norris wrote:
quoted
On Mon, Dec 15, 2014 at 11:59:15AM +0000, Lee Jones wrote:
quoted
The previous code was based on 3-byte JEDEC IDs, with a possible 2-byte
extension.  However, devices are now emerging that return 6 or more bytes of
READID data and the additional bytes are required to differentiate between
variants or generations of similar devices.

This patch refactors the device table and JEDEC probe code to handle arbitrary
length READIDs, with the standard JEDEC definition now becoming a special case.
Functionally, there should be no change in behaviour.  A subsequent patch will
update the table with extended READIDs where applicable.
BTW, how's that promise going, where you work on adapting this driver to
the spi-nor framework? We've already done some of this same work there.
I have pushed this point within ST and someone has agreed to do the
work.  Last I heard it relied on these patches, but I'll ask again.
OK.
quoted
quoted
+#define RDID(...) __VA_ARGS__  /* Dummy macro to protect array argument. */
What? What needs "protected"?
You're asking me questions I can't answer I'm afraid and Angus has now
left the building.  I guess he thinks __VA_ARGS__ will prevent some
kind of overflow?
If you don't understand your own code, how can I be expected to maintain
it? This one's pretty trivial and harmless, but an accumulation of
answers like this don't exactly put me in a good mood.

FWIW, I expect the comment has nothing to do with the __VA_ARGS__; it's
just commenting that he has placed a macro around the array just in case
somebody needs/wants to rearrange formats later. That way, we don't
necessarily have to rewrite the whole table, but can just change the
macros.

So the __VA_ARGS__ is just there to make the compiler happy (it thinks
an array argument to a macro actually looks like more than one
argument), and the comment is only mildly descriptive of its purpose.

Brian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help