Re: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
On Tue, Dec 12, 2023 at 10:39:58AM -0600, Ninad Palsule wrote: > From: Johannes Holland > > Add a dt schema to support device tree bindings for the generic I2C > physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP) > Specification for TPM 2.0 v1.04 Revision 14. > > This includes descriptions for the Nuvoton and Infineon devices. This is incomplete and conflicts with this series[1]. Please help review and make sure it works for the cases you care about. Rob [1] https://lore.kernel.org/all/cover.1701093036.git.lu...@wunner.de/
Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths
Hi Kees, On 2023-12-12 22:19 Kees Cook wrote: > On Thu, 30 Nov 2023 12:51:17 -0800, Kees Cook wrote: > > This attempts to fix the issue Ronald Monthero found[1]. Avoids using a > > too-short struct buffer when reading the string, by using the existing > > struct union. > > > > -Kees > > > > [1] > > https://lore.kernel.org/lkml/20231112095353.579855-1-debug.penguin32@gmai > > l.com/ > > > > [...] > > I'll put these in -next since there's been no more discussion on it. > > Applied to for-next/hardening, thanks! thanks for taking care of this (and apologies for me being unresponsive) If it's not too late, feel free to add Acked-by: Anders Larsen Cheers Anders
Re: [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc
On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote: > Document the new compatibles used on IBM system1-bmc > > Tested: this not very useful line :-) (nit) > This board is tested using the simics simulator. Just leave this (w/o indentation) > > Signed-off-by: Ninad Palsule > --- > Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 + > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml > b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml > index 6f7543463d89..ebebe14c42aa 100644 > --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml > +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml > @@ -85,6 +85,7 @@ properties: >- facebook,yosemite4-bmc >- ibm,everest-bmc >- ibm,rainier-bmc > + - ibm,system1-bmc >- ibm,tacoma-bmc >- inventec,starscream-bmc >- inventec,transformer-bmc > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml > b/Documentation/devicetree/bindings/trivial-devices.yaml > index 441b55723675..b12a60d2eb0f 100644 > --- a/Documentation/devicetree/bindings/trivial-devices.yaml > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml > @@ -135,6 +135,8 @@ properties: >- ibm,cffps1 > # IBM Common Form Factor Power Supply Versions 2 >- ibm,cffps2 > +# Infineon barometric pressure and temperature sensor > + - infineon,dps310 > # Infineon IR36021 digital POL buck controller >- infineon,ir36021 > # Infineon IR38060 Voltage Regulator BR, Jarkko
Re: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote:
> From: Johannes Holland
>
> Add a dt schema to support device tree bindings for the generic I2C
> physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
> Specification for TPM 2.0 v1.04 Revision 14.
>
> This includes descriptions for the Nuvoton and Infineon devices.
>
> OpenBMC-Staging-Count: 3
Please don't invent your own tags.
> Signed-off-by: Johannes Holland
> Signed-off-by: Joel Stanley
> Signed-off-by: Ninad Palsule
> ---
> .../bindings/security/tpm/tpm-tis-i2c.yaml| 50 +++
> 1 file changed, 50 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>
> diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> new file mode 100644
> index ..de1e34065748
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: I2C PTP based TPM Devices
> +
> +maintainers:
> + - Johannes Holland
> +
> +description:
> + Device Tree Bindings for I2C based Trusted Platform Module (TPM).
> +
> +properties:
> + $nodename:
> +pattern: "^tpm(@[0-9a-f]+)?$"
> +
> + compatible:
> +oneOf:
> + - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
> +items:
> + - const: infineon,slb9673
> + - const: tcg,tpm-tis-i2c
> + - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
> +items:
> + - const: nuvoton,npct75x
> + - const: tcg,tpm-tis-i2c
> + - const: tcg,tpm-tis-i2c
> + reg:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + tpm@2e {
> +compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
> +reg = <0x2e>;
> + };
> +};
> +...
BR, Jarkko
Re: [PATCH v1 1/8] dt-bindings: arm: aspeed: add IBM system1-bmc
Hello Jarkko, On 12/13/23 12:18, Jarkko Sakkinen wrote: On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote: Document the new compatibles used on IBM system1-bmc Tested: this not very useful line :-) (nit) This board is tested using the simics simulator. Just leave this (w/o indentation) Based on Conor's suggestion, I have removed both lines. Thanks for the review. Thanks & Regards, Ninad Signed-off-by: Ninad Palsule --- Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 + Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 2 files changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml index 6f7543463d89..ebebe14c42aa 100644 --- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml @@ -85,6 +85,7 @@ properties: - facebook,yosemite4-bmc - ibm,everest-bmc - ibm,rainier-bmc + - ibm,system1-bmc - ibm,tacoma-bmc - inventec,starscream-bmc - inventec,transformer-bmc diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 441b55723675..b12a60d2eb0f 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -135,6 +135,8 @@ properties: - ibm,cffps1 # IBM Common Form Factor Power Supply Versions 2 - ibm,cffps2 +# Infineon barometric pressure and temperature sensor + - infineon,dps310 # Infineon IR36021 digital POL buck controller - infineon,ir36021 # Infineon IR38060 Voltage Regulator BR, Jarkko
Re: [PATCH v1 2/8] dt-bindings: tpm: Add schema for TIS I2C devices
Hello Jarkko,
On 12/13/23 12:20, Jarkko Sakkinen wrote:
On Tue Dec 12, 2023 at 6:39 PM EET, Ninad Palsule wrote:
From: Johannes Holland
Add a dt schema to support device tree bindings for the generic I2C
physical layer. Refer to the TCG PC Client Platform TPM Profile (PTP)
Specification for TPM 2.0 v1.04 Revision 14.
This includes descriptions for the Nuvoton and Infineon devices.
OpenBMC-Staging-Count: 3
Please don't invent your own tags.
Yes, Sorry. I have cherry-picked this commit from openbmc. Now I have
removed this line.
Thanks for the review.
Thanks & Regards,
Ninad
Signed-off-by: Johannes Holland
Signed-off-by: Joel Stanley
Signed-off-by: Ninad Palsule
---
.../bindings/security/tpm/tpm-tis-i2c.yaml| 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
diff --git a/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
new file mode 100644
index ..de1e34065748
--- /dev/null
+++ b/Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/security/tpm/tpm-tis-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C PTP based TPM Devices
+
+maintainers:
+ - Johannes Holland
+
+description:
+ Device Tree Bindings for I2C based Trusted Platform Module (TPM).
+
+properties:
+ $nodename:
+pattern: "^tpm(@[0-9a-f]+)?$"
+
+ compatible:
+oneOf:
+ - description: Infineon's Trusted Platform Module (TPM) (SLB9673).
+items:
+ - const: infineon,slb9673
+ - const: tcg,tpm-tis-i2c
+ - description: Nuvoton's Trusted Platform Module (TPM) (NPCT75x).
+items:
+ - const: nuvoton,npct75x
+ - const: tcg,tpm-tis-i2c
+ - const: tcg,tpm-tis-i2c
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tpm@2e {
+compatible = "nuvoton,npct75x", "tcg,tpm-tis-i2c";
+reg = <0x2e>;
+ };
+};
+...
BR, Jarkko
Re: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
Hello Krzysztof,
On 12/12/23 14:26, Krzysztof Kozlowski wrote:
On 12/12/2023 17:40, Ninad Palsule wrote:
This drop adds following devices in the device tree.
- EEPROM/VPD
- Power supplies
- Humidity, pressure and temperature sensors.
- Trusted platform module(TPM) chip
Tested:
This board is tested using the simics simulator.
Signed-off-by: Ninad Palsule
---
Don't mix DTS with drivers. DTS and drivers go via different subsystems
and cannot have dependencies, so why DTS is patch #6, then driver #7 and
now again DTS #7?
There is a dependency on driver code as patch #8 uses the compatibility
string added in driver patch #7. I have now moved driver patch at the
start. Is that ok? OR you are suggesting something else?
v1-0001-tpm-tis-i2c-Add-more-compatible-strings.patch
|
v1-0009-ARM-dts-aspeed-System1-PS-sensor-and-more.patch
.../dts/aspeed/aspeed-bmc-ibm-system1.dts | 76 +++
1 file changed, 76 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
index 75562aa63701..d960b938fe8d 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-ibm-system1.dts
@@ -461,6 +461,11 @@ &kcs3 {
&i2c0 {
status = "okay";
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
regulator@60 {
compatible = "maxim,max8952";
reg = <0x60>;
@@ -655,6 +660,25 @@ pca0: pca9539@74 {
&i2c2 {
status = "okay";
+
+ power-supply@58 {
+ compatible = "ibm,cffps";
+ reg = <0x58>;
+ };
+
+ power-supply@59 {
+ compatible = "ibm,cffps";
+ reg = <0x59>;
+ };
+
+ power-supply@5a {
+ compatible = "ibm,cffps";
+ reg = <0x5a>;
+ };
Missing blank line
Fixed it.
Thanks for the review.
Regards,
Ninad
+ power-supply@5b {
+ compatible = "ibm,cffps";
+ reg = <0x5b>;
+ };
Best regards,
Krzysztof
Re: [PATCH v2 0/2] qnx4: Avoid confusing compiler about buffer lengths
On Wed, Dec 13, 2023 at 05:43:08PM +0100, Anders Larsen wrote: > Hi Kees, > > On 2023-12-12 22:19 Kees Cook wrote: > > On Thu, 30 Nov 2023 12:51:17 -0800, Kees Cook wrote: > > > This attempts to fix the issue Ronald Monthero found[1]. Avoids using a > > > too-short struct buffer when reading the string, by using the existing > > > struct union. > > > > > > -Kees > > > > > > [1] > > > https://lore.kernel.org/lkml/20231112095353.579855-1-debug.penguin32@gmai > > > l.com/ > > > > > > [...] > > > > I'll put these in -next since there's been no more discussion on it. > > > > Applied to for-next/hardening, thanks! > > thanks for taking care of this (and apologies for me being unresponsive) > > If it's not too late, feel free to add > Acked-by: Anders Larsen Thanks! I'll update the tags. :) -- Kees Cook
Re: [PATCH v2 00/18] sysctl: constify sysctl ctl_tables
Luis Chamberlain writes: > On Mon, Dec 11, 2023 at 12:25:10PM +0100, Thomas Weißschuh wrote: >> Before sending it I'd like to get feedback on the internal rework of the >> is_empty detection from you and/or Luis. >> >> https://git.sr.ht/~t-8ch/linux/commit/ea27507070f3c47be6febebe451bbb88f6ea707e >> or the attached patch. > > Please send as a new patch as RFC and please ensure on the To field is > first "Eric W. Biederman" with a bit more > elaborate commit log as suggested from my review below. If there are > any hidden things me and Joel could probably miss I'm sure Eric will > be easily able to spot it. > >> From ea27507070f3c47be6febebe451bbb88f6ea707e Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= >> Date: Sun, 3 Dec 2023 21:56:46 +0100 >> Subject: [PATCH] sysctl: move permanently empty flag to ctl_dir >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 8bit >> >> Simplify the logic by always keeping the permanently_empty flag on the >> ctl_dir. >> The previous logic kept the flag in the leaf ctl_table and from there >> transferred it to the ctl_table from the directory. >> >> This also removes the need to have a mutable ctl_table and will allow >> the constification of those structs. > Please elaborate a bit more on this here in your next RFC. > It's a pretty aggressive cleanup, specially with the new hipster guard() > call but I'd love Eric's eyeballs on a proper v2. I will look at a v2 time permitting. My sense is that changing the locking probably make sense as a separate patch. Eric
Re: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
On 13/12/2023 20:02, Ninad Palsule wrote: > Hello Krzysztof, > > On 12/12/23 14:26, Krzysztof Kozlowski wrote: >> On 12/12/2023 17:40, Ninad Palsule wrote: >>> This drop adds following devices in the device tree. >>> - EEPROM/VPD >>> - Power supplies >>> - Humidity, pressure and temperature sensors. >>> - Trusted platform module(TPM) chip >>> >>> Tested: >>> This board is tested using the simics simulator. >>> >>> Signed-off-by: Ninad Palsule >>> --- >> Don't mix DTS with drivers. DTS and drivers go via different subsystems >> and cannot have dependencies, so why DTS is patch #6, then driver #7 and >> now again DTS #7? > > There is a dependency on driver code as patch #8 uses the compatibility > string added in driver patch #7. I have now moved driver patch at the > start. Is that ok? OR you are suggesting something else? First, there is no dependency. Second, except confusing order anyway DTS will go via separate trees. Third, again, there is no dependency. If there is, your patchset is broken and this needs to be fixed. Although I don't understand how new hardware can depend on driver... it's really odd. Best regards, Krzysztof
Re: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
Hello Krzysztof, On 12/13/23 13:37, Krzysztof Kozlowski wrote: On 13/12/2023 20:02, Ninad Palsule wrote: Hello Krzysztof, On 12/12/23 14:26, Krzysztof Kozlowski wrote: On 12/12/2023 17:40, Ninad Palsule wrote: This drop adds following devices in the device tree. - EEPROM/VPD - Power supplies - Humidity, pressure and temperature sensors. - Trusted platform module(TPM) chip Tested: This board is tested using the simics simulator. Signed-off-by: Ninad Palsule --- Don't mix DTS with drivers. DTS and drivers go via different subsystems and cannot have dependencies, so why DTS is patch #6, then driver #7 and now again DTS #7? There is a dependency on driver code as patch #8 uses the compatibility string added in driver patch #7. I have now moved driver patch at the start. Is that ok? OR you are suggesting something else? First, there is no dependency. Second, except confusing order anyway DTS will go via separate trees. Third, again, there is no dependency. If there is, your patchset is broken and this needs to be fixed. Although I don't understand how new hardware can depend on driver... it's really odd. Thanks for the quick response. This board uses the nuvoton TPM device. The tpm devices uses "nuvoton,npct75x" driver hence we added it in the device tree. If the driver doesn't have this compatibility string then it won't load. So if someone tries to use this board then tpm won't work unless the compatibility string is added in the driver. That is the dependency I am talking about. Please let me know. Regards, Ninad Best regards, Krzysztof
Re: [PATCH v3] iio: sx9324: avoid copying property strings
Quoting Justin Stitt (2023-12-11 16:42:52)
> diff --git a/drivers/iio/proximity/sx9324.c b/drivers/iio/proximity/sx9324.c
> index 438f9c9aba6e..e3bc30b57b19 100644
> --- a/drivers/iio/proximity/sx9324.c
> +++ b/drivers/iio/proximity/sx9324.c
> @@ -873,6 +873,32 @@ static int sx9324_init_compensation(struct iio_dev
> *indio_dev)
> 2, 200);
> }
>
> +static u32 sx9324_parse_phase_prop(struct device *dev,
return u8? because that's the type of struct sx_common_reg_default::def.
> + struct sx_common_reg_default *reg_def,
> + int idx, const char *prop)
> +{
> + unsigned int pin_defs[SX9324_NUM_PINS];
> + int count, ret, pin;
> + u8 default_def;
> + u32 raw = 0;
> +
> + default_def = sx9324_default_regs[idx].def;
Do we need to do this? Isn't this reg_def->def?
> +
> + count = device_property_count_u32(dev, prop);
> + if (count != ARRAY_SIZE(pin_defs))
> + return default_def;
return reg_def->def?
> + ret = device_property_read_u32_array(dev, prop, pin_defs,
> +ARRAY_SIZE(pin_defs));
> + if (ret)
> + return default_def;
return reg_def->def?
> +
> + for (pin = 0; pin < SX9324_NUM_PINS; pin++)
> + raw |= (pin_defs[pin] << (2 * pin)) &
> + SX9324_REG_AFE_PH0_PIN_MASK(pin);
> +
> + return raw;
> +}
> +
> static const struct sx_common_reg_default *
> sx9324_get_default_reg(struct device *dev, int idx,
>struct sx_common_reg_default *reg_def)
> @@ -884,35 +910,30 @@ sx9324_get_default_reg(struct device *dev, int idx,
> #define SX9324_PIN_DEF "semtech,ph0-pin"
> #define SX9324_RESOLUTION_DEF "semtech,ph01-resolution"
> #define SX9324_PROXRAW_DEF "semtech,ph01-proxraw-strength"
Can you send a followup to remove these defines?
> - unsigned int pin_defs[SX9324_NUM_PINS];
> - char prop[] = SX9324_PROXRAW_DEF;
> + const char *prop = SX9324_PROXRAW_DEF;
This can be left unassigned now, right?
> u32 start = 0, raw = 0, pos = 0;
> - int ret, count, ph, pin;
> const char *res;
> + int ret;
Re: [PATCH] cxgb3: Avoid potential string truncation in desc
Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski : On Tue, 12 Dec 2023 14:09:57 -0800 you wrote: > Builds with W=1 were warning about potential string truncations: > > drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c: In function 'cxgb_up': > drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:394:38: warning: '%d' > directive output may be truncated writing between 1 and 11 bytes into a > region of size between 5 and 20 [-Wformat-truncation=] > 394 | "%s-%d", d->name, pi->first_qset + > i); > | ^~ > In function 'name_msix_vecs', > inlined from 'cxgb_up' at > drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:1264:3: > drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:394:34: note: directive > argument in the range [-2147483641, 509] > 394 | "%s-%d", d->name, pi->first_qset + > i); > | ^~~ > drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c:393:25: note: 'snprintf' > output between 3 and 28 bytes into a destination of size 21 > 393 | snprintf(adap->msix_info[msi_idx].desc, n, > | ^~ > 394 | "%s-%d", d->name, pi->first_qset + > i); > | ~ > > [...] Here is the summary with links: - cxgb3: Avoid potential string truncation in desc https://git.kernel.org/netdev/net-next/c/bc044ae9d64b You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH] amd-xgbe: Avoid potential string truncation in name
Hello: This patch was applied to netdev/net-next.git (main) by Jakub Kicinski : On Tue, 12 Dec 2023 14:13:12 -0800 you wrote: > Build with W=1 were warning about a potential string truncation: > > drivers/net/ethernet/amd/xgbe/xgbe-drv.c: In function 'xgbe_alloc_channels': > drivers/net/ethernet/amd/xgbe/xgbe-drv.c:211:73: warning: '%u' directive > output may be truncated writing between 1 and 10 bytes into a region of size > 8 [-Wformat-truncation=] > 211 | snprintf(channel->name, sizeof(channel->name), > "channel-%u", i); > | > ^~ > drivers/net/ethernet/amd/xgbe/xgbe-drv.c:211:64: note: directive argument in > the range [0, 4294967294] > 211 | snprintf(channel->name, sizeof(channel->name), > "channel-%u", i); > | > ^~~~ > drivers/net/ethernet/amd/xgbe/xgbe-drv.c:211:17: note: 'snprintf' output > between 10 and 19 bytes into a destination of size 16 > 211 | snprintf(channel->name, sizeof(channel->name), > "channel-%u", i); > | > ^~~ > > [...] Here is the summary with links: - amd-xgbe: Avoid potential string truncation in name https://git.kernel.org/netdev/net-next/c/84cc99199a34 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v2] scsi: fcoe: use sysfs_match_string over fcoe_parse_mode
Justin, > Instead of copying @buf into a new buffer and carefully managing its > newline/null-terminating status, we can just use sysfs_match_string() > as it uses sysfs_streq() internally which handles newline/null-term: Applied to 6.8/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ibmvscsi: replace deprecated strncpy with strscpy
On Mon, 30 Oct 2023 20:40:48 +, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > We expect partition_name to be NUL-terminated based on its usage with > format strings: > | dev_info(hostdata->dev, "host srp version: %s, " > |"host partition %s (%d), OS %d, max io %u\n", > |hostdata->madapter_info.srp_version, > |hostdata->madapter_info.partition_name, > |be32_to_cpu(hostdata->madapter_info.partition_number), > |be32_to_cpu(hostdata->madapter_info.os_type), > |be32_to_cpu(hostdata->madapter_info.port_max_txu[0])); > ... > | len = snprintf(buf, PAGE_SIZE, "%s\n", > |hostdata->madapter_info.partition_name); > > [...] Applied to 6.8/scsi-queue, thanks! [1/1] scsi: ibmvscsi: replace deprecated strncpy with strscpy https://git.kernel.org/mkp/scsi/c/712b3f43ba0e -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ibmvfc: replace deprecated strncpy with strscpy
On Mon, 30 Oct 2023 19:04:33 +, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > We expect these fields to be NUL-terminated as the property names from > which they are derived are also NUL-terminated. > > [...] Applied to 6.8/scsi-queue, thanks! [1/1] scsi: ibmvfc: replace deprecated strncpy with strscpy https://git.kernel.org/mkp/scsi/c/a9baa16b4fc1 -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2] scsi: zfcp: Replace strlcpy() with strscpy()
On Thu, 30 Nov 2023 12:41:00 -0800, Kees Cook wrote: > strlcpy() reads the entire source buffer first. This read may exceed > the destination size limit. This is both inefficient and can lead > to linear read overflows if a source string is not NUL-terminated[1]. > Additionally, it returns the size of the source string, not the > resulting size of the destination string. In an effort to remove strlcpy() > completely[2], replace strlcpy() here with strscpy(). > > [...] Applied to 6.8/scsi-queue, thanks! [1/1] scsi: zfcp: Replace strlcpy() with strscpy() https://git.kernel.org/mkp/scsi/c/0d224b1088af -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v1 8/8] ARM: dts: aspeed: System1: PS, sensor and more
On 13/12/2023 20:49, Ninad Palsule wrote: > Hello Krzysztof, > > On 12/13/23 13:37, Krzysztof Kozlowski wrote: >> On 13/12/2023 20:02, Ninad Palsule wrote: >>> Hello Krzysztof, >>> >>> On 12/12/23 14:26, Krzysztof Kozlowski wrote: On 12/12/2023 17:40, Ninad Palsule wrote: > This drop adds following devices in the device tree. > - EEPROM/VPD > - Power supplies > - Humidity, pressure and temperature sensors. > - Trusted platform module(TPM) chip > > Tested: > This board is tested using the simics simulator. > > Signed-off-by: Ninad Palsule > --- Don't mix DTS with drivers. DTS and drivers go via different subsystems and cannot have dependencies, so why DTS is patch #6, then driver #7 and now again DTS #7? >>> There is a dependency on driver code as patch #8 uses the compatibility >>> string added in driver patch #7. I have now moved driver patch at the >>> start. Is that ok? OR you are suggesting something else? >> First, there is no dependency. Second, except confusing order anyway DTS >> will go via separate trees. Third, again, there is no dependency. If >> there is, your patchset is broken and this needs to be fixed. Although I >> don't understand how new hardware can depend on driver... it's really odd. > > Thanks for the quick response. > > This board uses the nuvoton TPM device. The tpm devices uses > "nuvoton,npct75x" driver hence we added it in the device tree. If the > driver doesn't have this compatibility string then it won't load. So if > someone tries to use this board then tpm won't work unless the ... and if there is no board it also fails to load. > compatibility string is added in the driver. That is the dependency I am > talking about. This is not a dependency! It's unrelated. Best regards, Krzysztof
