lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A765B125120D1346A63912DDE6D8B6315EE059@NTXXIAMBX02.xacn.micron.com>
Date:	Thu, 27 Nov 2014 05:55:43 +0000
From:	bpqw <bpqw@...ron.com>
To:	Brian Norris <computersforpeace@...il.com>
CC:	Marek Vasut <marex@...x.de>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"shijie8@...il.com" <shijie8@...il.com>,
	"geert+renesas@...der.be" <geert+renesas@...der.be>,
	"grmoore@...era.com" <grmoore@...era.com>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	bpqw <bpqw@...ron.com>
Subject: RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for
 Micron spi nor

>First of all, can you fix your mail so that you have a proper 'From'?
>That should be your real name (not bpqw), so that it gives a proper patch author. 
>If you can't get your mail header to have the right 'From:' line, then it also works to begin your mail with:

Sorry for this confusion. This bpqw email is our software public mailbox dedicated to submit linux patch.
Because our personal email title include Chinese name, this will result to messy code in from item.
I have ever submit one patch many times by my personal mail, but I always didn't accept maintainer's response.
So I think, maybe my patch with Chinese name has been moved into maintainer's junk folder.

I don't know my mail from-field with Chinese name can or not be accepted, if can, 
I will submit next version patch by my personal mail.
 
>> This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
>> 
>> For Micron SPI NOR flash,enabling or disabling quad I/O protocol is 
>> controlled by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
>> When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O mode.

>What's the difference between using EVCR and the ENTER QUAD I/O MODE
>(35h) command I see in some of your datasheets? Are both supported on all Micron quad I/O SPI NOR flash?

There is no difference between using EVCR and the ENTER QUAD I/O MODE command.
But, for some Micron spi nor, there no ENTER Quad I/O command(35h),such as n25q064.
for all current Micron spi nor, if it support quad I/O mode, Using EVCR definitely be supported.
So, we recommend that enable QUAD I/O mode by writing ECVR.
  

>Also, which SPI NOR is this enabled for? I don't see any Micron entries in spi_nor_ids[] which contain the SPI_NOR_QUAD_READ flag.

Yes, we now don't see any Micron entries in spi_nor_ids[] which contain the SPI_NOR_QUAD_READ flag.
But Micron spi nor in spi_nor_ids[] all support Quad I/O mode. maybe customer want to use default mode(extended I/O mode),
When submitted relevant patch, they didn't SPI_NOR_QUAD_READ flag in the spi_nor_ids[].
This patch is just for wanting to enable Micron Quad I/O mode.


>> Signed-off-by: bean huo <beanhuo@...ron.com>
>> Acked-by: Marek Vasut <marex@...x.de>
>> ---
>>  v1-v2:
>> 	Modified to that capture wait_till_ready()
>> 	return value,if error,directly return its
>> 	the value.
>>  v2-v3:
>> 	Directly use the reurning error value of
>> 	read_reg and write_reg,instead of -EINVAL.
>>  v3-v4:
>> 	Modify commit logs that wraped into 80 columns
>>  v4-v5:
>> 	Rebuild new patch based on latest linux-mtd

>Please rebase on l2-mtd.git. Sorry if that wasn't clear earlier.

OK,I will rebase it and sumbit a new version. Thanks for your suggestion.

>> +		dev_err(nor->dev,
>> +			"error while writing EVCR register\n");

>Join the above two lines?

Will be fixed it in the next version.

>> +		return ret;
>> +	}
>> +
>> +	ret = wait_till_ready(nor);

>It's spi_nor_wait_till_ready(), now.

OK, will be fixed it.

>>  
>>  #define SR_QUAD_EN_MX		0x40	/* Macronix Quad I/O */
>>  
>> +#define EVCR_QUAD_EN_MICRON    0x80    /* Micron Quad I/O */

>Like with other register bitfields (SR, FSR), please place a comment above to describe the register, like:


OK, will be fixed it.

>Brian

All in all ,thanks for your response and valuable suggestions.
I will rebuild a new version, and submit it .

---Bean Huo---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ