Re: [RFC v3] net: add PCINet driver
On Nov 5, 2008, at 3:22 PM, Ira Snyder wrote: > This adds support to Linux for a virtual ethernet interface which uses the > PCI bus as its transport mechanism. It creates a simple, familiar, and fast > method of communication for two devices connected by a PCI interface. > > I have implemented client support for the Freescale MPC8349EMDS board, > which is capable of running in PCI Agent mode (It acts like a PCI card, but > is a complete PowerPC computer, running Linux). It is almost certainly > trivially ported to any MPC83xx system. > > It was developed to work in a CompactPCI crate of computers, one of which > is a relatively standard x86 system (acting as the host) and many PowerPC > systems (acting as clients). > > RFC v2 -> RFC v3: > * use inline functions for accessing struct circ_buf_desc > * use pointer dereferencing on PowerPC local memory instead of ioread32() > * move IMMR and buffer descriptor accessors inside drivers > * update for dma_mapping_error() API changes > * use minimal locking primitives (i.e. spin_lock() instead of _irqsave()) > * always disable checksumming, PCI is reliable > * replace typedef cbd_t with struct circ_buf_desc > * use get_immrbase() to get IMMR register offsets > > RFC v1 -> RFC v2: > * remove vim modelines > * use net_device->name in request_irq(), for irqbalance > * remove unneccesary wqt_get_stats(), use default get_stats() instead > * use dev_printk() and friends > * add message unit to MPC8349EMDS dts file > > Signed-off-by: Ira W. Snyder > --- > This is the third RFC posting of this driver. I got some feedback, and have > corrected the problems. Thanks to everyone who has done review! I have > gotten off-list feedback from several potential users, so there are > definitely many potential users. > > I'll post up a revised version about once a week as long as the changes are > minor. If they are more substantial, I'll post them as needed. > > The remaining issues I see in this driver: > 1) Naming > The name wqt originally stood for "workqueue-test" and somewhat evolved > over time into the current driver. I'm looking for suggestions for a > better name. It should be the same between the host and client drivers, > to make porting the code between them easier. The drivers are /very/ > similar other than the setup code. > 2) IMMR Usage > In the Freescale client driver, I use the whole set of board control > registers (AKA IMMR registers). I only need a very small subset of them, > during startup to set up the DMA window. I used the full set of > registers so that I could share the register offsets between the drivers > (in pcinet_hw.h) > 3) Hardcoded DMA Window Address > In the Freescale client driver, I just hardcoded the address of the > outbound PCI window into the DMA transfer code. It is 0x8000. > Suggestions on how to get this value at runtime are welcome. > > > Rationale behind some decisions: > 1) Usage of the PCINET_NET_REGISTERS_VALID bit > I want to be able to use this driver from U-Boot to tftp a kernel over > the PCI backplane, and then boot up the board. This means that the > device descriptor memory, which lives in the client RAM, becomes invalid > during boot. > 2) Buffer Descriptors in client memory > I chose to put the buffer descriptors in client memory rather than host > memory. It seemed more logical to me at the time. In my application, > I'll have 19 boards + 1 host per cPCI chassis. The client -> host > direction will see most of the traffic, and so I thought I would cut > down on the number of PCI accesses needed. I'm willing to change this. > 3) Usage of client DMA controller for all data transfer > This was done purely for speed. I tried using the CPU to transfer all > data, and it is very slow: ~3MB/sec. Using the DMA controller gets me to > ~40MB/sec (as tested with netperf). > 4) Static 1GB DMA window > Maintaining a window while DMA's in flight, and then changing it seemed > too complicated. Also, testing showed that using a static window gave me > a ~10MB/sec speedup compared to moving the window for each skb. > 5) The serial driver > Yes, there are two essentially separate drivers here. I needed a method > to communicate with the U-Boot bootloader on these boards without > plugging in a serial cable. With 19 clients + 1 host per chassis, the > cable clutter is worth avoiding. Since everything is connected via the > PCI bus anyway, I used that. A virtual serial port was simple to > implement using the messaging unit hardware that I used for the network > driver. > > I'll post both U-Boot drivers to their mailing list once this driver is > finalized. > > Thanks, > Ira > > arch/powerpc/boot/dts/mpc834x_mds.dts |7 + > drivers/net/Kconfig | 29 + > drivers/net/Makefile |3 + > drivers/net/pcinet.h |
Re: I can not get my MII working on MPC8247 with Linux 2.6.32.6
I tried to skip the turn around bit check in source, but the mii bus still get the 0x PHYIDs. I will check if there is any pull ups on mdio line. Thank you. 2010/3/31 p...@conspiracy.net : > I had the same issue on a board. The original was config was a 8247 > with 2.6.27 and changed the CPU card in the system to 8567 & 2.6.32. > The old code did not check the turn around bit. Can't remember the > exact fix but as I remember if there are no pull ups on the mdio line > the turn around bit will not be in the correct state (it just opens the > line not not driving it to 1). Will try to ask the hw guy if he > remembers when he comes in tomorrow. > Paul > > On 3/30/2010 8:46 PM, Peter Pan wrote: >> Recently, I'm porting Linux 2.6.32.6 to our customized MPC8247 based >> board. Everything is fine out except my ethernets. I uses >> cpm2-scc-enet and cpm2-fcc-enet drivers. >> My ethernet works fine in U-Boot with the same setting, and our >> previous Linux 2.6.22 is also working, so there should be nothing >> wrong with the hardware. >> The boot log of the MII part is: >> >> CPM2 Bitbanged MII: probed >> mdio_bus f0010d00: error probing PHY at address 0 >> mdio_bus f0010d00: error probing PHY at address 1 >> >> I add some print, and find out that the MII bus can not be get the >> turn around bit, and can not get the PHYIDs. That makes the PHY probe >> failed. >> Maybe it's because my wrongly typed dts file? My ethernet part of my >> dts file is: >> My MDIO pin is using PA23, MDC pin is using PA22. >> ___ >> Linuxppc-dev mailing list >> Linuxppc-dev@lists.ozlabs.org >> https://lists.ozlabs.org/listinfo/linuxppc-dev >> > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Requesting a GPIO that hasn't been registered yet
Guys:
I'm sure this is a FAQ, but I can't seem to find the answer. I'm happy
to RTFM, if someone can please tell me where the FM is. :)
I'm adding device table support to gpio_keys. The target is an
MPC5200B. I have statements in my dts file that look like this:
...
i...@3d40 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <0x3d40 0x40>;
interrupts = <2 16 0>;
...
lext60: max7...@60 {
compatible = "maxim,max7314","phillips,pca953x";
reg = <0x60>;
gpio-controller;
#gpio-cells = <2>;
};
};
...
gpio-keys {
compatible = "gpio-keys";
encoder_button {
gpios = <&lext60 12 0>;
code = <28>;
type = <1>;
active-low = <0>;
wakeup = <0>;
debounce-interval = <0>;
rep = <0>;
};
};
In other words, the GPIO pin I'm using for the key is one of the bits on
my pca953x GPIO expander chip.
The above would all be great, except that I haven't come up with a way
to make sure that my encoder_button doesn't try to probe before lext60
is available. In fact, I'm consistently getting initialization in the
wrong order!
Eventually the GPIO expander chip gets plugged in, because I can see it
show up in sysfs. And what's really odd is, I recently made similar
mods to gpio_leds and they are working fine--- although the GPIO pin is
on a pca953x at address 20, instead of 60. I'm at a loss to explain why
one works, but the other doesn't. And I don't know how to really fix
this problem for good!
Any suggestions? Thanks!!
b.g.
--
Bill Gatliff
b...@billgatliff.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/12] arch/powerpc/kernel: Add missing unlock
Hi Julia, On Mon, 29 Mar 2010 17:33:34 +0200 (CEST) Julia Lawall wrote: > > From: Julia Lawall > > Add an unlock before exiting the function. Thanks for this. > Signed-off-by: Julia Lawall Acked-by: Stephen Rothwell -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpuDP3oN9M5S.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
I can not get my MII working on MPC8247 with Linux 2.6.32.6
Recently, I'm porting Linux 2.6.32.6 to our customized MPC8247 based
board. Everything is fine out except my ethernets. I uses
cpm2-scc-enet and cpm2-fcc-enet drivers.
My ethernet works fine in U-Boot with the same setting, and our
previous Linux 2.6.22 is also working, so there should be nothing
wrong with the hardware.
The boot log of the MII part is:
CPM2 Bitbanged MII: probed
mdio_bus f0010d00: error probing PHY at address 0
mdio_bus f0010d00: error probing PHY at address 1
I add some print, and find out that the MII bus can not be get the
turn around bit, and can not get the PHYIDs. That makes the PHY probe
failed.
Maybe it's because my wrongly typed dts file? My ethernet part of my
dts file is:
My MDIO pin is using PA23, MDC pin is using PA22.
s...@f000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8247-immr", "fsl,pq2-soc";
ranges = <0x0 0xf000 0x53000>;
bus-frequency = <0>; /* Filled in by U-Boot */
c...@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8247-cpm", "fsl,cpm2";
reg = <0x119c0 0x30>;
ranges;
muram {
compatible = "fsl,cpm-muram";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x1>;
d...@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x80 0x1f80 0x9800 0x800>;
};
};
m...@10d00 {
device_type = "mdio";
compatible = "fsl,cpm2-mdio-bitbang";
reg = <0x10d00 0x14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <23>;
fsl,mdc-pin = <22>;
PHY0: ethernet-...@0 {
interrupt-parent = <&PIC>;
interrupts = <22 8>;
reg = <0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-...@1 {
interrupt-parent = <&PIC>;
interrupts = <22 8>;
reg = <1>;
device_type = "ethernet-phy";
};
};
eth0: ether...@11300 {
device_type = "network";
compatible = "fsl,mpc8247-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <0x12000300>;
fsl,cpm-txclk = <9>;
fsl,cpm-rxclk = <10>;
};
eth1: ether...@11320 {
device_type = "network";
compatible = "fsl,mpc8247-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <33 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <0x16200300>;
fsl,cpm-txclk = <15>;
fsl,cpm-rxclk = <16>;
};
eth2: ether...@11a40 {
device_type = "network";
compatible = "fsl,mpc8247-scc-enet",
"fsl,cpm2-scc-enet";
reg = <0x11a40 0x20 0x8200 0x100 0x11390 1>;
local-mac-address = [00 00 00 00 00 00];
interrupts = <42 8>;
interrupt-parent = <&PIC>;
linux,network-index = <2>;
fsl,cpm-command = <0x8c0>;
fsl,cpm-txclk = <8>;
fsl,cpm-rxclk = <5>;
};
eth3: ether...@11a60 {
device_type = "network";
compatible = "fsl,mpc8247-scc-enet",
"fsl,cpm2-scc-enet";
reg = <0x11a60 0x20 0x8300 0x100 0x11390 1>;
local-mac-address = [00 00 00 00 00 00];
interrupts = <43 8>;
interrupt-parent = <&PIC>;
linux,network-index = <3>;
fsl,cpm-command = <0xce0>;
fsl,cpm-txclk = <7>;
fsl,cpm-rxclk = <6>;
};
Re: [PATCH] fix the problem where pcix node is probed again as pci node.
On Tue, 2010-03-30 at 15:02 -0700, Feng Kan wrote: > Ok thanks. This short string match may be useful in some cases, but I > agree it plays havoc with the current code. Yeah well, it's not actually -that- useful and is definitely broken :-) If you want multiples matches, then it's the compatible property itself that should contain multiple entries since it's a list. The string match should be exact. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fix the problem where pcix node is probed again as pci node.
On Tue, Mar 30, 2010 at 3:14 PM, Benjamin Herrenschmidt wrote: > On Wed, 2010-03-31 at 07:48 +1100, Benjamin Herrenschmidt wrote: >> On Tue, 2010-03-30 at 10:41 -0700, Feng Kan wrote: >> > From: Feng Kan >> > >> > The current matching scheme make the pci node match to pcix or pciex node. >> > To avoid the match, change the method so only one type of initialization >> > is called per node. >> >> No, your patch is not right. The problem was introduced by a patch from >> Grant that incorrectly made of_device_is_compatible do a substring >> match. Grant should have fixed that now. Grant ? Is your fix upstream >> yet ? If not, can you send that ASAP ? > > Better if I CC him too :-) The fix is in upstream. Commit 1976152fd8e706135deed6cf333e347c08416056 g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fix the problem where pcix node is probed again as pci node.
Ok thanks. This short string match may be useful in some cases, but I
agree it plays havoc with the current code.
Feng Kan
On Mar 30, 2010, at 14:14, "Benjamin Herrenschmidt" > wrote:
On Wed, 2010-03-31 at 07:48 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2010-03-30 at 10:41 -0700, Feng Kan wrote:
From: Feng Kan
The current matching scheme make the pci node match to pcix or
pciex node.
To avoid the match, change the method so only one type of
initialization
is called per node.
No, your patch is not right. The problem was introduced by a patch
from
Grant that incorrectly made of_device_is_compatible do a substring
match. Grant should have fixed that now. Grant ? Is your fix upstream
yet ? If not, can you send that ASAP ?
Better if I CC him too :-)
Cheers,
Ben.
Cheers,
Ben.
Signed-off-by: Feng Kan
Signed-off-by: Tirumala R Marri
---
arch/powerpc/sysdev/ppc4xx_pci.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/
sysdev/ppc4xx_pci.c
index 8aa3302..1e67c74 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1842,14 +1842,16 @@ static int __init ppc4xx_pci_find_bridges
(void)
ppc_pci_flags |= PPC_PCI_ENABLE_PROC_DOMAINS |
PPC_PCI_COMPAT_DOMAIN_0;
+for_each_compatible_node(np, NULL, "ibm,plb-pci") {
+if (of_device_is_compatible(np, "ibm,plb-pcix"))
+ppc4xx_probe_pcix_bridge(np);
#ifdef CONFIG_PPC4xx_PCI_EXPRESS
-for_each_compatible_node(np, NULL, "ibm,plb-pciex")
-ppc4xx_probe_pciex_bridge(np);
+else if (of_device_is_compatible(np, "ibm,plb-pciex"))
+ppc4xx_probe_pciex_bridge(np);
#endif
-for_each_compatible_node(np, NULL, "ibm,plb-pcix")
-ppc4xx_probe_pcix_bridge(np);
-for_each_compatible_node(np, NULL, "ibm,plb-pci")
-ppc4xx_probe_pci_bridge(np);
+else
+ppc4xx_probe_pci_bridge(np);
+}
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fix the problem where pcix node is probed again as pci node.
On Wed, 2010-03-31 at 07:48 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2010-03-30 at 10:41 -0700, Feng Kan wrote:
> > From: Feng Kan
> >
> > The current matching scheme make the pci node match to pcix or pciex node.
> > To avoid the match, change the method so only one type of initialization
> > is called per node.
>
> No, your patch is not right. The problem was introduced by a patch from
> Grant that incorrectly made of_device_is_compatible do a substring
> match. Grant should have fixed that now. Grant ? Is your fix upstream
> yet ? If not, can you send that ASAP ?
Better if I CC him too :-)
Cheers,
Ben.
> Cheers,
> Ben.
>
>
> > Signed-off-by: Feng Kan
> > Signed-off-by: Tirumala R Marri
> > ---
> > arch/powerpc/sysdev/ppc4xx_pci.c | 14 --
> > 1 files changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c
> > b/arch/powerpc/sysdev/ppc4xx_pci.c
> > index 8aa3302..1e67c74 100644
> > --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> > +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> > @@ -1842,14 +1842,16 @@ static int __init ppc4xx_pci_find_bridges(void)
> >
> > ppc_pci_flags |= PPC_PCI_ENABLE_PROC_DOMAINS | PPC_PCI_COMPAT_DOMAIN_0;
> >
> > + for_each_compatible_node(np, NULL, "ibm,plb-pci") {
> > + if (of_device_is_compatible(np, "ibm,plb-pcix"))
> > + ppc4xx_probe_pcix_bridge(np);
> > #ifdef CONFIG_PPC4xx_PCI_EXPRESS
> > - for_each_compatible_node(np, NULL, "ibm,plb-pciex")
> > - ppc4xx_probe_pciex_bridge(np);
> > + else if (of_device_is_compatible(np, "ibm,plb-pciex"))
> > + ppc4xx_probe_pciex_bridge(np);
> > #endif
> > - for_each_compatible_node(np, NULL, "ibm,plb-pcix")
> > - ppc4xx_probe_pcix_bridge(np);
> > - for_each_compatible_node(np, NULL, "ibm,plb-pci")
> > - ppc4xx_probe_pci_bridge(np);
> > + else
> > + ppc4xx_probe_pci_bridge(np);
> > + }
> >
> > return 0;
> > }
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fix the problem where pcix node is probed again as pci node.
On Tue, 2010-03-30 at 10:41 -0700, Feng Kan wrote:
> From: Feng Kan
>
> The current matching scheme make the pci node match to pcix or pciex node.
> To avoid the match, change the method so only one type of initialization
> is called per node.
No, your patch is not right. The problem was introduced by a patch from
Grant that incorrectly made of_device_is_compatible do a substring
match. Grant should have fixed that now. Grant ? Is your fix upstream
yet ? If not, can you send that ASAP ?
Cheers,
Ben.
> Signed-off-by: Feng Kan
> Signed-off-by: Tirumala R Marri
> ---
> arch/powerpc/sysdev/ppc4xx_pci.c | 14 --
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c
> b/arch/powerpc/sysdev/ppc4xx_pci.c
> index 8aa3302..1e67c74 100644
> --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> @@ -1842,14 +1842,16 @@ static int __init ppc4xx_pci_find_bridges(void)
>
> ppc_pci_flags |= PPC_PCI_ENABLE_PROC_DOMAINS | PPC_PCI_COMPAT_DOMAIN_0;
>
> + for_each_compatible_node(np, NULL, "ibm,plb-pci") {
> + if (of_device_is_compatible(np, "ibm,plb-pcix"))
> + ppc4xx_probe_pcix_bridge(np);
> #ifdef CONFIG_PPC4xx_PCI_EXPRESS
> - for_each_compatible_node(np, NULL, "ibm,plb-pciex")
> - ppc4xx_probe_pciex_bridge(np);
> + else if (of_device_is_compatible(np, "ibm,plb-pciex"))
> + ppc4xx_probe_pciex_bridge(np);
> #endif
> - for_each_compatible_node(np, NULL, "ibm,plb-pcix")
> - ppc4xx_probe_pcix_bridge(np);
> - for_each_compatible_node(np, NULL, "ibm,plb-pci")
> - ppc4xx_probe_pci_bridge(np);
> + else
> + ppc4xx_probe_pci_bridge(np);
> + }
>
> return 0;
> }
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fix the problem where pcix node is probed again as pci node.
From: Feng Kan
The current matching scheme make the pci node match to pcix or pciex node.
To avoid the match, change the method so only one type of initialization
is called per node.
Signed-off-by: Feng Kan
Signed-off-by: Tirumala R Marri
---
arch/powerpc/sysdev/ppc4xx_pci.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 8aa3302..1e67c74 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1842,14 +1842,16 @@ static int __init ppc4xx_pci_find_bridges(void)
ppc_pci_flags |= PPC_PCI_ENABLE_PROC_DOMAINS | PPC_PCI_COMPAT_DOMAIN_0;
+ for_each_compatible_node(np, NULL, "ibm,plb-pci") {
+ if (of_device_is_compatible(np, "ibm,plb-pcix"))
+ ppc4xx_probe_pcix_bridge(np);
#ifdef CONFIG_PPC4xx_PCI_EXPRESS
- for_each_compatible_node(np, NULL, "ibm,plb-pciex")
- ppc4xx_probe_pciex_bridge(np);
+ else if (of_device_is_compatible(np, "ibm,plb-pciex"))
+ ppc4xx_probe_pciex_bridge(np);
#endif
- for_each_compatible_node(np, NULL, "ibm,plb-pcix")
- ppc4xx_probe_pcix_bridge(np);
- for_each_compatible_node(np, NULL, "ibm,plb-pci")
- ppc4xx_probe_pci_bridge(np);
+ else
+ ppc4xx_probe_pci_bridge(np);
+ }
return 0;
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 04/11] mtd: Add MPC5121 NAND Flash Controller driver
On Tue, 2010-02-09 at 19:42 -0700, Grant Likely wrote: > On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin wrote: > > Adds NAND Flash Controller driver for MPC5121 Revision 2. > > All device features, except hardware ECC and power management, > > are supported. > > > > Signed-off-by: Piotr Ziecik > > Signed-off-by: Wolfgang Denk > > Signed-off-by: Anatolij Gustschin > > Cc: > > Cc: Grant Likely > > Cc: John Rigby > > On *very* brief review... > > Acked-by: Grant Likely > > David, there are ordering issues on this patch with arch-specific > code. If the patch looks okay to you, then can I pick it up into my > tree? Because of the general large response time of the MTD community, I suggest you to go put this stuff to your tree. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down
Roman Fietze wrote: > Hello, > > I think this is a never ending story. This error still happens under > higher load every few seconds, until I get a "PHY: f0003000:00 - Link > is Down", on my box easiliy reproducable after maybe 15 to 30 seconds. > I can recover using "ip link set down/up dev eth0". > > I double checked that I'm using the most recent version of this driver > (checked with DENX, benh master/next, using Wolfgang Denk's version of > the 2.6.33), this includes the locking patches from Asier Llano, the > hard setting of mii_speed in the PHY mdio transfer routine of course. > I tried all 8 combinations of PLDIS, BSDIS and SE, with and without > CONFIG_NOT_COHERENT_CACHE. > > As some of you probably remember, I'm running this controller under > high load on FEC, ATA and LPC. As soon as "the" load is going above a > certain level I get those FEC RFIFO errors, sometimes ATA errors > (MWDMA2) and sometimes even lost SDMA interrupts using BestComm with > the SCLPC (now switched back to simple PIO). I quite sure almost all > of this is the BestComm's fault. This problem shows up quickly with NAPI, but I have never observed it with the current version. The error occurs when the software is not able to readout the messages in time. Unfortunately, dealing with Bestcomm is a pain. > Did somebody already try the latest NAPI patches, which might give me > a slight chance to have a workaround? Any idea or upcoming patch to > address this problem once more, and if it's just by recovering e.g. > within mpc52xx_fec_mdio_transfer's timeout using some other dirty > workaround? Yes, I have a NAPI version ready for testing. I will roll it out as RFC today or tomorrow. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 1/2] PPC64-HWBKPT: Disable interrupts for data breakpoint exceptions
On Tue, Mar 30, 2010 at 04:32:25PM +1100, Benjamin Herrenschmidt wrote: > On Tue, 2010-03-30 at 16:24 +1100, Paul Mackerras wrote: > > On Tue, Mar 23, 2010 at 07:37:02PM +0530, K.Prasad wrote: > > > > > Index: linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > > > === > > > --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/exceptions-64s.S > > > +++ linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > > > @@ -735,6 +735,9 @@ _STATIC(do_hash_page) > > > std r3,_DAR(r1) > > > std r4,_DSISR(r1) > > > > > > + andis. r0,r4,0x0040/* Data Address Breakpoint match? */ > > > > Minor comment: why not dsisr_dabrma...@h instead of 0x0040? > > > > > + bne-handle_dabr_fault > > > + > > > andis. r0,r4,0xa450/* weird error? */ > > > bne-handle_page_fault /* if not, try to insert a HPTE */ > > > BEGIN_FTR_SECTION > > > @@ -823,6 +826,15 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER > > > bl .raw_local_irq_restore > > > b 11f > > I would move your new test to the "weird error" case (ie, after the bne- > handle_page_fault) to avoid hitting the fast path. > Done that...so basically the branch to handle_page_fault will happen only if 0xa410 matches. The changes can be seen here: linuxppc-dev: message-id: 20100330095925.gb14...@in.ibm.com. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 1/2] PPC64-HWBKPT: Disable interrupts for data breakpoint exceptions
On Tue, Mar 30, 2010 at 04:24:42PM +1100, Paul Mackerras wrote: > On Tue, Mar 23, 2010 at 07:37:02PM +0530, K.Prasad wrote: > > > Index: linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > > === > > --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/exceptions-64s.S > > +++ linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > > @@ -735,6 +735,9 @@ _STATIC(do_hash_page) > > std r3,_DAR(r1) > > std r4,_DSISR(r1) > > > > + andis. r0,r4,0x0040/* Data Address Breakpoint match? */ > > Minor comment: why not dsisr_dabrma...@h instead of 0x0040? > Sure...I didn't realise that the upper 16-bits could be extracted as shown aboveI've implemented the suggestion in the next version of the patch sent here: linuxppc-dev message-id:20100330095809.ga14...@in.ibm.com. > > + bne-handle_dabr_fault > > + > > andis. r0,r4,0xa450/* weird error? */ > > bne-handle_page_fault /* if not, try to insert a HPTE */ > > BEGIN_FTR_SECTION > > @@ -823,6 +826,15 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER > > bl .raw_local_irq_restore > > b 11f > > > > +/* We have a data breakpoint exception - handle it */ > > +handle_dabr_fault: > > + /* Populate the pt_regs structure */ > > Another minor comment: that comment isn't accurate since you're not > putting anything in the pt_regs, just getting arguments to do_dabr > from it. > Thanks for pointing it out...it has been removed. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Mon, Mar 29, 2010 at 02:53:36PM -0500, Dave Kleikamp wrote: > On Mon, 2010-03-29 at 17:01 +0530, K.Prasad wrote: > > On Fri, Mar 26, 2010 at 04:11:45PM -0500, Dave Kleikamp wrote: > > > On Tue, 2010-03-23 at 19:37 +0530, K.Prasad wrote: > > > > plain text document attachment (ppc64_hbkpt_02) > > > > Implement perf-events based hw-breakpoint interfaces for PPC64 > > > > processors. > > > > These interfaces help arbitrate requests from various users and > > > > schedules > > > > them as appropriate. > > > > > > > > Signed-off-by: K.Prasad > > > > > > SNIP > > > > > > > Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > > > > === > > > > --- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/cputable.h > > > > +++ linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > > > > @@ -511,6 +511,13 @@ static inline int cpu_has_feature(unsign > > > > & feature); > > > > } > > > > > > > > +#define CPU_FTR_HAS_DABR (defined(CONFIG_PPC64) && \ > > > > + !defined(CONFIG_PPC_ADV_DEBUG_REGS)) > > > > +#ifdef CPU_FTR_HAS_DABR > > > > +/* Number of physical HW breakpoint registers */ > > > > +#define HBP_NUM 1 > > > > +#endif > > > > + > > > > #endif /* !__ASSEMBLY__ */ > > > > > > > > #endif /* __KERNEL__ */ > > > > > > These new defines don't really correlate to the cpu table. One would > > > expect cpu_has_feature(CPU_FTR_HAS_DABR) to have meaning, but it would > > > have to be defined similar to the other CPU_FTR_ constants, and or-ed > > > with CPU_FTRS_ALWAYS (when appropriate). > > > > > [snipped] > > There are a few issues with such an approach: > > i) Two such fields would be required in 'struct cpu_spec' - one for > > instruction breakpoints and other for data. > > ii) As pointed out by you below, hbp_num or num_hw_brkpts would always > > be assigned to the compile time constant HBP_NUM (hence a variable is not > > required to store it). > > iii) HBP_NUM still cannot be entirely removed as it is used by generic > > kernel/hw_breakpoint.c code (and is used by x86 code as well). > > > > I think the simplest approach would be to have the following entry in > > cputable.h (and get away with the rest of the additions seen in patch > > ver XV) > > > > #ifdef CONFIG_PPC_BOOK3S_64 > > #define HBP_NUM 1 > > #endif > > > > The next version of the patch should contain changes to that effect > > (assuming I hear no objections). > > I just don't think this belongs in cputable.h. Why not put this in > hw_breakpoint.h? > HBP_NUM was originally defined in hw_breakpoint.h (until ver XIV) but was moved to cputable.h as it introduces a duplicate definition in processor.h (which is how it is done in the x86 implementation). linux/hw_breakpoint.h inclusion in processor.h, to circumvent the duplication leads to circular dependancies w.r.t. declarations. I think leaving it in cputable.h (as in version XVI of the patch sent here: message-id:20100330095809.ga14...@in.ibm.com) gives us a much cleaner implementation (than x86 which has duplicate HBP_NUM definitions). Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/cputable.h |4
arch/powerpc/include/asm/hw_breakpoint.h | 50
arch/powerpc/include/asm/processor.h |8
arch/powerpc/kernel/Makefile |1
arch/powerpc/kernel/hw_breakpoint.c | 324 +++
arch/powerpc/kernel/machine_kexec_64.c |3
arch/powerpc/kernel/process.c|6
arch/powerpc/kernel/ptrace.c | 81 +++
9 files changed, 478 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,50 @@
+#ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
+#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+#ifdef CONFIG_PPC_BOOK3S_64
+
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target data symbol */
+ int type;
+ unsigned long address;
+};
+
+#include
+#include
+#include
+
+struct perf_event;
+struct pmu;
+struct perf_sample_data;
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
+
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp,
+ struct task_struct *tsk);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk);
+
+extern struct pmu perf_ops_bp;
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else
+static inline void hw_breakpoint_disable(void)
+{
+ /* Function is defined only on PPC_BOOK3S_64 for now */
+}
+#endif /* CONFIG_PPC_BOOK3S_64 */
+#endif /* __KERNEL__ */
+#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,324 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers. Derived from
+ * "arch/x86/kernel/hw_breakpoint.c"
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2009 IBM Corporation
+ * Author: K.Prasad
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/*
+ * Store the 'bp' that caused the hw-breakpoint exception just before we
+ * single-step. Use it to distinguish a single-step exception (due to a
+ * previous hw-breakpoint exception) from a normal one
+ */
+static DEFINE_PER_CPU(struct perf_event *, last_hit_bp);
+
+/*
+ * Stores the breakpoints currently in use on each breakpoint address
+ * register for every cpu
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg);
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg);
+
+ *slot = bp;
+ set_dabr(info->address | info->type | DABR_TRANSLATION);
+ return 0;
+}
+
+/*
+ * Uninstall the breakpoint contained in the given counter.
+ *
+ * First we search the debug address register it uses and then we disable
+ * it.
+ *
+ * Atomi
MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down
Hello, I think this is a never ending story. This error still happens under higher load every few seconds, until I get a "PHY: f0003000:00 - Link is Down", on my box easiliy reproducable after maybe 15 to 30 seconds. I can recover using "ip link set down/up dev eth0". I double checked that I'm using the most recent version of this driver (checked with DENX, benh master/next, using Wolfgang Denk's version of the 2.6.33), this includes the locking patches from Asier Llano, the hard setting of mii_speed in the PHY mdio transfer routine of course. I tried all 8 combinations of PLDIS, BSDIS and SE, with and without CONFIG_NOT_COHERENT_CACHE. As some of you probably remember, I'm running this controller under high load on FEC, ATA and LPC. As soon as "the" load is going above a certain level I get those FEC RFIFO errors, sometimes ATA errors (MWDMA2) and sometimes even lost SDMA interrupts using BestComm with the SCLPC (now switched back to simple PIO). I quite sure almost all of this is the BestComm's fault. Did somebody already try the latest NAPI patches, which might give me a slight chance to have a workaround? Any idea or upcoming patch to address this problem once more, and if it's just by recovering e.g. within mpc52xx_fec_mdio_transfer's timeout using some other dirty workaround? Roman -- Roman FietzeTelemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 1/2] PPC64-HWBKPT: Disable interrupts for data breakpoint exceptions
Data address breakpoint exceptions are currently handled along with page-faults
which require interrupts to remain in enabled state. Since exception handling
for data breakpoints aren't pre-empt safe, we handle them separately.
Signed-off-by: K.Prasad
---
arch/powerpc/kernel/exceptions-64s.S | 13 -
arch/powerpc/mm/fault.c |5 +++--
2 files changed, 15 insertions(+), 3 deletions(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/exceptions-64s.S
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S
@@ -735,8 +735,11 @@ _STATIC(do_hash_page)
std r3,_DAR(r1)
std r4,_DSISR(r1)
- andis. r0,r4,0xa450/* weird error? */
+ andis. r0,r4,0xa410/* weird error? */
bne-handle_page_fault /* if not, try to insert a HPTE */
+ andis. r0,r4,dsisr_dabrma...@h
+ bne-handle_dabr_fault
+
BEGIN_FTR_SECTION
andis. r0,r4,0x0020/* Is it a segment table fault? */
bne-do_ste_alloc/* If so handle it */
@@ -823,6 +826,14 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
bl .raw_local_irq_restore
b 11f
+/* We have a data breakpoint exception - handle it */
+handle_dabr_fault:
+ ld r4,_DAR(r1)
+ ld r5,_DSISR(r1)
+ addir3,r1,STACK_FRAME_OVERHEAD
+ bl .do_dabr
+ b .ret_from_except_lite
+
/* Here we have a page fault that hash_page can't handle. */
handle_page_fault:
ENABLE_INTS
Index: linux-2.6.ppc64_test/arch/powerpc/mm/fault.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/mm/fault.c
+++ linux-2.6.ppc64_test/arch/powerpc/mm/fault.c
@@ -151,13 +151,14 @@ int __kprobes do_page_fault(struct pt_re
if (!user_mode(regs) && (address >= TASK_SIZE))
return SIGSEGV;
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE) || \
+defined(CONFIG_PPC_BOOK3S_64))
if (error_code & DSISR_DABRMATCH) {
/* DABR match */
do_dabr(regs, address, error_code);
return 0;
}
-#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
+#endif
if (in_atomic() || mm == NULL) {
if (!user_mode(regs))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 0/2] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XVI
Hi All, Please find the version XVI of the patches that implement hardware-breakpoint interfaces for PPC64 Server machines (with one DABR). The changes over the previous version are as listed below. Changelog - ver XVI (Version XV: linuxppc-dev ref: 20100323140639.ga21...@in.ibm.com) - Used a new config option CONFIG_PPC_BOOK3S_64 (in lieu of CONFIG_PPC64/CPU_FTR_HAS_DABR) to limit the scope of the new code. - Disabled breakpoints before kexec of the machine using hw_breakpoint_disable(). - Minor optimisation in exception-64s.S to check for data breakpoint exceptions in DSISR finally (after check for other causes) + changes in code comments and representation of DSISR_DABRMATCH constant. - Rebased to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6. Let me know if you have any comments. Thanks, K.Prasad Changelog - ver XV (Version XIV: linuxppc-dev ref: 20100308181232.ga3...@in.ibm.com) - Additional patch to disable interrupts during data breakpoint exception handling. - Moved HBP_NUM definition to cputable.h under a new CPU_FTR definition (CPU_FTR_HAS_DABR). - Filtering of extraneous exceptions (due to accesses outside symbol length) is by-passed for ptrace requests. - Removed flush_ptrace_hw_breakpoint() from __switch_to() due to incorrect coding placement. - Changes to code comments as per community reviews for previous version. - Minor coding-style changes in hw_breakpoint.c as per review comments. - Re-based to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6 Changelog - ver XIV (Version XIII: linuxppc-dev ref: 20100215055605.gb3...@in.ibm.com) - Removed the 'name' field from 'struct arch_hw_breakpoint'. - All callback invocations through bp->overflow_handler() are replaced with perf_bp_event(). - Removed the check for pre-existing single-stepping mode in hw_breakpoint_handler() as this check is unreliable while in kernel-space. Side effect of this change is the non-triggering of hw-breakpoints while single-stepping kernel through KGDB or Xmon. - Minor code-cleanups and addition of comments in hw_breakpoint_handler() and single_step_dabr_instruction(). - Re-based to commit 25cf84cf377c0aae5dbcf937ea89bc7893db5176 of linux-2.6 Changelog - ver XIII (Version XII: linuxppc-dev ref: 20100121084640.ga3...@in.ibm.com) - Fixed a bug for user-space breakpoints (triggered following the failure of a breakpoint request). - Re-based on commit 724e6d3fe8003c3f60bf404bf22e4e331327c596 of linux-2.6 Changelog - ver XII (Version XI: linuxppc-dev ref: 20100119091234.ga9...@in.ibm.com) - Unset MSR_SE only if kernel was not previously in single-step mode. - Pre-emption is now enabled before returning from the hw-breakpoint exception handler. - Variables to track the source of single-step exception (breakpoint from kernel, user-space vs single-stepping due to other requests) are added. - Extraneous hw-breakpoint exceptions (due to memory accesses lying outside monitored symbol length) is now done for both kernel and user-space (previously only user-space). - single_step_dabr_instruction() now returns NOTIFY_DONE if kernel was in single-step mode even before the hw-breakpoint. This enables other users of single-step mode to be notified of the exception. - User-space instructions are not emulated from kernel-space, they are instead single-stepped. Changelog - ver XI -- (Version X: linuxppc-dev ref: 20091211160144.ga23...@in.ibm.com) - Conditionally unset MSR_SE in the single-step handler - Added comments to explain the duration and need for pre-emption disable following hw-breakpoint exception. Changelog - ver X -- - Re-write the PPC64 patches for the new implementation of hw-breakpoints that uses the perf-layer. - Rebased to commit 7622fc234190a37d4e9fe3ed944a2b61a63fca03 of -tip. Changelog - ver IX --- - Invocation of user-defined callback will be 'trigger-after-execute' (except for ptrace). - Creation of a new global per-CPU breakpoint structure to help invocation of user-defined callback from single-step handler. (Changes made now) - Validation before registration will fail only if the address does not match the kernel symbol's (if specified) resolved address (through kallsyms_lookup_name()). - 'symbolsize' value is expected to within the range contained by the symbol's starting address and the end of a double-word boundary (8 Bytes). - PPC64's arch-dependant code is now aware of 'cpumask' in 'struct hw_breakpoint' and can accomodate requests for a subset of CPUs in the system. - Introduced arch_disable_hw_breakpoint() required for _hw_breakpoint() APIs. Changelog - ver VIII --- - Reverting changes to allow one-shot breakpoints only for ptrace requests. - Minor changes in sanity checking in arch_validate_hwbkpt_settings(). - put_cpu_no_resched(
