mbox series

[v3,00/16] Converge on using secs_to_jiffies() part two

Message ID 20250225-converge-secs-to-jiffies-part-two-v3-0-a43967e36c88@linux.microsoft.com
Headers show
Series Converge on using secs_to_jiffies() part two | expand

Message

Easwar Hariharan Feb. 25, 2025, 8:17 p.m. UTC
This is the second series (part 1*) that converts users of msecs_to_jiffies() that
either use the multiply pattern of either of:
- msecs_to_jiffies(N*1000) or
- msecs_to_jiffies(N*MSEC_PER_SEC)

where N is a constant or an expression, to avoid the multiplication.

The conversion is made with Coccinelle with the secs_to_jiffies() script
in scripts/coccinelle/misc. Attention is paid to what the best change
can be rather than restricting to what the tool provides.

Andrew has kindly agreed to take the series through mm.git modulo the
patches maintainers want to pick through their own trees.

This series is based on next-20250225

Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>

* https://lore.kernel.org/all/20241210-converge-secs-to-jiffies-v3-0-ddfefd7e9f2a@linux.microsoft.com/

---
Changes in v3:
- Change commit message prefix from libata: zpodd to ata: libata-zpodd: in patch 8 (Damien)
- Split up overly long line in patch 9 (Christoph)
- Fixup unnecessary line break in patch 14 (Ilpo)
- Combine v1 and v2
- Fix some additional hunks in patch 2 (scsi: lpfc) which the more concise script missed
- msecs_to_jiffies -> msecs_to_jiffies() in commit messages throughout
- Bug in secs_to_jiffies() uncovered by LKP merged in 6.14-rc2: bb2784d9ab4958 ("jiffies: Cast to unsigned long in secs_to_jiffies() conversion")
- Link to v2: https://lore.kernel.org/r/20250203-converge-secs-to-jiffies-part-two-v2-0-d7058a01fd0e@linux.microsoft.com

Changes in v2:
- Remove unneeded range checks in rbd and libceph. While there, convert some timeouts that should have been fixed in part 1. (Ilya)
- Fixup secs_to_jiffies.cocci to be a bit more verbose
- Link to v1: https://lore.kernel.org/r/20250128-converge-secs-to-jiffies-part-two-v1-0-9a6ecf0b2308@linux.microsoft.com

---
Easwar Hariharan (16):
      coccinelle: misc: secs_to_jiffies: Patch expressions too
      scsi: lpfc: convert timeouts to secs_to_jiffies()
      accel/habanalabs: convert timeouts to secs_to_jiffies()
      ALSA: ac97: convert timeouts to secs_to_jiffies()
      btrfs: convert timeouts to secs_to_jiffies()
      rbd: convert timeouts to secs_to_jiffies()
      libceph: convert timeouts to secs_to_jiffies()
      ata: libata-zpodd: convert timeouts to secs_to_jiffies()
      xfs: convert timeouts to secs_to_jiffies()
      power: supply: da9030: convert timeouts to secs_to_jiffies()
      nvme: convert timeouts to secs_to_jiffies()
      spi: spi-fsl-lpspi: convert timeouts to secs_to_jiffies()
      spi: spi-imx: convert timeouts to secs_to_jiffies()
      platform/x86/amd/pmf: convert timeouts to secs_to_jiffies()
      platform/x86: thinkpad_acpi: convert timeouts to secs_to_jiffies()
      RDMA/bnxt_re: convert timeouts to secs_to_jiffies()

 .../accel/habanalabs/common/command_submission.c   |  2 +-
 drivers/accel/habanalabs/common/debugfs.c          |  2 +-
 drivers/accel/habanalabs/common/device.c           |  2 +-
 drivers/accel/habanalabs/common/habanalabs_drv.c   |  2 +-
 drivers/ata/libata-zpodd.c                         |  3 +-
 drivers/block/rbd.c                                |  8 ++---
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c         |  2 +-
 drivers/nvme/host/core.c                           |  6 ++--
 drivers/platform/x86/amd/pmf/acpi.c                |  2 +-
 drivers/platform/x86/thinkpad_acpi.c               |  2 +-
 drivers/power/supply/da9030_battery.c              |  3 +-
 drivers/scsi/lpfc/lpfc.h                           |  3 +-
 drivers/scsi/lpfc/lpfc_els.c                       | 11 +++---
 drivers/scsi/lpfc/lpfc_hbadisc.c                   |  2 +-
 drivers/scsi/lpfc/lpfc_init.c                      | 10 +++---
 drivers/scsi/lpfc/lpfc_scsi.c                      | 12 +++----
 drivers/scsi/lpfc/lpfc_sli.c                       | 41 +++++++++-------------
 drivers/scsi/lpfc/lpfc_vport.c                     |  2 +-
 drivers/spi/spi-fsl-lpspi.c                        |  2 +-
 drivers/spi/spi-imx.c                              |  2 +-
 fs/btrfs/disk-io.c                                 |  6 ++--
 fs/xfs/xfs_icache.c                                |  2 +-
 fs/xfs/xfs_sysfs.c                                 |  8 ++---
 include/linux/ceph/libceph.h                       | 12 +++----
 net/ceph/ceph_common.c                             | 18 ++++------
 net/ceph/osd_client.c                              |  3 +-
 scripts/coccinelle/misc/secs_to_jiffies.cocci      | 10 ++++++
 sound/pci/ac97/ac97_codec.c                        |  3 +-
 28 files changed, 82 insertions(+), 99 deletions(-)
---
base-commit: 0226d0ce98a477937ed295fb7df4cc30b46fc304
change-id: 20241217-converge-secs-to-jiffies-part-two-f44017aa6f67

Best regards,

Comments

Andrew Morton Feb. 26, 2025, 8:38 p.m. UTC | #1
On Wed, 26 Feb 2025 11:29:53 +0000 Mark Brown <broonie@kernel.org> wrote:

> On Tue, Feb 25, 2025 at 08:17:14PM +0000, Easwar Hariharan wrote:
> > This is the second series (part 1*) that converts users of msecs_to_jiffies() that
> > either use the multiply pattern of either of:
> > - msecs_to_jiffies(N*1000) or
> > - msecs_to_jiffies(N*MSEC_PER_SEC)
> > 
> > where N is a constant or an expression, to avoid the multiplication.
> 
> Please don't combine patches for multiple subsystems into a single
> series if there's no dependencies between them, it just creates
> confusion about how things get merged, problems for tooling and makes
> everything more noisy.  It's best to split things up per subsystem in
> that case.

I asked for this.  I'll merge everything, spend a few weeks gathering
up maintainer acks.  Anything which a subsystem maintainer merges will
be reported by Stephen and I'll drop that particular patch.

This way, nothing gets lost.  I take this approach often and it works.

If these were sent as a bunch of individual patches then it would be up
to the sender to keep track of what has been merged and what hasn't. 
That person will be resending some stragglers many times.  Until they
give up and some patches get permanently lost.

Scale all that across many senders and the whole process becomes costly
and unreliable.  Whereas centralizing it on akpm is more efficient,
more reliable, more scalable, lower latency and less frustrating for
senders.
Mark Brown Feb. 26, 2025, 10:26 p.m. UTC | #2
On Wed, Feb 26, 2025 at 12:38:51PM -0800, Andrew Morton wrote:
> On Wed, 26 Feb 2025 11:29:53 +0000 Mark Brown <broonie@kernel.org> wrote:

> > Please don't combine patches for multiple subsystems into a single
> > series if there's no dependencies between them, it just creates
> > confusion about how things get merged, problems for tooling and makes
> > everything more noisy.  It's best to split things up per subsystem in
> > that case.

> I asked for this.  I'll merge everything, spend a few weeks gathering
> up maintainer acks.  Anything which a subsystem maintainer merges will
> be reported by Stephen and I'll drop that particular patch.

> This way, nothing gets lost.  I take this approach often and it works.

I've only started seeing these in the past few weeks, but we do have a
bunch of people routinely doing cross tree stuff who split things up and
it seems to work OK there.

> If these were sent as a bunch of individual patches then it would be up
> to the sender to keep track of what has been merged and what hasn't. 
> That person will be resending some stragglers many times.  Until they
> give up and some patches get permanently lost.

Surely the sender can just CC you on each individual thing just as well?
Ensuring things get picked up is great, but it's not clear to me that
copying everyone on a cross tree series is helping with that.

> Scale all that across many senders and the whole process becomes costly
> and unreliable.  Whereas centralizing it on akpm is more efficient,
> more reliable, more scalable, lower latency and less frustrating for
> senders.

Whereas copying everyone means all the maintainers see something that
looks terribly complicated in their inboxes and have to figure out if
there are actually any dependencies in the series and how it's supposed
to be handed, and then every reply goes to a huge CC list.  That's not
good for either getting people to look at things or general noise
avoidance, especially for people who are expecting to get cross tree
serieses which do have dependencies that need to be managed.

There's also some bad failure modes as soon as anyone has any sort of
comment on the series, suddenly everyone's got a coding style debate or
whatever in their inboxes they can pile into.
Carlos Maiolino Feb. 27, 2025, 9:02 a.m. UTC | #3
On Wed, Feb 26, 2025 at 12:38:51PM -0800, Andrew Morton wrote:
> On Wed, 26 Feb 2025 11:29:53 +0000 Mark Brown <broonie@kernel.org> wrote:
> 
> > On Tue, Feb 25, 2025 at 08:17:14PM +0000, Easwar Hariharan wrote:
> > > This is the second series (part 1*) that converts users of msecs_to_jiffies() that
> > > either use the multiply pattern of either of:
> > > - msecs_to_jiffies(N*1000) or
> > > - msecs_to_jiffies(N*MSEC_PER_SEC)
> > >
> > > where N is a constant or an expression, to avoid the multiplication.
> >
> > Please don't combine patches for multiple subsystems into a single
> > series if there's no dependencies between them, it just creates
> > confusion about how things get merged, problems for tooling and makes
> > everything more noisy.  It's best to split things up per subsystem in
> > that case.
> 
> I asked for this.  I'll merge everything, spend a few weeks gathering
> up maintainer acks.  Anything which a subsystem maintainer merges will
> be reported by Stephen and I'll drop that particular patch.

I'm removing this from my queue then and let it go through your tree.
Cheers,

Carlos

> 
> This way, nothing gets lost.  I take this approach often and it works.
> 
> If these were sent as a bunch of individual patches then it would be up
> to the sender to keep track of what has been merged and what hasn't.
> That person will be resending some stragglers many times.  Until they
> give up and some patches get permanently lost.
> 
> Scale all that across many senders and the whole process becomes costly
> and unreliable.  Whereas centralizing it on akpm is more efficient,
> more reliable, more scalable, lower latency and less frustrating for
> senders.
>