Re: [PATCH v4 5/5] clocksource: mips-gic-timer: Use local counter on synced multi-cluster systems

[Thomas Bogendoerfer]

On Wed, Sep 30, 2026 at 05:49:17PM +0200, Benoît Monin wrote:
> On Tuesday, 29 September 2026 at 18:59:16 CEST, Thomas Bogendoerfer wrote:
> > >  static int gic_starting_cpu(unsigned int cpu)
> > >  {
> > > -      /* Ensure the GIC counter is running */
> > > -      clear_gic_config(GIC_CONFIG_COUNTSTOP);
> > > +      unsigned int cluster = cpu_cluster(&cpu_data[cpu]);
> > > +
> > > +      if (read_gic_config() & GIC_CONFIG_COUNTSTOP) {
> > > +              clear_gic_config(GIC_CONFIG_COUNTSTOP);
> > > +
> > > +              if (cluster && mips_cm_is64 && !gic_clock_unstable)
> > > +                      gic_sync_counter_64(cluster);
> > > +
> > > +              if (gic_synced_cl_map &&
> > > +                  bitmap_full(gic_synced_cl_map, mips_cps_numclusters()))
> > > +                      schedule_work(&gic_promote_work);
> > 
> > do we really need the workqueue ? As far as I understand
> > sched_clock_register() doesn't use the clocksource mutex, so we should
> > be able to directly call gic_promote() again.
> 
> With CONFIG_IRQ_TIME_ACCOUNTING=y, calling sched_clock_register() from the
> CPU hotplug STARTING callback leads to a deadlock. We also need the
> workqueue to call it.

thank you for checking

Reviewed-by: Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]