On Thu, 2011-06-09 at 19:08 +0400, Dmitry Eremin-Solenikov wrote:
> >>>> +#ifdef CONFIG_OF> >>>> + if (master->node)> >>>> + of_node_get(master->node);> >>>> +#endif> >>>> >>> These ifdefs are not very nice, do you have ideas how to avoid them?> >>> Ideally, mtdcore should not know or bother about OF things. All> >>> OF-specific things should be done in ofpart.c...> >>> >> I know they aren't nice. OTOH ofpart.c also seems a bit non-logical: one> >> can have of node in the MTD, but doesn't (strangely) want to compile in> >> ofpart.c. Of course I can add separate small of-handling functions (to> >> do OF handling) to mtdcore.c to be replaced by empty functions in the> >> absence of CONFIG_OF, but this also look like overhead for me.> >> > How about turning the "origin" argument into "void *private" and> > declaring that this is "parser-specific info". It then can become> > "origin" for the RedBoot parser and the OF node pointer for the ofpart> > parser?> > And what will happen when ixp4xx (the only user of redboot "exception") > will get OF support?
Hmm, may be introducing something like:
/**
* struct mtd_part_parser_data - used to pass data to MTD partition parsers.
* @origin: blah blah, RedBoot-specific
* @of_node: points to the OF node describing the partitions, ofpart-specific
*/
struct mtd_part_parser_data {
unsigned long origin;
struct device_node *of_node;
};
And change the current "origin" argument with a
"struct mtd_part_parser_data *data" pointer?

On Thu, 2011-06-09 at 18:17 +0300, Artem Bityutskiy wrote:
> And change the current "origin" argument with a> "struct mtd_part_parser_data *data" pointer?
Which of course can be NULL if there is nothing to say, as well as
of_node may be NULL, in which case the parsers which needs those things
can just return "no partitions" or something like that?

On Thu, 2011-06-09 at 18:37 +0400, Dmitry Eremin-Solenikov wrote:
> I know they aren't nice. OTOH ofpart.c also seems a bit non-logical: one > can have of node in the MTD, but doesn't (strangely) want to compile in > ofpart.c. Of course I can add separate small of-handling functions (to > do OF handling) to mtdcore.c to be replaced by empty functions in the > absence of CONFIG_OF, but this also look like overhead for me.
Anyway, if I understand correctly (correct me if I don't!) - this is
basically about passing parser-specific information to parsers. And if
this is right, your way of adding this parser-specific information to
'struct mtd_info *' is bad, and we need to invent something better.
Right?