cam: Remove left-over sys/cdefs.h in sys/cam

These weren't removed when $FreeBSD$ was removed. They aren't needed and
now are a style(9) nonconformity.

Sponsored by: Netflix

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

cam/mmc: Migrate to modern uintXX_t from u_intXX_t

As per https://lists.freebsd.org/archives/freebsd-scsi/2023-July/000257.html
move to the modern uintXX_t.

MFC After: 3 days
Sponsored by: Netflix

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

kerneldump: remove physical argument from d_dumper

The physical address argument is essentially ignored by every dumper
method. In addition, the dump routines don't actually pass a real
address; every call to dump_append() passes a value of zero for
physical.

Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35173

mmc_da: create disk(9) for pre-2.0 SD cards

It does not look like there is anything in mmc_da code that actually
requires protocol 2.0 or later. dev/mmc code also does not have such a
restriction.

Tested with a very old 2GB mini-SD card. Prior to this change mmc_da
would claim the card but would not expose it to GEOM.

Without MMCCAM:
mmc0: <MMC/SD bus> on sdhci_pci0
mmc0: Probing bus
mmc0: SD probe: OK (OCR: 0x00ff8000)
mmc0: Current OCR: 0x00ff8000
mmc0: CMD8 failed, RESULT: 1
mmc0: Probing cards
mmc0: New card detected (CID 1c53565344432020100002982e007600)
mmc0: New card detected (CSD 005e00325f5a83d02db7ffbf96800000)
mmc0: Card at relative address 0xb368 added:
mmc0: card: SD SDC 1.0 SN 0002982E MFG 06/2007 by 28 SV
mmc0: quirks: 0
mmc0: bus: 4bit, 50MHz (high speed timing)
mmc0: memory: 3998720 blocks, erase sector 256 blocks
mmc0: setting transfer rate to 50.000MHz (high speed timing)
GEOM: new disk mmcsd0
mmcsd0: 2GB <SD SDC 1.0 SN 0002982E MFG 06/2007 by 28 SV> at mmc0 50.0MHz/4bit/65535-block
mmc0: setting bus width to 4 bits high speed timing

With MMCCAM and this change:
sdda0 at sdhci_slot0 bus 0 scbus2 target 0 lun 0
sdda0: Relative addr: 0000b368
Card features: <Memory>
sdda0: Serial Number 0002982E
sdda0: SD SDC 1.0 SN 0002982E MFG 06/2007 by 28 SV
GEOM: new disk sdda0

Reviewed by: manu
MFC after: 3 weeks

mmc_da: remove write-only local variables

MFC after: 1 week

mmc_da: use MMC_SECTOR_SIZE constant in place of literals

Suggested by: manu
MFC after: 2 weeks

mmc_da: implement d_dump method, sddadump

sddadump has been derived from sddastart.

mmc_sim interface has grown a new method, cam_poll, to support polled
operation.

mmc_sim code has been changed to provide a sim_poll hook only if the
controller implements the new method. The hooks is implemented in terms
of the new mmc_sim_cam_poll method.
Additionally, in-progress CCB-s now have CAM_REQ_INPROG status to
satisfy xpt_pollwait().

mmc_sim_cam_poll method has been implemented in dwmmc host controller.

Reviewed by: manu, mav, imp
MFC after: 2 weeks
Relnotes: perhaps
Differential Revision: https://reviews.freebsd.org/D33843

sddadone: 'error' gets assigned only errno codes, never MMC_ERR codes

MFC after: 2 weeks

Assert that invalid bus widths can't be passed to bus_width_str().

This appeases a -Wreturn-type warning from GCC.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31935

mmccam: Read the common members of CSD v1.0 and v2.0

And only get the differents ones based on the version.

No functional changes intented.

Sponsored by: Diablotin Systems

mmccam: Style(9) more mmc_da.c

No functional changes.
Sponsored by: Diablotin Systems

cam: make sure to clear even more CCBs allocated on the stack

This is my second pass, this time over all of CAM except
for the SCSI target bits. There should be no functional
changes.

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

Make MAXPHYS tunable. Bump MAXPHYS to 1M.

Replace MAXPHYS by runtime variable maxphys. It is initialized from
MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.

Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer
cache buffers exactly to atop(maxbcachebuf) (currently it is sized to
atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1.
The +1 for pbufs allow several pbuf consumers, among them vmapbuf(),
to use unaligned buffers still sized to maxphys, esp. when such
buffers come from userspace (*). Overall, we save significant amount
of otherwise wasted memory in b_pages[] for buffer cache buffers,
while bumping MAXPHYS to desired high value.

Eliminate all direct uses of the MAXPHYS constant in kernel and driver
sources, except a place which initialize maxphys. Some random (and
arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted
straight. Some drivers, which use MAXPHYS to size embeded structures,
get private MAXPHYS-like constant; their convertion is out of scope
for this work.

Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs,
dev/siis, where either submitted by, or based on changes by mav.

Suggested by: mav (*)
Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions)
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D27225

mmccam: We can't sleep during sdda_add_part so use M_NOWAIT

Reviewed by: kibab
Differential Revision: https://reviews.freebsd.org/D25947

Do not truncate the last character from serial number.

strlcpy() requires one more byte for the NULL character.

Submitted by: Henri Hennebert (hlh at restart dot be)
MFC after: 3 days

Always return MMC errors from mmc_handle_reply()

There are two ways to propagate the error in MMCCAM:
* Using cmd.error which is set by the peripheral driver;
* Using CCB status which is... also set by the driver.

The problem is that those two error conditions don't necessarily match.
This leads to the confusion when handling the MMC reply. So enforce the consistency
by panicking if request is marked as completed successfully but MMC-level error
is present (this hints to the programming error).

Reviewed by: manu
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D26925

mmc_da: universally use uint8_t for the partition index

Also, assert in sdda_init_switch_part() that the index is within the
defined range.

MFC after: 1 week

mmc_da: fix a typo and a too long line

MFC after: 1 week

mmc_da: make sure that part_index is not used uninitialized in sddastart

This is a fix to r334065.

Without this change I once got stuck I/O with endless partition switching:

(sdda0:aw_mmc_sim2:0:0:0): sddastart
(sdda0:aw_mmc_sim2:0:0:0): Partition 0 -> -525703168
(sdda0:aw_mmc_sim2:0:0:0): xpt_action: func 0x91d XPT_MMC_IO
(sdda0:aw_mmc_sim2:0:0:0): xpt_done: func= 0x91d XPT_MMC_IO status 0x1
(sdda0:aw_mmc_sim2:0:0:0): sddadone
(sdda0:aw_mmc_sim2:0:0:0): Card status: 00000000
(sdda0:aw_mmc_sim2:0:0:0): Current state: 4
(sdda0:aw_mmc_sim2:0:0:0): Compteting partition switch to 0

Note that -525703168 (an int) is 0xe0aa6800 in binary representation.
The partition indexes are actually stored as uint8_t, so that value
was converted / truncated to zero.

MFC after: 1 week

cam: clean up empty lines in .c and .h files

mmc_da: fix memory leak in sddaregister()

In case we are failing to allocate mmcdata, we are returning with
a softc allocated but not attached to anything and thus leak the
memory.

Reviewed by: scottl
MFC after: 2 weeks
X-MFC: only if we also mfc other mmccam changes?
Differential Revision: https://reviews.freebsd.org/D25987

mmccam: Unhold the periph when we add the device

Otherwise the device node aren't created.

Pointy hat to: manu
Reported by: bz

mmccam: Hold the periph during init

We need to sleep during this routine so acquire the cam hold too.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D25946

mmccam: Add some aliases for non-mmccam to mmccam transition

A new tunable is present, kern.cam.sdda.mmcsd_compat to enable
this feature or not (default is enabled)

mmccam: Add support for 1.2V and 1.8V eMMC

If the card reports that it support 1.2V or 1.8V signaling switch to this voltage.

Submitted by: kibab

Now that we don't have special-case geom hacking defined in md_var.h, stop
including it. sparc64 was the last straggler here, but these weren't removed at
the time.

Ever since the block layer expanded its command syntax beyond just
BIO_READ and BIO_WRITE, we've handled this expanded syntax poorly in
drivers when the driver doesn't support a particular command. Do a
sweep and fix that.

Reported by: imp

Regularize my copyright notice

o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't claim All Rights reserved by listing
All Rights Reserved on same line as other copyright holders (but not
me). Other such holders are also listed last where it's clear.

Add GEOM attribute to report physical device name, and report it
via 'diskinfo -v'. This avoids the need to track it down via CAM,
and should also work for disks that don't use CAM. And since it's
inherited thru the GEOM hierarchy, in most cases one doesn't need
to walk the GEOM graph either, eg you can use it on a partition
instead of disk itself.

Reviewed by: allanjude, imp
Sponsored by: Klara Inc
Differential Revision: https://reviews.freebsd.org/D22249

Add new fields to mmc_data in preparation to SDIO CMD53 block mode support

SDIO command CMD53 (IO_RW_EXTENDED) allows data transfers using blocks of 1-2048 bytes,
with a maximum of 511 blocks per request.
Extend mmc_data structure to properly describe such requests,
and initialize the new fields in kernel and userland consumers.

No actual driver changes happen yet, these will follow in the separate changes.

Reviewed by: bz
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D19779

Refactor error handling

There is some code duplication in error handling paths in a few functions.
Create a function for printing such errors in human-readable way and get rid
of duplicates.

Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D15912

Use information about max data size that the controller is able to operate

Using DFLTPHYS/MAXPHYS is not always OK, instead make it possible for the
controller driver to provide maximum data size to MMCCAM, and use it there.

The old stack already does this.

Reviewed by: manu
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D15892

Correctly define rawscr so initializing it doesn't result in overwriting memory.

We need 8 bytes of storage for rawscr.

Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D15889

Set MMC_DATA_MULTI flag when doing multi-block transfers

Lower layers (MMC / SDHCI controller drivers) may make certain decisions
based on the presence of this flag. The fact that sdhci.c doesn't
look at this flag is another problem that should be fixed separately.

Found when adding MMCCAM support to AllWinner MMC controller driver
where the presence of this flag actually matters.

Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D15888

Enable high-speed on the card before increasing frequency on the controller

Increasing operating frequency without telling card to switch
to high-speed mode first upsets some cards and generates CRC errors.

While here, deselect / reselect cards after CMD6 and SCR fetch, as in original code.

Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D15568

Implement initial MMC partitions support for MMCCAM.

For MMC cards, add partitions found on the card as separate disk(9) devices.
Don't do anything with RPMB partition for now.
Lots of code is copied almost 1:1 from the mmcsd.c in the old stack,
credits Marius Strobl (marius@FreeBSD.org)

Reviewed by: marius
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D12762

Hold the reference count until the CCB is released

When a disk disappears and the periph is invalidated, any I/Os that
are pending with the controller can cause a crash when they
complete. Move to holding the softc reference count taken in dastart()
until the I/O is complete rather than only until xpt_action()
returns. (This approach was suggested by Ken Merry.) This extends
the method used in da to ada, nda, and mda.

Sponsored by: Netflix
Submitted by: Chuck Silvers

Return a C errno for cam_periph_acquire().

There's no compelling reason to return a cam_status type for this
function and doing so only creates confusion with normal C
coding practices. It's technically an API change, but the periph API
isn't widely used. No efffective change to operation.

Reviewed by: imp, mav, ken
Sponsored by: Netflix
Differential Revision: D14063

SPDX: finish tagging sys/cam.

Define xpt_path_inq.

This provides a nice wrarpper around the XPT_PATH_INQ ccb creation and
calling.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13387

Remove unused 4th argument to match the standard error routines.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13386

Miscellaneous fixes and improvements to MMCCAM stack

* Demote the level of several debug messages to CAM_DEBUG_TRACE
* Add detection for SDHC cards that can do 1.8V. No voltage switch sequence
is issued yet;
* Don't create a separate LUN for each SDIO function. We need just one to make
pass(4) attach;
* Remove obsolete mmc_sdio* files. SDIO functionality will be moved into the
separate device that will manage a new sdio(4) bus;
* Terminate probing if got no reply to CMD0;
* Make bcm2835 SDHCI host controller driver compile with 'option MMCCAM'.

Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D12109

An MMC/SD/SDIO stack using CAM

Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
flexible queueing will make it easier to write non-storage drivers
than the legacy stack. SDIO drivers from both the kernel and as
userland daemons are possible, though much of that functionality will
come later.

Some of the CAM integration isn't complete (there are sleeps in the
device probe state machine, for example), but those minor issues can
be improved in-tree more easily than out of tree and shouldn't gate
progress on other fronts. Appologies to reviews if specific items
have been overlooked.

Submitted by: Ilya Bakulin
Reviewed by: emaste, imp, mav, adrian, ian
Differential Review: https://reviews.freebsd.org/D4761

merge with first commit, various compile hacks.