Andy Green wrote: > It makes sense, Harald did this unto Glamo too. Yup. That's actually the kind of structure I had in mind. There are two styles:
- keep core and subsystems all in drivers/mfd/ - keep only the core there and put the subsystems elsewhere Only SM501 seems to be of the latter type in our current mainline, but upstream has some more examples of such drivers. I think the "everything under drivers/mfd/" approach is clearer for things like Glamo or PMU, where the subsystem drivers are specialized anyway and there are many internal interfaces that are of no use to anything else. But I can see the benefits of the other approach as well. I'll inquire what's best in this case. > Werner, how do you feel about guiding and helping Balaji with that? Sounds good. > It's not simple but it is largely rearrangement and adaptation of known > working stuff (so it is testable stage by stage), There's one problem, though: this change, while modifying very little code, makes the driver completely different from our mainline as far as git, diff, etc. see it. So moving later changes from one branch to the other would always require manual intervention and when the whole thing eventually comes back from upstream, it would be difficult to tell the restructuring from any other changes that have happened after. So I'd suggest to do only the restructuring now, without any other beautification or fixing, and then merging the restructured pcf50633 driver back into our mainline. That way, it's easy to review the changes, because one can just cat the parts and diff that against the current monolithic driver. - Werner
