Re: [musl] New powerpc vdso calling convention
On Sat, Apr 25, 2020 at 03:22:27PM +1000, Nicholas Piggin wrote: > As noted in the 'scv' thread, powerpc's vdso calling convention does not > match the C ELF ABI calling convention (or the proposed scv convention). > I think we could implement a new ABI by basically duplicating function > entry points with different names. > > The ELF v2 ABI convention would suit it well, because the caller already > requires the function address for ctr, so having it in r12 will > eliminate the need for address calculation, which suits the vdso data > page access. > > Is there a need for ELF v1 specific calls as well, or could those just be > deprecated and remain on existing functions or required to use the ELF > v2 calls using asm wrappers? musl doesn't use ELFv1, but my expectation would be for the kernel to provide an ELFv1 VDSO to an ELFv1 process. (I'm pretty sure the kernel has to be aware of this property of the process-image (executable file) since it affects how signals work.) > Is there a good reason for the system call fallback to go in the vdso > function rather than have the caller handle it? Originally it was deemed the vdso's responsibility to do fallback, but MIPS broke this contract so musl always makes a syscall itself if the vdso function returns -ENOSYS. I believe it honors other errors. We could change it to fallback on all errors if needed. I'm not sure what glibc does here. Rich
New powerpc vdso calling convention
As noted in the 'scv' thread, powerpc's vdso calling convention does not match the C ELF ABI calling convention (or the proposed scv convention). I think we could implement a new ABI by basically duplicating function entry points with different names. The ELF v2 ABI convention would suit it well, because the caller already requires the function address for ctr, so having it in r12 will eliminate the need for address calculation, which suits the vdso data page access. Is there a need for ELF v1 specific calls as well, or could those just be deprecated and remain on existing functions or required to use the ELF v2 calls using asm wrappers? Is there a good reason for the system call fallback to go in the vdso function rather than have the caller handle it? Thanks, Nick
Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
On Sat, Apr 25, 2020 at 01:40:24PM +1000, Nicholas Piggin wrote: > Excerpts from Rich Felker's message of April 24, 2020 3:42 am: > > On Thu, Apr 23, 2020 at 02:15:58PM -0300, Adhemerval Zanella wrote: > >> > >> > >> On 23/04/2020 13:43, Rich Felker wrote: > >> > On Thu, Apr 23, 2020 at 01:35:01PM -0300, Adhemerval Zanella wrote: > >> >> > >> >> > >> >> On 23/04/2020 13:18, Rich Felker wrote: > >> >>> On Thu, Apr 23, 2020 at 09:13:57AM -0300, Adhemerval Zanella wrote: > >> > >> > >> On 22/04/2020 23:36, Rich Felker wrote: > >> > On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote: > >> >> Yeah I had a bit of a play around with musl (which is very nice > >> >> code I > >> >> must say). The powerpc64 syscall asm is missing ctr clobber by the > >> >> way. > >> >> Fortunately adding it doesn't change code generation for me, but it > >> >> should be fixed. glibc had the same bug at one point I think > >> >> (probably > >> >> due to syscall ABI documentation not existing -- something now > >> >> lives in > >> >> linux/Documentation/powerpc/syscall64-abi.rst). > >> > > >> > Do you know anywhere I can read about the ctr issue, possibly the > >> > relevant glibc bug report? I'm not particularly familiar with ppc > >> > register file (at least I have to refamiliarize myself every time I > >> > work on this stuff) so it'd be nice to understand what's > >> > potentially-wrong now. > >> > >> My understanding is the ctr issue only happens for vDSO calls where it > >> fallback to a syscall in case an error (invalid argument, etc. and > >> assuming if vDSO does not fallback to a syscall it always succeed). > >> This makes the vDSO call on powerpc to have same same ABI constraint > >> as a syscall, where it clobbers CR0. > >> >>> > >> >>> I think you mean "vsyscall", the old thing glibc used where there are > >> >>> in-userspace implementations of some syscalls with call interfaces > >> >>> roughly equivalent to a syscall. musl has never used this. It only > >> >>> uses the actual exported functions from the vdso which have normal > >> >>> external function call ABI. > >> >> > >> >> I wasn't thinking in vsyscall in fact, which afaik it is a x86 thing. > >> >> The issue is indeed when calling the powerpc provided functions in > >> >> vDSO, which musl might want to do eventually. > >> > > >> > AIUI (at least this is true for all other archs) the functions have > >> > normal external function call ABI and calling them has nothing to do > >> > with syscall mechanisms. > >> > >> My point is powerpc specifically does not follow it, since it issues a > >> syscall in fallback and its semantic follow kernel syscalls (error > >> signalled in cr0, r3 being always a positive value): > > > > Oh, then I think we'll just ignore these unless the kernel can make > > ones with a reasonable ABI. It's not worth having ppc-specific code > > for this... It would be really nice if ones that actually behave like > > functions could be added though. > > Yeah this is an annoyance for me after making the scv ABI return -ve in > r3 for error and other things that more closely follow function calls, > we still have the vdso functions using the old style. > > Maybe we should add function call style vdso too. Please do. Rich
Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
Excerpts from Rich Felker's message of April 24, 2020 3:42 am: > On Thu, Apr 23, 2020 at 02:15:58PM -0300, Adhemerval Zanella wrote: >> >> >> On 23/04/2020 13:43, Rich Felker wrote: >> > On Thu, Apr 23, 2020 at 01:35:01PM -0300, Adhemerval Zanella wrote: >> >> >> >> >> >> On 23/04/2020 13:18, Rich Felker wrote: >> >>> On Thu, Apr 23, 2020 at 09:13:57AM -0300, Adhemerval Zanella wrote: >> >> >> On 22/04/2020 23:36, Rich Felker wrote: >> > On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote: >> >> Yeah I had a bit of a play around with musl (which is very nice code I >> >> must say). The powerpc64 syscall asm is missing ctr clobber by the >> >> way. >> >> Fortunately adding it doesn't change code generation for me, but it >> >> should be fixed. glibc had the same bug at one point I think >> >> (probably >> >> due to syscall ABI documentation not existing -- something now lives >> >> in >> >> linux/Documentation/powerpc/syscall64-abi.rst). >> > >> > Do you know anywhere I can read about the ctr issue, possibly the >> > relevant glibc bug report? I'm not particularly familiar with ppc >> > register file (at least I have to refamiliarize myself every time I >> > work on this stuff) so it'd be nice to understand what's >> > potentially-wrong now. >> >> My understanding is the ctr issue only happens for vDSO calls where it >> fallback to a syscall in case an error (invalid argument, etc. and >> assuming if vDSO does not fallback to a syscall it always succeed). >> This makes the vDSO call on powerpc to have same same ABI constraint >> as a syscall, where it clobbers CR0. >> >>> >> >>> I think you mean "vsyscall", the old thing glibc used where there are >> >>> in-userspace implementations of some syscalls with call interfaces >> >>> roughly equivalent to a syscall. musl has never used this. It only >> >>> uses the actual exported functions from the vdso which have normal >> >>> external function call ABI. >> >> >> >> I wasn't thinking in vsyscall in fact, which afaik it is a x86 thing. >> >> The issue is indeed when calling the powerpc provided functions in >> >> vDSO, which musl might want to do eventually. >> > >> > AIUI (at least this is true for all other archs) the functions have >> > normal external function call ABI and calling them has nothing to do >> > with syscall mechanisms. >> >> My point is powerpc specifically does not follow it, since it issues a >> syscall in fallback and its semantic follow kernel syscalls (error >> signalled in cr0, r3 being always a positive value): > > Oh, then I think we'll just ignore these unless the kernel can make > ones with a reasonable ABI. It's not worth having ppc-specific code > for this... It would be really nice if ones that actually behave like > functions could be added though. Yeah this is an annoyance for me after making the scv ABI return -ve in r3 for error and other things that more closely follow function calls, we still have the vdso functions using the old style. Maybe we should add function call style vdso too. Thanks, Nick
Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
Excerpts from Rich Felker's message of April 23, 2020 12:36 pm: > On Wed, Apr 22, 2020 at 04:18:36PM +1000, Nicholas Piggin wrote: >> Yeah I had a bit of a play around with musl (which is very nice code I >> must say). The powerpc64 syscall asm is missing ctr clobber by the way. >> Fortunately adding it doesn't change code generation for me, but it >> should be fixed. glibc had the same bug at one point I think (probably >> due to syscall ABI documentation not existing -- something now lives in >> linux/Documentation/powerpc/syscall64-abi.rst). > > Do you know anywhere I can read about the ctr issue, possibly the > relevant glibc bug report? I'm not particularly familiar with ppc > register file (at least I have to refamiliarize myself every time I > work on this stuff) so it'd be nice to understand what's > potentially-wrong now. Ah I was misremembering, glibc was (and still is) actually missing cr clobbers from its "vsyscall", probably because it copied syscall which only clobbers cr0, but vsyscall clobbers cr0-1,5-7 like a normal function call. musl is missing the ctr register clobber from syscalls. powerpc has gpr0-31 GPRs, cr0-7 condition regs, and lr and ctr branch registers (lr is generally used for function returns, ctr for other indirect branches). ctr is volatile (caller saved) across C function calls, and sc system calls on Linux. Thanks, Nick
Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY
On Fri, Apr 24, 2020 at 11:29:38PM +0100, Darren Stevens wrote:
> Since cbb961ca271e ("Use random MAC address when none is given")
> Varisys Cyrus P5020 boards have been listing 5 ethernet ports instead of
> the 2 the board has.This is because we were preventing the adding of the
> unused ports by not suppling them a MAC address, which this patch now
> supplies.
>
> Prevent them from appearing in the net devices list by checking for a
> 'status="disabled"' entry during probe and skipping the port if we find
> it.
Hi Darren
I'm surprised the core is probing a device which has status disabled.
Are you sure this is the correct explanation?
Thanks
Andrew
Re: [PATCH v2 1/2] PCI/AER: Allow Native AER Host Bridges to use AER
Hi Jon, I'm glad you raised this because I think the way we handle FIRMWARE_FIRST is really screwed up. On Mon, Apr 20, 2020 at 03:37:09PM -0600, Jon Derrick wrote: > Some platforms have a mix of ports whose capabilities can be negotiated > by _OSC, and some ports which are not described by ACPI and instead > managed by Native drivers. The existing Firmware-First HEST model can > incorrectly tag these Native, Non-ACPI ports as Firmware-First managed > ports by advertising the HEST Global Flag and matching the type and > class of the port (aer_hest_parse). > > If the port requests Native AER through the Host Bridge's capability > settings, the AER driver should honor those settings and allow the port > to bind. This patch changes the definition of Firmware-First to exclude > ports whose Host Bridges request Native AER. > > Signed-off-by: Jon Derrick > --- > drivers/pci/pcie/aer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c > index f4274d3..30fbd1f 100644 > --- a/drivers/pci/pcie/aer.c > +++ b/drivers/pci/pcie/aer.c > @@ -314,6 +314,9 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev) > if (pcie_ports_native) > return 0; > > + if (pci_find_host_bridge(dev->bus)->native_aer) > + return 0; I hope we don't have to complicate pcie_aer_get_firmware_first() by adding this "native_aer" check here. I'm not sure what we actually *should* do based on FIRMWARE_FIRST, but I don't think the current uses really make sense. I think Linux makes too many assumptions based on the FIRMWARE_FIRST bit. The ACPI spec really only says (ACPI v6.3, sec 18.3.2.4): If set, FIRMWARE_FIRST indicates to the OSPM that system firmware will handle errors from this source first. If FIRMWARE_FIRST is set in the flags field, the Enabled field [of the HEST AER structure] is ignored by the OSPM. I do not see anything there about who owns the AER Capability, but Linux assumes that if FIRMWARE_FIRST is set, firmware must own the AER Capability. I think that's reading too much into the spec. We already have _OSC, which *does* explicitly talk about who owns the AER Capability, and I think we should rely on that. If firmware doesn't want the OS to touch the AER Capability, it should decline to give ownership to the OS via _OSC. > if (!dev->__aer_firmware_first_valid) > aer_set_firmware_first(dev); > return dev->__aer_firmware_first; > -- > 1.8.3.1 >
Re: [PATCH] PCI: Use of_node_name_eq for node name comparisons
On Thu, Apr 16, 2020 at 04:51:14PM -0500, Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Bjorn Helgaas
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
Applied to pci/hotplug for v5.8, thanks!
> ---
> drivers/pci/hotplug/rpaphp_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/rpaphp_core.c
> b/drivers/pci/hotplug/rpaphp_core.c
> index 6504869efabc..9887c9de08c3 100644
> --- a/drivers/pci/hotplug/rpaphp_core.c
> +++ b/drivers/pci/hotplug/rpaphp_core.c
> @@ -435,7 +435,7 @@ static int rpaphp_drc_add_slot(struct device_node *dn)
> */
> int rpaphp_add_slot(struct device_node *dn)
> {
> - if (!dn->name || strcmp(dn->name, "pci"))
> + if (!of_node_name_eq(dn, "pci"))
> return 0;
>
> if (of_find_property(dn, "ibm,drc-info", NULL))
> --
> 2.20.1
>
Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY
On 4/24/2020 3:29 PM, Darren Stevens wrote:
> Since cbb961ca271e ("Use random MAC address when none is given")
> Varisys Cyrus P5020 boards have been listing 5 ethernet ports instead of
> the 2 the board has.This is because we were preventing the adding of the
> unused ports by not suppling them a MAC address, which this patch now
> supplies.
>
> Prevent them from appearing in the net devices list by checking for a
> 'status="disabled"' entry during probe and skipping the port if we find
> it.
>
> Signed-off-by: Darren Stevens
>
> ---
>
> drivers/net/ethernet/freescale/fman/mac.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/fman/mac.c
> b/drivers/net/ethernet/freescale/fman/mac.c
> index 43427c5..c9ed411 100644
> --- a/drivers/net/ethernet/freescale/fman/mac.c
> +++ b/drivers/net/ethernet/freescale/fman/mac.c
> @@ -606,6 +606,7 @@ static int mac_probe(struct platform_device *_of_dev)
> struct resource res;
> struct mac_priv_s *priv;
> const u8*mac_addr;
> + const char *prop;
> u32 val;
> u8 fman_id;
> phy_interface_t phy_if;
> @@ -628,6 +629,16 @@ static int mac_probe(struct platform_device *_of_dev)
> mac_dev->priv = priv;
> priv->dev = dev;
>
> + /* check for disabled devices and skip them, as now a missing
> + * MAC address will be replaced with a Random one rather than
> + * disabling the port
> + */
> + prop = of_get_property(mac_node, "status", NULL);
> + if (prop && !strncmp(prop, "disabled", 8) {
> + err = -ENODEV;
> + goto _return
> + }
There is a sorter version: of_device_is_available(mac_node) which will
do the same thing.
> +
> if (of_device_is_compatible(mac_node, "fsl,fman-dtsec")) {
> setup_dtsec(mac_dev);
> priv->internal_phy_node = of_parse_phandle(mac_node,
>
--
Florian
[RFC PATCH dpss_eth] Don't initialise ports with no PHY
Since cbb961ca271e ("Use random MAC address when none is given")
Varisys Cyrus P5020 boards have been listing 5 ethernet ports instead of
the 2 the board has.This is because we were preventing the adding of the
unused ports by not suppling them a MAC address, which this patch now
supplies.
Prevent them from appearing in the net devices list by checking for a
'status="disabled"' entry during probe and skipping the port if we find
it.
Signed-off-by: Darren Stevens
---
drivers/net/ethernet/freescale/fman/mac.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c
b/drivers/net/ethernet/freescale/fman/mac.c
index 43427c5..c9ed411 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -606,6 +606,7 @@ static int mac_probe(struct platform_device *_of_dev)
struct resource res;
struct mac_priv_s *priv;
const u8*mac_addr;
+ const char *prop;
u32 val;
u8 fman_id;
phy_interface_t phy_if;
@@ -628,6 +629,16 @@ static int mac_probe(struct platform_device *_of_dev)
mac_dev->priv = priv;
priv->dev = dev;
+ /* check for disabled devices and skip them, as now a missing
+* MAC address will be replaced with a Random one rather than
+* disabling the port
+*/
+ prop = of_get_property(mac_node, "status", NULL);
+ if (prop && !strncmp(prop, "disabled", 8) {
+ err = -ENODEV;
+ goto _return
+ }
+
if (of_device_is_compatible(mac_node, "fsl,fman-dtsec")) {
setup_dtsec(mac_dev);
priv->internal_phy_node = of_parse_phandle(mac_node,
Re: [PATCH 3/3] powerpc/kprobes: Check return value of patch_instruction()
Steven Rostedt wrote:
On Fri, 24 Apr 2020 23:56:25 +0530
"Naveen N. Rao" wrote:
> #define PATCH_INSN(addr, instr) \
> ({
>int rc = patch_instruction((unsigned int *)(addr), instr); \
>if (rc) \
>pr_err("%s:%d Error patching instruction at 0x%pK (%pS): %d\n", \
>__func__, __LINE__, \
>(void *)(addr), (void *)(addr), rc); \
>rc; \
> })
>
>
> Then you can just do:
>
> ret = PATCH_INSN(...);
>if (ret)
>return ret;
>
> in the code.
That's really nice. However, in this case, I guess I can simply use an
inline function? The primary reason I used the macro was for including a
'return' statement in it.
I thought the primary reason was the __func__, __LINE__ which wont work as
expected as an inline.
Ugh, you're right indeed. I clearly didn't think it through. :facepalm:
I'll use this variant.
Regards,
Naveen
Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()
On Fri Apr 24, 2020 at 9:15 AM, Steven Rostedt wrote: > On Thu, 23 Apr 2020 18:21:14 +0200 > Christophe Leroy wrote: > > > > Le 23/04/2020 à 17:09, Naveen N. Rao a écrit : > > > With STRICT_KERNEL_RWX, we are currently ignoring return value from > > > __patch_instruction() in do_patch_instruction(), resulting in the error > > > not being propagated back. Fix the same. > > > > Good patch. > > > > Be aware that there is ongoing work which tend to wanting to replace > > error reporting by BUG_ON() . See > > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003 > > > Thanks for the reference. I still believe that WARN_ON() should be used > in > 99% of the cases, including here. And only do a BUG_ON() when you know > there's no recovering from it. > > > In fact, there's still BUG_ON()s in my code that I need to convert to > WARN_ON() (it was written when BUG_ON() was still acceptable ;-) > Figured I'd chime in since I am working on that other series :) The BUG_ON()s are _only_ in the init code to set things up to allow a temporary mapping for patching a STRICT_RWX kernel later. There's no ongoing work to "replace error reporting by BUG_ON()". If that initial setup fails we cannot patch under STRICT_KERNEL_RWX at all which imo warrants a BUG_ON(). I am still working on v2 of my RFC which does return any __patch_instruction() error back to the caller of patch_instruction() similar to this patch. > > -- Steve > > > >
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #25 from Erhard F. (erhar...@mailbox.org) --- (In reply to Michael Ellerman from comment #23) > The memory leak is a separate issue, see bug #206695. > > Can anyone verify that bcf3588d8ed fixes the original issue? Yes, thanks to Wolframs patch the WINDFARM_PM112 is automatically loaded again when built as a module. So my original issue is fixed with that commit. -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 3/3] powerpc/kprobes: Check return value of patch_instruction()
On Fri, 24 Apr 2020 23:56:25 +0530
"Naveen N. Rao" wrote:
> > #define PATCH_INSN(addr, instr) \
> > ({
> > int rc = patch_instruction((unsigned int *)(addr), instr); \
> > if (rc) \
> > pr_err("%s:%d Error patching instruction at 0x%pK (%pS): %d\n",
> > \
> > __func__, __LINE__, \
> > (void *)(addr), (void *)(addr), rc); \
> > rc; \
> > })
> >
> >
> > Then you can just do:
> >
> > ret = PATCH_INSN(...);
> > if (ret)
> > return ret;
> >
> > in the code.
>
> That's really nice. However, in this case, I guess I can simply use an
> inline function? The primary reason I used the macro was for including a
> 'return' statement in it.
I thought the primary reason was the __func__, __LINE__ which wont work as
expected as an inline.
-- Steve
Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()
On Fri, 24 Apr 2020 23:37:06 +0530 "Naveen N. Rao" wrote: > >> Le 23/04/2020 à 17:09, Naveen N. Rao a écrit : > >> > With STRICT_KERNEL_RWX, we are currently ignoring return value from > >> > __patch_instruction() in do_patch_instruction(), resulting in the error > >> > not being propagated back. Fix the same. > >> > >> Good patch. > >> > >> Be aware that there is ongoing work which tend to wanting to replace > >> error reporting by BUG_ON() . See > >> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003 > > > > Thanks for the reference. I still believe that WARN_ON() should be used in > > 99% of the cases, including here. And only do a BUG_ON() when you know > > there's no recovering from it. > > I'm not sure if you meant that we should have a WARN_ON() in > patch_instruction(), or if it was about the users of > patch_instruction(). As you're well aware, ftrace likes to do its own > WARN_ON() if any of its operations fail through ftrace_bug(). That was > the reason I didn't add anything here. I'm fine with that too, and better reason not to call BUG_ON(), because I'm guessing if we crash, we never make it to the ftrace_bug() which reports information that can be used to debug what went wrong. -- Steve
Re: [PATCH 3/3] powerpc/kprobes: Check return value of patch_instruction()
Steven Rostedt wrote:
On Thu, 23 Apr 2020 17:41:52 +0200
Christophe Leroy wrote:
> diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
> index 024f7aad1952..046485bb0a52 100644
> --- a/arch/powerpc/kernel/optprobes.c
> +++ b/arch/powerpc/kernel/optprobes.c
> @@ -139,52 +139,67 @@ void arch_remove_optimized_kprobe(struct
optimized_kprobe *op)
>}
> }
>
> +#define PATCH_INSN(addr, instr) \
> +do {
\
> + int rc = patch_instruction((unsigned int *)(addr), instr); \
> + if (rc) {\
> + pr_err("%s:%d Error patching instruction at 0x%pK (%pS): %d\n", \
> + __func__, __LINE__, \
> + (void *)(addr), (void *)(addr), rc); \
> + return rc; \
> + }\
> +} while (0)
> +
I hate this kind of macro which hides the "return".
What about keeping the return action in the caller ?
Otherwise, what about implementing something based on the use of goto,
on the same model as unsafe_put_user() for instance ?
Thanks for the review.
I noticed this as a warning from checkpatch.pl, but this looked compact
and correct for use in the two following functions. You'll notice that I
added it just before the two functions this is used in.
I suppose 'goto err' is usable too, but the ftrace code (patch 2) will
end up with more changes. I'm also struggling to see how a 'goto' is
less offensive. I think Steve's suggestion below would be the better way
to go, to make things explicit.
#define PATCH_INSN(addr, instr) \
({
int rc = patch_instruction((unsigned int *)(addr), instr); \
if (rc) \
pr_err("%s:%d Error patching instruction at 0x%pK (%pS): %d\n",
\
__func__, __LINE__, \
(void *)(addr), (void *)(addr), rc); \
rc; \
})
Then you can just do:
ret = PATCH_INSN(...);
if (ret)
return ret;
in the code.
That's really nice. However, in this case, I guess I can simply use an
inline function? The primary reason I used the macro was for including a
'return' statement in it.
Thanks for the review!
- Naveen
Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()
Hi Steve, Steven Rostedt wrote: On Thu, 23 Apr 2020 18:21:14 +0200 Christophe Leroy wrote: Le 23/04/2020 à 17:09, Naveen N. Rao a écrit : > With STRICT_KERNEL_RWX, we are currently ignoring return value from > __patch_instruction() in do_patch_instruction(), resulting in the error > not being propagated back. Fix the same. Good patch. Be aware that there is ongoing work which tend to wanting to replace error reporting by BUG_ON() . See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003 Thanks for the reference. I still believe that WARN_ON() should be used in 99% of the cases, including here. And only do a BUG_ON() when you know there's no recovering from it. I'm not sure if you meant that we should have a WARN_ON() in patch_instruction(), or if it was about the users of patch_instruction(). As you're well aware, ftrace likes to do its own WARN_ON() if any of its operations fail through ftrace_bug(). That was the reason I didn't add anything here. - Naveen
Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()
Christophe Leroy wrote:
Le 23/04/2020 à 17:09, Naveen N. Rao a écrit :
With STRICT_KERNEL_RWX, we are currently ignoring return value from
__patch_instruction() in do_patch_instruction(), resulting in the error
not being propagated back. Fix the same.
Good patch.
Be aware that there is ongoing work which tend to wanting to replace
error reporting by BUG_ON() . See
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003
Hah, I see that you pointed out this exact issue in your review there!
I had noticed this when Russell's series for STRICT_MODULE_RWX started
causing kretprobe failures, due to one of the early boot-time patching
failing silently.
I'll defer to Michael on which patch he prefers to take, between this
one and the series you point out above.
Fixes: 37bc3e5fd764f ("powerpc/lib/code-patching: Use alternate map for
patch_instruction()")
Signed-off-by: Naveen N. Rao
---
arch/powerpc/lib/code-patching.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 3345f039a876..5c713a6c0bd8 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -138,7 +138,7 @@ static inline int unmap_patch_area(unsigned long addr)
static int do_patch_instruction(unsigned int *addr, unsigned int instr)
{
- int err;
+ int err, rc = 0;
unsigned int *patch_addr = NULL;
unsigned long flags;
unsigned long text_poke_addr;
@@ -163,7 +163,7 @@ static int do_patch_instruction(unsigned int *addr,
unsigned int instr)
patch_addr = (unsigned int *)(text_poke_addr) +
((kaddr & ~PAGE_MASK) / sizeof(unsigned int));
- __patch_instruction(addr, instr, patch_addr);
+ rc = __patch_instruction(addr, instr, patch_addr);
err = unmap_patch_area(text_poke_addr);
if (err)
@@ -172,7 +172,7 @@ static int do_patch_instruction(unsigned int *addr,
unsigned int instr)
out:
local_irq_restore(flags);
- return err;
+ return rc ? rc : err;
That's not really consistent. __patch_instruction() and
unmap_patch_area() return a valid minus errno, while in case of
map_patch_area() failure, err has value -1
Not sure I follow -- I'm not changing what would be returned in those
cases, just also capturing return value from __patch_instruction().
If anything, I've considered the different return codes to be a good
thing -- return code gives you a clear idea of what exactly failed.
- Naveen
Re: [PATCH v5 0/6] implement KASLR for powerpc/fsl_booke/64
Hi Jason, Apologies for the delay in testing. I'm seeing this problem when I try to boot on a t4240rdb: random: get_random_u64 called from .start_kernel+0x734/0x964 with crng_init=0 [8/973] clocksource: timebase: mask: 0x max_cycles: 0xa9210e89c, max_idle_ns: 440795203878 ns clocksource: timebase mult[15d17460] shift[24] registered Console: colour dummy device 80x25 pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) e6500 family performance monitor hardware support registered rcu: Hierarchical SRCU implementation. smp: Bringing up secondary CPUs ... Processor 2 is stuck. Processor 3 is stuck. Processor 4 is stuck. Processor 5 is stuck. Processor 6 is stuck. Processor 7 is stuck. Processor 8 is stuck. Processor 9 is stuck. Processor 10 is stuck. Processor 11 is stuck. Processor 12 is stuck. Processor 13 is stuck. Processor 14 is stuck. ... Processor 22 is stuck. Processor 23 is stuck. smp: Brought up 1 node, 2 CPUs Using standard scheduler topology devtmpfs: initialized clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns futex hash table entries: 8192 (order: 7, 524288 bytes, linear) NET: Registered protocol family 16 audit: initializing netlink subsys (disabled) audit: type=2000 audit(108.032:1): state=initialized audit_enabled=0 res=1 Machine: fsl,T4240RDB SoC family: QorIQ T4240 SoC ID: svr:0x82480020, Revision: 2.0 ... boot continues ... If I boot with nokaslr, all the CPUs come up with no issue. This is on top of powerpc/merge at 8299da600ad05b8aa0f15ec0f5f03bd40e37d6f0. If you'd like me to test any debug patches I can do that. I've attached my .config. Regards, Daniel .config Description: Binary data > This is a try to implement KASLR for Freescale BookE64 which is based on > my earlier implementation for Freescale BookE32: > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718=* > > The implementation for Freescale BookE64 is similar as BookE32. One > difference is that Freescale BookE64 set up a TLB mapping of 1G during > booting. Another difference is that ppc64 needs the kernel to be > 64K-aligned. So we can randomize the kernel in this 1G mapping and make > it 64K-aligned. This can save some code to creat another TLB map at > early boot. The disadvantage is that we only have about 1G/64K = 16384 > slots to put the kernel in. > > KERNELBASE > > 64K |--> kernel <--| >| | | > +--+--+--++--+--+--+--+--+--+--+--+--++--+--+ > | | | || | | | | | | | | || | | > +--+--+--++--+--+--+--+--+--+--+--+--++--+--+ > | |1G > |-> offset<-| > > kernstart_virt_addr > > I'm not sure if the slot numbers is enough or the design has any > defects. If you have some better ideas, I would be happy to hear that. > > Thank you all. > > v4->v5: > Fix "-Werror=maybe-uninitialized" compile error. > Fix typo "similar as" -> "similar to". > v3->v4: > Do not define __kaslr_offset as a fixed symbol. Reference __run_at_load and > __kaslr_offset by symbol instead of magic offsets. > Use IS_ENABLED(CONFIG_PPC32) instead of #ifdef CONFIG_PPC32. > Change kaslr-booke32 to kaslr-booke in index.rst > Switch some instructions to 64-bit. > v2->v3: > Fix build error when KASLR is disabled. > v1->v2: > Add __kaslr_offset for the secondary cpu boot up. > > Jason Yan (6): > powerpc/fsl_booke/kaslr: refactor kaslr_legal_offset() and > kaslr_early_init() > powerpc/fsl_booke/64: introduce reloc_kernel_entry() helper > powerpc/fsl_booke/64: implement KASLR for fsl_booke64 > powerpc/fsl_booke/64: do not clear the BSS for the second pass > powerpc/fsl_booke/64: clear the original kernel if randomized > powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst > and add 64bit part > > Documentation/powerpc/index.rst | 2 +- >
Re: [PATCH v3 2/3] powerpc/eeh: fix pseries_eeh_configure_bridge()
Sam Bobroff writes:
> If a device is hot unplgged during EEH recovery, it's possible for the
> RTAS call to ibm,configure-pe in pseries_eeh_configure() to return
> parameter error (-3), however negative return values are not checked
> for and this leads to an infinite loop.
>
> Fix this by correctly bailing out on negative values.
>
> Signed-off-by: Sam Bobroff
> ---
> arch/powerpc/platforms/pseries/eeh_pseries.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c
> b/arch/powerpc/platforms/pseries/eeh_pseries.c
> index 893ba3f562c4..9ea1c06a78cd 100644
> --- a/arch/powerpc/platforms/pseries/eeh_pseries.c
> +++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
> @@ -607,6 +607,8 @@ static int pseries_eeh_configure_bridge(struct eeh_pe *pe)
>
> if (!ret)
> return ret;
> + if (ret < 0)
> + break;
>
> /*
>* If RTAS returns a delay value that's above 100ms, cut it
> @@ -627,7 +629,7 @@ static int pseries_eeh_configure_bridge(struct eeh_pe *pe)
>
> pr_warn("%s: Unable to configure bridge PHB#%x-PE#%x (%d)\n",
> __func__, pe->phb->global_number, pe->addr, ret);
> - return ret;
> + return rtas_error_rc(ret);
See my response to patch #1. I think the best you can do here right now
is return -EINVAL for -3, -EIO for any other (unarchitected) negative
value.
Re: [PATCH v3 1/3] powerpc/rtas: Export rtas_error_rc
Sam Bobroff writes: > Export rtas_error_rc() so that it can be used by other users of > rtas_call() (which is already exported). This will do the right thing for your ibm,configure-pe use case in patch 2, but the -900x => errno translations in rtas_error_rc() appear tailored for the indicator- and sensor-related calls that currently use it. From my reading of PAPR+, the meaning of a -900x RTAS status word depends on the call. For example, -9002 commonly means "not authorized", which we would typically translate to -EPERM, but rtas_error_rc() would translate it to -ENODEV. Also the semantics of -9001 as a return value seem to vary a bit. So I don't think rtas_error_rc() should be advertised as a generically useful facility in its current form. (I have had some thoughts about how firmware/hypervisor call status can be translated to meaningful Linux error values without tedious switch statements, which I'm happy to expand on if anyone is interested, but I don't want to hijack your submission for that discussion.)
Re: [PATCH] ASoC: fsl_easrc: Check for null pointer before dereferencing “ctx” in fsl_easrc_hw_free()
> The patch 955ac624058f: "ASoC: fsl_easrc: Add EASRC ASoC CPU DAI > drivers" from Apr 16, 2020, leads to the following Smatch complaint: > > sound/soc/fsl/fsl_easrc.c:1529 fsl_easrc_hw_free() > warn: variable dereferenced before check 'ctx' (see line 1527) Please avoid a typo in the final commit subject. Regards, Markus
Re: [PATCH 3/3] powerpc/kprobes: Check return value of patch_instruction()
On Thu, 23 Apr 2020 17:41:52 +0200
Christophe Leroy wrote:
> > diff --git a/arch/powerpc/kernel/optprobes.c
> > b/arch/powerpc/kernel/optprobes.c
> > index 024f7aad1952..046485bb0a52 100644
> > --- a/arch/powerpc/kernel/optprobes.c
> > +++ b/arch/powerpc/kernel/optprobes.c
> > @@ -139,52 +139,67 @@ void arch_remove_optimized_kprobe(struct
> > optimized_kprobe *op)
> > }
> > }
> >
> > +#define PATCH_INSN(addr, instr)
> > \
> > +do {
> > \
> > + int rc = patch_instruction((unsigned int *)(addr), instr); \
> > + if (rc) {\
> > + pr_err("%s:%d Error patching instruction at 0x%pK (%pS): %d\n",
> > \
> > + __func__, __LINE__, \
> > + (void *)(addr), (void *)(addr), rc); \
> > + return rc; \
> > + }\
> > +} while (0)
> > +
>
> I hate this kind of macro which hides the "return".
>
> What about keeping the return action in the caller ?
>
> Otherwise, what about implementing something based on the use of goto,
> on the same model as unsafe_put_user() for instance ?
#define PATCH_INSN(addr, instr) \
({
int rc = patch_instruction((unsigned int *)(addr), instr); \
if (rc) \
pr_err("%s:%d Error patching instruction at 0x%pK (%pS): %d\n",
\
__func__, __LINE__, \
(void *)(addr), (void *)(addr), rc); \
rc; \
})
Then you can just do:
ret = PATCH_INSN(...);
if (ret)
return ret;
in the code.
-- Steve
Re: [PATCH 1/3] powerpc: Properly return error code from do_patch_instruction()
On Thu, 23 Apr 2020 18:21:14 +0200 Christophe Leroy wrote: > Le 23/04/2020 à 17:09, Naveen N. Rao a écrit : > > With STRICT_KERNEL_RWX, we are currently ignoring return value from > > __patch_instruction() in do_patch_instruction(), resulting in the error > > not being propagated back. Fix the same. > > Good patch. > > Be aware that there is ongoing work which tend to wanting to replace > error reporting by BUG_ON() . See > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=166003 Thanks for the reference. I still believe that WARN_ON() should be used in 99% of the cases, including here. And only do a BUG_ON() when you know there's no recovering from it. In fact, there's still BUG_ON()s in my code that I need to convert to WARN_ON() (it was written when BUG_ON() was still acceptable ;-) -- Steve
Re: [RFC PATCH 2/3] powerpc/lib: Initialize a temporary mm for code patching
On Fri, 17 Apr 2020 10:57:10 +1000
Michael Ellerman wrote:
> >>> Does it needs to be a BUG_ON() ? Can't we fail gracefully with just a
> >>> WARN_ON ?
> >>>
> >>
> >> I'm not sure what failing gracefully means here? The main reason this could
> >> fail is if there is not enough memory to allocate the patching_mm. The
> >> previous implementation had this justification for BUG_ON():
> >
> > But the system can continue running just fine after this failure.
> > Only the things that make use of code patching will fail (ftrace, kgdb,
> > ...)
>
> That's probably true of ftrace, but we can't fail patching for jump
> labels (static keys).
>
> See:
>
> void arch_jump_label_transform(struct jump_entry *entry,
> enum jump_label_type type)
> {
> u32 *addr = (u32 *)(unsigned long)entry->code;
>
> if (type == JUMP_LABEL_JMP)
> patch_branch(addr, entry->target, 0);
> else
> patch_instruction(addr, PPC_INST_NOP);
> }
I would still error on a WARN_ON() as a lot of static keys should still
work if they don't get switched over.
If a user is concerned about something like this, they can always set
panic_on_warn.
-- Steve
[PATCH] ASoC: fsl_easrc: Check NULL pinter before dereference
The patch 955ac624058f: "ASoC: fsl_easrc: Add EASRC ASoC CPU DAI
drivers" from Apr 16, 2020, leads to the following Smatch complaint:
sound/soc/fsl/fsl_easrc.c:1529 fsl_easrc_hw_free()
warn: variable dereferenced before check 'ctx' (see line 1527)
sound/soc/fsl/fsl_easrc.c
1526 struct fsl_asrc_pair *ctx = runtime->private_data;
1527 struct fsl_easrc_ctx_priv *ctx_priv = ctx->private;
^
Dereference
1528
1529 if (ctx && (ctx_priv->ctx_streams & BIT(substream->stream))) {
^^^
This check is too late, to prevent a NULL dereference.
1530 ctx_priv->ctx_streams &= ~BIT(substream->stream);
1531 fsl_easrc_release_context(ctx);
Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
Reported-by: Dan Carpenter
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_easrc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 97658e1f4989..20326bffab64 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1524,9 +1524,14 @@ static int fsl_easrc_hw_free(struct snd_pcm_substream
*substream,
{
struct snd_pcm_runtime *runtime = substream->runtime;
struct fsl_asrc_pair *ctx = runtime->private_data;
- struct fsl_easrc_ctx_priv *ctx_priv = ctx->private;
+ struct fsl_easrc_ctx_priv *ctx_priv;
+
+ if (!ctx)
+ return -EINVAL;
+
+ ctx_priv = ctx->private;
- if (ctx && (ctx_priv->ctx_streams & BIT(substream->stream))) {
+ if (ctx_priv->ctx_streams & BIT(substream->stream)) {
ctx_priv->ctx_streams &= ~BIT(substream->stream);
fsl_easrc_release_context(ctx);
}
--
2.21.0
Re: [PATCH] ASoC: fsl_esai: Remove the tasklet
On Fri, Apr 24, 2020 at 02:54:06PM +0800, Shengjiu Wang wrote: > Remove tasklet for it may cause the reset operation > can't be handled immediately, then there will be > endless xrun interrupt. The reset routine is really long and expensive, so not sure if it'd be good to do it completely inside HW ISR. Have you tried to clear xEIE bits to disable xrun interrupts, before scheduling the tasklet? If that does not solve the problem, we may go for this change.
[PATCH v4, 5/5] powerpc: sysdev: support userspace access of fsl_85xx_sram
New module which registers its memory allocation and free APIs to the
sram_dynamic module, which would create a device of struct sram_device
type to act as an interface for user level applications to access the
backend hardware device, fsl_85xx_cache_sram, which is drived by the
FSL_85XX_CACHE_SRAM module.
Signed-off-by: Wang Wenhu
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: linuxppc-dev@lists.ozlabs.org
---
Changes since v3: Addressed comments from Christophe
* Move the module to drivers/soc/fsl/ directory
* Minor changes of coding-style
---
.../powerpc/include/asm/fsl_85xx_cache_sram.h | 17
arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 2 +
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +
arch/powerpc/sysdev/fsl_85xx_sram_uapi.c | 39 +++
drivers/soc/fsl/Kconfig | 12 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/fsl_85xx_sram.h | 13 +++
drivers/soc/fsl/fsl_85xx_sram_uapi.c | 39 +++
8 files changed, 125 insertions(+)
create mode 100644 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
create mode 100644 drivers/soc/fsl/fsl_85xx_sram.h
create mode 100644 drivers/soc/fsl/fsl_85xx_sram_uapi.c
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
index 0235a0447baa..50fd6733c506 100644
--- a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -26,8 +26,25 @@ struct mpc85xx_cache_sram {
unsigned int size;
rh_info_t *rh;
spinlock_t lock;
+
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+ struct device *dev;
+#endif
};
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+static inline void set_cache_sram_dev(struct mpc85xx_cache_sram *sram,
+ struct device *dev)
+{
+ sram->dev = dev;
+}
+#else
+static inline void set_cache_sram_dev(struct mpc85xx_cache_sram *sram,
+ struct device *dev)
+{
+}
+#endif
+
extern void mpc85xx_cache_sram_free(void *ptr);
extern void *mpc85xx_cache_sram_alloc(unsigned int size,
phys_addr_t *phys, unsigned int align);
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
index ce370749add9..beb855adcfec 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
@@ -10,6 +10,8 @@
#ifndef __FSL_85XX_CACHE_CTLR_H__
#define __FSL_85XX_CACHE_CTLR_H__
+#include
+
#define L2CR_L2FI 0x4000 /* L2 flash invalidate */
#define L2CR_L2IO 0x0020 /* L2 instruction only */
#define L2CR_SRAM_ZERO 0x /* L2SRAM zero size */
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index 3de5ac8382c0..96d4a02b06fe 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -115,6 +115,8 @@ int instantiate_cache_sram(struct platform_device *dev,
rh_attach_region(cache_sram->rh, 0, cache_sram->size);
spin_lock_init(_sram->lock);
+ set_cache_sram_dev(cache_sram, >dev);
+
dev_info(>dev, "[base:0x%llx, size:0x%x] configured and loaded\n",
(unsigned long long)cache_sram->base_phys, cache_sram->size);
diff --git a/arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
b/arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
new file mode 100644
index ..64fdf082d069
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
+ * Copyright (C) 2020 Wang Wenhu
+ * All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include "fsl_85xx_sram.h"
+
+static struct sram_api mpc85xx_sram_api = {
+ .name = "mpc85xx_sram",
+ .alloc = mpc85xx_cache_sram_alloc,
+ .free = mpc85xx_cache_sram_free,
+};
+
+static int __init mpc85xx_sram_uapi_init(void)
+{
+ struct mpc85xx_cache_sram *sram = mpc85xx_get_cache_sram();
+
+ if (!sram)
+ return -ENODEV;
+
+ return sram_register_device(sram->dev, _sram_api);
+}
+subsys_initcall(mpc85xx_sram_uapi_init);
+
+static void __exit mpc85xx_sram_uapi_exit(void)
+{
+ sram_unregister_device(_sram_api);
+}
+module_exit(mpc85xx_sram_uapi_exit);
+
+MODULE_AUTHOR("Wang Wenhu ");
+MODULE_DESCRIPTION("MPC85xx SRAM User-Space API Support");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 4df32bc4c7a6..ceeebb22f6d3 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -50,4 +50,16 @@ config FSL_RCPM
tasks associated with power management, such as wakeup source control.
Note that currently this driver will not support PowerPC based
[PATCH v4, 3/5] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Randy Dunlap
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Reviewed-by: Christophe Leroy
Signed-off-by: Wang Wenhu
---
No change v1-v4
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index be3aef4229d7..3de5ac8382c0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr)
}
EXPORT_SYMBOL(mpc85xx_cache_sram_free);
-int __init instantiate_cache_sram(struct platform_device *dev,
+int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params)
{
int ret = 0;
--
2.17.1
[PATCH v4,4/5] misc: sram_dynamic for user level SRAM access
A generic User-Kernel interface module that allows a misc device created when a backend SRAM hardware device driver registers its APIs to support file operations of ioctl and mmap for user space applications to allocate SRAM memory, mmap it to process address space and free it then after. It is extremely helpful for the user space applications that require high performance memory accesses, such as embedded networking devices that would process data in user space, and PowerPC e500 is one case. Signed-off-by: Wang Wenhu Cc: Greg Kroah-Hartman Cc: Arnd Bergmann Cc: Christophe Leroy Cc: Scott Wood Cc: Michael Ellerman Cc: linuxppc-dev@lists.ozlabs.org --- Changes since v1: addressed comments from Arnd * Changed the ioctl cmd definitions using _IO micros * Export interfaces for HW-SRAM drivers to register apis to available list * Modified allocation alignment to PAGE_SIZE * Use phys_addr_t as type of SRAM resource size and offset * Support compat_ioctl * Misc device name:sram * Use tristate for SRAM_UAPI * Use postcore_initcall Changes since v2: addressed comments from Arnd, greg and Scott * Name the module with sram_dynamic in comparing with drivers/misc/sram.c I tried to tie the sram_dynamic with the abstractions in sram.c as Arnd suggested, and actually sram.c probes SRAM devices from devicetree and manages them with different partitions and create memory pools which are managed with genalloc functions. Here sram_dynamic acts only as a interface to user space. A SRAM memory pool is managed by the module that registers APIs to us, such as the backend hardware driver of Freescale 85xx Cache-SRAM. * Create one sram_device for each backend SRAM device(from Scott) * Allow only one block of SRAM memory allocated to a file descriptor(from Scott) * Add sysfs files for every allocated SRAM memory block * More documentations(As Greg commented) * Make uapi and non-uapi components apart(from Arnd and Greg) Changes since v3: * Addressed comments from Christophe * Auto select SRAM_DYNAMIC by the caller modules * Delete useless sram_uapi.c Links: v1: https://lore.kernel.org/lkml/20200418162157.50428-5-wenhu.w...@vivo.com/ v2: https://lore.kernel.org/lkml/20200420030538.101696-1-wenhu.w...@vivo.com/ UIO version: v5: https://lore.kernel.org/lkml/20200417071616.44598-5-wenhu.w...@vivo.com/ --- drivers/misc/Kconfig | 11 + drivers/misc/Makefile| 1 + drivers/misc/sram_dynamic.c | 580 +++ include/linux/sram_dynamic.h | 23 ++ include/uapi/linux/sram.h| 11 + 5 files changed, 626 insertions(+) create mode 100644 drivers/misc/sram_dynamic.c create mode 100644 include/linux/sram_dynamic.h create mode 100644 include/uapi/linux/sram.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 99e151475d8f..26f161bc0282 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -465,6 +465,17 @@ config PVPANIC a paravirtualized device provided by QEMU; it lets a virtual machine (guest) communicate panic events to the host. +config SRAM_DYNAMIC + tristate + help + This driver allows you to create a misc device which could be used + as an interface to allocate SRAM memory from user level dynamically. + + It is extremely helpful for some user space applications that require + high performance memory accesses. + + If unsure, say N. + source "drivers/misc/c2port/Kconfig" source "drivers/misc/eeprom/Kconfig" source "drivers/misc/cb710/Kconfig" diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 9abf2923d831..c32085026d30 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -46,6 +46,7 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o obj-$(CONFIG_SRAM) += sram.o obj-$(CONFIG_SRAM_EXEC)+= sram-exec.o +obj-$(CONFIG_SRAM_DYNAMIC) += sram_dynamic.o obj-y += mic/ obj-$(CONFIG_GENWQE) += genwqe/ obj-$(CONFIG_ECHO) += echo/ diff --git a/drivers/misc/sram_dynamic.c b/drivers/misc/sram_dynamic.c new file mode 100644 index ..ea2d4d92cccf --- /dev/null +++ b/drivers/misc/sram_dynamic.c @@ -0,0 +1,580 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd. + * Copyright (C) 2020 Wang Wenhu + * All rights reserved. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define SRAM_MAX_DEVICES (1U << MINORBITS) + +/** + * struct sram_res - allocated SRAM memory resource description. + * + * @virt: virtual memory address of the SRAM memory resource + * @phys: physical memory address of the SRAM memory resource + * @size: size of the SRAM memory resource + * @sdev: sram_device the resource belongs to + * @map: sysfs directory of
[PATCH v4, 2/5] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile error when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of
function ‘ioremap_coherent’; did you mean ‘bitmap_complement’?
[-Werror=implicit-function-declaration]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^~~~
bitmap_complement
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes
pointer from integer without a cast [-Werror=int-conversion]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of
function ‘iounmap’; did you mean ‘roundup’?
[-Werror=implicit-function-declaration]
iounmap(cache_sram->base_virt);
^~~
roundup
cc1: all warnings being treated as errors
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Randy Dunlap
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Reviewed-by: Christophe Leroy
Signed-off-by: Wang Wenhu
---
No change v1-v4
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index f6c665dac725..be3aef4229d7 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
[PATCH v4, 1/5] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of
function ‘of_iomap’; did you mean ‘pci_iomap’?
[-Werror=implicit-function-declaration]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^~~~
pci_iomap
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer
from integer without a cast [-Werror=int-conversion]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:267: recipe for target
'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Randy Dunlap
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Reviewed-by: Christophe Leroy
Signed-off-by: Wang Wenhu
---
No change v1-v4
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 2d0af0c517bb..7533572492f0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
Re: [PATCH] lib/mpi: Fix building for powerpc with clang
On Fri, Apr 24, 2020 at 01:23:37PM +1000, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > On Tue, Apr 14, 2020 at 11:57:31PM +1000, Herbert Xu wrote:
> >> On Mon, Apr 13, 2020 at 12:50:42PM -0700, Nathan Chancellor wrote:
> >> > 0day reports over and over on an powerpc randconfig with clang:
> >> >
> >> > lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
> >> > inline asm context requiring an l-value: remove the cast or build with
> >> > -fheinous-gnu-extensions
> >> >
> >> > Remove the superfluous casts, which have been done previously for x86
> >> > and arm32 in commit dea632cadd12 ("lib/mpi: fix build with clang") and
> >> > commit 7b7c1df2883d ("lib/mpi/longlong.h: fix building with 32-bit
> >> > x86").
> >> >
> >> > Reported-by: kbuild test robot
> >> > Link: https://github.com/ClangBuiltLinux/linux/issues/991
> >> > Signed-off-by: Nathan Chancellor
> >>
> >> Acked-by: Herbert Xu
> >> --
> >> Email: Herbert Xu
> >> Home Page: http://gondor.apana.org.au/~herbert/
> >> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> >
> > Might be better for you to take this instead. 0day just tripped over
> > this again.
>
> Sorry I missed the ack. Will pick it up today.
>
> cheers
Thank you!
Cheers,
Nathan
Re: [PATCH v3,5/5] powerpc: sysdev: support userspace access of fsl_85xx_sram
create mode 100644 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
>>>
>>> We shouldn't add more stuff in arch/powerpc/sysdev/
>>>
>>> Either it is dedicated to 85xx, and it should go into
>>> arch/powerpc/platform/85xx/ , or it is common to several
>>> platforms/architectures and should be moved to drivers/soc/fsl/
>>>
>>
>> Sure, actually I tried to find a better place, but did not recognize
>> the driver/soc. Thanks, and I will put fsl_85xx_sram_uapi there.
>>
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
index 0235a0447baa..99cb7e202c38 100644
--- a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -26,6 +26,10 @@ struct mpc85xx_cache_sram {
unsigned int size;
rh_info_t *rh;
spinlock_t lock;
+
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+ struct device *dev;
+#endif
};
extern void mpc85xx_cache_sram_free(void *ptr);
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index fa3d29dcb57e..3a6f6af973eb 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -16,6 +16,16 @@ if FSL_SOC_BOOKE
if PPC32
+config FSL_85XX_SRAM_UAPI
+ tristate "Freescale MPC85xx SRAM UAPI Support"
+ depends on FSL_SOC_BOOKE && SRAM_DYNAMIC
>>>
>>> Is SRAM_DYNAMIC usefull on its own, without a driver like this one ? Is
>>> that worth allowing tiny selection of both drivers ? Shouldn't one of
>>> them imply the other one ?
>>
>> Truely the module like this is the top level selection, and SRAM_DYNAMIC
>> should be selected by any caller modules. As SRAM_DYNAMIC may be used by
>> other drivers(in the future, but currently only us here), I think make it
>> seleted by this is better? (show below)
>>
>> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
>> index 4df32bc4c7a6..ceeebb22f6d3 100644
>> --- a/drivers/soc/fsl/Kconfig
>> +++ b/drivers/soc/fsl/Kconfig
>> @@ -50,4 +50,16 @@ config FSL_RCPM
>>tasks associated with power management, such as wakeup source control.
>>Note that currently this driver will not support PowerPC based
>>QorIQ processor.
>> +
>> +config FSL_85XX_SRAM_UAPI
>> +tristate "Freescale MPC85xx SRAM UAPI Support"
>> +depends on FSL_SOC_BOOKE && PPC32
>> +select FSL_85XX_CACHE_SRAM
>> +select SRAM_DYNAMIC
>> +help
>> + This registers a device of struct sram_device type which would act as
>> + an interface for user level applications to access the Freescale 85xx
>> + Cache-SRAM memory dynamically, meaning allocate on demand dynamically
>> + while they are running.
>> +
>
>And then in patch 4, I'm not sure it is worth to keep SRAM_DYNAMIC as
>user selectable.
>
Maybe it could be used as a module probed dynamically or so,
Currently seems there is not need to make it selectable for users.
>> endmenu
>> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
>> index 906f1cd8af01..716e38f75735 100644
>> --- a/drivers/soc/fsl/Makefile
>> +++ b/drivers/soc/fsl/Makefile
>> @@ -10,3 +10,4 @@ obj-$(CONFIG_FSL_RCPM) += rcpm.o
>> obj-$(CONFIG_FSL_GUTS) += guts.o
>> obj-$(CONFIG_FSL_MC_DPIO) += dpio/
>> obj-$(CONFIG_DPAA2_CONSOLE)+= dpaa2-console.o
>> +obj-$(CONFIG_FSL_85XX_SRAM_UAPI)+= fsl_85xx_sram_uapi.o
>>
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+extern struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void);
>>>
>>> 'extern' keywork is meaningless here, remove it.
>>>
>>
>> I will remove it in patch v4.
>>
+#endif
+
extern int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params);
extern void remove_cache_sram(struct platform_device *dev);
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index 3de5ac8382c0..0156ea63a3a2 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -23,6 +23,14 @@
struct mpc85xx_cache_sram *cache_sram;
+
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void)
+{
+ return cache_sram;
+}
+#endif
>>>
>>> This function is not worth the mess of an #ifdef in a .c file.
>>> cache_sram is already globaly visible, so this function should go in
>>> fsl_85xx_cache_ctlr.h as a 'static inline'
>>>
>>
>> Yes, and I will change it like this, with an extern of cache_sram.
>>
>> #define L2CR_SRAM_ZERO 0x /* L2SRAM zero size */
>> @@ -81,6 +83,15 @@ struct sram_parameters {
>> phys_addr_t sram_offset;
>> };
>>
[Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
https://bugzilla.kernel.org/show_bug.cgi?id=199471 --- Comment #24 from Wolfram Sang (w...@the-dreams.de) --- @Michael: commit bcf3588d8ed has the following tags: Reported-by: Erhard Furtner Tested-by: Erhard Furtner And Erhard is also the one who created this bug entry. -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 15/21] mm: memmap_init: iterate over memblock regions rather that check each PFN
On 12.04.20 21:48, Mike Rapoport wrote:
> From: Baoquan He
>
> When called during boot the memmap_init_zone() function checks if each PFN
> is valid and actually belongs to the node being initialized using
> early_pfn_valid() and early_pfn_in_nid().
>
> Each such check may cost up to O(log(n)) where n is the number of memory
> banks, so for large amount of memory overall time spent in early_pfn*()
> becomes substantial.
>
> Since the information is anyway present in memblock, we can iterate over
> memblock memory regions in memmap_init() and only call memmap_init_zone()
> for PFN ranges that are know to be valid and in the appropriate node.
>
> Signed-off-by: Baoquan He
> Signed-off-by: Mike Rapoport
> ---
> mm/page_alloc.c | 26 --
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7f6a3081edb8..c43ce8709457 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5995,14 +5995,6 @@ void __meminit memmap_init_zone(unsigned long size,
> int nid, unsigned long zone,
>* function. They do not exist on hotplugged memory.
>*/
After this change, the comment above is stale. the "holes in boot-time
mem_map" are handled by the caller now AFAIKs.
> if (context == MEMMAP_EARLY) {
> - if (!early_pfn_valid(pfn)) {
> - pfn = next_pfn(pfn);
> - continue;
> - }
> - if (!early_pfn_in_nid(pfn, nid)) {
> - pfn++;
> - continue;
> - }
> if (overlap_memmap_init(zone, ))
> continue;
> if (defer_init(nid, pfn, end_pfn))
--
Thanks,
David / dhildenb
Re: [PATCH v3,5/5] powerpc: sysdev: support userspace access of fsl_85xx_sram
Le 24/04/2020 à 09:05, 王文虎 a écrit :
Le 24/04/2020 à 04:45, Wang Wenhu a écrit :
New module which registers its memory allocation and free APIs to the
sram_dynamic module, which would create a device of struct sram_device
type to act as an interface for user level applications to access the
backend hardware device, fsl_85xx_cache_sram, which is drived by the
FSL_85XX_CACHE_SRAM module.
Signed-off-by: Wang Wenhu
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Greg Kroah-Hartman
Cc: Arnd Bergmann
Cc: linuxppc-dev@lists.ozlabs.org
---
.../powerpc/include/asm/fsl_85xx_cache_sram.h | 4 ++
arch/powerpc/platforms/85xx/Kconfig | 10 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 6 +++
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 12 ++
arch/powerpc/sysdev/fsl_85xx_sram_uapi.c | 39 +++
6 files changed, 72 insertions(+)
create mode 100644 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
We shouldn't add more stuff in arch/powerpc/sysdev/
Either it is dedicated to 85xx, and it should go into
arch/powerpc/platform/85xx/ , or it is common to several
platforms/architectures and should be moved to drivers/soc/fsl/
Sure, actually I tried to find a better place, but did not recognize
the driver/soc. Thanks, and I will put fsl_85xx_sram_uapi there.
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
index 0235a0447baa..99cb7e202c38 100644
--- a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -26,6 +26,10 @@ struct mpc85xx_cache_sram {
unsigned int size;
rh_info_t *rh;
spinlock_t lock;
+
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+ struct device *dev;
+#endif
};
extern void mpc85xx_cache_sram_free(void *ptr);
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index fa3d29dcb57e..3a6f6af973eb 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -16,6 +16,16 @@ if FSL_SOC_BOOKE
if PPC32
+config FSL_85XX_SRAM_UAPI
+ tristate "Freescale MPC85xx SRAM UAPI Support"
+ depends on FSL_SOC_BOOKE && SRAM_DYNAMIC
Is SRAM_DYNAMIC usefull on its own, without a driver like this one ? Is
that worth allowing tiny selection of both drivers ? Shouldn't one of
them imply the other one ?
Truely the module like this is the top level selection, and SRAM_DYNAMIC
should be selected by any caller modules. As SRAM_DYNAMIC may be used by
other drivers(in the future, but currently only us here), I think make it
seleted by this is better? (show below)
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 4df32bc4c7a6..ceeebb22f6d3 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -50,4 +50,16 @@ config FSL_RCPM
tasks associated with power management, such as wakeup source control.
Note that currently this driver will not support PowerPC based
QorIQ processor.
+
+config FSL_85XX_SRAM_UAPI
+ tristate "Freescale MPC85xx SRAM UAPI Support"
+ depends on FSL_SOC_BOOKE && PPC32
+ select FSL_85XX_CACHE_SRAM
+ select SRAM_DYNAMIC
+ help
+ This registers a device of struct sram_device type which would act as
+ an interface for user level applications to access the Freescale 85xx
+ Cache-SRAM memory dynamically, meaning allocate on demand dynamically
+ while they are running.
+
And then in patch 4, I'm not sure it is worth to keep SRAM_DYNAMIC as
user selectable.
endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 906f1cd8af01..716e38f75735 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_FSL_RCPM)+= rcpm.o
obj-$(CONFIG_FSL_GUTS)+= guts.o
obj-$(CONFIG_FSL_MC_DPIO) += dpio/
obj-$(CONFIG_DPAA2_CONSOLE) += dpaa2-console.o
+obj-$(CONFIG_FSL_85XX_SRAM_UAPI) += fsl_85xx_sram_uapi.o
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+extern struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void);
'extern' keywork is meaningless here, remove it.
I will remove it in patch v4.
+#endif
+
extern int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params);
extern void remove_cache_sram(struct platform_device *dev);
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index 3de5ac8382c0..0156ea63a3a2 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -23,6 +23,14 @@
struct mpc85xx_cache_sram *cache_sram;
+
+#ifdef CONFIG_FSL_85XX_SRAM_UAPI
+struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void)
+{
+ return cache_sram;
+}
[RFC PATCH v2 7/7] powerpc/selftest: reuse ppc-opcode macros to avoid redundancy
Avoid redefining macros to encode ppc instructions instead reuse it from ppc-opcode.h, Makefile changes are necessary to compile memcmp_64.S with __ASSEMBLY__ defined from selftests. Signed-off-by: Balamuruhan S --- .../selftests/powerpc/stringloops/Makefile| 34 ++ .../powerpc/stringloops/asm/asm-const.h | 1 + .../powerpc/stringloops/asm/ppc-opcode.h | 36 +-- 3 files changed, 29 insertions(+), 42 deletions(-) create mode 12 tools/testing/selftests/powerpc/stringloops/asm/asm-const.h mode change 100644 => 12 tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h diff --git a/tools/testing/selftests/powerpc/stringloops/Makefile b/tools/testing/selftests/powerpc/stringloops/Makefile index 7fc0623d85c3..efe76c5a5b94 100644 --- a/tools/testing/selftests/powerpc/stringloops/Makefile +++ b/tools/testing/selftests/powerpc/stringloops/Makefile @@ -1,26 +1,44 @@ # SPDX-License-Identifier: GPL-2.0 # The loops are all 64-bit code -CFLAGS += -I$(CURDIR) +GIT_VERSION = $(shell git describe --always --long --dirty || echo "unknown") +CFLAGS += -DGIT_VERSION='"$(GIT_VERSION)"' -I$(CURDIR) -I$(CURDIR)/../include EXTRA_SOURCES := ../harness.c build_32bit = $(shell if ($(CC) $(CFLAGS) -m32 -o /dev/null memcmp.c >/dev/null 2>&1) then echo "1"; fi) +ifneq ($(build_32bit),1) TEST_GEN_PROGS := memcmp_64 strlen +TEST_GEN_FILES := memcmp.o memcmp_64.o memcmp_64 +MEMCMP := $(OUTPUT)/memcmp.o +MEMCMP_64 := $(OUTPUT)/memcmp_64.o +HARNESS := $(OUTPUT)/../harness.o +CFLAGS += -m64 -maltivec -$(OUTPUT)/memcmp_64: memcmp.c -$(OUTPUT)/memcmp_64: CFLAGS += -m64 -maltivec +OVERRIDE_TARGETS := 1 +include ../../lib.mk -ifeq ($(build_32bit),1) +$(OUTPUT)/memcmp_64: $(MEMCMP_64) $(MEMCMP) $(HARNESS) + $(CC) $(CFLAGS) memcmp.o memcmp_64.o ../harness.o -o memcmp_64 + +$(MEMCMP_64): memcmp_64.S + $(CC) $(CFLAGS) -D__ASSEMBLY__ -o memcmp_64.o -c memcmp_64.S + +$(MEMCMP): memcmp.c + $(CC) $(CFLAGS) -o memcmp.o -c memcmp.c + +$(HARNESS): $(EXTRA_SOURCES) + $(CC) $(CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"' -o ../harness.o -c $(EXTRA_SOURCES) +else $(OUTPUT)/memcmp_32: memcmp.c $(OUTPUT)/memcmp_32: CFLAGS += -m32 TEST_GEN_PROGS += memcmp_32 endif -$(OUTPUT)/strlen: strlen.c string.c - -ifeq ($(build_32bit),1) +ifneq ($(build_32bit),1) +$(OUTPUT)/strlen: string.c +else $(OUTPUT)/strlen_32: strlen.c $(OUTPUT)/strlen_32: CFLAGS += -m32 @@ -30,6 +48,8 @@ endif ASFLAGS = $(CFLAGS) top_srcdir = ../../../../.. +ifeq ($(build_32bit),1) include ../../lib.mk +endif $(TEST_GEN_PROGS): $(EXTRA_SOURCES) diff --git a/tools/testing/selftests/powerpc/stringloops/asm/asm-const.h b/tools/testing/selftests/powerpc/stringloops/asm/asm-const.h new file mode 12 index ..18d8be13e67f --- /dev/null +++ b/tools/testing/selftests/powerpc/stringloops/asm/asm-const.h @@ -0,0 +1 @@ +../../../../../../arch/powerpc/include/asm/asm-const.h \ No newline at end of file diff --git a/tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h b/tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h deleted file mode 100644 index 3edd1a1d9128.. --- a/tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h +++ /dev/null @@ -1,35 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-or-later */ -/* - * Copyright 2009 Freescale Semiconductor, Inc. - * - * provides masks and opcode images for use by code generation, emulation - * and for instructions that older assemblers might not know about - */ -#ifndef _ASM_POWERPC_PPC_OPCODE_H -#define _ASM_POWERPC_PPC_OPCODE_H - - -# define stringify_in_c(...) __VA_ARGS__ -# define ASM_CONST(x) x - - -#define PPC_INST_VCMPEQUD_RC 0x10c7 -#define PPC_INST_VCMPEQUB_RC 0x1006 - -#define __PPC_RC21 (0x1 << 10) - -/* macros to insert fields into opcodes */ -#define ___PPC_RA(a) (((a) & 0x1f) << 16) -#define ___PPC_RB(b) (((b) & 0x1f) << 11) -#define ___PPC_RS(s) (((s) & 0x1f) << 21) -#define ___PPC_RT(t) ___PPC_RS(t) - -#define VCMPEQUD_RC(vrt, vra, vrb) stringify_in_c(.long PPC_INST_VCMPEQUD_RC | \ - ___PPC_RT(vrt) | ___PPC_RA(vra) | \ - ___PPC_RB(vrb) | __PPC_RC21) - -#define VCMPEQUB_RC(vrt, vra, vrb) stringify_in_c(.long PPC_INST_VCMPEQUB_RC | \ - ___PPC_RT(vrt) | ___PPC_RA(vra) | \ - ___PPC_RB(vrb) | __PPC_RC21) - -#endif /* _ASM_POWERPC_PPC_OPCODE_H */ diff --git a/tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h b/tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h new file mode 12 index ..f9b1f27ac335 --- /dev/null +++ b/tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h @@ -0,0 +1 @@ +../../../../../../arch/powerpc/include/asm/ppc-opcode.h \ No newline at end of file -- 2.24.1
[RFC PATCH v2 5/7] powerpc/ppc-opcode: reuse raw instruction macros to stringify
Wrap existing stringify macros to reuse raw instruction encoding macros that are newly added. Signed-off-by: Balamuruhan S --- arch/powerpc/include/asm/ppc-opcode.h | 220 +- 1 file changed, 71 insertions(+), 149 deletions(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index 6b9a891884be..34584df0ebc4 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -778,166 +778,92 @@ ___PPC_RA(a)) /* Deal with instructions that older assemblers aren't aware of */ -#definePPC_CP_ABORTstringify_in_c(.long PPC_INST_CP_ABORT) -#definePPC_COPY(a, b) stringify_in_c(.long PPC_INST_COPY | \ - ___PPC_RA(a) | ___PPC_RB(b)) -#define PPC_DARN(t, l) stringify_in_c(.long PPC_INST_DARN | \ - ___PPC_RT(t) | \ - (((l) & 0x3) << 16)) -#definePPC_DCBAL(a, b) stringify_in_c(.long PPC_INST_DCBAL | \ - __PPC_RA(a) | __PPC_RB(b)) -#definePPC_DCBZL(a, b) stringify_in_c(.long PPC_INST_DCBZL | \ - __PPC_RA(a) | __PPC_RB(b)) -#define PPC_LQARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LQARX | \ - ___PPC_RT(t) | ___PPC_RA(a) | \ - ___PPC_RB(b) | __PPC_EH(eh)) -#define PPC_LDARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LDARX | \ - ___PPC_RT(t) | ___PPC_RA(a) | \ - ___PPC_RB(b) | __PPC_EH(eh)) -#define PPC_LWARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LWARX | \ - ___PPC_RT(t) | ___PPC_RA(a) | \ - ___PPC_RB(b) | __PPC_EH(eh)) -#define PPC_STQCX(t, a, b) stringify_in_c(.long PPC_INST_STQCX | \ - ___PPC_RT(t) | ___PPC_RA(a) | \ - ___PPC_RB(b)) -#define PPC_MADDHD(t, a, b, c) stringify_in_c(.long PPC_INST_MADDHD | \ - ___PPC_RT(t) | ___PPC_RA(a) | \ - ___PPC_RB(b) | ___PPC_RC(c)) -#define PPC_MADDHDU(t, a, b, c)stringify_in_c(.long PPC_INST_MADDHDU | \ - ___PPC_RT(t) | ___PPC_RA(a) | \ - ___PPC_RB(b) | ___PPC_RC(c)) -#define PPC_MADDLD(t, a, b, c) stringify_in_c(.long PPC_INST_MADDLD | \ - ___PPC_RT(t) | ___PPC_RA(a) | \ - ___PPC_RB(b) | ___PPC_RC(c)) -#define PPC_MSGSND(b) stringify_in_c(.long PPC_INST_MSGSND | \ - ___PPC_RB(b)) -#define PPC_MSGSYNCstringify_in_c(.long PPC_INST_MSGSYNC) -#define PPC_MSGCLR(b) stringify_in_c(.long PPC_INST_MSGCLR | \ - ___PPC_RB(b)) -#define PPC_MSGSNDP(b) stringify_in_c(.long PPC_INST_MSGSNDP | \ - ___PPC_RB(b)) -#define PPC_MSGCLRP(b) stringify_in_c(.long PPC_INST_MSGCLRP | \ - ___PPC_RB(b)) -#define PPC_PASTE(a, b)stringify_in_c(.long PPC_INST_PASTE | \ - ___PPC_RA(a) | ___PPC_RB(b)) -#define PPC_POPCNTB(a, s) stringify_in_c(.long PPC_INST_POPCNTB | \ - __PPC_RA(a) | __PPC_RS(s)) -#define PPC_POPCNTD(a, s) stringify_in_c(.long PPC_INST_POPCNTD | \ - __PPC_RA(a) | __PPC_RS(s)) -#define PPC_POPCNTW(a, s) stringify_in_c(.long PPC_INST_POPCNTW | \ - __PPC_RA(a) | __PPC_RS(s)) -#define PPC_RFCI stringify_in_c(.long PPC_INST_RFCI) -#define PPC_RFDI stringify_in_c(.long PPC_INST_RFDI) -#define PPC_RFMCI stringify_in_c(.long PPC_INST_RFMCI) -#define PPC_TLBILX(t, a, b)stringify_in_c(.long PPC_INST_TLBILX | \ - __PPC_T_TLB(t) | __PPC_RA0(a) | __PPC_RB(b)) +#definePPC_CP_ABORTstringify_in_c(.long PPC_RAW_CP_ABORT) +#definePPC_COPY(a, b) stringify_in_c(.long PPC_RAW_COPY(a, b)) +#define PPC_DARN(t, l) stringify_in_c(.long PPC_RAW_DARN(t, l)) +#definePPC_DCBAL(a, b) stringify_in_c(.long PPC_RAW_DCBAL(a, b)) +#definePPC_DCBZL(a, b) stringify_in_c(.long PPC_RAW_DCBZL(a, b)) +#define PPC_LQARX(t, a, b, eh) stringify_in_c(.long PPC_RAW_LQARX(t, a, b, eh)) +#define PPC_LDARX(t, a, b, eh) stringify_in_c(.long PPC_RAW_LDARX(t, a, b, eh)) +#define PPC_LWARX(t, a, b, eh) stringify_in_c(.long
[RFC PATCH v2 6/7] powerpc/ppc-opcode: fold PPC_INST_* macros into PPC_RAW_* macros
Lot of PPC_INST_* macros are used only ever in PPC_* macros, fold those PPC_INST_* into PPC_RAW_* to avoid using PPC_INST_* accidentally. Signed-off-by: Balamuruhan S --- arch/powerpc/include/asm/ppc-opcode.h | 381 +- 1 file changed, 125 insertions(+), 256 deletions(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index 34584df0ebc4..1ffdd0e69e77 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -205,56 +205,27 @@ #define OP_LQ56 /* sorted alphabetically */ -#define PPC_INST_BHRBE 0x7c00025c -#define PPC_INST_CLRBHRB 0x7c00035c #define PPC_INST_COPY 0x7c20060c -#define PPC_INST_CP_ABORT 0x7c00068c -#define PPC_INST_DARN 0x7c0005e6 #define PPC_INST_DCBA 0x7c0005ec #define PPC_INST_DCBA_MASK 0xfc0007fe -#define PPC_INST_DCBAL 0x7c2005ec -#define PPC_INST_DCBZL 0x7c2007ec -#define PPC_INST_ICBT 0x7c2c -#define PPC_INST_ICSWX 0x7c00032d -#define PPC_INST_ICSWEPX 0x7c00076d #define PPC_INST_ISEL 0x7c1e #define PPC_INST_ISEL_MASK 0xfc3e -#define PPC_INST_LDARX 0x7ca8 -#define PPC_INST_STDCX 0x7c0001ad -#define PPC_INST_LQARX 0x7c000228 -#define PPC_INST_STQCX 0x7c00016d #define PPC_INST_LSWI 0x7c0004aa #define PPC_INST_LSWX 0x7c00042a -#define PPC_INST_LWARX 0x7c28 -#define PPC_INST_STWCX 0x7c00012d #define PPC_INST_LWSYNC0x7c2004ac #define PPC_INST_SYNC 0x7c0004ac #define PPC_INST_SYNC_MASK 0xfc0007fe #define PPC_INST_ISYNC 0x4c00012c -#define PPC_INST_LXVD2X0x7c000698 #define PPC_INST_MCRXR 0x7c000400 #define PPC_INST_MCRXR_MASK0xfc0007fe #define PPC_INST_MFSPR_PVR 0x7c1f42a6 #define PPC_INST_MFSPR_PVR_MASK0xfc1e -#define PPC_INST_MFTMR 0x7c0002dc -#define PPC_INST_MSGSND0x7c00019c -#define PPC_INST_MSGCLR0x7c0001dc -#define PPC_INST_MSGSYNC 0x7c0006ec -#define PPC_INST_MSGSNDP 0x7c00011c -#define PPC_INST_MSGCLRP 0x7c00015c #define PPC_INST_MTMSRD0x7c000164 -#define PPC_INST_MTTMR 0x7c0003dc #define PPC_INST_NOP 0x6000 -#define PPC_INST_PASTE 0x7c20070d #define PPC_INST_POPCNTB 0x7cf4 #define PPC_INST_POPCNTB_MASK 0xfc0007fe -#define PPC_INST_POPCNTD 0x7c0003f4 -#define PPC_INST_POPCNTW 0x7c0002f4 #define PPC_INST_RFEBB 0x4c000124 -#define PPC_INST_RFCI 0x4c66 -#define PPC_INST_RFDI 0x4c4e #define PPC_INST_RFID 0x4c24 -#define PPC_INST_RFMCI 0x4c4c #define PPC_INST_MFSPR 0x7c0002a6 #define PPC_INST_MFSPR_DSCR0x7c1102a6 #define PPC_INST_MFSPR_DSCR_MASK 0xfc1e @@ -264,131 +235,30 @@ #define PPC_INST_MFSPR_DSCR_USER_MASK 0xfc1e #define PPC_INST_MTSPR_DSCR_USER 0x7c0303a6 #define PPC_INST_MTSPR_DSCR_USER_MASK 0xfc1e -#define PPC_INST_MFVSRD0x7c66 -#define PPC_INST_MTVSRD0x7c000166 #define PPC_INST_SC0x4402 -#define PPC_INST_SLBFEE0x7c0007a7 -#define PPC_INST_SLBIA 0x7c0003e4 - #define PPC_INST_STRING0x7c00042a #define PPC_INST_STRING_MASK 0xfc0007fe #define PPC_INST_STRING_GEN_MASK 0xfc00067e - #define PPC_INST_STSWI 0x7c0005aa #define PPC_INST_STSWX 0x7c00052a -#define PPC_INST_STXVD2X 0x7c000798 -#define PPC_INST_TLBIE 0x7c000264 -#define PPC_INST_TLBIEL0x7c000224 -#define PPC_INST_TLBILX0x7c24 -#define PPC_INST_WAIT 0x7c7c -#define PPC_INST_TLBIVAX 0x7c000624 -#define PPC_INST_TLBSRX_DOT0x7c0006a5 -#define PPC_INST_VPMSUMW 0x1488 -#define PPC_INST_VPMSUMD 0x14c8 -#define PPC_INST_VPERMXOR 0x102d -#define PPC_INST_XXLOR 0xf490 -#define PPC_INST_XXSWAPD 0xf250 -#define PPC_INST_XVCPSGNDP 0xf780 #define PPC_INST_TRECHKPT 0x7c0007dd #define PPC_INST_TRECLAIM 0x7c00075d -#define PPC_INST_TABORT0x7c00071d #define PPC_INST_TSR 0x7c0005dd - -#define PPC_INST_NAP
[RFC PATCH v2 4/7] powerpc/ppc-opcode: consolidate powerpc instructions from bpf_jit.h
move macro definitions of powerpc instructions from bpf_jit.h to ppc-opcode.h and adopt the users of the macros accordingly. `PPC_MR()` is defined twice in bpf_jit.h, remove the duplicate one. Signed-off-by: Balamuruhan S --- arch/powerpc/include/asm/ppc-opcode.h | 139 + arch/powerpc/net/bpf_jit.h| 166 ++- arch/powerpc/net/bpf_jit32.h | 24 +-- arch/powerpc/net/bpf_jit64.h | 12 +- arch/powerpc/net/bpf_jit_comp.c | 132 ++-- arch/powerpc/net/bpf_jit_comp64.c | 278 +- 6 files changed, 378 insertions(+), 373 deletions(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index 2ae0afc5c2bb..6b9a891884be 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -79,6 +79,16 @@ #define IMM_L(i) ((uintptr_t)(i) & 0x) #define IMM_DS(i) ((uintptr_t)(i) & 0xfffc) +/* + * 16-bit immediate helper macros: HA() is for use with sign-extending instrs + * (e.g. LD, ADDI). If the bottom 16 bits is "-ve", add another bit into the + * top half to negate the effect (i.e. 0x + 1 = 0x(1)). + */ +#define IMM_H(i)((uintptr_t)(i)>>16) +#define IMM_HA(i) (((uintptr_t)(i)>>16) + \ + (((uintptr_t)(i) & 0x8000) >> 15)) + + /* opcode and xopcode for instructions */ #define OP_TRAP 3 #define OP_TRAP_64 2 @@ -637,6 +647,135 @@ #define PPC_RAW_ADDC_DOT(t, a, b) (PPC_INST_ADDC | ___PPC_RT(t) | \ ___PPC_RA(a) | ___PPC_RB(b) | \ 0x1) +#define PPC_RAW_NOP() (PPC_INST_NOP) +#define PPC_RAW_BLR() (PPC_INST_BLR) +#define PPC_RAW_BLRL() (PPC_INST_BLRL) +#define PPC_RAW_MTLR(r)(PPC_INST_MTLR | ___PPC_RT(r)) +#define PPC_RAW_BCTR() (PPC_INST_BCTR) +#define PPC_RAW_MTCTR(r) (PPC_INST_MTCTR | ___PPC_RT(r)) +#define PPC_RAW_ADDI(d, a, i) (PPC_INST_ADDI | ___PPC_RT(d) | \ + ___PPC_RA(a) | IMM_L(i)) +#define PPC_RAW_LI(r, i) PPC_RAW_ADDI(r, 0, i) +#define PPC_RAW_ADDIS(d, a, i) (PPC_INST_ADDIS | \ + ___PPC_RT(d) | ___PPC_RA(a) | \ + IMM_L(i)) +#define PPC_RAW_LIS(r, i) PPC_RAW_ADDIS(r, 0, i) +#define PPC_RAW_STDX(r, base, b) (PPC_INST_STDX | ___PPC_RS(r) | \ + ___PPC_RA(base) | ___PPC_RB(b)) +#define PPC_RAW_STDU(r, base, i) (PPC_INST_STDU | ___PPC_RS(r) | \ + ___PPC_RA(base) | \ + ((i) & 0xfffc)) +#define PPC_RAW_STW(r, base, i)(PPC_INST_STW | ___PPC_RS(r) | \ + ___PPC_RA(base) | IMM_L(i)) +#define PPC_RAW_STWU(r, base, i) (PPC_INST_STWU | ___PPC_RS(r) | \ + ___PPC_RA(base) | IMM_L(i)) +#define PPC_RAW_STH(r, base, i)(PPC_INST_STH | ___PPC_RS(r) | \ + ___PPC_RA(base) | IMM_L(i)) +#define PPC_RAW_STB(r, base, i)(PPC_INST_STB | ___PPC_RS(r) | \ + ___PPC_RA(base) | IMM_L(i)) +#define PPC_RAW_LBZ(r, base, i)(PPC_INST_LBZ | ___PPC_RT(r) | \ + ___PPC_RA(base) | IMM_L(i)) +#define PPC_RAW_LDX(r, base, b)(PPC_INST_LDX | ___PPC_RT(r) | \ + ___PPC_RA(base) | ___PPC_RB(b)) +#define PPC_RAW_LHZ(r, base, i)(PPC_INST_LHZ | ___PPC_RT(r) | \ + ___PPC_RA(base) | IMM_L(i)) +#define PPC_RAW_LHBRX(r, base, b) (PPC_INST_LHBRX | ___PPC_RT(r) | \ + ___PPC_RA(base) | ___PPC_RB(b)) +#define PPC_RAW_LDBRX(r, base, b) (PPC_INST_LDBRX | ___PPC_RT(r) | \ + ___PPC_RA(base) | ___PPC_RB(b)) +#define PPC_RAW_STWCX(s, a, b) (PPC_INST_STWCX | ___PPC_RS(s) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_CMPWI(a, i)(PPC_INST_CMPWI | ___PPC_RA(a) | IMM_L(i)) +#define PPC_RAW_CMPDI(a, i)(PPC_INST_CMPDI | ___PPC_RA(a) | IMM_L(i)) +#define PPC_RAW_CMPW(a, b) (PPC_INST_CMPW | ___PPC_RA(a) | \ + ___PPC_RB(b)) +#define PPC_RAW_CMPD(a, b) (PPC_INST_CMPD | ___PPC_RA(a) | \ + ___PPC_RB(b)) +#define PPC_RAW_CMPLWI(a, i)
[RFC PATCH v2 3/7] powerpc/bpf_jit: reuse instruction macros from ppc-opcode.h
remove duplicate macro definitions from bpf_jit.h and reuse the macros from
ppc-opcode.h
Signed-off-by: Balamuruhan S
---
arch/powerpc/net/bpf_jit.h| 18 +-
arch/powerpc/net/bpf_jit32.h | 10 +-
arch/powerpc/net/bpf_jit64.h | 4 ++--
arch/powerpc/net/bpf_jit_comp.c | 2 +-
arch/powerpc/net/bpf_jit_comp64.c | 20 ++--
5 files changed, 19 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 55d4377ccfae..535d1de4dfee 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -11,6 +11,7 @@
#ifndef __ASSEMBLY__
#include
+#include
#ifdef PPC64_ELF_ABI_v1
#define FUNCTION_DESCR_SIZE24
@@ -26,7 +27,6 @@
#define IMM_H(i) ((uintptr_t)(i)>>16)
#define IMM_HA(i) (((uintptr_t)(i)>>16) + \
(((uintptr_t)(i) & 0x8000) >> 15))
-#define IMM_L(i) ((uintptr_t)(i) & 0x)
#define PLANT_INSTR(d, idx, instr) \
do { if (d) { (d)[idx] = instr; } idx++; } while (0)
@@ -45,8 +45,6 @@
#define PPC_ADDIS(d, a, i) EMIT(PPC_INST_ADDIS | \
___PPC_RT(d) | ___PPC_RA(a) | IMM_L(i))
#define PPC_LIS(r, i) PPC_ADDIS(r, 0, i)
-#define PPC_STD(r, base, i)EMIT(PPC_INST_STD | ___PPC_RS(r) |\
-___PPC_RA(base) | ((i) & 0xfffc))
#define PPC_STDX(r, base, b) EMIT(PPC_INST_STDX | ___PPC_RS(r) | \
___PPC_RA(base) | ___PPC_RB(b))
#define PPC_STDU(r, base, i) EMIT(PPC_INST_STDU | ___PPC_RS(r) | \
@@ -62,12 +60,8 @@
#define PPC_LBZ(r, base, i)EMIT(PPC_INST_LBZ | ___PPC_RT(r) |\
___PPC_RA(base) | IMM_L(i))
-#define PPC_LD(r, base, i) EMIT(PPC_INST_LD | ___PPC_RT(r) | \
-___PPC_RA(base) | ((i) & 0xfffc))
#define PPC_LDX(r, base, b)EMIT(PPC_INST_LDX | ___PPC_RT(r) |\
___PPC_RA(base) | ___PPC_RB(b))
-#define PPC_LWZ(r, base, i)EMIT(PPC_INST_LWZ | ___PPC_RT(r) |\
-___PPC_RA(base) | IMM_L(i))
#define PPC_LHZ(r, base, i)EMIT(PPC_INST_LHZ | ___PPC_RT(r) |\
___PPC_RA(base) | IMM_L(i))
#define PPC_LHBRX(r, base, b) EMIT(PPC_INST_LHBRX | ___PPC_RT(r) | \
@@ -75,16 +69,8 @@
#define PPC_LDBRX(r, base, b) EMIT(PPC_INST_LDBRX | ___PPC_RT(r) | \
___PPC_RA(base) | ___PPC_RB(b))
-#define PPC_BPF_LDARX(t, a, b, eh) EMIT(PPC_INST_LDARX | ___PPC_RT(t) |
\
- ___PPC_RA(a) | ___PPC_RB(b) | \
- __PPC_EH(eh))
-#define PPC_BPF_LWARX(t, a, b, eh) EMIT(PPC_INST_LWARX | ___PPC_RT(t) |
\
- ___PPC_RA(a) | ___PPC_RB(b) | \
- __PPC_EH(eh))
#define PPC_BPF_STWCX(s, a, b) EMIT(PPC_INST_STWCX | ___PPC_RS(s) | \
___PPC_RA(a) | ___PPC_RB(b))
-#define PPC_BPF_STDCX(s, a, b) EMIT(PPC_INST_STDCX | ___PPC_RS(s) | \
- ___PPC_RA(a) | ___PPC_RB(b))
#define PPC_CMPWI(a, i)EMIT(PPC_INST_CMPWI | ___PPC_RA(a) |
IMM_L(i))
#define PPC_CMPDI(a, i)EMIT(PPC_INST_CMPDI | ___PPC_RA(a) |
IMM_L(i))
#define PPC_CMPW(a, b) EMIT(PPC_INST_CMPW | ___PPC_RA(a) | \
@@ -100,8 +86,6 @@
#define PPC_SUB(d, a, b) EMIT(PPC_INST_SUB | ___PPC_RT(d) |\
___PPC_RB(a) | ___PPC_RA(b))
-#define PPC_ADD(d, a, b) EMIT(PPC_INST_ADD | ___PPC_RT(d) |\
-___PPC_RA(a) | ___PPC_RB(b))
#define PPC_MULD(d, a, b) EMIT(PPC_INST_MULLD | ___PPC_RT(d) | \
___PPC_RA(a) | ___PPC_RB(b))
#define PPC_MULW(d, a, b) EMIT(PPC_INST_MULLW | ___PPC_RT(d) | \
diff --git a/arch/powerpc/net/bpf_jit32.h b/arch/powerpc/net/bpf_jit32.h
index 4ec2a9f14f84..753c244a7cf9 100644
--- a/arch/powerpc/net/bpf_jit32.h
+++ b/arch/powerpc/net/bpf_jit32.h
@@ -76,13 +76,13 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
else { PPC_ADDIS(r, base, IMM_HA(i));\
PPC_LBZ(r, r, IMM_L(i)); } } while(0)
-#define PPC_LD_OFFS(r, base, i) do { if ((i) < 32768) PPC_LD(r, base, i); \
+#define PPC_LD_OFFS(r, base, i) do { if ((i) < 32768) EMIT(PPC_RAW_LD(r, base,
i)); \
else { PPC_ADDIS(r, base, IMM_HA(i));\
- PPC_LD(r, r,
[RFC PATCH v2 1/7] powerpc/ppc-opcode: introduce PPC_RAW_* macros for base instruction encoding
Introduce PPC_RAW_* macros to have all the bare encoding of ppc instructions. Move `VSX_XX*()` and `TMRN()` macros up to reuse it. Signed-off-by: Balamuruhan S --- arch/powerpc/include/asm/ppc-opcode.h | 183 -- 1 file changed, 175 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index c1df75edde44..c5ec2ea283f1 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -428,6 +428,181 @@ #define __PPC_EH(eh) 0 #endif +/* Base instruction encoding */ +#define PPC_RAW_CP_ABORT (PPC_INST_CP_ABORT) +#define PPC_RAW_COPY(a, b) (PPC_INST_COPY | ___PPC_RA(a) | \ + ___PPC_RB(b)) +#define PPC_RAW_DARN(t, l) (PPC_INST_DARN | ___PPC_RT(t) | \ + (((l) & 0x3) << 16)) +#define PPC_RAW_DCBAL(a, b)(PPC_INST_DCBAL | __PPC_RA(a) | \ + __PPC_RB(b)) +#define PPC_RAW_DCBZL(a, b)(PPC_INST_DCBZL | __PPC_RA(a) | \ + __PPC_RB(b)) +#define PPC_RAW_LQARX(t, a, b, eh) (PPC_INST_LQARX | ___PPC_RT(t) | \ + ___PPC_RA(a) | \ + ___PPC_RB(b) | __PPC_EH(eh)) +#define PPC_RAW_LDARX(t, a, b, eh) (PPC_INST_LDARX | ___PPC_RT(t) | \ + ___PPC_RA(a) | \ + ___PPC_RB(b) | __PPC_EH(eh)) +#define PPC_RAW_LWARX(t, a, b, eh) (PPC_INST_LWARX | \ + ___PPC_RT(t) | ___PPC_RA(a) | \ + ___PPC_RB(b) | __PPC_EH(eh)) +#define PPC_RAW_STQCX(t, a, b) (PPC_INST_STQCX | \ + ___PPC_RT(t) | ___PPC_RA(a) | \ + ___PPC_RB(b)) +#define PPC_RAW_MADDHD(t, a, b, c) (PPC_INST_MADDHD | \ + ___PPC_RT(t) | ___PPC_RA(a) | \ + ___PPC_RB(b) | ___PPC_RC(c)) +#define PPC_RAW_MADDHDU(t, a, b, c)(PPC_INST_MADDHDU | \ + ___PPC_RT(t) | ___PPC_RA(a) | \ + ___PPC_RB(b) | ___PPC_RC(c)) +#define PPC_RAW_MADDLD(t, a, b, c) (PPC_INST_MADDLD | \ + ___PPC_RT(t) | ___PPC_RA(a) | \ + ___PPC_RB(b) | ___PPC_RC(c)) +#define PPC_RAW_MSGSND(b) (PPC_INST_MSGSND | ___PPC_RB(b)) +#define PPC_RAW_MSGSYNC(PPC_INST_MSGSYNC) +#define PPC_RAW_MSGCLR(b) (PPC_INST_MSGCLR | ___PPC_RB(b)) +#define PPC_RAW_MSGSNDP(b) (PPC_INST_MSGSNDP | ___PPC_RB(b)) +#define PPC_RAW_MSGCLRP(b) (PPC_INST_MSGCLRP | ___PPC_RB(b)) +#define PPC_RAW_PASTE(a, b)(PPC_INST_PASTE | ___PPC_RA(a) | \ + ___PPC_RB(b)) +#define PPC_RAW_POPCNTB(a, s) (PPC_INST_POPCNTB | __PPC_RA(a) | \ + __PPC_RS(s)) +#define PPC_RAW_POPCNTD(a, s) (PPC_INST_POPCNTD | __PPC_RA(a) | \ + __PPC_RS(s)) +#define PPC_RAW_POPCNTW(a, s) (PPC_INST_POPCNTW | __PPC_RA(a) | \ + __PPC_RS(s)) +#define PPC_RAW_RFCI (PPC_INST_RFCI) +#define PPC_RAW_RFDI (PPC_INST_RFDI) +#define PPC_RAW_RFMCI (PPC_INST_RFMCI) +#define PPC_RAW_TLBILX(t, a, b)(PPC_INST_TLBILX | \ + __PPC_T_TLB(t) | \ + __PPC_RA0(a) | \ + __PPC_RB(b)) +#define PPC_RAW_WAIT(w)(PPC_INST_WAIT | __PPC_WC(w)) +#define PPC_RAW_TLBIE(lp, a) (PPC_INST_TLBIE | ___PPC_RB(a) | \ + ___PPC_RS(lp)) +#define PPC_RAW_TLBIE_5(rb, rs, ric, prs, r) \ + (PPC_INST_TLBIE | \ + ___PPC_RB(rb) | \ + ___PPC_RS(rs) | \ + ___PPC_RIC(ric) | \ + ___PPC_PRS(prs) | \ + ___PPC_R(r)) +#define PPC_RAW_TLBIEL(rb, rs, ric, prs, r) \ + (PPC_INST_TLBIEL | \ + ___PPC_RB(rb) | \ + ___PPC_RS(rs) | \ +
[RFC PATCH v2 2/7] powerpc/ppc-opcode: move ppc instruction encoding from test_emulate_step
Few ppc instructions are encoded in test_emulate_step.c, consolidate them and use it from ppc-opcode.h Signed-off-by: Balamuruhan S --- arch/powerpc/include/asm/ppc-opcode.h | 35 ++ arch/powerpc/lib/test_emulate_step.c | 155 ++ 2 files changed, 91 insertions(+), 99 deletions(-) diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h index c5ec2ea283f1..2ae0afc5c2bb 100644 --- a/arch/powerpc/include/asm/ppc-opcode.h +++ b/arch/powerpc/include/asm/ppc-opcode.h @@ -76,6 +76,9 @@ #define__REGA0_R30 30 #define__REGA0_R31 31 +#define IMM_L(i) ((uintptr_t)(i) & 0x) +#define IMM_DS(i) ((uintptr_t)(i) & 0xfffc) + /* opcode and xopcode for instructions */ #define OP_TRAP 3 #define OP_TRAP_64 2 @@ -602,6 +605,38 @@ ___PPC_RT(vrt) | \ ___PPC_RA(vra) | \ ___PPC_RB(vrb) | __PPC_RC21) +#define PPC_RAW_LD(r, base, i) (PPC_INST_LD | ___PPC_RT(r) | \ + ___PPC_RA(base) | IMM_DS(i)) +#define PPC_RAW_LWZ(r, base, i)(PPC_INST_LWZ | ___PPC_RT(r) | \ + ___PPC_RA(base) | IMM_L(i)) +#define PPC_RAW_LWZX(t, a, b) (PPC_INST_LWZX | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_STD(r, base, i)(PPC_INST_STD | ___PPC_RS(r) | \ + ___PPC_RA(base) | IMM_DS(i)) +#define PPC_RAW_STDCX(s, a, b) (PPC_INST_STDCX | ___PPC_RS(s) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_LFSX(t, a, b) (PPC_INST_LFSX | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_STFSX(s, a, b) (PPC_INST_STFSX | ___PPC_RS(s) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_LFDX(t, a, b) (PPC_INST_LFDX | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_STFDX(s, a, b) (PPC_INST_STFDX | ___PPC_RS(s) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_LVX(t, a, b) (PPC_INST_LVX | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_STVX(s, a, b) (PPC_INST_STVX | ___PPC_RS(s) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_ADD(t, a, b) (PPC_INST_ADD | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_ADD_DOT(t, a, b) (PPC_INST_ADD | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b) | \ + 0x1) +#define PPC_RAW_ADDC(t, a, b) (PPC_INST_ADDC | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b)) +#define PPC_RAW_ADDC_DOT(t, a, b) (PPC_INST_ADDC | ___PPC_RT(t) | \ + ___PPC_RA(a) | ___PPC_RB(b) | \ + 0x1) /* Deal with instructions that older assemblers aren't aware of */ #definePPC_CP_ABORTstringify_in_c(.long PPC_INST_CP_ABORT) diff --git a/arch/powerpc/lib/test_emulate_step.c b/arch/powerpc/lib/test_emulate_step.c index 53df4146dd32..7a703bec3061 100644 --- a/arch/powerpc/lib/test_emulate_step.c +++ b/arch/powerpc/lib/test_emulate_step.c @@ -12,49 +12,6 @@ #include #include -#define IMM_L(i) ((uintptr_t)(i) & 0x) -#define IMM_DS(i) ((uintptr_t)(i) & 0xfffc) - -/* - * Defined with TEST_ prefix so it does not conflict with other - * definitions. - */ -#define TEST_LD(r, base, i)(PPC_INST_LD | ___PPC_RT(r) | \ - ___PPC_RA(base) | IMM_DS(i)) -#define TEST_LWZ(r, base, i) (PPC_INST_LWZ | ___PPC_RT(r) | \ - ___PPC_RA(base) | IMM_L(i)) -#define TEST_LWZX(t, a, b) (PPC_INST_LWZX | ___PPC_RT(t) | \ - ___PPC_RA(a) | ___PPC_RB(b)) -#define TEST_STD(r, base, i) (PPC_INST_STD | ___PPC_RS(r) | \ - ___PPC_RA(base) | IMM_DS(i)) -#define TEST_LDARX(t, a, b, eh)(PPC_INST_LDARX | ___PPC_RT(t) | \ - ___PPC_RA(a) | ___PPC_RB(b) | \ - __PPC_EH(eh)) -#define TEST_STDCX(s, a, b)(PPC_INST_STDCX | ___PPC_RS(s) |\ - ___PPC_RA(a) | ___PPC_RB(b)) -#define
[RFC PATCH v2 0/7] consolidate PowerPC instruction encoding macros
ppc-opcode.h have base instruction encoding wrapped with stringify_in_c() for raw encoding to have compatibility. But there are redundant macros for base instruction encodings in bpf, instruction emulation test infrastructure and powerpc selftests. Currently PPC_INST_* macros are used for encoding instruction opcode and PPC_* for raw instuction encoding, this rfc patchset introduces PPC_RAW_* macros for base instruction encoding and reuse it from elsewhere. With this change we can avoid redundant macro definitions in multiple files and start adding new instructions in ppc-opcode.h in future. Changes in v2: - Fix review comments/suggestions from Naveen and Michael Ellerman, * Rename PPC_ENCODE_* to PPC_RAW_* for base instruction encoding macros. * Split the patches that does mass renaming and make them simpler that just adds new macros. * Keep the patch to update all the existing names later (patch 6). * Lot of PPC_INST_* macros are used only in ppc-opcode.h for PPC_* macros, fold PPC_INST_* encoding into PPC_RAW_* to avoid using them accidentally. * Fixed clipped macros that was due to a typo/copy-paste * Consolidated all the instruction encoding macros from bpf_jit.h to ppc-opcode.h * squashed patch that removes the duplicate macro PPC_MR() in bpf_jit.h * merge few changes in bpf_jit files from patch 2 into patch 3 * few fixes in powerpc selftest stringloops Makefile * build tested for ppc64le_defconfig, ppc64e_defconfig and pmac32_defconfig * Rebased on next branch of linuxppc tree Testing: --- * Tested it by compiling vmlinux and comparing objdump of it with and without the patchset and observed that it remains same, # diff vmlinux_objdump vmlinux_rfc_objdump 2c2 < vmlinux: file format elf64-powerpcle --- > vmlinux_rfc: file format elf64-powerpcle * Tested building it with this changes for Fedora30 config, booted VM with powerpc next and powerpc next + patchset to run powerpc selftest and ftrace selftest. There were couple of failures that were common and patchset did not introduce any new failures. ftrace selftest: --- # # of passed: 96 # # of failed: 1 # # of unresolved: 7 # # of untested: 0 # # of unsupported: 1 # # of xfailed: 1 # # of undefined(test bug): 0 not ok 1 selftests: ftrace: ftracetest # exit=1 powerpc selftest: not ok 7 selftests: powerpc/dscr: dscr_sysfs_thread_test # exit=1 not ok 20 selftests: powerpc/pmu/ebb: lost_exception_test # TIMEOUT not ok 2 selftests: powerpc/security: spectre_v2 # exit=1 Thanks to Naveen, Sandipan and Michael on overall suggestions/improvements. I would request for review and suggestions to make it better. v1: https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-March/206494.html Balamuruhan S (7): powerpc/ppc-opcode: introduce PPC_RAW_* macros for base instruction encoding powerpc/ppc-opcode: move ppc instruction encoding from test_emulate_step powerpc/bpf_jit: reuse instruction macros from ppc-opcode.h powerpc/ppc-opcode: consolidate powerpc instructions from bpf_jit.h powerpc/ppc-opcode: reuse raw instruction macros to stringify powerpc/ppc-opcode: fold PPC_INST_* macros into PPC_RAW_* macros powerpc/selftest: reuse ppc-opcode macros to avoid redundancy arch/powerpc/include/asm/ppc-opcode.h | 706 +++--- arch/powerpc/lib/test_emulate_step.c | 155 ++-- arch/powerpc/net/bpf_jit.h| 184 + arch/powerpc/net/bpf_jit32.h | 34 +- arch/powerpc/net/bpf_jit64.h | 16 +- arch/powerpc/net/bpf_jit_comp.c | 134 ++-- arch/powerpc/net/bpf_jit_comp64.c | 298 .../selftests/powerpc/stringloops/Makefile| 34 +- .../powerpc/stringloops/asm/asm-const.h | 1 + .../powerpc/stringloops/asm/ppc-opcode.h | 36 +- 10 files changed, 762 insertions(+), 836 deletions(-) create mode 12 tools/testing/selftests/powerpc/stringloops/asm/asm-const.h mode change 100644 => 12 tools/testing/selftests/powerpc/stringloops/asm/ppc-opcode.h base-commit: 45591da765885f7320a111d290b3a28a23eed359 -- 2.24.1
Re: [PATCH v3,5/5] powerpc: sysdev: support userspace access of fsl_85xx_sram
>Le 24/04/2020 à 04:45, Wang Wenhu a écrit :
>> New module which registers its memory allocation and free APIs to the
>> sram_dynamic module, which would create a device of struct sram_device
>> type to act as an interface for user level applications to access the
>> backend hardware device, fsl_85xx_cache_sram, which is drived by the
>> FSL_85XX_CACHE_SRAM module.
>>
>> Signed-off-by: Wang Wenhu
>> Cc: Christophe Leroy
>> Cc: Scott Wood
>> Cc: Michael Ellerman
>> Cc: Greg Kroah-Hartman
>> Cc: Arnd Bergmann
>> Cc: linuxppc-dev@lists.ozlabs.org
>> ---
>> .../powerpc/include/asm/fsl_85xx_cache_sram.h | 4 ++
>> arch/powerpc/platforms/85xx/Kconfig | 10 +
>> arch/powerpc/sysdev/Makefile | 1 +
>> arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 6 +++
>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 12 ++
>> arch/powerpc/sysdev/fsl_85xx_sram_uapi.c | 39 +++
>> 6 files changed, 72 insertions(+)
>> create mode 100644 arch/powerpc/sysdev/fsl_85xx_sram_uapi.c
>
>We shouldn't add more stuff in arch/powerpc/sysdev/
>
>Either it is dedicated to 85xx, and it should go into
>arch/powerpc/platform/85xx/ , or it is common to several
>platforms/architectures and should be moved to drivers/soc/fsl/
>
Sure, actually I tried to find a better place, but did not recognize
the driver/soc. Thanks, and I will put fsl_85xx_sram_uapi there.
>>
>> diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
>> b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
>> index 0235a0447baa..99cb7e202c38 100644
>> --- a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
>> +++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
>> @@ -26,6 +26,10 @@ struct mpc85xx_cache_sram {
>> unsigned int size;
>> rh_info_t *rh;
>> spinlock_t lock;
>> +
>> +#ifdef CONFIG_FSL_85XX_SRAM_UAPI
>> +struct device *dev;
>> +#endif
>> };
>>
>> extern void mpc85xx_cache_sram_free(void *ptr);
>> diff --git a/arch/powerpc/platforms/85xx/Kconfig
>> b/arch/powerpc/platforms/85xx/Kconfig
>> index fa3d29dcb57e..3a6f6af973eb 100644
>> --- a/arch/powerpc/platforms/85xx/Kconfig
>> +++ b/arch/powerpc/platforms/85xx/Kconfig
>> @@ -16,6 +16,16 @@ if FSL_SOC_BOOKE
>>
>> if PPC32
>>
>> +config FSL_85XX_SRAM_UAPI
>> +tristate "Freescale MPC85xx SRAM UAPI Support"
>> +depends on FSL_SOC_BOOKE && SRAM_DYNAMIC
>
>Is SRAM_DYNAMIC usefull on its own, without a driver like this one ? Is
>that worth allowing tiny selection of both drivers ? Shouldn't one of
>them imply the other one ?
Truely the module like this is the top level selection, and SRAM_DYNAMIC
should be selected by any caller modules. As SRAM_DYNAMIC may be used by
other drivers(in the future, but currently only us here), I think make it
seleted by this is better? (show below)
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 4df32bc4c7a6..ceeebb22f6d3 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -50,4 +50,16 @@ config FSL_RCPM
tasks associated with power management, such as wakeup source control.
Note that currently this driver will not support PowerPC based
QorIQ processor.
+
+config FSL_85XX_SRAM_UAPI
+ tristate "Freescale MPC85xx SRAM UAPI Support"
+ depends on FSL_SOC_BOOKE && PPC32
+ select FSL_85XX_CACHE_SRAM
+ select SRAM_DYNAMIC
+ help
+ This registers a device of struct sram_device type which would act as
+ an interface for user level applications to access the Freescale 85xx
+ Cache-SRAM memory dynamically, meaning allocate on demand dynamically
+ while they are running.
+
endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 906f1cd8af01..716e38f75735 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_FSL_RCPM)+= rcpm.o
obj-$(CONFIG_FSL_GUTS) += guts.o
obj-$(CONFIG_FSL_MC_DPIO) += dpio/
obj-$(CONFIG_DPAA2_CONSOLE)+= dpaa2-console.o
+obj-$(CONFIG_FSL_85XX_SRAM_UAPI) += fsl_85xx_sram_uapi.o
>>
>> +#ifdef CONFIG_FSL_85XX_SRAM_UAPI
>> +extern struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void);
>
>'extern' keywork is meaningless here, remove it.
>
I will remove it in patch v4.
>> +#endif
>> +
>> extern int instantiate_cache_sram(struct platform_device *dev,
>> struct sram_parameters sram_params);
>> extern void remove_cache_sram(struct platform_device *dev);
>> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
>> b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
>> index 3de5ac8382c0..0156ea63a3a2 100644
>> --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
>> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
>> @@ -23,6 +23,14 @@
>>
>> struct mpc85xx_cache_sram *cache_sram;
>>
>> +
>> +#ifdef CONFIG_FSL_85XX_SRAM_UAPI
>> +struct mpc85xx_cache_sram *mpc85xx_get_cache_sram(void)
>> +{
[PATCH] ASoC: fsl_esai: Remove the tasklet
Remove tasklet for it may cause the reset operation
can't be handled immediately, then there will be
endless xrun interrupt.
Fixes: 7ccafa2b3879 ("ASoC: fsl_esai: recover the channel swap after xrun")
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index c7a49d03463a..1ad0859da5e2 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -32,7 +32,6 @@
* @extalclk: esai clock source to derive HCK, SCK and FS
* @fsysclk: system clock source to derive HCK, SCK and FS
* @spbaclk: SPBA clock (optional, depending on SoC design)
- * @task: tasklet to handle the reset operation
* @lock: spin lock between hw_reset() and trigger()
* @fifo_depth: depth of tx/rx FIFO
* @slot_width: width of each DAI slot
@@ -56,7 +55,6 @@ struct fsl_esai {
struct clk *extalclk;
struct clk *fsysclk;
struct clk *spbaclk;
- struct tasklet_struct task;
spinlock_t lock; /* Protect hw_reset and trigger */
u32 fifo_depth;
u32 slot_width;
@@ -74,6 +72,8 @@ struct fsl_esai {
char name[32];
};
+static void fsl_esai_hw_reset(struct fsl_esai *esai_priv);
+
static irqreturn_t esai_isr(int irq, void *devid)
{
struct fsl_esai *esai_priv = (struct fsl_esai *)devid;
@@ -87,7 +87,7 @@ static irqreturn_t esai_isr(int irq, void *devid)
if ((saisr & (ESAI_SAISR_TUE | ESAI_SAISR_ROE)) &&
esai_priv->reset_at_xrun) {
dev_dbg(>dev, "reset module for xrun\n");
- tasklet_schedule(_priv->task);
+ fsl_esai_hw_reset(esai_priv);
}
if (esr & ESAI_ESR_TINIT_MASK)
@@ -674,9 +674,8 @@ static void fsl_esai_trigger_stop(struct fsl_esai
*esai_priv, bool tx)
ESAI_xFCR_xFR, 0);
}
-static void fsl_esai_hw_reset(unsigned long arg)
+static void fsl_esai_hw_reset(struct fsl_esai *esai_priv)
{
- struct fsl_esai *esai_priv = (struct fsl_esai *)arg;
bool tx = true, rx = false, enabled[2];
unsigned long lock_flags;
u32 tfcr, rfcr;
@@ -1034,9 +1033,6 @@ static int fsl_esai_probe(struct platform_device *pdev)
return ret;
}
- tasklet_init(_priv->task, fsl_esai_hw_reset,
-(unsigned long)esai_priv);
-
pm_runtime_enable(>dev);
regcache_cache_only(esai_priv->regmap, true);
@@ -1050,10 +1046,7 @@ static int fsl_esai_probe(struct platform_device *pdev)
static int fsl_esai_remove(struct platform_device *pdev)
{
- struct fsl_esai *esai_priv = platform_get_drvdata(pdev);
-
pm_runtime_disable(>dev);
- tasklet_kill(_priv->task);
return 0;
}
--
2.21.0
Re: [PATCH v3,4/5] misc: sram_dynamic for user level SRAM access
>> diff --git a/include/linux/sram_dynamic.h b/include/linux/sram_dynamic.h
>> new file mode 100644
>> index ..c77e9e7b1151
>> --- /dev/null
>> +++ b/include/linux/sram_dynamic.h
>> @@ -0,0 +1,23 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef __SRAM_DYNAMIC_H
>> +#define __SRAM_DYNAMIC_H
>> +
>> +struct sram_api {
>> +const char *name;
>> +struct sram_device *sdev;
>> +void *(*alloc)(__u32 size, phys_addr_t *phys, __u32 align);
>> +void (*free)(void *ptr);
>> +};
>> +
>> +extern int __must_check
>> +__sram_register_device(struct module *owner,
>> + struct device *parent,
>> + struct sram_api *sa);
>
>'extern' keyword is useless here, remove it (checkpatch --strict will
>likely tell you the same)
>
>> +
>> +/* Use a define to avoid include chaining to get THIS_MODULE */
>> +#define sram_register_device(parent, sa) \
>> +__sram_register_device(THIS_MODULE, parent, sa)
>> +
>> +extern void sram_unregister_device(struct sram_api *sa);
>
>Same, no 'extern' please.
>
Thanks, I will remove them in patch v4. And checkpatch with --strict will be
prefered.
Wenhu
