On Fri, Apr 7, 2017 at 10:48 AM, Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Apr 07, 2017 at 10:30:12AM +0200, Linus Walleij wrote: >> On Fri, Apr 7, 2017 at 10:27 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> > On Wed, Apr 5, 2017 at 12:07 PM, Richard Fitzgerald >> > <rf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> > >> >> This patch adds a header file of register definitions for Cirrus >> >> Logic "Madera" class codecs. These codecs are all based off a common >> >> set of hardware IP so have a common register map (with a few minor >> >> device-to-device variations). These are complex devices with a large >> >> mber of features and so have a correspondingly large register set. >> >> The registers.h file has been auto-generated from the hardware register >> >> definitions, stripped down to only registers we need to access from >> >> the driver. >> >> >> >> Signed-off-by: Richard Fitzgerald <rf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> >> > >> > This: >> > include/linux/mfd/madera/registers.h | 8832 ++++++++++++++++++++++++++++++++++ >> > >> > Get included in all subdrivers I suppose? >> > >> > So you are broadcasting 8800+ lines into every subdriver across the >> > entire kernel. >> > >> > Just the time spent in the preprocessor parsing this will affect compilation >> > time. >> >> Or maybe this is a necessary sacrifice to get the regmap cache >> centralized in MFD. I don't know. I feel stupid. >> >> I guess I should focus on "my" subsystems... >> > > This only gets included in files that are part of this driver, it > shouldn't affect compilation time for anyone not building the > madera driver and even then it should only affect compilation > times for the 10 or so C files that make up the driver. Also I > don't really see any other way to specify the registers for the > device. No when using regmap cache this seems necessary. I was just wrong. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
