* [LTP] [PATCH][RFC] network: test_net.sh: allow to run tests on a single machine
From: Alexey Kodanev @ 2016-11-14 13:33 UTC (permalink / raw)
To: ltp
When 'TST_USE_NETNS' environment variable is defined, test_net.sh
will setup 'ltp_ns' netns and configure veth pair according to
other LTP network variables. Then, each tst_rhost_run() call will
be executed in the new netns on the same host.
Usage:
TST_USE_NETNS=1... ./network.sh -i
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
---
testcases/lib/test_net.sh | 50 ++++++++++++++++++++++++++++++++++++---------
1 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/testcases/lib/test_net.sh b/testcases/lib/test_net.sh
index dc52d95..67c702b 100644
--- a/testcases/lib/test_net.sh
+++ b/testcases/lib/test_net.sh
@@ -20,6 +20,31 @@
[ -z "$TST_LIB_LOADED" ] && . test.sh
+init_ltp_netspace()
+{
+ if [ ! -f /var/run/netns/ltp_ns ]; then
+ ROD ip net add ltp_ns
+ ROD ip li add name ltp_veth1 type veth peer name ltp_veth2
+ ROD ip li set dev ltp_veth1 netns ltp_ns
+ fi
+
+ LHOST_IFACES=${LHOST_IFACES:-"ltp_ns_veth2"}
+ RHOST_IFACES=${RHOST_IFACES:-"ltp_ns_veth1"}
+
+ export TST_INIT_NETNS="no"
+ export LTP_NETNS=${LTP_NETNS:-"ip netns exec ltp_ns"}
+
+ tst_init_iface
+ tst_init_iface rhost
+
+ tst_add_ipaddr
+ tst_add_ipaddr rhost
+
+ TST_IPV6=6 tst_add_ipaddr
+ TST_IPV6=6 tst_add_ipaddr rhost
+
+}
+
# Run command on remote host.
# Options:
# -b run in background
@@ -67,6 +92,9 @@ tst_rhost_run()
if [ -n "$TST_USE_SSH" ]; then
output=`ssh -n -q $user@$RHOST "sh -c \
'$pre_cmd $cmd $post_cmd'" $out 2>&1 || echo 'RTERR'`
+ elif [ -n "$TST_USE_NETNS" ]; then
+ output=`$LTP_NETNS sh -c \
+ "$pre_cmd $cmd $post_cmd" $out 2>&1 || echo 'RTERR'`
else
output=`rsh -n -l $user $RHOST "sh -c \
'$pre_cmd $cmd $post_cmd'" $out 2>&1 || echo 'RTERR'`
@@ -346,22 +374,14 @@ tst_ping()
}
# Management Link
-[ -z "$RHOST" ] && tst_brkm TBROK "RHOST variable not defined"
+[ -z "$RHOST" -a -z "$TST_USE_NETNS" ] && \
+ tst_brkm TBROK "RHOST variable not defined"
export RHOST="$RHOST"
export PASSWD=${PASSWD:-""}
# Don't use it in new tests, use tst_rhost_run() from test_net.sh instead.
export LTP_RSH=${LTP_RSH:-"rsh -n"}
# Test Links
-# Warning: make sure to set valid interface names and IP addresses below.
-# Set names for test interfaces, e.g. "eth0 eth1"
-export LHOST_IFACES=${LHOST_IFACES:-"eth0"}
-export RHOST_IFACES=${RHOST_IFACES:-"eth0"}
-
-# Set corresponding HW addresses, e.g. "00:00:00:00:00:01 00:00:00:00:00:02"
-export LHOST_HWADDRS=${LHOST_HWADDRS:-"$(tst_get_hwaddrs lhost)"}
-export RHOST_HWADDRS=${RHOST_HWADDRS:-"$(tst_get_hwaddrs rhost)"}
-
# Set first three octets of the network address, default is '10.0.0'
export IPV4_NETWORK=${IPV4_NETWORK:-"10.0.0"}
# Set local host last octet, default is '2'
@@ -408,5 +428,15 @@ export UPLOAD_REGFILESIZE=${UPLOAD_REGFILESIZE:-"1024"}
export MCASTNUM_NORMAL=${MCASTNUM_NORMAL:-"20"}
export MCASTNUM_HEAVY=${MCASTNUM_HEAVY:-"40000"}
+[ -n "$TST_USE_NETNS" -a "$TST_INIT_NETNS" != "no" ] && init_ltp_netspace
+
+# Warning: make sure to set valid interface names and IP addresses below.
+# Set names for test interfaces, e.g. "eth0 eth1"
+export LHOST_IFACES=${LHOST_IFACES:-"eth0"}
+export RHOST_IFACES=${RHOST_IFACES:-"eth0"}
+# Set corresponding HW addresses, e.g. "00:00:00:00:00:01 00:00:00:00:00:02"
+export LHOST_HWADDRS=${LHOST_HWADDRS:-"$(tst_get_hwaddrs lhost)"}
+export RHOST_HWADDRS=${RHOST_HWADDRS:-"$(tst_get_hwaddrs rhost)"}
+
# More information about network parameters can be found
# in the following document: testcases/network/stress/README
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Burton, Ross @ 2016-11-14 13:34 UTC (permalink / raw)
To: Maciej Borzęcki; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAD4b0_LBO_WbaGdaYne7U8KT0QiBb=P5_Th0MjzR24F6px-vXA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 716 bytes --]
On 14 November 2016 at 10:35, Maciej Borzęcki <maciej.borzecki@rndity.com>
wrote:
> Do you think it makes sense to replace TARGET_ARCH check with something
> like this instead:
>
> arch = get_bb_var('HOST_ARCH', 'core-image-minimal')
>
> is_x86 = arch in ['i586', 'i686', 'x86-64']
> if is_x86:
> self.write_config('IMAGE_FSTYPES += " hddimg"\n'
> 'MACHINE_FEATURES_append = " efi"\n')
>
> Basically, I do not want to build syslinux or set config options that
> are usable on x86 target when building for other targets.
>
That expression is more likely to work, yeah, though woudn't TARGET_ be
more suitable than HOST_?
Ross
[-- Attachment #2: Type: text/html, Size: 1266 bytes --]
^ permalink raw reply
* Assalamu`Alaikum.
From: mohammad ouattala @ 2016-11-14 13:27 UTC (permalink / raw)
In-Reply-To: <2146323180.3695752.1479130044876.ref@mail.yahoo.com>
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account,
I will send you more details about this deal and the procedures to follow when I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
^ permalink raw reply
* [PATCH v2 7/9] openrisc: Consolidate setup to use memblock instead of bootmem
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
Clearing out one todo item. Use the memblock boot time memory
which is the current standard.
Signed-off-by: Stafford Horne <shorne@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jonas <jonas@southpole.se>
---
arch/openrisc/Kconfig | 1 +
arch/openrisc/TODO.openrisc | 3 ---
arch/openrisc/include/asm/pgalloc.h | 1 -
arch/openrisc/kernel/setup.c | 36 ++++++++++++------------------------
arch/openrisc/mm/init.c | 2 +-
arch/openrisc/mm/ioremap.c | 4 ----
6 files changed, 14 insertions(+), 33 deletions(-)
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 691e1af..8d22015 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -26,6 +26,7 @@ config OPENRISC
select HAVE_DEBUG_STACKOVERFLOW
select OR1K_PIC
select CPU_NO_EFFICIENT_FFS if !OPENRISC_HAVE_INST_FF1
+ select NO_BOOTMEM
config MMU
def_bool y
diff --git a/arch/openrisc/TODO.openrisc b/arch/openrisc/TODO.openrisc
index acfeef9..0eb04c8 100644
--- a/arch/openrisc/TODO.openrisc
+++ b/arch/openrisc/TODO.openrisc
@@ -5,9 +5,6 @@ that are due for investigation shortly, i.e. our TODO list:
-- Implement the rest of the DMA API... dma_map_sg, etc.
--- Consolidate usage of memblock and bootmem... move everything over to
- memblock.
-
-- Finish the renaming cleanup... there are references to or32 in the code
which was an older name for the architecture. The name we've settled on is
or1k and this change is slowly trickling through the stack. For the time
diff --git a/arch/openrisc/include/asm/pgalloc.h b/arch/openrisc/include/asm/pgalloc.h
index 87eebd1..3e1a466 100644
--- a/arch/openrisc/include/asm/pgalloc.h
+++ b/arch/openrisc/include/asm/pgalloc.h
@@ -23,7 +23,6 @@
#include <linux/threads.h>
#include <linux/mm.h>
#include <linux/memblock.h>
-#include <linux/bootmem.h>
extern int mem_init_done;
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index d2f78cf..6329d7a 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -50,18 +50,16 @@
#include "vmlinux.h"
-static unsigned long __init setup_memory(void)
+static void __init setup_memory(void)
{
- unsigned long bootmap_size;
unsigned long ram_start_pfn;
- unsigned long free_ram_start_pfn;
unsigned long ram_end_pfn;
phys_addr_t memory_start, memory_end;
struct memblock_region *region;
memory_end = memory_start = 0;
- /* Find main memory where is the kernel */
+ /* Find main memory where is the kernel, we assume its the only one */
for_each_memblock(memory, region) {
memory_start = region->base;
memory_end = region->base + region->size;
@@ -74,10 +72,11 @@ static unsigned long __init setup_memory(void)
}
ram_start_pfn = PFN_UP(memory_start);
- /* free_ram_start_pfn is first page after kernel */
- free_ram_start_pfn = PFN_UP(__pa(_end));
ram_end_pfn = PFN_DOWN(memblock_end_of_DRAM());
+ /* setup bootmem globals (we use no_bootmem, but mm still depends on this) */
+ min_low_pfn = ram_start_pfn;
+ max_low_pfn = ram_end_pfn;
max_pfn = ram_end_pfn;
/*
@@ -85,22 +84,13 @@ static unsigned long __init setup_memory(void)
*
* This makes the memory from the end of the kernel to the end of
* RAM usable.
- * init_bootmem sets the global values min_low_pfn, max_low_pfn.
*/
- bootmap_size = init_bootmem(free_ram_start_pfn,
- ram_end_pfn - ram_start_pfn);
- free_bootmem(PFN_PHYS(free_ram_start_pfn),
- (ram_end_pfn - free_ram_start_pfn) << PAGE_SHIFT);
- reserve_bootmem(PFN_PHYS(free_ram_start_pfn), bootmap_size,
- BOOTMEM_DEFAULT);
-
- for_each_memblock(reserved, region) {
- printk(KERN_INFO "Reserved - 0x%08x-0x%08x\n",
- (u32) region->base, (u32) region->size);
- reserve_bootmem(region->base, region->size, BOOTMEM_DEFAULT);
- }
+ memblock_reserve(__pa(_stext), _end - _stext);
+
+ early_init_fdt_reserve_self();
+ early_init_fdt_scan_reserved_mem();
- return ram_end_pfn;
+ memblock_dump_all();
}
struct cpuinfo cpuinfo;
@@ -272,8 +262,6 @@ void calibrate_delay(void)
void __init setup_arch(char **cmdline_p)
{
- unsigned long max_low_pfn;
-
unflatten_and_copy_device_tree();
setup_cpuinfo();
@@ -294,8 +282,8 @@ void __init setup_arch(char **cmdline_p)
initrd_below_start_ok = 1;
#endif
- /* setup bootmem allocator */
- max_low_pfn = setup_memory();
+ /* setup memblock allocator */
+ setup_memory();
/* paging_init() sets up the MMU and marks all pages as reserved */
paging_init();
diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
index b782ce9..f67d82b 100644
--- a/arch/openrisc/mm/init.c
+++ b/arch/openrisc/mm/init.c
@@ -106,7 +106,7 @@ static void __init map_ram(void)
}
/* Alloc one page for holding PTE's... */
- pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
+ pte = (pte_t *) __va(memblock_alloc(PAGE_SIZE, PAGE_SIZE));
set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
/* Fill the newly allocated page with PTE'S */
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index fa60b81..8705a46 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -124,11 +124,7 @@ pte_t __ref *pte_alloc_one_kernel(struct mm_struct *mm,
if (likely(mem_init_done)) {
pte = (pte_t *) __get_free_page(GFP_KERNEL);
} else {
- pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
-#if 0
- /* FIXME: use memblock... */
pte = (pte_t *) __va(memblock_alloc(PAGE_SIZE, PAGE_SIZE));
-#endif
}
if (pte)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/9] openrisc: remove the redundant of_platform_populate
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
From: Rob Herring <robh@kernel.org>
The of_platform_populate call in the openrisc arch code is now redundant
as the DT core provides a default call. Openrisc has a NULL match table
which means only top level nodes with compatible strings will have
devices creates. The default version will also descend nodes in the
match table such as "simple-bus" which should be fine as openrisc
doesn't have any of these (though it is preferred that memory-mapped
peripherals be grouped under a bus node(s)).
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Jonas Bonn <jonas@southpole.se>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/setup.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index b4ed8b3..d2f78cf 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -38,7 +38,6 @@
#include <linux/of.h>
#include <linux/memblock.h>
#include <linux/device.h>
-#include <linux/of_platform.h>
#include <asm/sections.h>
#include <asm/segment.h>
@@ -219,15 +218,6 @@ void __init or32_early_setup(void *fdt)
early_init_devtree(fdt);
}
-static int __init openrisc_device_probe(void)
-{
- of_platform_populate(NULL, NULL, NULL, NULL);
-
- return 0;
-}
-
-device_initcall(openrisc_device_probe);
-
static inline unsigned long extract_value_bits(unsigned long reg,
short bit_nr, short width)
{
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/9] openrisc: Add thread-local storage (TLS) support
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
From: Christian Svensson <blue@cmd.nu>
Historically OpenRISC GCC has reserved r10 which we now use to hold
the thread pointer for thread-local storage (TLS).
Signed-off-by: Christian Svensson <blue@cmd.nu>
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
---
arch/openrisc/kernel/process.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 7095dfe..277123b 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -173,6 +173,19 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
if (usp)
userregs->sp = usp;
+
+ /*
+ * For CLONE_SETTLS set "tp" (r10) to the TLS pointer passed to sys_clone.
+ *
+ * The kernel entry is:
+ * int clone (long flags, void *child_stack, int *parent_tid,
+ * int *child_tid, struct void *tls)
+ *
+ * This makes the source r7 in the kernel registers.
+ */
+ if (clone_flags & CLONE_SETTLS)
+ userregs->gpr[10] = userregs->gpr[7];
+
userregs->gpr[11] = 0; /* Result from fork() */
kregs->gpr[20] = 0; /* Userspace thread */
--
2.7.4
^ permalink raw reply related
* Re: Debugging Ethernet issues
From: Andrew Lunn @ 2016-11-14 13:34 UTC (permalink / raw)
To: Mason
Cc: Florian Fainelli, netdev, Mans Rullgard, Sergei Shtylyov,
Tom Lendacky, Zach Brown, Shaohui Xie, Tim Beale, Brian Hill,
Vince Bridgers, Balakumaran Kannan, David S. Miller,
Sebastian Frias, Kirill Kapranov
In-Reply-To: <5829BBFC.7040800@free.fr>
> How exactly does one use the generic PHY driver?
If there is no specific driver available for the PHY, linux will fall
back to the generic driver. So just don't compile the specific driver.
You can see under /sys/bus/mdio_bus/devices which driver is being
used.
Andrew
^ permalink raw reply
* [PATCH v2 4/9] openrisc: Support both old (or32) and new (or1k) toolchain
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
From: Guenter Roeck <linux@roeck-us.net>
The output file format for or1k has changed from "elf32-or32"
to "elf32-or1k". Select the correct output format automatically
to be able to compile the kernel with both toolchain variants.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/vmlinux.lds.S | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/kernel/vmlinux.lds.S b/arch/openrisc/kernel/vmlinux.lds.S
index d68b9ed..ef31fc2 100644
--- a/arch/openrisc/kernel/vmlinux.lds.S
+++ b/arch/openrisc/kernel/vmlinux.lds.S
@@ -30,7 +30,13 @@
#include <asm/cache.h>
#include <asm-generic/vmlinux.lds.h>
-OUTPUT_FORMAT("elf32-or32", "elf32-or32", "elf32-or32")
+#ifdef __OR1K__
+#define __OUTPUT_FORMAT "elf32-or1k"
+#else
+#define __OUTPUT_FORMAT "elf32-or32"
+#endif
+
+OUTPUT_FORMAT(__OUTPUT_FORMAT, __OUTPUT_FORMAT, __OUTPUT_FORMAT)
jiffies = jiffies_64 + 4;
SECTIONS
--
2.7.4
^ permalink raw reply related
* [PATCH v2 8/9] openrisc: Updates after openrisc.net has been lost
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
The openrisc.net domain expired and was taken over by squatters.
These updates point documentation to the new domain, mailing lists
and git repos.
Also, Jonas is not the main maintainer anylonger, he reviews changes
but does not maintain a repo or sent pull requests. Updating this to
add Stafford and Stefan who are the active maintainers.
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
MAINTAINERS | 6 ++++--
arch/openrisc/README.openrisc | 8 ++++----
arch/openrisc/kernel/setup.c | 2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 851b89b..d84a585 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8958,9 +8958,11 @@ F: drivers/of/resolver.c
OPENRISC ARCHITECTURE
M: Jonas Bonn <jonas@southpole.se>
-W: http://openrisc.net
+M: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
+M: Stafford Horne <shorne@gmail.com>
+L: openrisc@lists.librecores.org
+W: http://openrisc.io
S: Maintained
-T: git git://openrisc.net/~jonas/linux
F: arch/openrisc/
OPENVSWITCH
diff --git a/arch/openrisc/README.openrisc b/arch/openrisc/README.openrisc
index c9f7edf..072069a 100644
--- a/arch/openrisc/README.openrisc
+++ b/arch/openrisc/README.openrisc
@@ -6,7 +6,7 @@ target architecture, specifically, is the 32-bit OpenRISC 1000 family (or1k).
For information about OpenRISC processors and ongoing development:
- website http://openrisc.net
+ website http://openrisc.io
For more information about Linux on OpenRISC, please contact South Pole AB.
@@ -24,17 +24,17 @@ In order to build and run Linux for OpenRISC, you'll need at least a basic
toolchain and, perhaps, the architectural simulator. Steps to get these bits
in place are outlined here.
-1) The toolchain can be obtained from openrisc.net. Instructions for building
+1) The toolchain can be obtained from openrisc.io. Instructions for building
a toolchain can be found at:
-http://openrisc.net/toolchain-build.html
+https://github.com/openrisc/tutorials
2) or1ksim (optional)
or1ksim is the architectural simulator which will allow you to actually run
your OpenRISC Linux kernel if you don't have an OpenRISC processor at hand.
- git clone git://openrisc.net/jonas/or1ksim-svn
+ git clone https://github.com/openrisc/or1ksim.git
cd or1ksim
./configure --prefix=$OPENRISC_PREFIX
diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
index 6329d7a..cb797a3 100644
--- a/arch/openrisc/kernel/setup.c
+++ b/arch/openrisc/kernel/setup.c
@@ -295,7 +295,7 @@ void __init setup_arch(char **cmdline_p)
*cmdline_p = boot_command_line;
- printk(KERN_INFO "OpenRISC Linux -- http://openrisc.net\n");
+ printk(KERN_INFO "OpenRISC Linux -- http://openrisc.io\n");
}
static int show_cpuinfo(struct seq_file *m, void *v)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/2] Salvator-X: Add GPIO keys support
From: Geert Uytterhoeven @ 2016-11-14 13:35 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Linux-Renesas, Kieran Bingham
In-Reply-To: <1479128837-30985-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
On Mon, Nov 14, 2016 at 2:07 PM, Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> This simple series adds GPIO keys support to both the H3- and M3-W-based
> Salvator-X boards. Please see individual patches for details.
Thanks for your series!
The main reason I haven't sent out a similar series yet is because the GPIOs
used for the 3 push buttons are shared with the 3 user LEDs. For each of them,
you have to choose at DT time if you want to use them as buttons or as LEDs.
On ULCB, the same issue is present. For those, we settled on 1 key and 2
LEDs...
Looking forward to more comments...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [U-Boot] [PATCH 4/9] w1: Add 1-Wire gpio driver
From: Maxime Ripard @ 2016-11-14 13:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ0ACi4YX2WZTVp5mVivvULUX9jK3HRA9KeqGQ-e_HibJg@mail.gmail.com>
Hi Simon,
On Fri, Nov 11, 2016 at 09:17:20AM -0700, Simon Glass wrote:
> Hi Maxime,
>
> On 8 November 2016 at 03:06, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Add a bus driver for bitbanging a 1-Wire bus over a GPIO.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/w1/Kconfig | 6 ++-
> > drivers/w1/Makefile | 1 +-
> > drivers/w1/w1-gpio.c | 160 ++++++++++++++++++++++++++++++++++++++++++++-
> > 3 files changed, 167 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/w1/w1-gpio.c
> >
> > diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
> > index 0c056b4c06a9..ccc3ae15db86 100644
> > --- a/drivers/w1/Kconfig
> > +++ b/drivers/w1/Kconfig
> > @@ -12,6 +12,12 @@ config W1
> >
> > if W1
> >
> > +config W1_GPIO
> > + bool "Enable 1-Wire GPIO bitbanging"
> > + depends on DM_GPIO
> > + help
> > + Emulate a 1-Wire bus using a GPIO.
>
> Any more details? How many GPIOs? Any particular chips that are
> supported?
1-Wire works on a single line, hence it's name. You usually have
either a controller (which is quite rare, but some SoCs have one) or
you can bitbang the bus. It's low bandwidth enough that it doesn't
really matter.
I'm not sure if it answers your question. I'll address your other
comments.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/340b8e75/attachment.sig>
^ permalink raw reply
* [PATCH v2 9/9] openrisc: include l.swa in check for write data pagefault
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
During page fault handling we check the last instruction to understand
if the fault was for a read or for a write. By default we fall back to
read. New instructions were added to the openrisc 1.1 spec for an
atomic load/store pair (l.lwa/l.swa).
This patch adds the opcode for l.swa (0x33) allowing it to be treated as
a write operation.
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
[shorne@gmail.com: expanded a bit on the comment]
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/entry.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
index 572d223..aac0bde 100644
--- a/arch/openrisc/kernel/entry.S
+++ b/arch/openrisc/kernel/entry.S
@@ -264,7 +264,7 @@ EXCEPTION_ENTRY(_data_page_fault_handler)
l.srli r6,r6,26 // check opcode for write access
#endif
- l.sfgeui r6,0x34 // check opcode for write access
+ l.sfgeui r6,0x33 // check opcode for write access
l.bnf 1f
l.sfleui r6,0x37
l.bnf 1f
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/9] openrisc: fix PTRS_PER_PGD define
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
On OpenRISC, with its 8k pages, PAGE_SHIFT is defined to be 13.
That makes the expression (1UL << (PAGE_SHIFT-2)) evaluate
to 2048.
The correct value for PTRS_PER_PGD should be 256.
Correcting the PTRS_PER_PGD define unveiled a bug in map_ram(),
where PTRS_PER_PGD was used when the intent was to iterate
over a set of page table entries.
This patch corrects that issue as well.
Signed-off-by: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Acked-by: Jonas Bonn <jonas@southpole.se>
Tested-by: Guenter Roeck <linux@roeck-us.net>
---
arch/openrisc/include/asm/pgtable.h | 2 +-
arch/openrisc/mm/init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/openrisc/include/asm/pgtable.h b/arch/openrisc/include/asm/pgtable.h
index 69c7df0..3567aa7 100644
--- a/arch/openrisc/include/asm/pgtable.h
+++ b/arch/openrisc/include/asm/pgtable.h
@@ -69,7 +69,7 @@ extern void paging_init(void);
*/
#define PTRS_PER_PTE (1UL << (PAGE_SHIFT-2))
-#define PTRS_PER_PGD (1UL << (PAGE_SHIFT-2))
+#define PTRS_PER_PGD (1UL << (32-PGDIR_SHIFT))
/* calculate how many PGD entries a user-level program can use
* the first mappable virtual address is 0
diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
index 7f94652..b782ce9 100644
--- a/arch/openrisc/mm/init.c
+++ b/arch/openrisc/mm/init.c
@@ -110,7 +110,7 @@ static void __init map_ram(void)
set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
/* Fill the newly allocated page with PTE'S */
- for (j = 0; p < e && j < PTRS_PER_PGD;
+ for (j = 0; p < e && j < PTRS_PER_PTE;
v += PAGE_SIZE, p += PAGE_SIZE, j++, pte++) {
if (v >= (u32) _e_kernel_ro ||
v < (u32) _s_kernel_ro)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/9] openrisc: restore all regs on rt_sigreturn
From: Stafford Horne @ 2016-11-14 13:30 UTC (permalink / raw)
To: stefan.kristiansson, shorne, jonas
Cc: linux, blue, robh, linux-kernel, openrisc
In-Reply-To: <cover.1479128947.git.shorne@gmail.com>
From: Jonas Bonn <jonas@southpole.se>
Fix signal handling for when signals are handled as the result of timers
or exceptions, previous code assumed syscalls. This was noticeable with X
crashing where it uses SIGALRM.
This patch restores all regs before returning to userspace via
_resume_userspace instead of via syscall return path.
The rt_sigreturn syscall is more like a context switch than a function
call; it entails a return from one context (the signal handler) to another
(the process in question). For a context switch like this there are
effectively no call-saved regs that remain constant across the transition.
Reported-by: Sebastian Macke <sebastian@macke.de>
Signed-off-by: Jonas Bonn <jonas@southpole.se>
Tested-by: Guenter Roeck <linux@roeck-us.net>
[shorne@gmail.com: Updated comment better reflect change and issue]
Signed-off-by: Stafford Horne <shorne@gmail.com>
---
arch/openrisc/kernel/entry.S | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/openrisc/kernel/entry.S b/arch/openrisc/kernel/entry.S
index fec8bf9..572d223 100644
--- a/arch/openrisc/kernel/entry.S
+++ b/arch/openrisc/kernel/entry.S
@@ -1101,8 +1101,16 @@ ENTRY(__sys_fork)
l.addi r3,r1,0
ENTRY(sys_rt_sigreturn)
- l.j _sys_rt_sigreturn
+ l.jal _sys_rt_sigreturn
l.addi r3,r1,0
+ l.sfne r30,r0
+ l.bnf _no_syscall_trace
+ l.nop
+ l.jal do_syscall_trace_leave
+ l.addi r3,r1,0
+_no_syscall_trace:
+ l.j _resume_userspace
+ l.nop
/* This is a catch-all syscall for atomic instructions for the OpenRISC 1000.
* The functions takes a variable number of parameters depending on which
--
2.7.4
^ permalink raw reply related
* [PATCHv2 1/2] net: arc_emac: annonce IFF_MULTICAST support
From: Alexander Kochetkov @ 2016-11-14 13:32 UTC (permalink / raw)
To: netdev, linux-kernel, davem, tremyfr, peter.chen, wxt, weiyj.lk
Cc: Alexander Kochetkov
In-Reply-To: <1479129627-27524-2-git-send-email-al.kochet@gmail.com>
Multicast support was implemented by commit 775dd682e2b0ec7
('arc_emac: implement promiscuous mode and multicast filtering').
It can be enabled explicity using 'ifconfig eth0 multicast'.
The patch is needed in order to remove explicit configuration
as most devices has multicast mode enabled by default.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
Changes in v2:
Add Signed-off-by text.
drivers/net/ethernet/arc/emac_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index b0da969..2e4ee86 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -764,8 +764,6 @@ int arc_emac_probe(struct net_device *ndev, int interface)
ndev->netdev_ops = &arc_emac_netdev_ops;
ndev->ethtool_ops = &arc_emac_ethtool_ops;
ndev->watchdog_timeo = TX_TIMEOUT;
- /* FIXME :: no multicast support yet */
- ndev->flags &= ~IFF_MULTICAST;
priv = netdev_priv(ndev);
priv->dev = dev;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 2/2] net: arc_emac: don't pass multicast packets to kernel in non-multicast mode
From: Alexander Kochetkov @ 2016-11-14 13:32 UTC (permalink / raw)
To: netdev, linux-kernel, davem, tremyfr, peter.chen, wxt, weiyj.lk
Cc: Alexander Kochetkov
In-Reply-To: <1479130373-28077-1-git-send-email-al.kochet@gmail.com>
The patch disable capturing multicast packets when multicast mode
disabled for ethernet ('ifconfig eth0 -multicast'). In that case
no multicast packet will be passed to kernel.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
Changes in v2:
Add Signed-off-by text.
Removed deleted line from patch.
drivers/net/ethernet/arc/emac_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 2e4ee86..be865b4 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -460,7 +460,7 @@ static void arc_emac_set_rx_mode(struct net_device *ndev)
if (ndev->flags & IFF_ALLMULTI) {
arc_reg_set(priv, R_LAFL, ~0);
arc_reg_set(priv, R_LAFH, ~0);
- } else {
+ } else if (ndev->flags & IFF_MULTICAST) {
struct netdev_hw_addr *ha;
unsigned int filter[2] = { 0, 0 };
int bit;
@@ -472,6 +472,9 @@ static void arc_emac_set_rx_mode(struct net_device *ndev)
arc_reg_set(priv, R_LAFL, filter[0]);
arc_reg_set(priv, R_LAFH, filter[1]);
+ } else {
+ arc_reg_set(priv, R_LAFL, 0);
+ arc_reg_set(priv, R_LAFH, 0);
}
}
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next v2 1/5] ethtool: (uapi) Add ETHTOOL_PHY_GTUNABLE and ETHTOOL_PHY_STUNABLE
From: Andrew Lunn @ 2016-11-14 13:36 UTC (permalink / raw)
To: Allan W. Nielsen; +Cc: netdev, raju.lakkaraju
In-Reply-To: <1479115760-1182-2-git-send-email-allan.nielsen@microsemi.com>
On Mon, Nov 14, 2016 at 10:29:16AM +0100, Allan W. Nielsen wrote:
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> Defines a generic API to get/set phy tunables. The API is using the
> existing ethtool_tunable/tunable_type_id types which is already being used
> for mac level tunables.
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] [media] gp8psk-fe: add missing MODULE_foo() macros
From: Paul Bolle @ 2016-11-14 13:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20161114111437.29317cdb@vento.lan>
On Mon, 2016-11-14 at 11:14 -0200, Mauro Carvalho Chehab wrote:
> --- a/drivers/media/dvb-frontends/gp8psk-fe.c
> +++ b/drivers/media/dvb-frontends/gp8psk-fe.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, version 2.
> +MODULE_LICENSE("GPL");
Nit: according to the comments in include/linux/module.h the "ident" that
matches the license described at the top of this file is "GPL v2".
Paul Bolle
^ permalink raw reply
* Re: [RFC 06/14] SoundWire: Add register/unregister APIs
From: Mark Brown @ 2016-11-14 13:37 UTC (permalink / raw)
To: Hardik Shah
Cc: alsa-devel, linux-kernel, tiwai, pierre-louis.bossart, lgirdwood,
plai, patches.audio, Sanyog Kale
In-Reply-To: <1477053673-16021-7-git-send-email-hardik.t.shah@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]
On Fri, Oct 21, 2016 at 06:11:04PM +0530, Hardik Shah wrote:
> +static void sdw_mstr_release(struct device *dev)
> +{
> + struct sdw_master *mstr = to_sdw_master(dev);
> +
> + complete(&mstr->slv_released_complete);
> +}
Other buses don't do this... this is a big warning sign that you're
abusing the driver model.
> +/**
> + * sdw_slv_verify - return parameter as sdw_slave, or NULL
> + * @dev: device, probably from some driver model iterator
> + *
> + * When traversing the driver model tree, perhaps using driver model
> + * iterators like @device_for_each_child(), you can't assume very much
> + * about the nodes you find. Use this function to avoid oopses caused
> + * by wrongly treating some non-SDW device as an sdw_slave.
> + */
This is also *very* scary, especially given that there's no analysis
presented as to why there might be random other things on the bus. Why
does SoundWire need this when other buses don't?
> +static struct sdw_slave *sdw_slv_verify(struct device *dev)
> +{
> + return (dev->type == &sdw_slv_type)
> + ? to_sdw_slave(dev)
> + : NULL;
This is needlessly obfuscated, if you want to write an if statement
write an if statement.
> +static int sdw_slv_match(struct device *dev, struct device_driver *driver)
> +{
> + struct sdw_slave *sdw_slv;
> + struct sdw_driver *sdw_drv = to_sdw_driver(driver);
> + struct sdw_slave_driver *drv;
> + int ret = 0;
> +
> +
> + if (sdw_drv->driver_type != SDW_DRIVER_TYPE_SLAVE)
> + return ret;
Why do we need a check like this?
> +static int sdw_mstr_probe(struct device *dev)
> +{
> + const struct sdw_master_driver *sdrv =
> + to_sdw_master_driver(dev->driver);
> + struct sdw_master *mstr = to_sdw_master(dev);
> + int ret;
> +
> + ret = dev_pm_domain_attach(dev, true);
> +
> + if (ret != -EPROBE_DEFER) {
> + ret = sdrv->probe(mstr, sdw_match_mstr(sdrv->id_table, mstr));
> + if (ret < 0)
> + dev_pm_domain_detach(dev, true);
> + }
This looks *very* broken. Surely if we fail to attach a pm_domain for
any reason other than one not being there to attach we shouldn't be
trying to probe the device?
> +EXPORT_SYMBOL_GPL(snd_sdw_master_register_driver);
This is EXPORT_SYMBOL_GPL() but the bus itself is dual licensed GPL/BSD
- seems a bit inconsistent.
> +/**
> + * snd_sdw_master_add: Registers the SoundWire Master interface. This needs
> + * to be called for each Master interface supported by SoC. This
> + * represents One clock and data line (Optionally multiple data lanes)
> + * of Master interface.
> + *
> + * @master: the Master to be added.
> + */
> +int snd_sdw_master_add(struct sdw_master *master)
This lies at the heart of the issues that seem to exist with the misuse
of the driver model in this code. Normally what we see is that the
controller would instantiate as whatever bus type the controller is
attached by (typically a PCI or platform device) and then it wouild
register a bus with the bus subsystem which would then instantiate
slaves. Instead we have this system where the bus is registered by
something in the system and then the master is a driver on the bus
parallel to the slaves but with a separate driver type that causes
confusion. Without having seen a master driver it's not even clear how
this is going to work and allow the master to talk to its own hardware.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH 2/2] ARM: rename is_smp()
From: Russell King - ARM Linux @ 2016-11-14 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878tsmchyc.fsf@free-electrons.com>
On Mon, Nov 14, 2016 at 02:24:43PM +0100, Gregory CLEMENT wrote:
> Hi Russell,
>
> Unless I am wrong I don't see any modification of the code behavior:
> just renaming the function and adding more comments. So it won't affect
> our platform and I am OK with the new name which also match our
> comments.
That's correct - it's an exercise in renaming to a clearer name.
Thanks for the ack.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: libdbus-c++
From: Burton, Ross @ 2016-11-14 13:38 UTC (permalink / raw)
To: thilo.cestonaro@ts.fujitsu.com; +Cc: openembedded-core@lists.openembedded.org
In-Reply-To: <1479130386.8647.5.camel@ts.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On 14 November 2016 at 13:33, thilo.cestonaro@ts.fujitsu.com <
thilo.cestonaro@ts.fujitsu.com> wrote:
> Yeah I propably can and will be if I need to write my own. But the funny
> thing is, that there ones was a meta-oe dbus-c++ recipe and this was
> removed with the comment, that it didn't work and it's
> better to use the one from oe-core :)
> http://lists.openembedded.org/pipermail/openembedded-devel/
> 2011-August/079834.html
>
> So I just wanted to make sure, that none exists.
>
That's strange, I can't find any dbus-c++ in oe-core's history. Maybe the
submitter was referring to plain libdbus or something else?
Ross
[-- Attachment #2: Type: text/html, Size: 1274 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH RESEND 5/9] EEPROM: Add an EEPROM uclass
From: Maxime Ripard @ 2016-11-14 13:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAAtXAHdjn6O-AF639KyRMpMiZ-36uQ4LbfONCa8Xp96KX5Ao0g@mail.gmail.com>
Hi Moritz,
On Fri, Nov 11, 2016 at 11:13:39AM -0800, Moritz Fischer wrote:
> Hi Maxime,
>
> On Fri, Nov 11, 2016 at 8:17 AM, Simon Glass <sjg@chromium.org> wrote:
> > Hi Maxime,
> >
> > On 8 November 2016 at 03:19, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> >> We might want to access data stored onto EEPROMs. Create a framework to
> >> provide a consistent API.
> >
> > We have UCLASS_I2C_EEPROM. Can we unify these? If not, please add a
> > sandbox driver and test.
>
> I've been working on something very similar (the API looks the same obviously,
> since the ops are pretty trivial, modulo function names)
> In my opinion it should be working as follows:
>
> UCLASS_EEPROM
> \... I2C_EEPROM
> \....SPI_EEPROM (AT25)
I agree. Different board variations might be using different buses to
store the same data, and it's all EEPROM anyway.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/b782892c/attachment.sig>
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] ethtool: Implements ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE
From: Andrew Lunn @ 2016-11-14 13:40 UTC (permalink / raw)
To: Allan W. Nielsen; +Cc: netdev, raju.lakkaraju
In-Reply-To: <1479115760-1182-3-git-send-email-allan.nielsen@microsemi.com>
On Mon, Nov 14, 2016 at 10:29:17AM +0100, Allan W. Nielsen wrote:
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> Adding get_tunable/set_tunable function pointer to the phy_driver
> structure, and uses these function pointers to implement the
> ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE ioctls.
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] ARM: ftrace: fix syscall name matching
From: Russell King - ARM Linux @ 2016-11-14 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479128625-20948-1-git-send-email-rabin.vincent@axis.com>
On Mon, Nov 14, 2016 at 02:03:45PM +0100, Rabin Vincent wrote:
> From: Rabin Vincent <rabinv@axis.com>
>
> ARM has a few system calls (most notably mmap) for which the names of
> the functions which are referenced in the syscall table do not match the
> names of the syscall tracepoints. As a consequence of this, these
> tracepoints are not made available. Implement
> arch_syscall_match_sym_name to fix this and allow tracing even these
> system calls.
>
> Signed-off-by: Rabin Vincent <rabinv@axis.com>
> ---
> arch/arm/include/asm/ftrace.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> index bfe2a2f..8467909 100644
> --- a/arch/arm/include/asm/ftrace.h
> +++ b/arch/arm/include/asm/ftrace.h
> @@ -54,6 +54,27 @@ static inline void *return_address(unsigned int level)
>
> #define ftrace_return_address(n) return_address(n)
>
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +
> +static inline bool arch_syscall_match_sym_name(const char *sym,
> + const char *name)
> +{
> + /* Skip sys_ */
> + sym += 4;
> + name += 4;
Is this really safe? What guarantees that we can wind forward four
bytes here? If it's always safe, it needs a better comment than just
two words.
> +
> + if (!strcmp(sym, "mmap2"))
> + sym = "mmap_pgoff";
> + else if (!strcmp(sym, "statfs64_wrapper"))
> + sym = "statfs64";
> + else if (!strcmp(sym, "fstatfs64_wrapper"))
> + sym = "fstatfs64";
> + else if (!strcmp(sym, "arm_fadvise64_64"))
> + sym = "fadvise64_64";
> +
> + return !strcmp(sym, name);
> +}
> +
> #endif /* ifndef __ASSEMBLY__ */
>
> #endif /* _ASM_ARM_FTRACE */
> --
> 2.1.4
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH] ARM: ftrace: fix syscall name matching
From: Russell King - ARM Linux @ 2016-11-14 13:40 UTC (permalink / raw)
To: Rabin Vincent; +Cc: rostedt, linux-arm-kernel, linux-kernel, Rabin Vincent
In-Reply-To: <1479128625-20948-1-git-send-email-rabin.vincent@axis.com>
On Mon, Nov 14, 2016 at 02:03:45PM +0100, Rabin Vincent wrote:
> From: Rabin Vincent <rabinv@axis.com>
>
> ARM has a few system calls (most notably mmap) for which the names of
> the functions which are referenced in the syscall table do not match the
> names of the syscall tracepoints. As a consequence of this, these
> tracepoints are not made available. Implement
> arch_syscall_match_sym_name to fix this and allow tracing even these
> system calls.
>
> Signed-off-by: Rabin Vincent <rabinv@axis.com>
> ---
> arch/arm/include/asm/ftrace.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> index bfe2a2f..8467909 100644
> --- a/arch/arm/include/asm/ftrace.h
> +++ b/arch/arm/include/asm/ftrace.h
> @@ -54,6 +54,27 @@ static inline void *return_address(unsigned int level)
>
> #define ftrace_return_address(n) return_address(n)
>
> +#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
> +
> +static inline bool arch_syscall_match_sym_name(const char *sym,
> + const char *name)
> +{
> + /* Skip sys_ */
> + sym += 4;
> + name += 4;
Is this really safe? What guarantees that we can wind forward four
bytes here? If it's always safe, it needs a better comment than just
two words.
> +
> + if (!strcmp(sym, "mmap2"))
> + sym = "mmap_pgoff";
> + else if (!strcmp(sym, "statfs64_wrapper"))
> + sym = "statfs64";
> + else if (!strcmp(sym, "fstatfs64_wrapper"))
> + sym = "fstatfs64";
> + else if (!strcmp(sym, "arm_fadvise64_64"))
> + sym = "fadvise64_64";
> +
> + return !strcmp(sym, name);
> +}
> +
> #endif /* ifndef __ASSEMBLY__ */
>
> #endif /* _ASM_ARM_FTRACE */
> --
> 2.1.4
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.