to synchronize_rcu() makes replacing tables
slower by as much as an order of magnitude.
Revert these patches and fix the issue in a different way.
Signed-off-by: Mark Tomlinson
---
net/ipv4/netfilter/arp_tables.c | 2 +-
net/ipv4/netfilter/ip_tables.c | 2 +-
net/ipv6/netfilter/ip6_tables.c | 2
to synchronize_rcu() makes replacing tables
slower by as much as an order of magnitude.
Prior to using RCU a script calling "iptables" approx. 200 times was
taking 1.16s. With RCU this increased to 11.59s.
Revert these patches and fix the issue in a different way.
Signed-off-by: Mark
), while still
maintaining the same speed of replacing tables.
The smb_mb() barriers potentially slow the packet path, however testing
has shown no measurable change in performance on a 4-core MIPS64
platform.
Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
Signed-of
can be used to ensure ordering of reads/writes. This
can simply be done by changing from smp_wmb() to smp_mb().
changes in v2:
- Update commit messages only
Mark Tomlinson (3):
Revert "netfilter: x_tables: Update remaining dereference to RCU"
Revert "netfilter: x_tables: Switch
On Thu, 2021-03-04 at 08:46 +0100, Florian Westphal wrote:
> Mark Tomlinson wrote:
> > Changing to using smp_mb() instead of smp_wmb() fixes the kernel panic
> > reported in cc00bcaa5899,
>
> Can you reproduce the crashes without this change?
Yes. In our test environment we
to synchronize_rcu() makes replacing tables
slower by as much as an order of magnitude.
See https://lore.kernel.org/patchwork/patch/151796/ for why using RCU is
not a good idea.
Revert these patches and fix the issue in a different way.
Signed-off-by: Mark Tomlinson
---
include/linux/netfilter
the same speed of
replacing tables.
Fixes: 7f5c6d4f665b ("netfilter: get rid of atomic ops in fast path")
Signed-off-by: Mark Tomlinson
---
include/linux/netfilter/x_tables.h | 2 +-
net/netfilter/x_tables.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/inc
to synchronize_rcu() makes replacing tables
slower by as much as an order of magnitude.
See https://lore.kernel.org/patchwork/patch/151796/ for why using RCU is
not a good idea.
Revert these patches and fix the issue in a different way.
Signed-off-by: Mark Tomlinson
---
net/ipv4/netfilter
can be used to ensure ordering of reads/writes. This
can simply be done by changing from smp_wmb() to smp_mb().
Mark Tomlinson (3):
Revert "netfilter: x_tables: Update remaining dereference to RCU"
Revert "netfilter: x_tables: Switch synchronization to RCU"
netfilter: x
pport for Broadcom NSP
SoC")
Signed-off-by: Mark Tomlinson
---
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
index a00a42a61a90..942f04ca4868 100644
---
river")
Signed-off-by: Mark Tomlinson
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index e2bd2dce6bb4..cadcf5eb0466 100644
--- a/drivers/pinctrl/b
If calling mtdoops_write, don't also schedule work to be done later.
Although this appears to not be causing an issue, possibly because the
scheduled work will never get done, it is confusing.
Fixes: 016c1291ce70 ("mtd: mtdoops: do not use mtd->panic_write directly")
Signed
This adds i2c bus recovery to the mv64xxx driver.
Implement bus recovery to recover from SCL/SDA stuck low.
This uses the generic recovery function, setting the clock/data lines as
GPIO pins, and sending 9 clocks to try and recover the bus.
Signed-off-by: Mark Tomlinson
---
Changes in v2
On Tue, 2020-08-25 at 11:26 +0200, Wolfram Sang wrote:
> On Tue, Aug 25, 2020 at 10:52:54AM +1200, Mark Tomlinson wrote:
>
> This adds i2c bus recovery to the mv64xxx driver.
>
> Implement bus recovery to recover from SCL/SDA stuck low.
>
> This uses the generic recov
This adds i2c bus recovery to the mv64xxx driver.
Implement bus recovery to recover from SCL/SDA stuck low.
This uses the generic recovery function, setting the clock/data lines as
GPIO pins, and sending 9 clocks to try and recover the bus.
Signed-off-by: Mark Tomlinson
---
Changes in v2
inner packets, but still defaults to IPv6.
Fixes: 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE
functions")
Signed-off-by: Mark Tomlinson
---
net/ipv6/ip6_tunnel.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_tunnel.c
of warnings. It would be preferable to have a
warning per device, but the pci_dev structure is not available here, and
a lookup from devfn would be far too slow.
Suggested-by: Bjorn Helgaas
Fixes: fb2659230120 ("PCI: Warn on possible RW1C corruption for sub-32 bit
config writes")
Signed-of
watchdog kicks in, and calls
the standard pretimeout function, which can (for example) call panic.
Signed-off-by: Mark Tomlinson
---
drivers/rtc/rtc-ds1307.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc
of warnings. It would be preferable to have a
warning per device, but the pci_dev structure is not available here, and
a lookup from devfn would be far too slow.
Suggested-by: Bjorn Helgaas
Fixes: fb2659230120 ("PCI: Warn on possible RW1C corruption for sub-32 bit
config writes")
Signed-of
The core interrupt code expects the irq_set_affinity call to update the
effective affinity for the interrupt. This was not being done, so update
iproc_msi_irq_set_affinity() to do so.
Fixes: 3bc2b2348835 ("PCI: iproc: Add iProc PCIe MSI support")
Signed-off-by: Mark Tomlinson
---
cha
On Fri, 2020-07-31 at 09:32 -0600, Rob Herring wrote:
>
> If we don't want to just warn when a 8 or 16 bit access occurs (I'm
> not sure if 32-bit only accesses is possible or common. Seems like
> PCI_COMMAND would always get written?), then a simple way to do this
> is just move this out of line
of warnings. It would be preferable to have a
warning per device, but the pci_dev structure is not available here, and
a lookup from devfn would be far too slow.
Suggested-by: Bjorn Helgaas
Fixes: fb2659230120 ("PCI: Warn on possible RW1C corruption for sub-32 bit
config writes")
Signed-of
The core interrupt code expects the irq_set_affinity call to update the
effective affinity for the interrupt. This was not being done, so update
iproc_msi_irq_set_affinity() to do so.
Fixes: 3bc2b2348835 ("PCI: iproc: Add iProc PCIe MSI support")
Signed-off-by: Mark Tomlinson
---
cha
On Thu, 2020-07-30 at 11:09 -0500, Bjorn Helgaas wrote:
> I think it would be better to have a warning once per device, so if
> XYZ device has a problem and we look at the dmesg log, we would find a
> single message for device XYZ as a hint. Would that reduce the
> nuisance level enough?
We
been written for reading/writing the config registers.
Signed-off-by: Mark Tomlinson
---
drivers/pci/controller/pcie-iproc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index 2c836eede42c
The core interrupt code expects the irq_set_affinity call to update the
effective affinity for the interrupt. This was not being done, so update
iproc_msi_irq_set_affinity() to do so.
Signed-off-by: Mark Tomlinson
---
drivers/pci/controller/pcie-iproc-msi.c | 13 +
1 file changed, 9
This makes the read/write functions more generic, allowing them to be
used from other places.
Signed-off-by: Mark Tomlinson
---
drivers/pci/controller/pcie-iproc.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
The function ip6mr_mfc_add() declared an array of ttls. If MAXMIFS is
large, this would create a large stack frame. This is fixed, and made
more efficient, by passing mf6cc_ifset to ip6mr_update_thresholds().
Signed-off-by: Mark Tomlinson
---
As background to this patch, we have MAXMIFS set
This adds i2c bus recovery to the mv64xxx driver.
Implement bus recovery to recover from SCL/SDA stuck low.
This uses the generic recovery function, setting the clock/data lines as
GPIO pins, and sending 9 clocks to try and recover the bus.
Signed-off-by: Mark Tomlinson
---
drivers/i2c/busses
one interrupt instead of all interrupts which are
currently active. Finally there is no need to clear the interrupt during
the interrupt handler, since the edge-triggered handler will do that for
us.
Signed-off-by: Mark Tomlinson
---
Changes in v2:
- Don't perform unnecessary acks.
drivers/pinctrl
On Tue, 2020-06-30 at 15:26 -0700, Ray Jui wrote:
> - u32 trigger_type;
> >
> > - trigger_type = irq_get_trigger_type(d->irq);
> > - if (trigger_type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
> > - nsp_set_bit(chip, REG, NSP_GPIO_EVENT, gpio, val);
> > +
On Tue, 2020-06-30 at 20:14 -0700, Florian Fainelli wrote:
> Sorry, it looks like I made a mistake in my testing (or I was lucky),
> > and this patch doesn't fix the issue. What is happening is:
> > 1) nsp-pinmux driver is registered (arch_initcall).
> > 2) nsp-gpio-a driver is registered
On Tue, 2020-06-30 at 15:08 -0700, Ray Jui wrote:
> May I know which GPIO driver you are referring to on NSP? Both the iProc
> GPIO driver and the NSP GPIO driver are initialized at the level of
> 'arch_initcall_sync', which is supposed to be after 'arch_initcall' used
> here in the pinmux driver
to end users. To fix this, change the time the
pinctrl is probed, so that it is always before the GPIO driver.
Signed-off-by: Mark Tomlinson
---
drivers/pinctrl/bcm/pinctrl-nsp-mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-mux.c
b/drivers
it is edge or level triggered.
Signed-off-by: Mark Tomlinson
---
drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
index bed0124388c0
On Mon, 2020-06-15 at 15:32 +0100, Mark Brown wrote:
> On Mon, Jun 15, 2020 at 04:05:56PM +1200, Mark Tomlinson wrote:
>
> > When needing to send/receive data in small chunks, make this interrupt
> > driven rather than waiting for a completion event for each small section
>
On iProc devices (unlike previous BCM SoCs) the clock rate of the SPI
can be set. This patch adds the appropriate code for setting that.
Reviewed-by: Callum Sinclair
Reviewed-by: Chris Packham
Signed-off-by: Mark Tomlinson
---
drivers/spi/spi-bcm-qspi.c | 34
When needing to send/receive data in small chunks, make this interrupt
driven rather than waiting for a completion event for each small section
of data.
Reviewed-by: Callum Sinclair
Reviewed-by: Chris Packham
Signed-off-by: Mark Tomlinson
---
drivers/spi/spi-bcm-qspi.c | 44
This patch prevents device debug when data is not read from hardware
(i.e. when there is no receive buffer).
Reviewed-by: Callum Sinclair
Reviewed-by: Chris Packham
Signed-off-by: Mark Tomlinson
---
drivers/spi/spi-bcm-qspi.c | 31 ---
1 file changed, 16 insertions
This series of patches came from a single large Broadcom patch that
implements drivers for a number of their integrated switch chips. Mostly
this is just splitting the qspi driver into smaller parts and doesn't
include much original from me.
Mark Tomlinson (5):
spi: bcm-qspi: Add support
Instead of splitting transfers into smaller parts, just perform the
operation that the higher level asked for.
Reviewed-by: Callum Sinclair
Reviewed-by: Chris Packham
Signed-off-by: Mark Tomlinson
---
drivers/spi/spi-bcm-qspi.c | 69 +++---
1 file changed, 27
Acknowledge interrupts correctly and add support for fifo-full
interrupt, distinguishing it from the done interrupt.
Reviewed-by: Callum Sinclair
Reviewed-by: Chris Packham
Signed-off-by: Mark Tomlinson
---
drivers/spi/spi-bcm-qspi.c | 11 ++-
drivers/spi/spi-bcm-qspi.h | 5 -
2
On 27/11/18 11:11 PM, Greg KH wrote:
> On Tue, Nov 27, 2018 at 09:57:23AM +1300, Mark Tomlinson wrote:
>> sysrq_do_reset() is called in softirq context, so it cannot call
>> sync() directly. Instead, call orderly_reboot(), which creates a work
>> item to run /sbin/reboot,
On 27/11/18 11:11 PM, Greg KH wrote:
> On Tue, Nov 27, 2018 at 09:57:23AM +1300, Mark Tomlinson wrote:
>> sysrq_do_reset() is called in softirq context, so it cannot call
>> sync() directly. Instead, call orderly_reboot(), which creates a work
>> item to run /sbin/reboot,
sysrq_do_reset() is called in softirq context, so it cannot call
sync() directly. Instead, call orderly_reboot(), which creates a work
item to run /sbin/reboot, or do emergency_sync and restart if the
command fails.
Signed-off-by: Mark Tomlinson
---
drivers/tty/sysrq.c | 3 +--
1 file changed
sysrq_do_reset() is called in softirq context, so it cannot call
sync() directly. Instead, call orderly_reboot(), which creates a work
item to run /sbin/reboot, or do emergency_sync and restart if the
command fails.
Signed-off-by: Mark Tomlinson
---
drivers/tty/sysrq.c | 3 +--
1 file changed
, but not return anything.
When the lookup occurs after this, the JFFS2 driver will find this
information and can quickly return the filled-in dentry.
Signed-off-by: Mark Tomlinson
---
fs/jffs2/dir.c | 41 +--
fs/namei.c | 63
I have posted this before, but have extended the patch into a few more
functions. The intent of the code is as before -- to improve JFFS2 lookups
by not locking i_mutex for long periods when files are not in cache. For
our embedded environment, we see a *five second* improvement in boot time.
, but not return anything.
When the lookup occurs after this, the JFFS2 driver will find this
information and can quickly return the filled-in dentry.
Signed-off-by: Mark Tomlinson mark.tomlin...@alliedtelesis.co.nz
---
fs/jffs2/dir.c | 41 +--
fs/namei.c | 63
I have posted this before, but have extended the patch into a few more
functions. The intent of the code is as before -- to improve JFFS2 lookups
by not locking i_mutex for long periods when files are not in cache. For
our embedded environment, we see a *five second* improvement in boot time.
50 matches
Mail list logo
