Since the aw88261_acf.bin file appears to be device-specific, add
firmware-name support so that devicetree users can point to a
device-specific path to not conflict with other devices that might also
ship a aw88261_acf.bin.
Read the "firmware-name" property if available, and otherwise fall back
to the generic name.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://patch.msgid.link/20260211-aw88261-fwname-v1-3-e24e833a019d@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the aw88261_acf.bin file appears to be device-specific, add a
firmware-name property so that devicetree users can point to a
device-specific path to not conflict with other devices that might also
ship a aw88261_acf.bin.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260211-aw88261-fwname-v1-2-e24e833a019d@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Lecoo Bellator N176 requires a specific quirk to enable the DMIC
support.
Signed-off-by: Mingyou Chen <qby140326@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260213055904.110256-4-qby140326@gmail.com
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The RPL driver is no longer needed because its functionality has been
superseded by the YC driver
Signed-off-by: Mingyou Chen <qby140326@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260213055904.110256-3-qby140326@gmail.com
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Update the example devicetree with unique regulator names for all
regulators. This reflects the same change made to the actual .dtsi file.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260219-mtk-mt6359-fix-regulator-names-v1-2-ee0fcebfe1d9@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the AHT20 datasheet (updated to V1.0 after the 2023.09
version), the initialization command for AHT20 is 0b10111110 (0xBE).
The previous sequence (0xE1) used in earlier versions is no longer
compatible with newer AHT20 sensors. Update the initialization
command to ensure the sensor is properly initialized.
While at it, use binary notation for DHT20_CMD_INIT to match the notation
used in the datasheet.
Fixes: d2abcb5cc8 ("hwmon: (aht10) Add support for compatible aht20")
Signed-off-by: Hao Yu <haoyufine@gmail.com>
Link: https://lore.kernel.org/r/20260222170332.1616-3-haoyufine@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The macsmc-hwmon driver experienced several issues related to value
scaling and type conversion:
1. macsmc_hwmon_read_f32_scaled() clipped values to INT_MAX/INT_MIN.
On 64-bit systems, hwmon supports long values, so clipping to
32-bit range was premature and caused loss of range for high-power
sensors. Changed it to use long and clip to LONG_MAX/LONG_MIN.
2. The overflow check in macsmc_hwmon_read_f32_scaled() used 1UL,
which is 32-bit on some platforms. Switched to 1ULL.
3. macsmc_hwmon_read_key() used a u32 temporary variable for f32
values. When assigned to a 64-bit long, negative values were
zero-extended instead of sign-extended, resulting in large
positive numbers.
4. macsmc_hwmon_read_ioft_scaled() used mult_frac() which could
overflow during intermediate multiplication. Switched to
mul_u64_u32_div() to handle the 64-bit multiplication safely.
5. ioft values (unsigned 48.16) could overflow long when scaled
by 1,000,000. Added explicit clipping to LONG_MAX in the caller.
6. macsmc_hwmon_write_f32() truncated its long argument to int,
potentially causing issues for large values.
Fix these issues by using appropriate types and helper functions.
Fixes: 785205fd81 ("hwmon: Add Apple Silicon SMC hwmon driver")
Cc: James Calligeros <jcalligeros99@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Neal Gompa <neal@gompa.dev>
Cc: Janne Grunau <j@jannau.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20260129175112.3751907-3-linux@roeck-us.net
Reviewed-by: James Calligeros <jcalligeros99@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The recently added macsmc-hwmon driver contained several critical
bugs in its sensor population logic and float conversion routines.
Specifically:
- The voltage sensor population loop used the wrong prefix ("volt-"
instead of "voltage-") and incorrectly assigned sensors to the
temperature sensor array (hwmon->temp.sensors) instead of the
voltage sensor array (hwmon->volt.sensors). This would lead to
out-of-bounds memory access or data corruption when both temperature
and voltage sensors were present.
- The float conversion in macsmc_hwmon_write_f32() had flawed exponent
logic for values >= 2^24 and lacked masking for the mantissa, which
could lead to incorrect values being written to the SMC.
Fix these issues to ensure correct sensor registration and reliable
manual fan control.
Confirm that the reported overflow in FIELD_PREP is fixed by declaring
macsmc_hwmon_write_f32() as __always_inline for a compile test.
Fixes: 785205fd81 ("hwmon: Add Apple Silicon SMC hwmon driver")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/linux-hwmon/20260119195817.GA1035354@ax162/
Cc: James Calligeros <jcalligeros99@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Neal Gompa <neal@gompa.dev>
Cc: Janne Grunau <j@jannau.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build only
Link: https://lore.kernel.org/r/20260129175112.3751907-2-linux@roeck-us.net
Reviewed-by: James Calligeros <jcalligeros99@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The NPCM8XX DTSI currently includes a 'syscon' phandle in the watchdog
node, but this property is not used by any upstream driver and is not
documented in the NPCM watchdog binding. Since it was never reviewed and
does not form part of the DT ABI, remove it.
[arj: Drop 'safely' language in line with Krzysztof's commentary]
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260218184800.2261674-1-tmaimon77@gmail.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
The siliconid_to_name() function currently masks the input silicon ID
with 0xff00ffff, but compares it against unmasked table entries. This
causes matching to fail if the table entries contain non-zero values in
the bits covered by the mask (bits 16-23).
Update the logic to apply the 0xff00ffff mask to the table entries
during comparison. This ensures that only the relevant model and
revision bits are considered, providing a consistent match across
different manufacturing batches.
[arj: Add Fixes: tag, fix 'soninfo' typo, clarify function reference]
Fixes: e0218dca57 ("soc: aspeed: Add soc info driver")
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Link: https://patch.msgid.link/20260122-soc_aspeed_name_fix-v1-1-33a847f2581c@gmail.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
add NFC NXP NCI device support to NFC tag reading
Signed-off-by: Carl Lee <carl.lee@amd.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Document the new comptaibles for AST2500 based Asrock Paul IPMI card
Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260125-asrock-paul-v1-1-956085a4bd06@gmail.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Add a 128M layout for the BMC flash chip we didn't boot from. Including
this allows the user to write to each partition on the alternate spi
chip. This dtsi follows the existing standard of using the same layout
as non alt version and prepending `alt` to each partition's name.
[arj: Update subject, elide test demonstration]
Signed-off-by: Marc Olberding <molberding@nvidia.com>
Link: https://patch.msgid.link/20260120-alt-128-v4-1-0e5c491a532c@nvidia.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Add device tree for Asus Kommando IPMI Expansion card, an AST2600 based
PCIe BMC card.
Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Document the new comptaibles for AST2600 based Asus Kommando IPMI card
Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
When device_get_child_node_count() got split to the fwnode and device
respective APIs, the fwnode didn't inherit the ability to traverse over
the secondary fwnode. Hence any user, that switches from device to fwnode
API misses this feature. In particular, this was revealed by the commit
1490cbb9db ("device property: Split fwnode_get_child_node_count()")
that effectively broke the GPIO enumeration on Intel Galileo boards.
Fix this by moving the secondary lookup from device to fwnode API.
Note, in general no device_*() API should go into the depth of the fwnode
implementation.
Fixes: 114dbb4fa7 ("drivers property: When no children in primary, try secondary")
Cc: stable@vger.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/20260210135822.47335-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
cifs_pick_channel uses (start % chan_count) when channels are equally
loaded, but that can return a channel that failed the eligibility
checks.
Drop the fallback and return the scan-selected channel instead. If none
is eligible, keep the existing behavior of using the primary channel.
Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com>
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Acked-by: Meetakshi Setiya <msetiya@microsoft.com>
Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
There are no remaining users of divider_round_rate() and
divider_round_rate_parent(), so let's go ahead and remove them.
Signed-off-by: Brian Masney <bmasney@redhat.com>
The round_rate() clk ops is deprecated, and all in tree drivers have
been converted, so let's go ahead and remove any references to the
round_rate() clk ops.
Signed-off-by: Brian Masney <bmasney@redhat.com>
The round_rate() clk ops is deprecated and going away, so migrate
this driver from round_rate() to determine_rate().
Signed-off-by: Brian Masney <bmasney@redhat.com>
The round_rate() clk ops is going away, so let's go ahead and remove any
references to it in the comments.
Signed-off-by: Brian Masney <bmasney@redhat.com>
The EDP_HOTPLUG pin is optional, and muxed with other functions (notably
HDMI CEC), so move its selection from the SoC DTSI to the boards which
apparently want it, namely those which enable eDP without "force-hpd".
By the same token we drop it from Pinebook Pro, which already uses
"force-hpd", and according to the schematics does not have the pin wired
at all.
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://patch.msgid.link/c7d972d07875241805db8659305b26bd694867d4.1769191673.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
TS433 devices received a board revision adding gpios for per hard-disk
presence-detection and power-control. These boards have a PCB-id of at
least 13 which can be read from an EEPROM.
The presence detection is not really necessary and there are also no
existing bindings for doing something with it. So add them as gpio hog
to at least document them and allow its state to be read from debugfs.
The power-control is modelled as regulator, with connected to the
RK3568's SATA controller as target-supply.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260201191804.41421-5-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
TS233 devices received a board revision adding gpios for per hard-disk
presence-detection and power-control. These boards have a PCB-id of at
least 12 (mainboard) and 11 (backplane), which can be read from an EEPROM.
The presence detection is not really necessary and there are also no
existing bindings for doing something with it. So add them as gpio hogs
to at least document them and allow their state to be read from debugfs.
The power-control is modelled as regulators, with the hdd1+hdd2 variants
connected to the RK3568's SATA controllers as target-supplies.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260201191804.41421-4-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
TS433 devices received a board revision adding gpios for per hard-disk
presence-detection and power-control. These board have a PCB-id of at
least 12 (mainboard) and 10 (backplane), which can be read from an EEPROM.
The presence detection is not really necessary and there are also no
existing bindings for doing something with it. So add them as gpio hogs
to at least document them and allow their state to be read from debugfs.
The power-control is modelled as regulators, with the hdd1+hdd2 variants
connected to the RK3568's SATA controllers as target-supplies. The
JMicron AHCI controller on PCIe didn't have bindings for that, I could
find, so they get an always-on state for now.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260201191804.41421-3-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The SATA controllers on RK356x are identical to the ones found on RK3588,
but don't yet provide a port sub-node. Per the datasheet the RK356x also
supports the fbscp capability and has the same queue maximums.
So add port sub-nodes to both sata controllers on RK356x, and move the
phy properties to it. Also add phandles to the ports, so that boards can
add their target-supply when available.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260201191804.41421-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add support for the two Awinic aw87391 audio amplifiers used in the
Anbernic RG-DS. These amplifiers require a specific init sequence to
start which is usually provided by a firmware file, but in our case
the manufacturer only provided the sequence. As a result, we hard-code
a device specific compatible.
Additionally, add support for the VDD regulator used to power both
amplifiers. Note that the amps can accept and respond to i2c commands
even without regulator power (perhaps due to a secondary power source)
but cannot play audio.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260128174608.1498-4-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The power domains pd_rkvdec0/1 and pd_venc0/1 depend on two voltage
supplies, vdd_vdenc_s0 and vdd_vdenc_mem_s0. These supplies might be
missing or cause probe deferral. Since the Rockchip power domain
management code currently supports managing only one power supply, and
both supplies belong to the same PMIC (making it highly unlikely for
one to be available while the other is not), a practical solution
is implemented.
Both supplies are configured with the boot-on and always-on properties.
Only one of them is assigned as the domain-supply for pd_rkvdec0/1 and
pd_venc0/1. This allows the power domain code to perform a nominal enable
operation on this single supply, thereby successfully acquiring a
reference to both supplies (as they are from the same PMIC). The system
then relies on their boot-on and always-on flags to maintain the correct
state.
Crucially, this approach handles cases like probe deferral correctly:
if the PMIC is not yet ready, enabling the power domain will be deferred
until the necessary supplies become available.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1770950113-19802-2-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The OneThing Edge Cube (OEC) series features the RK3566 SoC, 8GB
eMMC storage, and supports one SATA interface, one Gigabit Ethernet
port, and one USB 3.0 port.
Other than the difference in RAM capacity, the OEC and OEC-turbo are
identical in all other specifications.
Specification:
- Rockchip RK3566
- LPDDR4X 2GB (OEC) / 4GB (OEC-turbo)
- eMMC 8GB
- Gigabit Ethernet port x 1
- USB 3.0 port x 1
- USB-C 2.0 port x 1
- 12V DC Power supply
- SATA 3.0 connector x 1
These devices do not have a PMIC, and their hardware circuit design
is highly similar to that of the rk3566-box-demo[1]. Hardware schematics
are not available at this time, with the vendor firmware dts available
for reference[2].
Ethernet, USB 3.0 and SATA 3.0 ports tested, all working well.
[1] https://elixir.bootlin.com/linux/v6.18.6/source/arch/arm64/boot/dts/rockchip/rk3566-box-demo.dts
[2] https://archive.org/download/wxy-oec-RK3566-4G-dump/wxy-oec-RK3566-4G-dump.dts
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Link: https://patch.msgid.link/20260214021719.620752-4-jerrysteve1101@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add devicetree binding for the OneThing OEC and OEC-turbo
The OneThing Edge Cube (OEC) series features the RK3566 SoC, 8GB
eMMC storage, and supports one SATA interface, one Gigabit Ethernet
port, and one USB 3.0 port.
Among the lineup, the standard OEC model comes with 2GB of RAM, while
the OEC-turbo features 4GB of RAM; The rest of the specifications are
identical.
The OneThing Edge Cube series (shipping with the vendor firmware) is
originally designed as a PCDN (P2P Content Delivery Network) device.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260214021719.620752-3-jerrysteve1101@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The DisplayPort on rk3576 is compliant with DisplayPort Specification
Version 1.4 with MST support, and share the USBDP combo PHY with USB 3.1
OTG0 controller.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20260206010421.443605-6-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This reverts commit 6d54d93506.
It seems there are different variants of the Wifi chipset in use on the
Pinebook Pro. And according to the reported regression - see Closes
below, the reverted change causes issues with one Wifi chipset.
The original commit message indicates a "further description" only and
does not indicate this would fix an actual problem, so a revert should
not cause further problems.
Fixes: 6d54d93506 ("arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro")
Cc: Jan Palus <jpalus@fastmail.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/r/aUKOlj-RvTYlrpiS@rock.grzadka/
Tested-by: Jan Palus <jpalus@fastmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260210120142.698512-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
- Fix a build error on parisc
- Remove the non-large-folio-aware function fsverity_verify_page()
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCaZtg+xQcZWJpZ2dlcnNA
a2VybmVsLm9yZwAKCRDzXCl4vpKOKwQ+AQCiXEYAibl3vHRgQo7qEPCC5or4FtkF
HZ0ERRArhsU17AD/TKHE/AJkyFrwK4rGTb6I9Wi1OXnpG7jihZlYjj03Ag4=
=CUql
-----END PGP SIGNATURE-----
Merge tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux
Pull fsverity fixes from Eric Biggers:
- Fix a build error on parisc
- Remove the non-large-folio-aware function fsverity_verify_page()
* tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux:
fsverity: fix build error by adding fsverity_readahead() stub
fsverity: remove fsverity_verify_page()
f2fs: make f2fs_verify_cluster() partially large-folio-aware
f2fs: remove unnecessary ClearPageUptodate in f2fs_verify_cluster()
Fix a big endian specific issue in the PPC64-optimized AES code.
-----BEGIN PGP SIGNATURE-----
iIoEABYIADIWIQSacvsUNc7UX4ntmEPzXCl4vpKOKwUCaZtiphQcZWJpZ2dlcnNA
a2VybmVsLm9yZwAKCRDzXCl4vpKOK/z2AQD1j15Ao3iDW3yBSyTS+tFJaRUVDtjg
bNostoNJAjMM9wD/X0oAnt95WTNkdHexs+2aMzQ4ULKFRcwQrUTarKx7IgY=
=Dmfx
-----END PGP SIGNATURE-----
Merge tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux
Pull crypto library fix from Eric Biggers:
"Fix a big endian specific issue in the PPC64-optimized AES code"
* tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux:
lib/crypto: powerpc/aes: Fix rndkey_from_vsx() on big endian CPUs
Stephen retired and stepped back from -next maintainership, update his
entry in CREDITS to recognise his 18 years of hard work making it what
it is today and all the impact it's had on our development process.
Also update to his current GnuPG key while we're here.
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: SeongJae Park <sj@kernel.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The x509 public key code gained a dependency on the sha256 hash
implementation, causing a rare link time failure in randconfig
builds:
arm-linux-gnueabi-ld: crypto/asymmetric_keys/x509_public_key.o: in function `x509_get_sig_params':
x509_public_key.c:(.text.x509_get_sig_params+0x12): undefined reference to `sha256'
arm-linux-gnueabi-ld: (sha256): Unknown destination type (ARM/Thumb) in crypto/asymmetric_keys/x509_public_key.o
x509_public_key.c:(.text.x509_get_sig_params+0x12): dangerous relocation: unsupported relocation
Select the necessary library code from Kconfig.
Fixes: 2c62068ac8 ("x509: Separately calculate sha256 for blacklist")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
