UNLESS you're writing a trusted kernel for trusted computing system, but that's usually rare in hobby OSdev.
I have a problem with the concept of Trusted Computing in general - or rather, with the narrative laid on top of it by marketing departments, which gives a highly distorted view of the idea - but that is going off topic enough that anything further said about it should be in a separate thread. Suffice it to say that actual Trusted Computing is incompatible with consumer-grade hardware and software.
Getting back to the topic, the real issue is that the CPU does not, as a rule, have access to the drive's firmware and internal hardware in the first place - the ATA model realistically requires that drive be managed by an embedded microcontroller with its own memory and firmware (which on higher-end devices are usually a flash memory, to allow for firmware updates, but could be an actual masked ROM in cheaper models), which the CPU has no direct interaction with - and a programmer would need details of the hardware which are not generally made available in order to affect the on-drive control electronics directly. This isolation is at least partially deliberate, as the primary goal of the controller design going back to the XT days was to relieve the CPU of these tasks - even with the original MFM drives, the CPU didn't need
to do most of that work, and successive controller models have offloaded more and more of the work onto the controller board and the drive itself over time.
In most cases, the only interaction that the computer's CPU has with the firmware is to pass a firmware update to it, and a reputable hardware manufacturer should
be using some kind of encryption on that and bundle it with with an ECC signature and a hash signature for tamper-checking (while those aren't foolproof, they do make tampering impractical for most casual attacks). I don't know if any do, but... anyway.
This isolation is a Good Thing, because these operations take a lot
of computation, so off-loading it only makes sense - just as with CPU-driven video
, a CPU-driven disk would eat an inordinate amount of cycles when in use. Also, it modularizes the system better, reducing the chances that a bug in the driver will trash the disk records or the disk itself - in the bad old days of minicomputers with loadable platter packs, and even in the early 8-bit home computer days with the Shugart, Apple ProFile, and Apple Sider drives, it was possible for a wonky driver to cause physical damage to the platters and/or read heads. Finally, it abstracts away the design of the drive itself, making it possible to use a single generic driver for not only many models of hard disk without regard to the drive's actual geometry or control electronics, but also with completely different storage technologies such as solid-state flash and NVMe.