Hi Greg, On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH <greg@xxxxxxxxx> wrote: > > On Wed, Mar 12, 2014 at 12:51:52AM +0000, Mark Brown wrote: > > > > After merging the driver-core tree, today's linux-next build () > > failed like this on a PowerPC defconfig: > > > > HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next' > > GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile > > # > > # configuration written to .config > > # > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store': > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration] > > sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj, > > ^ > > cc1: all warnings being treated as errors > > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1 > > make[3]: *** Waiting for unfinished jobs.... > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store': > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration] > > sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj, > > ^ > > cc1: all warnings being treated as errors > > > > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree. > > > > I reverted 774fea1a38c6a5a8 for today. > > Sounds like the powerpc tree also needs to stop using this function :) So, explain to us in detail why the old interface could not be maintained for a release, please. I thought we had become a bit more sophisticated about changing core APIs i.e. introduce the new API - fix up all the users - keep the old one around if possible for a release (or beyond -rc1) to catch the new users. It may be that there is a good reason not to so this in this case, but it is not explained as far as I can see. Alternatively, it looks as though there may be a fairly trivial transform from using the old interface to using the new one which could be applied as part of the merge of these two trees (in linux-next and then in Linus' tree during the merge window). Maybe you or Tejun should have explained that and provided a prototype for the merge fix up. Greg, you are doing core infrastructure changes in your trees - you need to consider that new usages may be introduced while those changes are ongoing. -- Cheers, Stephen Rothwell sfr@xxxxxxxxxxxxxxxx
Attachment:
pgpRagxDpUj6o.pgp
Description: PGP signature