[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