src/sys/dev/pms, branch stable/14 FreeBSD source tree chore: replace {0, 0} with {DEV,KOBJ}METHOD_END 2026-04-25T16:50:07+00:00 Enji Cooper ngie@FreeBSD.org 2026-02-21T06:14:46+00:00 1633c00828ac84fc5f9c08e5445fb6e6ead1939c Both of the aforementioned macros have been present in FreeBSD for well over a decade: 2009 for `KOBJMETHOD_END`; 2011 for `DEVMETHOD_END`. Adapt all hardcoded references of `{0, 0}` with `DEVMETHOD_END` and `KOBJMETHOD_END` as appropriate. This helps ensure that future adaptations to drivers following patterns documented in driver(9) can be made more easily/without issue. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D55414 MFC notes: All conflicts were dropped as they didn't apply to code in branch. Conflicts: sys/dev/flash/w25n.c sys/dev/nvd/nvd.c sys/dev/nvme/nvme_sim.c sys/dev/sound/pci/hdsp-pcm.c sys/dev/sound/pci/hdsp.c sys/dev/ufshci/ufshci_pci.c (cherry picked from commit 0fc6c3f731a2cca3120798806c330a3081c9424b) 
Both of the aforementioned macros have been present in FreeBSD
for well over a decade: 2009 for `KOBJMETHOD_END`; 2011 for
`DEVMETHOD_END`.

Adapt all hardcoded references of `{0, 0}` with `DEVMETHOD_END`
and `KOBJMETHOD_END` as appropriate. This helps ensure that
future adaptations to drivers following patterns documented
in driver(9) can be made more easily/without issue.

MFC after:	1 week
Differential Revision:	 https://reviews.freebsd.org/D55414

MFC notes:
	All conflicts were dropped as they didn't apply to code in branch.

Conflicts:
	sys/dev/flash/w25n.c
	sys/dev/nvd/nvd.c
	sys/dev/nvme/nvme_sim.c
	sys/dev/sound/pci/hdsp-pcm.c
	sys/dev/sound/pci/hdsp.c
	sys/dev/ufshci/ufshci_pci.c

(cherry picked from commit 0fc6c3f731a2cca3120798806c330a3081c9424b)
pms(4): Stop checking for failures from malloc(M_WAITOK) 2024-09-30T04:44:25+00:00 Zhenlei Huang zlei@FreeBSD.org 2024-09-03T10:25:32+00:00 025c4754941956e24830a9c3c6f5e2466b19a9e1 MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D45852 (cherry picked from commit 4fb8a80a78aa65e0b30bd5a74373512c678841c9) 
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D45852

(cherry picked from commit 4fb8a80a78aa65e0b30bd5a74373512c678841c9)
sys: Remove $FreeBSD$: one-line .c pattern 2023-08-16T17:54:36+00:00 Warner Losh imp@FreeBSD.org 2023-08-16T17:54:36+00:00 685dc743dc3b5645e34836464128e1c0558b404b Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ 
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
sys: Remove $FreeBSD$: one-line .c comment pattern 2023-08-16T17:54:24+00:00 Warner Losh imp@FreeBSD.org 2023-08-16T17:54:24+00:00 71625ec9ad2a9bc8c09784fbd23b759830e0ee5f Remove /^/[*/]\s*\$FreeBSD\$.*\n/ 
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
sys: Remove $FreeBSD$: one-line .h pattern 2023-08-16T17:54:18+00:00 Warner Losh imp@FreeBSD.org 2023-08-16T17:54:18+00:00 2ff63af9b88c7413b7d71715b5532625752a248e Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/ 
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
Adjust tdsaContext_t::NvmdResponseSet declaration to avoid clang 15 warning 2022-07-21T19:49:58+00:00 Dimitry Andric dim@FreeBSD.org 2022-07-21T19:49:47+00:00 95204d7a6368990e216db0ad51ef3e6018aed27c With clang 15, the following -Werror warnings are produced: In file included from sys/dev/pms/freebsd/driver/ini/src/agtiapi.c:70: sys/dev/pms/RefTisa/tisa/sassata/common/tdsatypes.h:346:13: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] volatile NvmdResponseSet; ~~~~~~~~ ^ int The NvmdResponseSet member is effectively only used as a boolean in the pms(4) driver, so it could be a single bit. But to avoid changing the semantics at all in this unmaintained driver, simply declare it as a volatile int. MFC after: 3 days 
With clang 15, the following -Werror warnings are produced:

    In file included from sys/dev/pms/freebsd/driver/ini/src/agtiapi.c:70:
    sys/dev/pms/RefTisa/tisa/sassata/common/tdsatypes.h:346:13: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
      volatile  NvmdResponseSet;
      ~~~~~~~~  ^
      int

The NvmdResponseSet member is effectively only used as a boolean in the
pms(4) driver, so it could be a single bit. But to avoid changing the
semantics at all in this unmaintained driver, simply declare it as a
volatile int.

MFC after:	3 days
pms: Remove unused devclass argument to DRIVER_MODULE. 2022-05-06T22:46:55+00:00 John Baldwin jhb@FreeBSD.org 2022-05-06T22:46:55+00:00 c59820837c28f7cef224b689ac5026ed113a5320 






Fix some common typos in source code comments
2021-08-14T06:55:58+00:00

Gordon Bergling
gbe@FreeBSD.org

2021-08-14T06:55:58+00:00

17db4b52fb41aeabeb945c68c1b5edd4db4eac31

- s/struture/structure/
- s/structre/structure/

MFC after:	5 days





- s/struture/structure/
- s/structre/structure/

MFC after:	5 days







pms(4): clear CCBs allocated on the stack
2021-05-21T06:29:23+00:00

Edward Tomasz Napierala
trasz@FreeBSD.org

2021-05-21T06:28:46+00:00

d39aac796bd20692919223b1bbec6ce6b2779e1a

Reviewed By:	imp
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D30300





Reviewed By:	imp
Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D30300







pms(4): Limit maximum I/O size to 256KB instead of 1MB.
2021-04-16T19:50:34+00:00

Alexander Motin
mav@FreeBSD.org

2021-04-16T19:39:01+00:00

3e347834200b5d91a33384e696793e4ac20a44d4

There is a weird limit of AGTIAPI_MAX_DMA_SEGS (128) S/G segments per
I/O since the initial driver import.  I don't know why it was added,
can only guess some hardware limitation, but in worst case it means
maximum I/O size of 508KB.  Respect it to be safe, rounding to 256KB.

MFC after:	1 week
Sponsored by:	iXsystems, Inc.





There is a weird limit of AGTIAPI_MAX_DMA_SEGS (128) S/G segments per
I/O since the initial driver import.  I don't know why it was added,
can only guess some hardware limitation, but in worst case it means
maximum I/O size of 508KB.  Respect it to be safe, rounding to 256KB.

MFC after:	1 week
Sponsored by:	iXsystems, Inc.