[PATCH v2 2/4] mtd: nand: convert printk() to pr_*()

[Brian Norris]

Now I'm not sure I entirely understand all your comments :)

On Thu, Jul 7, 2011 at 12:56 PM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> Well, ok, indeed, in the driver level we have no idea about partitions,
> we deal with the flash chip, by design...

What exactly are you referring to? That the inability for drivers to
distinguish between partitions and the master MTD prevents them from
handling our device structure correctly? I thought we're talking
mostly about the NAND layer, not the driver layer.

> Probably we should better use pr_* series of functions instead, I guess,
> as dev_* functions seem to not be really suitable for us. That's what
> you have originally done, sorry for bad suggestion.

OK, I can do that, but first, what about the code I posted earlier for
finding the correct device corresponding to mtd_info?

static inline struct device *mtd_to_dev(struct mtd_info *mtd)
{
       if (device_is_registered(&mtd->dev))
               return &mtd->dev;
       return mtd->dev.parent;
}

I think this would work for any NAND or MTD code, so that we can do
something like this:
     dev_info(mtd_to_dev(mtd), "ONFI flash detected\n");
In NAND/MTD code, we basically have two cases for the current mtd_info:
1) corresponds to the master device, which is not registered. Its
parent should be set to the physical device, so use mtd->dev.parent.
2) corresponds to a partition, which is registered. Use the partition
device &mtd->dev.
There's kind of a third case for non-partitioned flash:
3) corresponds to the master device, which is registered. Use &mtd->dev

These cases should all be covered, and I think the dev_* could would
be just fine. If that's not good enough though, then I'll just go back
to the pr_* code.

> On the other hand, why we cannot pass the partition struct mtd_info down
> to the driver instead? Well, ideally, drivers should not use struct
> mtd_info at all. But this is probably a different story...

Not quite sure where this is coming from. I don't believe I asked
about passing mtd_info to the driver (which happens all the time
anyway, AFAICT...). To be clear, what are the exact layers as you're
seeing them? It doesn't seem like we strictly follow them, but I see
something like this:
Filesystems
MTD
NAND
Driver
(Hardware)

Anyway, this thread has managed to diverge into several different
topics by now, and it all came from some simple printk stuff... maybe
it's worth wrapping up the printk's and handling any device issues
separately.

Brian