| Message ID | 1327563110-23966-2-git-send-email-computersforpeace@gmail.com |
|---|---|
| State | Accepted |
| Commit | fb3281d740b4d222746e5e366732d414038c951e |
| Headers | show |
On Thursday 26 January 2012 08:31:50 Brian Norris wrote: > When we have assigned non-consecutive device numbers to our UBI devices [...] > This patch adds a check to first see if device is present, then continue > to the next ID if it doesn't exist. >[ ... ] Looks Ok to me (when used with part 1). However, looking at the mtd-utils v1.4.6 ‘mtdinfo.c’, is there a similar issue there? But I have no idea how you could get non-consecutive MTD device numbers? cheers! -blf-
On Thu, Jan 26, 2012 at 12:53 AM, Brian Foster <brian.foster@maxim-ic.com> wrote: > On Thursday 26 January 2012 08:31:50 Brian Norris wrote: >> When we have assigned non-consecutive device numbers to our UBI devices [...] >> This patch adds a check to first see if device is present, then continue >> to the next ID if it doesn't exist. >>[ ... ] > > Looks Ok to me (when used with part 1). > > However, looking at the mtd-utils v1.4.6 ‘mtdinfo.c’, > is there a similar issue there? But I have no idea > how you could get non-consecutive MTD device numbers? Yeah, there is a problem there. It's a little more difficult to see, but it can happen. Suppose you have /dev/mtd0 on your system, then you can get an error with the following sequence: # modprobe mtdram # modprobe nandsim # rmmod mtdram # mtdinfo --all ... mtdinfo: error!: mtd1 does not correspond to any existing MTD device I'm sending a quick patch set for this. Brian
On Friday 27 January 2012 19:28:59 Brian Norris wrote: > On Thu, Jan 26, 2012 at 12:53 AM, Brian Foster <brian.foster@maxim-ic.com> wrote: > > [ ... ] looking at the mtd-utils v1.4.6 ‘mtdinfo.c’, > > is there a similar issue there? But I have no idea > > how you could get non-consecutive MTD device numbers? > > Yeah, there is a problem there. It's a little more difficult to see, > but it can happen. > > Suppose you have /dev/mtd0 on your system, then you can get an error > with the following sequence: > > # modprobe mtdram > # modprobe nandsim > # rmmod mtdram > # mtdinfo --all > ... > mtdinfo: error!: mtd1 does not correspond to any existing MTD device Ah, Ok! I had a similar thought over the weekend, and before seeing your e-mail tried to set-up the situation up on one of our SoC evaluation boards, using our H/W drivers. But for some reason those drivers won't unload — I should look into that — and then saw your e-mails .... > I'm sending a quick patch set for this. Yeah, saw it, seemed Ok to me. Thanks. cheers! -blf-
diff --git a/ubi-utils/ubinfo.c b/ubi-utils/ubinfo.c index 7aa4aa4..cb88f53 100644 --- a/ubi-utils/ubinfo.c +++ b/ubi-utils/ubinfo.c @@ -362,6 +362,8 @@ static int print_general_info(libubi_t libubi, int all) for (i = ubi_info.lowest_dev_num; i <= ubi_info.highest_dev_num; i++) { + if (!ubi_dev_present(libubi, i)) + continue; if(!first) printf("\n===================================\n\n"); first = 0;
When we have assigned non-consecutive device numbers to our UBI devices, then we run `ubinfo --all', we get errors once ubinfo tries to process the devices in the "hole". For instance, suppose there are two UBI devices, /dev/ubi0 and /dev/ubi10; then, ubinfo will fail trying to open /dev/ubi1 with: ubinfo: error!: cannot get information about UBI device 1 error 2 (No such file or directory) This patch adds a check to first see if device is present, then continue to the next ID if it doesn't exist. Reported-by: Brian Foster <brian.foster@maxim-ic.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> --- ubi-utils/ubinfo.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)