MEMGETREGIONCOUNT ioctl

MEMGETREGIONCOUNT ioctl

[Jitendra Jain]

Hi All,
 
I am trying to get some information regarding my NAND device on board
through the MEMGETREGIONCOUNT and the MEMGETREGIONINFO ioctls. What
troubles me is that the mtd/util application "flash_info" also doesnt
come to my rescue.
 
As per the driver, the MEMGETREGIONCOUNT returns the parameter
numeraseregions, which is meant to signify if the flash erase size is
same throughout or whether it has variable sized sectors (which is found
on NOR flash devices). Why does the util denote that number as number of
erase regions ??
 
Next, the MEMGETREGIONINFO seems to copy arguments from User to the
kernel which I dont understand. This is meant to give the User
information so, it ought to be copy_to_user.
 
Please excuse me if I am wrong on both the above accounts, but i would
be glad if anybody would let me know about that...
 
Thanx,

Regards
Jitendra Jain,

 



eInfochips Business Disclaimer:
This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc("eInfochips") unless sent with that express intent and with due authority of eInfochips. eInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.

RE: MEMGETREGIONCOUNT ioctl

[Gavin Lambert]

I'm a bit of an MTD newbie myself, so I could be wrong about some of
this, but:

Quoth Jitendra Jain [jitendra.jain@einfochips.com]:
> As per the driver, the MEMGETREGIONCOUNT returns the
> parameter numeraseregions, which is meant to signify if the
> flash erase size is same throughout or whether it has
> variable sized sectors (which is found on NOR flash devices).
> Why does the util denote that number as number of erase regions ??

Because that's sort of what it is.  If your driver doesn't support the
ioctl at all then callers assume the erase size is constant as given in
the erasesize field of MEMGETINFO.  If it does support the ioctl, then
callers expect it to return the number of erase block size-change
thresholds (since a region can cover multiple erase blocks, provided
they're contiguous and of the same size).

> Next, the MEMGETREGIONINFO seems to copy arguments from User
> to the kernel which I dont understand. This is meant to give
> the User information so, it ought to be copy_to_user.

It's bidirectional.  It has to first copy to the kernel so that the
kernel can read the regionindex field and find out which region the user
wants to know about.  Then once it's filled in the rest of the
kernel-side structure it needs to copy that back to userspace.

Re: MEMGETREGIONCOUNT ioctl

[MikeW]

Gavin Lambert <gavinl <at> compacsort.com> writes:

> 
> I'm a bit of an MTD newbie myself, so I could be wrong about some of
> this, but:
> 
> Quoth Jitendra Jain [jitendra.jain <at> einfochips.com]:
> > As per the driver, the MEMGETREGIONCOUNT returns the
> > parameter numeraseregions, which is meant to signify if the
> > flash erase size is same throughout or whether it has
> > variable sized sectors (which is found on NOR flash devices).
> > Why does the util denote that number as number of erase regions ??
> 
> Because that's sort of what it is.  If your driver doesn't support the
> ioctl at all then callers assume the erase size is constant as given in
> the erasesize field of MEMGETINFO.  If it does support the ioctl, then
> callers expect it to return the number of erase block size-change
> thresholds (since a region can cover multiple erase blocks, provided
> they're contiguous and of the same size).

Perhaps this suggests that the ioctl documentation could be made
clearer or more explicit in this area ...

Regards,
MikeW



=gmane-pad==gmane-pad==gmane-pad==gmane-pad==gmane-pad==gmane-pad=