[U-Boot] [PATCH] env: Allow accessing non-mtd devices

Lubomir Rintel lkundrak at v3.sk
Thu Feb 7 14:42:32 CET 2013


On Thu, 2013-02-07 at 00:21 +0100, Wolfgang Denk wrote:
> Dear Lubomir Rintel,
> 
> In message <1360191866.3594.10.camel at unicorn> you wrote:
> >
> > > > -		if (mtd_type != MTD_DATAFLASH)
> > > > +		if (mtd_type && mtd_type != MTD_DATAFLASH)
> > > 
> > > This change appears to be redundant.  If mtd_type is null, then this
> > > is already caught iun te test mtd_type != MTD_DATAFLASH, isn't it?
> > 
> > No. We don't want the erase ioctl to be called for non-MTD devices and
> > files (where mtd_type is null).
> 
> I see.  But you are misusing mtd_type.
> 
> You should define something like MTD_NO_FLASH or so, and use that.

I found it a bit more abusive to use a MTD_* macro in mtd_type variable
for something what is not actually a type of a MTD device, specially
when a change in MTD ABI would be needed.

Maybe passing a NULL mtd_info_user pointer to flash_{read,write}_buf()
instead of zero type (which happens to be MTD_ABSENT, and, as you
pointed out, a misuse) would make more sense for a non-MTD file?

> 
> > > > -		perror ("Cannot get MTD information");
> > > > +		perror ("Cannot access MTD device");
> > > 
> > > I don't understand this.  You talk about a MTD device here, but expect
> > > that MEMGETINFO will not work on it?  Please explain in which exact
> > > circumstances such a situation wouldhappen.
> > 
> > The error message (mention of MTD at that point) is incorrect. fstat()
> 
> So it needs to be fixed.

Hopefully fixed in a follow-up patch. I'll follow up with another one
(this time with proper changlog and versioning, sorry for that) once an
acceptable solution to the issue above is agreed upon.

Thanks,
--
Lubo



More information about the U-Boot mailing list