On 11/14/22 23:48, Christoph Hellwig wrote:
On Wed, Nov 09, 2022 at 09:29:47AM -0800, Bart Van Assche wrote:
I'm not sure how to interpret your reply. Anyway, this patch is required to
use the encryption functionality of the UFS Exynos controller. The
"vendor-specific fields" text in the patch description refers to the
encryption fields since these follow the data buffer when using the Exynos
controller. Although it makes me unhappy that the UFS Exynos controller is
not compliant with the UFS specification, since it is being used widely I
think we need support for this controller in the upstream kernel.
The fact that in UFS no one sticks to the standard, and not one but
us in the kernel being more strict and your employer sticking to that
can fix it.
The above statement is too strong. The Exynos controller is the least
compliant controller I'm aware of. Future Google Pixel devices will use
a UFS controller that is compliant with the UFSHCI standard.
Additionally, the Exynos UFS controller also occurs in devices produced
by other companies than my employer.
But that's not the point here - the point is that such fields are
always implementation specific and never vendor specific. Any
particular vendor can, and often does, have various different
implementation specific derivations from or extensions to a spec.
Just like there is no 'vendor' driver as there are plenty different
drivers for the same device class from the same manufacturer.
Do you perhaps want me to change what Eric Biggers suggested into
something more generic? I'm referring to the following suggestion from Eric:
config SCSI_UFS_VARIABLE_SG_ENTRY_SIZE
bool
default y if SCSI_UFS_EXYNOS && SCSI_UFS_CRYPTO
Thanks,
Bart.
