Check for SMU RX local/remote faults along with SPU LINK
status. Otherwise at times link is UP at our end but DOWN
at link partner's side. Also due to an issue in BGX it's
rarely seen that initialization doesn't happen properly
and SMU RX reports faults with everything fine at SPU.
This patch tries to reinitialize LMAC to fix it.
Also fixed LMAC disable sequence to properly bring down link.
Signed-off-by: Sunil Goutham <email address hidden>
Signed-off-by: Tao Wang <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from linux-next commit 3f4c68cfde30caa1f6d8368fd19590671411ade2)
Signed-off-by: dann frazier <email address hidden>
[18697.813871] tpm_crb MSFT0101:00: can't request region for resource
[mem 0xacdff080-0xacdfffff]
The mapping of the control area overlaps the mapping of the command
buffer. The control area is mapped over page, which is not right. It
should mapped over sizeof(struct crb_control_area).
Fixing this issue unmasks another issue. Command and response buffers
can overlap and they do interleave on this machine. According to the PTP
specification the overlapping means that they are mapped to the same
buffer.
The commit has been also on a Haswell NUC where things worked before
applying this fix so that the both code paths for response buffer
initialization are tested.
Cc: <email address hidden>
Fixes: 1bd047be37d9 ("tpm_crb: Use devm_ioremap_resource")
Signed-off-by: Jarkko Sakkinen <email address hidden>
Reviewed-by: Jason Gunthorpe <email address hidden>
(cherry picked from linux-next commit 0af6e0a2da2e4fedaa2743333da438d3b879192b)
Signed-off-by: Tim Gardner <email address hidden>
8a07577...
by
Jarkko Sakkinen <email address hidden>
tpm_crb: drop struct resource res from struct crb_priv
The iomem resource is needed only temporarily so it is better to pass
it on instead of storing it permanently. Named the variable as io_res
so that the code better documents itself.
Signed-off-by: Jarkko Sakkinen <email address hidden>
Reviewed-by: Stefan Berger <email address hidden>
(cherry picked from linux-next commit 3f944075e75e28c9cf1af8f82798398b0e3594b6)
Signed-off-by: Tim Gardner <email address hidden>
This is a better method for detecting the state of secure boot and
the MOKSBState override, as opposed to grepping status from the kernel log.
Both variables return 0 or 1. If secure_boot==0 then signed module
enforcement is not enabled. Likewise, if moksbstate_disabled==1 then
signed module enforcement is not enabled. The only conditions uder which
signed module enforcement is enabled is when secure_boot==1 and
moksbstate_disabled==0.
It would be much simpler if one could pass MOKSBState via a global variable,
but the the EFI bits appear to be managed and linked a bit differently then
a normal text section. Hence the shennanigans with boot_params.secure_boot.
Signed-off-by: Tim Gardner <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
This adds an additional keyring that is used to store certificates that
are blacklisted. This keyring is searched first when loading signed modules
and if the module's certificate is found, it will refuse to load. This is
useful in cases where third party certificates are used for module signing.
