* [PATCH 02/10] i2c: pasemi: Use io{read,write}32
From: Sven Peter @ 2021-09-26 9:58 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Olof Johansson
Cc: Arnd Bergmann, Sven Peter, Hector Martin, linux-kernel, linux-i2c,
linux-arm-kernel, Mohamed Mediouni, Stan Skowronek, linuxppc-dev,
Alyssa Rosenzweig, Mark Kettenis
In-Reply-To: <20210926095847.38261-1-sven@svenpeter.dev>
In preparation for splitting this driver up into a platform_driver
and a pci_driver, replace outl/inl usage with ioport_map and
ioread32/iowrite32.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
---
drivers/i2c/busses/i2c-pasemi.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pasemi.c b/drivers/i2c/busses/i2c-pasemi.c
index 20f2772c0e79..dd31d902a621 100644
--- a/drivers/i2c/busses/i2c-pasemi.c
+++ b/drivers/i2c/busses/i2c-pasemi.c
@@ -20,6 +20,7 @@ static struct pci_driver pasemi_smb_driver;
struct pasemi_smbus {
struct pci_dev *dev;
struct i2c_adapter adapter;
+ void __iomem *ioaddr;
unsigned long base;
int size;
};
@@ -53,13 +54,13 @@ static inline void reg_write(struct pasemi_smbus *smbus, int reg, int val)
{
dev_dbg(&smbus->dev->dev, "smbus write reg %lx val %08x\n",
smbus->base + reg, val);
- outl(val, smbus->base + reg);
+ iowrite32(val, smbus->ioaddr + reg);
}
static inline int reg_read(struct pasemi_smbus *smbus, int reg)
{
int ret;
- ret = inl(smbus->base + reg);
+ ret = ioread32(smbus->ioaddr + reg);
dev_dbg(&smbus->dev->dev, "smbus read reg %lx val %08x\n",
smbus->base + reg, ret);
return ret;
@@ -351,6 +352,12 @@ static int pasemi_smb_probe(struct pci_dev *dev,
goto out_kfree;
}
+ smbus->ioaddr = ioport_map(smbus->base, smbus->size);
+ if (!smbus->ioaddr) {
+ error = -EBUSY;
+ goto out_release_region;
+ }
+
smbus->adapter.owner = THIS_MODULE;
snprintf(smbus->adapter.name, sizeof(smbus->adapter.name),
"PA Semi SMBus adapter at 0x%lx", smbus->base);
@@ -366,12 +373,14 @@ static int pasemi_smb_probe(struct pci_dev *dev,
error = i2c_add_adapter(&smbus->adapter);
if (error)
- goto out_release_region;
+ goto out_ioport_unmap;
pci_set_drvdata(dev, smbus);
return 0;
+ out_ioport_unmap:
+ ioport_unmap(smbus->ioaddr);
out_release_region:
release_region(smbus->base, smbus->size);
out_kfree:
@@ -384,6 +393,7 @@ static void pasemi_smb_remove(struct pci_dev *dev)
struct pasemi_smbus *smbus = pci_get_drvdata(dev);
i2c_del_adapter(&smbus->adapter);
+ ioport_unmap(smbus->ioaddr);
release_region(smbus->base, smbus->size);
kfree(smbus);
}
--
2.25.1
^ permalink raw reply related
* [PATCH 03/10] i2c: pasemi: Remove usage of pci_dev
From: Sven Peter @ 2021-09-26 9:58 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Olof Johansson
Cc: Arnd Bergmann, Sven Peter, Hector Martin, linux-kernel, linux-i2c,
linux-arm-kernel, Mohamed Mediouni, Stan Skowronek, linuxppc-dev,
Alyssa Rosenzweig, Mark Kettenis
In-Reply-To: <20210926095847.38261-1-sven@svenpeter.dev>
Prepare to create a platform driver by removing all usages of pci_dev we
can.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
---
drivers/i2c/busses/i2c-pasemi.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pasemi.c b/drivers/i2c/busses/i2c-pasemi.c
index dd31d902a621..5a25c2e54b9e 100644
--- a/drivers/i2c/busses/i2c-pasemi.c
+++ b/drivers/i2c/busses/i2c-pasemi.c
@@ -18,7 +18,7 @@
static struct pci_driver pasemi_smb_driver;
struct pasemi_smbus {
- struct pci_dev *dev;
+ struct device *dev;
struct i2c_adapter adapter;
void __iomem *ioaddr;
unsigned long base;
@@ -52,7 +52,7 @@ struct pasemi_smbus {
static inline void reg_write(struct pasemi_smbus *smbus, int reg, int val)
{
- dev_dbg(&smbus->dev->dev, "smbus write reg %lx val %08x\n",
+ dev_dbg(smbus->dev, "smbus write reg %lx val %08x\n",
smbus->base + reg, val);
iowrite32(val, smbus->ioaddr + reg);
}
@@ -61,7 +61,7 @@ static inline int reg_read(struct pasemi_smbus *smbus, int reg)
{
int ret;
ret = ioread32(smbus->ioaddr + reg);
- dev_dbg(&smbus->dev->dev, "smbus read reg %lx val %08x\n",
+ dev_dbg(smbus->dev, "smbus read reg %lx val %08x\n",
smbus->base + reg, ret);
return ret;
}
@@ -94,7 +94,7 @@ static int pasemi_smb_waitready(struct pasemi_smbus *smbus)
return -ENXIO;
if (timeout < 0) {
- dev_warn(&smbus->dev->dev, "Timeout, status 0x%08x\n", status);
+ dev_warn(smbus->dev, "Timeout, status 0x%08x\n", status);
reg_write(smbus, REG_SMSTA, status);
return -ETIME;
}
@@ -342,7 +342,7 @@ static int pasemi_smb_probe(struct pci_dev *dev,
if (!smbus)
return -ENOMEM;
- smbus->dev = dev;
+ smbus->dev = &dev->dev;
smbus->base = pci_resource_start(dev, 0);
smbus->size = pci_resource_len(dev, 0);
@@ -366,7 +366,7 @@ static int pasemi_smb_probe(struct pci_dev *dev,
smbus->adapter.algo_data = smbus;
/* set up the sysfs linkage to our parent device */
- smbus->adapter.dev.parent = &dev->dev;
+ smbus->adapter.dev.parent = smbus->dev;
reg_write(smbus, REG_CTL, (CTL_MTR | CTL_MRR |
(CLK_100K_DIV & CTL_CLK_M)));
--
2.25.1
^ permalink raw reply related
* [PATCH 07/10] i2c: pasemi: Allow to configure bus frequency
From: Sven Peter @ 2021-09-26 9:58 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Olof Johansson
Cc: Arnd Bergmann, Sven Peter, Hector Martin, linux-kernel, linux-i2c,
linux-arm-kernel, Mohamed Mediouni, Stan Skowronek, linuxppc-dev,
Alyssa Rosenzweig, Mark Kettenis
In-Reply-To: <20210926095847.38261-1-sven@svenpeter.dev>
Right now the bus frequency has always been hardcoded as
100 KHz with the specific reference clock used in the PASemi
PCI controllers. Make this configurable to prepare for the
platform driver.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
---
drivers/i2c/busses/i2c-pasemi-core.c | 8 +++-----
drivers/i2c/busses/i2c-pasemi-core.h | 1 +
drivers/i2c/busses/i2c-pasemi-pci.c | 4 ++++
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pasemi-core.c b/drivers/i2c/busses/i2c-pasemi-core.c
index 7c6715f5dbb8..a39e3258b162 100644
--- a/drivers/i2c/busses/i2c-pasemi-core.c
+++ b/drivers/i2c/busses/i2c-pasemi-core.c
@@ -39,9 +39,6 @@
#define CTL_MTR 0x00000200
#define CTL_CLK_M 0x000000ff
-#define CLK_100K_DIV 84
-#define CLK_400K_DIV 21
-
static inline void reg_write(struct pasemi_smbus *smbus, int reg, int val)
{
dev_dbg(smbus->dev, "smbus write reg %lx val %08x\n",
@@ -63,8 +60,9 @@ static inline int reg_read(struct pasemi_smbus *smbus, int reg)
static void pasemi_reset(struct pasemi_smbus *smbus)
{
- reg_write(smbus, REG_CTL, (CTL_MTR | CTL_MRR |
- (CLK_100K_DIV & CTL_CLK_M)));
+ u32 val = (CTL_MTR | CTL_MRR | (smbus->clk_div & CTL_CLK_M));
+
+ reg_write(smbus, REG_CTL, val);
}
static void pasemi_smb_clear(struct pasemi_smbus *smbus)
diff --git a/drivers/i2c/busses/i2c-pasemi-core.h b/drivers/i2c/busses/i2c-pasemi-core.h
index 7acc33de6ce1..30a7990825ef 100644
--- a/drivers/i2c/busses/i2c-pasemi-core.h
+++ b/drivers/i2c/busses/i2c-pasemi-core.h
@@ -14,6 +14,7 @@ struct pasemi_smbus {
void __iomem *ioaddr;
unsigned long base;
int size;
+ unsigned int clk_div;
};
int pasemi_i2c_common_probe(struct pasemi_smbus *smbus);
diff --git a/drivers/i2c/busses/i2c-pasemi-pci.c b/drivers/i2c/busses/i2c-pasemi-pci.c
index 9a19df31866b..7405e0b48514 100644
--- a/drivers/i2c/busses/i2c-pasemi-pci.c
+++ b/drivers/i2c/busses/i2c-pasemi-pci.c
@@ -17,6 +17,9 @@
#include "i2c-pasemi-core.h"
+#define CLK_100K_DIV 84
+#define CLK_400K_DIV 21
+
static struct pci_driver pasemi_smb_pci_driver;
static int pasemi_smb_pci_probe(struct pci_dev *dev,
@@ -35,6 +38,7 @@ static int pasemi_smb_pci_probe(struct pci_dev *dev,
smbus->dev = &dev->dev;
smbus->base = pci_resource_start(dev, 0);
smbus->size = pci_resource_len(dev, 0);
+ smbus->clk_div = CLK_100K_DIV;
if (!request_region(smbus->base, smbus->size,
pasemi_smb_pci_driver.name)) {
--
2.25.1
^ permalink raw reply related
* [PATCH 01/10] dt-bindings: i2c: Add Apple I2C controller bindings
From: Sven Peter @ 2021-09-26 9:58 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Olof Johansson, Rob Herring
Cc: devicetree, Arnd Bergmann, Sven Peter, Hector Martin,
linux-kernel, linux-i2c, linux-arm-kernel, Mohamed Mediouni,
Stan Skowronek, linuxppc-dev, Alyssa Rosenzweig, Mark Kettenis
In-Reply-To: <20210926095847.38261-1-sven@svenpeter.dev>
The Apple I2C controller is based on the PASemi I2C controller.
It is present on Apple SoCs such as the M1.
Signed-off-by: Sven Peter <sven@svenpeter.dev>
---
.../devicetree/bindings/i2c/apple,i2c.yaml | 61 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/apple,i2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml
new file mode 100644
index 000000000000..22fc8483256f
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/i2c/apple,i2c.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Apple/PASemi I2C controller
+
+maintainers:
+ - Sven Peter <sven@svenpeter.dev>
+
+description: |
+ Apple SoCs such as the M1 come with a I2C controller based on the one found
+ in machines with P. A. Semi's PWRficient processors.
+ The bus is used to communicate with e.g. USB PD chips or the speaker
+ amp.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ enum:
+ - apple,t8103-i2c
+ - apple,i2c
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: I2C bus reference clock
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ description: |
+ Desired I2C bus clock frequency in Hz. If not specified, 100 kHz will be
+ used. This frequency is generated by dividing the reference clock.
+ Allowed values are between ref_clk/(16*4) and ref_clk/(16*255).
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@35010000 {
+ compatible = "apple,t8103-i2c";
+ reg = <0x35010000 0x4000>;
+ interrupt-parent = <&aic>;
+ interrupts = <0 627 4>;
+ clocks = <&ref_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 329d3a0a9fdb..380a680db92f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1734,6 +1734,7 @@ B: https://github.com/AsahiLinux/linux/issues
C: irc://irc.oftc.net/asahi-dev
T: git https://github.com/AsahiLinux/linux.git
F: Documentation/devicetree/bindings/arm/apple.yaml
+F: Documentation/devicetree/bindings/i2c/apple,i2c.yaml
F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
F: Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml
F: arch/arm64/boot/dts/apple/
--
2.25.1
^ permalink raw reply related
* Add Apple M1 support to PASemi i2c driver
From: Christian Zigotzky @ 2021-09-26 14:55 UTC (permalink / raw)
To: sven
Cc: Darren Stevens, arnd, marcan, Linux Kernel Mailing List,
linux-i2c, Paul Mackerras, alyssa, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, mark.kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, stan
Hi Sven,
Thanks a lot for your nice explanation of the history of the PASemi i2c
driver.
We are using Nemo boards with 64-bit dual-core PWRficient PA6T-1682M
CPUs (A-EON AmigaOne X1000). [1]
The RC2 of kernel 5.15 works without any problems on our Nemo boards. [2]
Could you please post all your patches merged in one patch? It's easier
for me to apply one patch.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=54056#p54056
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Christian Zigotzky @ 2021-09-26 20:27 UTC (permalink / raw)
To: sven
Cc: Darren Stevens, arnd, marcan, Linux Kernel Mailing List,
linux-i2c, Paul Mackerras, alyssa, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, mark.kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, stan
In-Reply-To: <6487d099-e0d6-4ea3-d312-6adbd94589f4@xenosoft.de>
Hi Sven,
I can't apply your patch 5 (i2c: pasemi: Split pci driver to its own
file). [1]
Error message:
patching file b/drivers/i2c/busses/i2c-pasemi-core.c (renamed from
a/drivers/i2c/busses/i2c-pasemi.c)
Hunk #3 FAILED at 344.
1 out of 3 hunks FAILED -- saving rejects to file
b/drivers/i2c/busses/i2c-pasemi-core.c.rej
patching file b/drivers/i2c/busses/i2c-pasemi-core.h
patching file b/drivers/i2c/busses/i2c-pasemi-pci.c
Please post one patch with all your modifications.
Thanks,
Christian
[1]
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234636.html
On 26 September 2021 at 04:55 pm, Christian Zigotzky wrote:
> Hi Sven,
>
> Thanks a lot for your nice explanation of the history of the PASemi
> i2c driver.
>
> We are using Nemo boards with 64-bit dual-core PWRficient PA6T-1682M
> CPUs (A-EON AmigaOne X1000). [1]
>
> The RC2 of kernel 5.15 works without any problems on our Nemo boards. [2]
>
> Could you please post all your patches merged in one patch? It's
> easier for me to apply one patch.
>
> Thanks,
> Christian
>
> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
> [2] https://forum.hyperion-entertainment.com/viewtopic.php?p=54056#p54056
^ permalink raw reply
* Re: [PATCH] mm: Remove HARDENED_USERCOPY_FALLBACK
From: David Rientjes @ 2021-09-26 20:49 UTC (permalink / raw)
To: Stephen Kitt
Cc: Andrew Morton, Kees Cook, James Morris, linux-kernel,
Pekka Enberg, linux-mm, linux-security-module, linux-hardening,
Christoph Lameter, linuxppc-dev, Joonsoo Kim, Vlastimil Babka,
Serge E . Hallyn
In-Reply-To: <20210921061149.1091163-1-steve@sk2.org>
On Tue, 21 Sep 2021, Stephen Kitt wrote:
> This has served its purpose and is no longer used. All usercopy
> violations appear to have been handled by now, any remaining
> instances (or new bugs) will cause copies to be rejected.
>
> This isn't a direct revert of commit 2d891fbc3bb6 ("usercopy: Allow
> strict enforcement of whitelists"); since usercopy_fallback is
> effectively 0, the fallback handling is removed too.
>
> This also removes the usercopy_fallback module parameter on
> slab_common.
>
> Link: https://github.com/KSPP/linux/issues/153
> Signed-off-by: Stephen Kitt <steve@sk2.org>
> Suggested-by: Kees Cook <keescook@chromium.org>
Acked-by: David Rientjes <rientjes@google.com>
^ permalink raw reply
* [PATCH] powerpc/eeh:Fix some mistakes in comments
From: Kai Song @ 2021-09-27 2:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Kai Song, linux-kernel, oohall, paulus
Get rid of warning:
arch/powerpc/kernel/eeh.c:774: warning: expecting prototype for eeh_set_pe_freset(). Prototype was for eeh_set_dev_freset() instead
Signed-off-by: Kai Song <songkai01@inspur.com>
---
arch/powerpc/kernel/eeh.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index e9b597ed423c..4cd4acb049ec 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -761,8 +761,8 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state stat
}
/**
- * eeh_set_pe_freset - Check the required reset for the indicated device
- * @data: EEH device
+ * eeh_set_dev_freset - Check the required reset for the indicated device
+ * @edev: EEH device
* @flag: return value
*
* Each device might have its preferred reset type: fundamental or
--
2.27.0
^ permalink raw reply related
* Re: Add Apple M1 support to PASemi i2c driver
From: Sven Peter @ 2021-09-27 5:39 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Darren Stevens, Arnd Bergmann, Hector Martin,
Linux Kernel Mailing List, linux-i2c, Paul Mackerras,
Alyssa Rosenzweig, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, Mark Kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <3dcc6c36-a0dd-0cad-428d-a6ed0f73e687@xenosoft.de>
Hi Christian,
Thanks already for volunteering to test this!
On Sun, Sep 26, 2021, at 22:27, Christian Zigotzky wrote:
> Hi Sven,
>
> I can't apply your patch 5 (i2c: pasemi: Split pci driver to its own
> file). [1]
That's strange because it should apply cleanly. I'll double check
after to work today to see if I messed up while sending this.
>
> Error message:
>
> patching file b/drivers/i2c/busses/i2c-pasemi-core.c (renamed from
> a/drivers/i2c/busses/i2c-pasemi.c)
> Hunk #3 FAILED at 344.
> 1 out of 3 hunks FAILED -- saving rejects to file
> b/drivers/i2c/busses/i2c-pasemi-core.c.rej
> patching file b/drivers/i2c/busses/i2c-pasemi-core.h
> patching file b/drivers/i2c/busses/i2c-pasemi-pci.c
>
> Please post one patch with all your modifications.
>
Sure, will do that later as well!
Best,
Sven
^ permalink raw reply
* Re: ppc32 doesn't boot when linkaddr=0x00900000
From: Christophe Leroy @ 2021-09-27 6:53 UTC (permalink / raw)
To: cp, linuxppc-dev; +Cc: paulus, torvalds
In-Reply-To: <CA+QBN9AFNSf3+U4iMhwZx7c69MLk-BtSbVODBEA97ObYWRczbQ@mail.gmail.com>
Hi,
Le 25/09/2021 à 11:49, cp a écrit :
> hi
> I am new to this list. Hope this is the right place to ask.
>
> I am working with a PPC405GP board, and as far as I understand, the
> support for ppc40x platforms like Acadia and Walnut were dropped with
> kernel 5.8.0, so this seems like a pretty straightforward question,
> but extensive experiments from kernel 4.11 to kernel 5.7.19 haven't
> shown a really clear, up-to-date answer.
>
> In k4.11 .. k5.7.19, when the kernel size is bigger than 8 MB, the
> final kernel doesn't boot but rather arch/powerpc/boot/main.c dies
> before the first message from the kernel shows up.
>
> Why?
>
...
>
> The following is the same kernel, compiled with the same .config, but
> with two link_addr values
>
> A) with link_addr=0x0080.0000
...
> Finalizing device tree... flat tree at 0xf23b80
...
> B) with link_addr=0x0080.0000
...
> Finalizing device tree... flat tree at 0x1023b80
...
> Any ideas?
> I am lost ...
>
As you can see above, when it works you have "flat tree at 0xf23b80",
when it fails you have "flat tree at 0x1023b80".
The reason for the failure is likely that ppc 40x only maps 16 Mbytes at
startup, so when your device tree is outside that map if fails.
See
https://elixir.bootlin.com/linux/v5.15-rc2/source/arch/powerpc/kernel/head_40x.S#L656
Called from
https://elixir.bootlin.com/linux/v5.15-rc2/source/arch/powerpc/kernel/head_40x.S#L56
As you can see it maps one 16Mbytes page.
Allthough I'm not an expert on 40x I think it should be easy to map a
second 16Mbytes page to get 32Mbytes mapped. I will send a patch later
today for you to test.
Christophe
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Wolfram Sang @ 2021-09-27 7:07 UTC (permalink / raw)
To: Sven Peter
Cc: Hector Martin, Arnd Bergmann, Christian Zigotzky,
Linux Kernel Mailing List, linux-i2c, Darren Stevens,
Paul Mackerras, Alyssa Rosenzweig, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, Mark Kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <d0a646c7-426b-4b40-b3fc-9776c6a1025d@www.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 145 bytes --]
> Sure, will do that later as well!
But please do it privately. For upstreaming, the patch series you sent
is way better than a single patch.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 02/10] i2c: pasemi: Use io{read,write}32
From: Arnd Bergmann @ 2021-09-27 7:39 UTC (permalink / raw)
To: Sven Peter
Cc: Arnd Bergmann, Hector Martin, Linux Kernel Mailing List,
Linux I2C, Paul Mackerras, Linux ARM, Olof Johansson,
Mohamed Mediouni, Mark Kettenis, linuxppc-dev, Alyssa Rosenzweig,
Stan Skowronek
In-Reply-To: <20210926095847.38261-3-sven@svenpeter.dev>
On Sun, Sep 26, 2021 at 12:00 PM Sven Peter <sven@svenpeter.dev> wrote:
>
> In preparation for splitting this driver up into a platform_driver
> and a pci_driver, replace outl/inl usage with ioport_map and
> ioread32/iowrite32.
>
> Signed-off-by: Sven Peter <sven@svenpeter.dev>
>
> + smbus->ioaddr = ioport_map(smbus->base, smbus->size);
> + if (!smbus->ioaddr) {
> + error = -EBUSY;
> + goto out_release_region;
> + }
While this works, I would suggest using the more regular pci_iomap()
or pcim_iomap() helper to turn the port number into an __iomem token.
Arnd
^ permalink raw reply
* Re: [PATCH 00/10] Add Apple M1 support to PASemi i2c driver
From: Arnd Bergmann @ 2021-09-27 7:42 UTC (permalink / raw)
To: Sven Peter
Cc: Arnd Bergmann, Hector Martin, Linux Kernel Mailing List,
Linux I2C, Paul Mackerras, Linux ARM, Olof Johansson,
Mohamed Mediouni, Mark Kettenis, linuxppc-dev, Alyssa Rosenzweig,
Stan Skowronek
In-Reply-To: <20210926095847.38261-1-sven@svenpeter.dev>
On Sun, Sep 26, 2021 at 12:00 PM Sven Peter <sven@svenpeter.dev> wrote:
>
> This series adds support for the I2C controller found on Apple Silicon Macs
> which has quite a bit of history:
>
> Apple bought P.A. Semi in 2008 and it looks like a part of its legacy continues
> to live on in the M1. This controller has actually been used since at least the
> iPhone 4S and hasn't changed much since then.
> Essentially, there are only a few differences that matter:
>
> - The controller no longer is a PCI device
> - Starting at some iPhone an additional bit in one register
> must be set in order to start transmissions.
> - The reference clock and hence the clock dividers are different
>
> In order to add support for a platform device I first replaced PCI-specific
> bits and split out the PCI driver to its own file. Then I added support
> to make the clock divider configurable and converted the driver to use
> managed device resources to make it a bit simpler.
>
> The Apple and PASemi driver will never be compiled in the same kernel
> since the Apple one will run on arm64 while the original PASemi driver
> will only be useful on powerpc.
> I've thus followed the octeon (mips)/thunderx(arm64) approach to do the
> split: I created a -core.c file which contains the shared logic and just
> compile that one for both the PASemi and the new Apple driver.
This looks all very good to me, I had one very minor comment.
Whole series
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Michael Ellerman @ 2021-09-27 7:58 UTC (permalink / raw)
To: Wolfram Sang, Sven Peter
Cc: Darren Stevens, Arnd Bergmann, Hector Martin,
Linux Kernel Mailing List, linux-i2c, Paul Mackerras,
Alyssa Rosenzweig, R.T.Dickinson, Christian Zigotzky,
Olof Johansson, mohamed.mediouni, Matthew Leaman, Mark Kettenis,
linuxppc-dev, R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <YVFtrpxfUbzv4XxT@shikoro>
Wolfram Sang <wsa@kernel.org> writes:
>> Sure, will do that later as well!
>
> But please do it privately. For upstreaming, the patch series you sent
> is way better than a single patch.
Christian, the whole series is downloadable as a single mbox here:
https://patchwork.ozlabs.org/series/264134/mbox/
Save that to a file and apply with `git am`.
eg:
$ wget -O mbox https://patchwork.ozlabs.org/series/264134/mbox/
$ git am mbox
It applies cleanly on v5.15-rc3.
cheers
^ permalink raw reply
* [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
From: Christophe Leroy @ 2021-09-27 10:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: cp, linuxppc-dev, linux-kernel
As reported by Carlo, 16Mbytes is not enough with modern kernels
that tend to be a bit big, so map another 16M page at boot.
Cc: cp <carlojpisani@gmail.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/head_40x.S | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 7d72ee5ab387..5fce4680d2d3 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -650,7 +650,7 @@ start_here:
b . /* prevent prefetch past rfi */
/* Set up the initial MMU state so we can do the first level of
- * kernel initialization. This maps the first 16 MBytes of memory 1:1
+ * kernel initialization. This maps the first 32 MBytes of memory 1:1
* virtual to physical and more importantly sets the cache mode.
*/
initial_mmu:
@@ -687,6 +687,12 @@ initial_mmu:
tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
+ li r0,62 /* TLB slot 62 */
+ addis r4,r4,SZ_16M
+ addis r3,r3,SZ_16M
+ tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
+ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
+
isync
/* Establish the exception vector base
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] Revert "ibmvnic: check failover_pending in login response"
From: patchwork-bot+netdevbpf @ 2021-09-27 12:30 UTC (permalink / raw)
To: Desnes A. Nunes do Rosario; +Cc: drt, netdev, tlfalcon, sukadev, linuxppc-dev
In-Reply-To: <20210925151418.1614874-1-desnesn@linux.ibm.com>
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Sat, 25 Sep 2021 12:14:18 -0300 you wrote:
> This reverts commit d437f5aa23aa2b7bd07cd44b839d7546cc17166f.
>
> Code has been duplicated through commit <273c29e944bd> "ibmvnic: check
> failover_pending in login response"
>
> Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.ibm.com>
>
> [...]
Here is the summary with links:
- Revert "ibmvnic: check failover_pending in login response"
https://git.kernel.org/netdev/net/c/2974b8a691a9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] ibmveth: Use dma_alloc_coherent() instead of kmalloc/dma_map_single()
From: patchwork-bot+netdevbpf @ 2021-09-27 12:30 UTC (permalink / raw)
To: Cai Huoqing
Cc: cforno12, linux-kernel, netdev, paulus, kuba, linuxppc-dev, davem
In-Reply-To: <20210926065214.495-1-caihuoqing@baidu.com>
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sun, 26 Sep 2021 14:52:14 +0800 you wrote:
> Replacing kmalloc/kfree/dma_map_single/dma_unmap_single()
> with dma_alloc_coherent/dma_free_coherent() helps to reduce
> code size, and simplify the code, and coherent DMA will not
> clear the cache every time.
>
> Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
>
> [...]
Here is the summary with links:
- [v2] ibmveth: Use dma_alloc_coherent() instead of kmalloc/dma_map_single()
https://git.kernel.org/netdev/net-next/c/4247ef026937
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 1/3] mm: Make generic arch_is_kernel_initmem_freed() do what it says
From: Michael Ellerman @ 2021-09-27 13:11 UTC (permalink / raw)
To: Christophe Leroy, Andrew Morton, arnd
Cc: linux-arch, linux-s390, linux-kernel, linux-mm, Gerald Schaefer,
linuxppc-dev
In-Reply-To: <0b55650058a5bf64f7d74781871a1ada2298c8b4.1632491308.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Commit 7a5da02de8d6 ("locking/lockdep: check for freed initmem in
> static_obj()") added arch_is_kernel_initmem_freed() which is supposed
> to report whether an object is part of already freed init memory.
>
> For the time being, the generic version of arch_is_kernel_initmem_freed()
> always reports 'false', allthough free_initmem() is generically called
> on all architectures.
>
> Therefore, change the generic version of arch_is_kernel_initmem_freed()
> to check whether free_initmem() has been called. If so, then check
> if a given address falls into init memory.
>
> In order to use function init_section_contains(), the fonction is
> moved at the end of asm-generic/section.h
>
> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> include/asm-generic/sections.h | 31 +++++++++++++++++--------------
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index d16302d3eb59..d1e5bb2c6b72 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -172,4 +158,21 @@ static inline bool is_kernel_rodata(unsigned long addr)
> addr < (unsigned long)__end_rodata;
> }
>
> +/*
> + * Check if an address is part of freed initmem. This is needed on architectures
> + * with virt == phys kernel mapping, for code that wants to check if an address
> + * is part of a static object within [_stext, _end]. After initmem is freed,
> + * memory can be allocated from it, and such allocations would then have
> + * addresses within the range [_stext, _end].
> + */
> +#ifndef arch_is_kernel_initmem_freed
> +static inline int arch_is_kernel_initmem_freed(unsigned long addr)
> +{
> + if (system_state < SYSTEM_RUNNING)
> + return 0;
> +
> + return init_section_contains((void *)addr, 1);
> +}
> +#endif
This will return an incorrect result for a short period during boot
won't it?
See init/main.c:
static int __ref kernel_init(void *unused)
{
...
free_initmem(); <- memory is freed here
mark_readonly();
/*
* Kernel mappings are now finalized - update the userspace page-table
* to finalize PTI.
*/
pti_finalize();
system_state = SYSTEM_RUNNING;
After free_initmem() we have address ranges that are now freed initmem,
but arch_is_kernel_initmem_freed() continues to return 0 (false) for all
addresses, until we update system_state.
Possibly that doesn't matter for any of the current callers, but it
seems pretty dicey to me.
cheers
^ permalink raw reply
* Re: [PATCH 1/3] mm: Make generic arch_is_kernel_initmem_freed() do what it says
From: Christophe Leroy @ 2021-09-27 13:51 UTC (permalink / raw)
To: Michael Ellerman, Andrew Morton, arnd
Cc: linux-arch, linux-s390, linux-kernel, linux-mm, Gerald Schaefer,
linuxppc-dev
In-Reply-To: <87h7e6kvs3.fsf@mpe.ellerman.id.au>
Le 27/09/2021 à 15:11, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Commit 7a5da02de8d6 ("locking/lockdep: check for freed initmem in
>> static_obj()") added arch_is_kernel_initmem_freed() which is supposed
>> to report whether an object is part of already freed init memory.
>>
>> For the time being, the generic version of arch_is_kernel_initmem_freed()
>> always reports 'false', allthough free_initmem() is generically called
>> on all architectures.
>>
>> Therefore, change the generic version of arch_is_kernel_initmem_freed()
>> to check whether free_initmem() has been called. If so, then check
>> if a given address falls into init memory.
>>
>> In order to use function init_section_contains(), the fonction is
>> moved at the end of asm-generic/section.h
>>
>> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> include/asm-generic/sections.h | 31 +++++++++++++++++--------------
>> 1 file changed, 17 insertions(+), 14 deletions(-)
>>
>> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
>> index d16302d3eb59..d1e5bb2c6b72 100644
>> --- a/include/asm-generic/sections.h
>> +++ b/include/asm-generic/sections.h
>> @@ -172,4 +158,21 @@ static inline bool is_kernel_rodata(unsigned long addr)
>> addr < (unsigned long)__end_rodata;
>> }
>>
>> +/*
>> + * Check if an address is part of freed initmem. This is needed on architectures
>> + * with virt == phys kernel mapping, for code that wants to check if an address
>> + * is part of a static object within [_stext, _end]. After initmem is freed,
>> + * memory can be allocated from it, and such allocations would then have
>> + * addresses within the range [_stext, _end].
>> + */
>> +#ifndef arch_is_kernel_initmem_freed
>> +static inline int arch_is_kernel_initmem_freed(unsigned long addr)
>> +{
>> + if (system_state < SYSTEM_RUNNING)
>> + return 0;
>> +
>> + return init_section_contains((void *)addr, 1);
>> +}
>> +#endif
>
> This will return an incorrect result for a short period during boot
> won't it?
>
> See init/main.c:
>
> static int __ref kernel_init(void *unused)
> {
> ...
> free_initmem(); <- memory is freed here
> mark_readonly();
>
> /*
> * Kernel mappings are now finalized - update the userspace page-table
> * to finalize PTI.
> */
> pti_finalize();
>
> system_state = SYSTEM_RUNNING;
>
>
> After free_initmem() we have address ranges that are now freed initmem,
> but arch_is_kernel_initmem_freed() continues to return 0 (false) for all
> addresses, until we update system_state.
>
> Possibly that doesn't matter for any of the current callers, but it
> seems pretty dicey to me.
>
Yes I saw it but as function core_kernel_text() uses that criteria for
deciding whether a given init text address is valid or not, I thought it
was just ok.
Should we add an intermediate state called for exemple
SYSTEM_FREEING_INIT just before SYSTEM_RUNNING ?
Christophe
^ permalink raw reply
* Re: Add Apple M1 support to PASemi i2c driver
From: Christian Zigotzky @ 2021-09-27 14:46 UTC (permalink / raw)
To: Michael Ellerman, Wolfram Sang, Sven Peter
Cc: Darren Stevens, Arnd Bergmann, Hector Martin,
Linux Kernel Mailing List, linux-i2c, Paul Mackerras,
Alyssa Rosenzweig, R.T.Dickinson, Olof Johansson,
mohamed.mediouni, Matthew Leaman, Mark Kettenis, linuxppc-dev,
R.T.Dickinson, linux-arm-kernel, Stan Skowronek
In-Reply-To: <87mtnylaam.fsf@mpe.ellerman.id.au>
On 27 September 2021 at 09:58 am, Michael Ellerman wrote:
> Wolfram Sang <wsa@kernel.org> writes:
>>> Sure, will do that later as well!
>> But please do it privately. For upstreaming, the patch series you sent
>> is way better than a single patch.
> Christian, the whole series is downloadable as a single mbox here:
>
> https://patchwork.ozlabs.org/series/264134/mbox/
>
> Save that to a file and apply with `git am`.
>
> eg:
>
> $ wget -O mbox https://patchwork.ozlabs.org/series/264134/mbox/
> $ git am mbox
>
> It applies cleanly on v5.15-rc3.
>
> cheers
I was able to patch it with the instructions above. Thanks! I will
compile and test the RC3 as soon as possible.
-- Christian
^ permalink raw reply
* [PATCH v2] powerpc/40x: Map 32Mbytes of memory at startup
From: Christophe Leroy @ 2021-09-27 15:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: cp, linuxppc-dev, linux-kernel
As reported by Carlo, 16Mbytes is not enough with modern kernels
that tend to be a bit big, so map another 16M page at boot.
Cc: cp <carlojpisani@gmail.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: Add missing header and missing @h
---
arch/powerpc/kernel/head_40x.S | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 7d72ee5ab387..e783860bea83 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -27,6 +27,7 @@
#include <linux/init.h>
#include <linux/pgtable.h>
+#include <linux/sizes.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/mmu.h>
@@ -650,7 +651,7 @@ start_here:
b . /* prevent prefetch past rfi */
/* Set up the initial MMU state so we can do the first level of
- * kernel initialization. This maps the first 16 MBytes of memory 1:1
+ * kernel initialization. This maps the first 32 MBytes of memory 1:1
* virtual to physical and more importantly sets the cache mode.
*/
initial_mmu:
@@ -687,6 +688,12 @@ initial_mmu:
tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
+ li r0,62 /* TLB slot 62 */
+ addis r4,r4,SZ_16M@h
+ addis r3,r3,SZ_16M@h
+ tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
+ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
+
isync
/* Establish the exception vector base
--
2.31.1
^ permalink raw reply related
* Re: [RFC PATCH 4/8] powerpc: add CPU field to struct thread_info
From: Ard Biesheuvel @ 2021-09-27 15:12 UTC (permalink / raw)
To: Linux Kernel Mailing List, Michael Ellerman
Cc: Peter Zijlstra, Catalin Marinas, Paul Mackerras, linux-riscv,
Will Deacon, open list:S390, Arnd Bergmann, Russell King,
Christian Borntraeger, Ingo Molnar, Albert Ou, Kees Cook,
Vasily Gorbik, Heiko Carstens, Keith Packard, Borislav Petkov,
Andy Lutomirski, Paul Walmsley, Thomas Gleixner, Linux ARM,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Palmer Dabbelt,
Linus Torvalds
In-Reply-To: <20210914121036.3975026-5-ardb@kernel.org>
On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> The CPU field will be moved back into thread_info even when
> THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
> of struct thread_info.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Michael,
Do you have any objections or issues with this patch or the subsequent
ones cleaning up the task CPU kludge for ppc32? Christophe indicated
that he was happy with it.
Thanks,
Ard.
> ---
> arch/powerpc/include/asm/thread_info.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
> index b4ec6c7dd72e..5725029aaa29 100644
> --- a/arch/powerpc/include/asm/thread_info.h
> +++ b/arch/powerpc/include/asm/thread_info.h
> @@ -47,6 +47,9 @@
> struct thread_info {
> int preempt_count; /* 0 => preemptable,
> <0 => BUG */
> +#ifdef CONFIG_SMP
> + unsigned int cpu;
> +#endif
> unsigned long local_flags; /* private flags for thread */
> #ifdef CONFIG_LIVEPATCH
> unsigned long *livepatch_sp;
> --
> 2.30.2
>
^ permalink raw reply
* Re: [PATCH v2 6/9] PCI: Add pci_find_dvsec_capability to find designated VSEC
From: Bjorn Helgaas @ 2021-09-27 17:46 UTC (permalink / raw)
To: Ben Widawsky
Cc: Andrew Donnellan, linux-pci, linux-cxl, Frederic Barrat, iommu,
David E . Box, Jonathan Cameron, Bjorn Helgaas, Dan Williams,
Kan Liang, linuxppc-dev, David Woodhouse, Lu Baolu
In-Reply-To: <20210923172647.72738-7-ben.widawsky@intel.com>
s/pci_find_dvsec_capability/pci_find_dvsec_capability()/ in subject
and commit log.
On Thu, Sep 23, 2021 at 10:26:44AM -0700, Ben Widawsky wrote:
> Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
> Extended Capability with the specified DVSEC ID.
"specified Vendor ID and Capability ID".
> The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
> more vendor specific capabilities that aren't tied to the vendor ID of
> the PCI component.
>
> DVSEC is critical for both the Compute Express Link (CXL) driver as well
> as the driver for OpenCAPI coherent accelerator (OCXL).
Strictly speaking, not really relevant for the commit log.
> Cc: David E. Box <david.e.box@linux.intel.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linux-pci@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Andrew Donnellan <ajd@linux.ibm.com>
> Cc: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
If you want to merge this with the series,
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Or if you want me to merge this on a branch, let me know.
> ---
> drivers/pci/pci.c | 32 ++++++++++++++++++++++++++++++++
> include/linux/pci.h | 1 +
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ce2ab62b64cf..94ac86ff28b0 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -732,6 +732,38 @@ u16 pci_find_vsec_capability(struct pci_dev *dev, u16 vendor, int cap)
> }
> EXPORT_SYMBOL_GPL(pci_find_vsec_capability);
>
> +/**
> + * pci_find_dvsec_capability - Find DVSEC for vendor
> + * @dev: PCI device to query
> + * @vendor: Vendor ID to match for the DVSEC
> + * @dvsec: Designated Vendor-specific capability ID
> + *
> + * If DVSEC has Vendor ID @vendor and DVSEC ID @dvsec return the capability
> + * offset in config space; otherwise return 0.
> + */
> +u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec)
> +{
> + int pos;
> +
> + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DVSEC);
> + if (!pos)
> + return 0;
> +
> + while (pos) {
> + u16 v, id;
> +
> + pci_read_config_word(dev, pos + PCI_DVSEC_HEADER1, &v);
> + pci_read_config_word(dev, pos + PCI_DVSEC_HEADER2, &id);
> + if (vendor == v && dvsec == id)
> + return pos;
> +
> + pos = pci_find_next_ext_capability(dev, pos, PCI_EXT_CAP_ID_DVSEC);
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_find_dvsec_capability);
> +
> /**
> * pci_find_parent_resource - return resource region of parent bus of given
> * region
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index cd8aa6fce204..c93ccfa4571b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1130,6 +1130,7 @@ u16 pci_find_ext_capability(struct pci_dev *dev, int cap);
> u16 pci_find_next_ext_capability(struct pci_dev *dev, u16 pos, int cap);
> struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
> u16 pci_find_vsec_capability(struct pci_dev *dev, u16 vendor, int cap);
> +u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec);
>
> u64 pci_get_dsn(struct pci_dev *dev);
>
> --
> 2.33.0
>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: nintendo-aes: Document the Wii and Wii U AES support
From: Rob Herring @ 2021-09-27 18:01 UTC (permalink / raw)
To: Emmanuel Gil Peyrot
Cc: devicetree, Herbert Xu, linux-kernel, linux-crypto,
Paul Mackerras, Ash Logan, linuxppc-dev, David S. Miller,
Jonathan Neuschäfer
In-Reply-To: <20210921213930.10366-3-linkmauve@linkmauve.fr>
On Tue, Sep 21, 2021 at 11:39:28PM +0200, Emmanuel Gil Peyrot wrote:
> Both of these consoles use the exact same AES engine, which only
> supports CBC mode with 128-bit keys.
>
> Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> ---
> .../bindings/crypto/nintendo-aes.yaml | 34 +++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/nintendo-aes.yaml
>
> diff --git a/Documentation/devicetree/bindings/crypto/nintendo-aes.yaml b/Documentation/devicetree/bindings/crypto/nintendo-aes.yaml
> new file mode 100644
> index 000000000000..e62a2bfc571c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/nintendo-aes.yaml
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings. checkpatch.pl will tell you this.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/crypto/nintendo-aes.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nintendo Wii and Wii U AES engine
> +
> +maintainers:
> + - Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> +
> +description: |+
> + The AES engine in the Nintendo Wii and Wii U supports the following:
> + -- Advanced Encryption Standard (AES) in CBC mode, with 128-bit keys
> +
> +properties:
> + compatible:
> + items:
> + - const: nintendo,hollywood-aes
> + - const: nintendo,latte-aes
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + description: Not supported yet.
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +additionalProperties: false
> --
> 2.33.0
>
>
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
From: cp @ 2021-09-27 19:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: torvalds, paulus
In-Reply-To: <CA+QBN9AFNSf3+U4iMhwZx7c69MLk-BtSbVODBEA97ObYWRczbQ@mail.gmail.com>
hi,
this is my first patch-test report.
Today I have successfully tested Christophe Leroy's patch.
I had to manually edit lines, but it worked with a kernel sized 9.1MByte :D
used toolchain:
- powerpc-unknown-linux-gnu-binutiles-v2.34
- powerpc-unknown-linux-gnu-gcc-v9.3.0
host:
- macmini-intel, Gentoo cross-compiler
target:
- AMCC PPC405GP
wrapper:
- cuboot
Applied to kernel-v5.2.1-vanilla
Attached I report here is the difference between the original file and mine.
Thanks guys!
Carlo
----------------
Map 32Mbytes rather than 16MB of memory at startup
--- arch/powerpc/kernel/head_40x.S.original 2021-09-27
16:32:04.536000000 -0000
+++ arch/powerpc/kernel/head_40x.S 2021-09-27 16:32:04.532000000 -0000
@@ -38,6 +38,8 @@
#include <asm/export.h>
#include <asm/asm-405.h>
+#include <linux/sizes.h> /* hack, include/linux/sizes.h defines "SZ_16M" */
+
#include "head_32.h"
/* As with the other PowerPC ports, it is expected that when code
@@ -839,18 +841,25 @@
mtspr SPRN_PID,r0
sync
- /* Configure and load one entry into TLB slots 63 */
+ /* Configure and load one entry into TLB slots 62/63 */ /* hacked */
clrrwi r4,r4,10 /* Mask off the real page number */
ori r4,r4,(TLB_WR | TLB_EX) /* Set the write and execute bits */
clrrwi r3,r3,10 /* Mask off the effective page number */
ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M))
- li r0,63 /* TLB slot 63 */
-
+//-- hack begin
-----------------------------------------------------------------------------
+// TLB 63 is used for first 16M page
+// TLB 62 is for the second 16M page
+// li r0,63 /* TLB slot 63 */ /* original */
+ li r0,62 /* TLB slot 62 */ /* hacked */
+// ------------------------------------------------------------------------------------------
tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
-
+// ------------------------------------------------------------------------------------------
+ addis r4,r4,SZ_16M@h /* added, hacked */
+ addis r3,r3,SZ_16M@h /* added, hacked */
+//-- hack end -----------------------------------------------------------------------------
isync
/* Establish the exception vector base
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox