Re: [PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets
Hi Anoob, [auto build test ERROR on v4.9-rc8] [also build test ERROR on next-20170519] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Anoob-Soman/openvswitch-clear-sender-cpu-before-forwarding-packets/20170519-111009 config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): net/openvswitch/vport.c: In function 'ovs_vport_send': >> net/openvswitch/vport.c:513:2: error: implicit declaration of function >> 'skb_sender_cpu_clear' [-Werror=implicit-function-declaration] skb_sender_cpu_clear(skb); ^~~~ cc1: some warnings being treated as errors vim +/skb_sender_cpu_clear +513 net/openvswitch/vport.c 507 packet_length(skb), mtu); 508 vport->dev->stats.tx_errors++; 509 goto drop; 510 } 511 512 skb->dev = vport->dev; > 513 skb_sender_cpu_clear(skb); 514 vport->ops->send(skb); 515 return; 516 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] rcu: mark debug_lockdep_rcu_enabled() as pure
On 20.05.2017 19:42, Paul E. McKenney wrote:
On Fri, May 19, 2017 at 10:03:59AM +0300, Konstantin Khlebnikov wrote:
This allows to get rid of unneeded invocations.
Function debug_lockdep_rcu_enabled() becomes really hot if several
debug options are enabled together with CONFIG_PROVE_RCU.
Hottest path ends with:
debug_lockdep_rcu_enabled
is_ftrace_trampoline
__kernel_text_address
Here debug_lockdep_rcu_enabled() is called from condition
(debug_lockdep_rcu_enabled() && !__warned && (c)) inside macro
do_for_each_ftrace_op(), where "c" is false.
With this patch "netperf -H localhost" shows boost from 2400 to 2500.
Signed-off-by: Konstantin Khlebnikov
Nice performance increase!
The gcc documentation says that __attribute__((pure)) functions are
supposed to have return values that depend only at the function's
arguments and the values of global variables. However, it also says:
Interesting non-pure functions are functions with infinite loops
or those depending on volatile memory or other system resource,
that may change between two consecutive calls (such as feof in
a multithreading environment).
This is OK for current->lockdep_recursion because this variable is changed
only by the current task (I think so, anyway).
It is sort of OK for debug_locks. This could be set to zero at any time
by any other task, but if we have a race condition that very rarely causes
two lockdep splats instead of just one, so what? (But I am sure that
some of the people on CC will correct me if I am wrong here.)
It should be OK for rcu_scheduler_active because the transition from
RCU_SCHEDULER_INACTIVE to RCU_SCHEDULER_INIT happens before the first
context switch, and the various barrier() calls, implied as well as
explicit, should keep things straight.
But I don't totally trust my analysis. Could you please get someone
more gcc-savvy to review this and give their ack/review? Given that,
I will queue it.
Thanx, Paul
Thank you for analisys.
__attribute__((pure)) allows compiler to deduplicate / eliminate calls.
This indeed might expand race windows when global switches like debug_locks
changes their state. But strict synchronization here isn't required.
---
include/linux/rcupdate.h |2 +-
kernel/rcu/update.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index e1e5d002fdb9..9ecb3cb715bd 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -472,7 +472,7 @@ extern struct lockdep_map rcu_lock_map;
extern struct lockdep_map rcu_bh_lock_map;
extern struct lockdep_map rcu_sched_lock_map;
extern struct lockdep_map rcu_callback_map;
-int debug_lockdep_rcu_enabled(void);
+int __pure debug_lockdep_rcu_enabled(void);
int rcu_read_lock_held(void);
int rcu_read_lock_bh_held(void);
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 273e869ca21d..a0c30abefdcd 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -292,7 +292,7 @@ struct lockdep_map rcu_callback_map =
STATIC_LOCKDEP_MAP_INIT("rcu_callback", _callback_key);
EXPORT_SYMBOL_GPL(rcu_callback_map);
-int notrace debug_lockdep_rcu_enabled(void)
+int __pure notrace debug_lockdep_rcu_enabled(void)
{
return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && debug_locks &&
current->lockdep_recursion == 0;
[PATCH] sysfs: remove signedness from sysfs_get_dirent
sysfs_get_dirent is usually invoked with a string literal, which
have the type char[]. While the toplevel Makefile
disables -Wpointer-sign, other Makefiles like
arch/x86/boot/compressed/Makefile
redefine KBUILD_CFLAGS. Fixes the warning:
In file included from arch/x86/boot/compressed/kaslr.c:17:
In file included from ./include/linux/module.h:17:
In file included from ./include/linux/kobject.h:21:
./include/linux/sysfs.h:517:37: warning: passing 'const unsigned char *'
to parameter of
type 'const char *' converts between pointers to integer types
with different sign
[-Wpointer-sign]
return kernfs_find_and_get(parent, name);
^~~~
./include/linux/kernfs.h:462:57: note: passing argument to parameter
'name' here
kernfs_find_and_get(struct kernfs_node *kn, const char *name)
^
Signed-off-by: Nick Desaulniers
---
Alternatively, maybe
KBUILD_CFLAGS += $(call cc-disable-warning, pointer-sign)
should be added elsewhere like
arch/x86/boot/compressed/Makefile
include/linux/sysfs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index c6f0f0d0e17e..7481fb72d927 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -512,7 +512,7 @@ static inline void sysfs_notify_dirent(struct kernfs_node
*kn)
}
static inline struct kernfs_node *sysfs_get_dirent(struct kernfs_node *parent,
- const unsigned char *name)
+ const char *name)
{
return kernfs_find_and_get(parent, name);
}
--
2.11.0
is alpha jensen support dead?
Hi all, it seems like the Alpha Jense build (the only one using pci-noop.c) and thus being a different build than all the later PCI capable system has been broken since at least: commit 6aca0503847f6329460b15b3ab2b0e30bb752793 Author: Christian Borntraeger Date: Tue Feb 2 21:46:33 2016 -0800 alpha/dma: use common noop dma ops which switches pci-noop.c to use generic code, but fat fingered a symbol and didn't wire up the Kconfig. Is there any value in keeping it alive? Especially as there probably isn't any build coverage.. Btw, how well is alpha working these days? It looks like there hasn't been any maintainer activity for about two years.
[PATCH] PCI: fix whitespace in printk() to align log entries
Remove the space character between "PCI" and the colon. This was printed before the patch: PCI : PCI BIOS area is rw and x. Use pci=nobios if you want it NX. Whereas other PCI printks are like that: $ dmesg | grep 'PCI:' [0.649178] PCI: MMCONFIG for domain [bus 00-7f] at [mem 0xf000-0xf7ff] (base 0xf000) [0.649180] PCI: MMCONFIG at [mem 0xf000-0xf7ff] reserved in E820 [0.649186] PCI: Using configuration type 1 for base access [0.676407] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [0.784009] PCI: Using ACPI for IRQ routing [0.795599] PCI: pci_cache_line_size set to 64 bytes [0.811154] PCI: CLS 0 bytes, default 64 Signed-off-by: Vincent Legoll --- arch/x86/pci/pcbios.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/pci/pcbios.c b/arch/x86/pci/pcbios.c index c1bdb9e..7659540 100644 --- a/arch/x86/pci/pcbios.c +++ b/arch/x86/pci/pcbios.c @@ -46,7 +46,7 @@ static inline void set_bios_x(void) pcibios_enabled = 1; set_memory_x(PAGE_OFFSET + BIOS_BEGIN, (BIOS_END - BIOS_BEGIN) >> PAGE_SHIFT); if (__supported_pte_mask & _PAGE_NX) - printk(KERN_INFO "PCI : PCI BIOS area is rw and x. Use pci=nobios if you want it NX.\n"); + printk(KERN_INFO "PCI: PCI BIOS area is rw and x. Use pci=nobios if you want it NX.\n"); } /* -- 2.7.4
Re: [PATCH] kconfig: Check for libncurses before menuconfig
Hi Borislav, 2017-05-21 5:33 GMT+09:00 Borislav Petkov : > On Sun, May 21, 2017 at 04:38:35AM +0900, Masahiro Yamada wrote: >> Strange, I could not reproduce this. > > Remove libncurses5-dev or whatever it is called on your system and do: > > $ make menuconfig > HOSTCC scripts/kconfig/mconf.o > In file included from scripts/kconfig/mconf.c:23:0: > scripts/kconfig/lxdialog/dialog.h:38:20: fatal error: curses.h: No such file > or directory > #include CURSES_LOC > ^ > compilation terminated. > scripts/Makefile.host:124: recipe for target 'scripts/kconfig/mconf.o' failed > make[1]: *** [scripts/kconfig/mconf.o] Error 1 > Makefile:548: recipe for target 'menuconfig' failed > make: *** [menuconfig] Error 2 OK, I see. So, it is $(obj)/mconf.o instead of $(obj)/mconf that should depend on $(obj)/dochecklxdialog. Could you change line 199 $(addprefix $(obj)/,$(lxdialog)): $(obj)/dochecklxdialog to $(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog and send v2, please? This will make sure dochecklxdialog is run before compiling mconf.o in parallel building. Thanks! -- Best Regards Masahiro Yamada
Re: [PATCH v3 3/3] arm/arm64: signal SIBGUS and inject SEA Error
2017-05-13 1:25 GMT+08:00, James Morse : > Hi gengdongjiu, > > On 10/05/17 09:44, gengdongjiu wrote: >> On 2017/5/9 1:28, James Morse wrote: > (hwpoison for KVM is a corner case as Qemu's memory effectively has two > users, > Qemu and KVM. This isn't the example of how user-space gets > signalled.) >>> >>> KVM creates guests as if they were additional users of Qemu's memory. The >>> code >>> in mm/memory-failure.c may find that Qemu didn't have the affected page >>> mapped >>> to user-space - but it may have been in use by stage2. >>> >>> The KVM+SIGBUS patch hides this difference, meaning Qemu gets a signal >>> when the >>> guest touches the hwpoison page as if Qemu had touched the page itself. >>> >>> Signals from KVM is a corner case, for firmware-first decisions should >>> happen in >>> the APEI code based on CPER records. > If so, how the KVM handle the SEA type other than hwpoison? > >>> To deliver to a guest? It shouldn't have to know, user space should use a >>> KVM >>> API to drive this. >>> >>> When received from hardware? It shouldn't have to care, these things >>> should be >>> passed into the APEI code for handling. KVM just needs to put the host >>> registers >>> back. > >> Recently I confirmed with the hardware team. they said almost all the SEA >> errors have the >> Poison flag, so may be there is no need to consider other SEA errors other >> than hwPoison. >> only consider SEA hwpoison errors can be enough. > > We should be careful here, by hwpoison I meant the Linux feature. > From Documentation/vm/hwpoison.txt: >> Upcoming Intel CPUs have support for recovering from some memory errors >> (``MCA recovery''). This requires the OS to declare a page "poisoned", >> kill the processes associated with it and avoid using it in the future. > > We were talking about KVM's reaction to 'the OS declaring a page poisoned'. > Lets try to call this one memory-failure, as that is its Kconfig name. (now > I > understand why we've been confusing each other!) > > Your hwpoison looks like something the CPU reports in the ERRSTATUS > registers > (4.6.10 of DDI0587). This is something firmware should read, then describe > to > the OS via CPER records. Depending on these CPER records linux may invoke > its > memory-failure code. yes > > injection a SEA is no more than setting some registers: elr_el1, PC, PSTATE, SPSR_el1, far_el1, esr_el1 I seen this KVM API do the same thing as Qemu. do you found call this API will have issue and necessary to choose another ESR value? >>> >>> Should we let user-space pick the ESR to deliver to the guest? Yes, >>> letting >>> user-space specify the ESR gives the most flexibility to do something >>> clever in >>> the future. An obvious choice for SEA is between the external-abort and >>> 'parity >>> or ECC error' codes. If we tell user-space which of these happened (I >>> don't >>> think Linux does today) then Qemu can relay that information to the >>> guest. > >> may be the ESR is delivered by the KVM. >> (1) guest OS EL0 happen SEA due to hwpoison >> (2) CPU traps to EL3 firmware, and update the ESR_EL3 >> (3) the EL3 firmware copies the ESR_EL3 to ESR_EL2 >> (4) then jump to EL2 hypervisor, hypervisor uses the ESR_EL2 to inject the >> SEA. >> >> May be the esr_el2 can provide the accurate error information. >> or do you think user-space specify the ESR instead of esr_el2 is better? > > I think the severity needs to be considered as the notification is handled > by > each exception level. There are cases where it will need to be upgraded > from > 'contained' to 'uncontained'. (more discussion on another part of the > thread). understand it. > > > Thanks, > > James >
Re: [PATCH 10/24] thunderbolt: Read vendor and device name from DROM
On Sun, May 21, 2017 at 10:48:19AM +0300, Mika Westerberg wrote: > On Sun, May 21, 2017 at 07:31:14AM +0200, Lukas Wunner wrote: > > On Fri, May 19, 2017 at 01:28:36PM +0300, Mika Westerberg wrote: > > > On Fri, May 19, 2017 at 12:07:10PM +0200, Lukas Wunner wrote: > > > > If there can be many attributes, should they be stored in a list > > > > rather than adding a char* pointer for each one to struct tb_switch? > > > > The latter doesn't scale. > > > > > > I don't think we need other attributes (well, at least right now). The > > > device/vendor name is useful because that's what we expose to the > > > userspace for device identification along with the device/vendor ID. > > > > Okay. It might be worth to log additional attributes with info level. > > I don't think we want to log anything with info level to be honest. The > driver currently already is pretty noisy so adding even more information > there just makes it worse ;-) > > I would rather convert debugging information to use tracepoints and get > rid of the tb_*_info() things completely. The noisiness has value in that it helps with reverse-engineering: Just google for dmesg output and check what other machines are reporting for unknown registers. :-) If there was public documentation available or Intel would be okay with answering specific questions (as you've done with the 0x30 attribute id), then the value obviously diminishes. Can't say anything about converting to tracepoints, that's Andreas' call. > The whole DROM content is already available through nvm_active/nvmem > file under each device (well starting with Alpine Ridge) so the > userspace can investigate it as much as it likes without spamming the > kernel dmesg :) Okay, fair enough, that should indeed suffice. Thanks, Lukas
Re: zswap: Delete an error message for a failed memory allocation in zswap_dstmem_prepare()
> Markus, can you please stop CCing me on every of those patches? Yes, of course. >> Link: >> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf Did I interpret any information from your presentation slides in an inappropriate way? > And why do you create a patch for every occasion in the same file? This can occasionally happen when I am more unsure about the change acceptance for a specific place. > Do you want to increase your patch count? This can also happen as a side effect if such a source code search pattern will point hundreds of places out for further software development considerations. How would you prefer to clarify the remaining update candidates there? Regards, Markus
[PATCH v2] kconfig: Check for libncurses before menuconfig
On Sun, May 21, 2017 at 06:15:53PM +0900, Masahiro Yamada wrote: > Could you change line 199 > > $(addprefix $(obj)/,$(lxdialog)): $(obj)/dochecklxdialog > > to > > $(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog > > and send v2, please? Here it is: --- From: Borislav Petkov Date: Sun, 9 Apr 2017 15:07:08 +0200 Subject: [PATCH v2] kconfig: Check for libncurses before menuconfig There is a check and a nice user-friendly message when the curses library is not present on the system and the user wants to do "make menuconfig". It doesn't get issued, though. Instead, we fail the build when mconf.c doesn't find the curses.h header: HOSTCC scripts/kconfig/mconf.o In file included from scripts/kconfig/mconf.c:23:0: scripts/kconfig/lxdialog/dialog.h:38:20: fatal error: curses.h: No such file or directory #include CURSES_LOC ^ compilation terminated. Make sure dochecklxdialog gets run before mconf is compiled so that the user sees the error message instead: $ make menuconfig *** Unable to find the ncurses libraries or the *** required header files. *** 'make menuconfig' requires the ncurses libraries. *** *** Install ncurses (ncurses-devel) and try again. *** scripts/kconfig/Makefile:203: recipe for target 'scripts/kconfig/dochecklxdialog' failed make[1]: *** [scripts/kconfig/dochecklxdialog] Error 1 Makefile:548: recipe for target 'menuconfig' failed make: *** [menuconfig] Error 2 Signed-off-by: Borislav Petkov Cc: linux-kbu...@vger.kernel.org Link: http://lkml.kernel.org/r/20170409130708.4753-1...@alien8.de --- scripts/kconfig/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 90a091b6ae4d..eb8144643b78 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -196,7 +196,7 @@ clean-files += config.pot linux.pot # Check that we have the required ncurses stuff installed for lxdialog (menuconfig) PHONY += $(obj)/dochecklxdialog -$(addprefix $(obj)/,$(lxdialog)): $(obj)/dochecklxdialog +$(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog $(obj)/dochecklxdialog: $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf) -- 2.11.0 -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v6] mfd: Add Cherry Trail Whiskey Cove PMIC driver
Hi,
On 20-05-17 21:26, Paul Gortmaker wrote:
On Sat, May 20, 2017 at 3:21 PM, Paul Gortmaker
wrote:
On Mon, May 15, 2017 at 2:20 PM, Hans de Goede wrote:
Hi,
This is actually v7, with the following changes:
Changes in v7:
-Add explanation why this is a bool and why it selects i2c-designwaree
Gah -- I missed the explanation mentioned above:
-Change Kconfig option from tristate to boolean and add a select for the
i2c-bus driver, this is necessary because the chtwc PMIC provides an ACPI
OPRegion handler, which must be available before other drivers using it
are loaded, which can only be ensured if the mfd, opregion and i2c-bus
drivers are built in
Given that, can we get rid of the modular macros in the code now as well?
Yes we can, to be clear you are talking about dropping:
MODULE_DEVICE_TABLE(i2c, cht_wc_i2c_id);
MODULE_DEVICE_TABLE(acpi, cht_wc_acpi_ids);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Hans de Goede ");
And replacing:
module_i2c_driver(cht_wc_driver);
with:
builtin_i2c_driver(cht_wc_driver);
Right ?
Anything I'm missing ?
If not I will post a new version with these removed / replaced.
Regards,
Hans
RE: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the switch structure
> -Original Message- > From: Levy, Amir (Jer) > Sent: Sunday, May 21, 2017 11:07 > To: Mika Westerberg ; Lukas Wunner > > Cc: Greg Kroah-Hartman ; Andreas Noever > ; Jamet, Michael ; > Bernat, Yehezkel ; Andy Lutomirski > ; mario.limoncie...@dell.com; > jared.doming...@dell.com; Andy Shevchenko > ; linux-kernel@vger.kernel.org > Subject: RE: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the > switch structure > > On Sun, May 21 2017, 11:00 AM, Mika Westerberg wrote: > > On Sun, May 21, 2017 at 10:40:41AM +0300, Mika Westerberg wrote: > > > On Sun, May 21, 2017 at 07:35:21AM +0200, Lukas Wunner wrote: > > > > On Sun, May 21, 2017 at 05:29:47AM +, Levy, Amir (Jer) wrote: > > > > > On Sun, May 21 2017, 07:47 AM, Lukas Wunner wrote: > > > > > > On Thu, May 18, 2017 at 05:39:08PM +0300, Mika Westerberg wrote: > > > > > > > + > > > > > > > + default: > > > > > > > + sw->generation = 1; > > > > > > > + break; > > > > > > > > > > > > If someone adds an entry for, say, a new TB3 controller to > > > > > > nhi_ids[] but forgets to update this function, the controller > > > > > > is assigned the wrong generation number. It might be better > > > > > > to make TB3 the default and list each TB1 controller instead > > > > > > since it's less likely for Intel to introduce an older gen chip. > > > > > > > > > > > > Generally I think it's problematic to require that multiple > > > > > > files are touched whenever a new controller is added. Isn't > > > > > > the generation number or link speed (10/20/40) stored in some > > > > > > register in PCI config space (VSEC 0x1234) or TB config space? > > > > > > > > > > How about setting information, that isn't available from PCI, in > > > > > pci_device_id.driver_data when initializing nhi_ids[]? > > > > > > > > Right, that would also be possible, though reading the generation > > > > number from a register would be more elegant, if such a register exists. > > > > > > I don't think there is such register but I can put this information > > > to the driver_data instead. > > > > Actually these are Thunderbolt switch IDs, not NHI PCI IDs so I don't > > think driver_data is the right place after all. So if no objections, > > I'll update the function to default to TBT3 but keep the switch case > > and add the TBT1 IDs + Win Ridge there. > > There is correlation between switch ID to NHI ID. I'm not sure defaulting to TBT3 is a good idea. ICM message format can be changed, DMA port can be different, nothing guaranties correct operation of the driver with newer unknown controllers.
Re: zswap: Delete an error message for a failed memory allocation in zswap_dstmem_prepare()
Markus, > > Markus, can you please stop CCing me on every of those patches? > > Yes, of course. Thanks! > >> Link: > >> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf > > Did I interpret any information from your presentation slides in an > inappropriate way? Have you read my LWN article "Best practices for a big patch series"? https://lwn.net/Articles/585782/ > > And why do you create a patch for every occasion in the same file? > > This can occasionally happen when I am more unsure about the change acceptance > for a specific place. Why were you unsure here? > This can also happen as a side effect if such a source code search pattern > will point hundreds of places out for further software development > considerations. > How would you prefer to clarify the remaining update candidates there? Maybe the article mentioned can provice further guidance? Have a nice sunday, Wolfram signature.asc Description: PGP signature
Re: Using best practices for big software change possibilities
> Have you read my LWN article "Best practices for a big patch series"? > > https://lwn.net/Articles/585782/ Yes. >> This can also happen as a side effect if such a source code search pattern >> will point hundreds of places out for further software development >> considerations. >> How would you prefer to clarify the remaining update candidates there? > > Maybe the article mentioned can provice further guidance? Partly, yes. I am trying to achieve some software improvements also for special change patterns. This approach can trigger corresponding communication difficulties. How do you think about to resolve them by additional means besides mail exchange? Regards, Markus
[GIT pull] irq fixes for 4.12
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
A set of small fixes for the irq subsystem:
- Cure a data ordering problem with chained interrupts
- Three small fixlets for the mbigen irq chip
Thanks,
tglx
-->
Hanjun Guo (2):
irqchip/mbigen: Fix memory mapping code
irqchip/mbigen: Fix potential NULL dereferencing
MaJun (1):
irqchip/mbigen: Fix the clear register offset calculation
Thomas Gleixner (1):
genirq: Fix chained interrupt data ordering
drivers/irqchip/irq-mbigen.c | 17 ++---
kernel/irq/chip.c| 2 +-
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index d2306c821ebb..31d6b5a582d2 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -106,10 +106,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t
hwirq,
static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
u32 *mask, u32 *addr)
{
- unsigned int ofst;
-
- hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
- ofst = hwirq / 32 * 4;
+ unsigned int ofst = (hwirq / 32) * 4;
*mask = 1 << (hwirq % 32);
*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
@@ -337,9 +334,15 @@ static int mbigen_device_probe(struct platform_device
*pdev)
mgn_chip->pdev = pdev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mgn_chip->base = devm_ioremap_resource(>dev, res);
- if (IS_ERR(mgn_chip->base))
- return PTR_ERR(mgn_chip->base);
+ if (!res)
+ return -EINVAL;
+
+ mgn_chip->base = devm_ioremap(>dev, res->start,
+ resource_size(res));
+ if (!mgn_chip->base) {
+ dev_err(>dev, "failed to ioremap %pR\n", res);
+ return -ENOMEM;
+ }
if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
err = mbigen_of_create_domain(pdev, mgn_chip);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 686be4b73018..c94da688ee9b 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -880,8 +880,8 @@ irq_set_chained_handler_and_data(unsigned int irq,
irq_flow_handler_t handle,
if (!desc)
return;
- __irq_do_set_handler(desc, handle, 1, NULL);
desc->irq_common_data.handler_data = data;
+ __irq_do_set_handler(desc, handle, 1, NULL);
irq_put_desc_busunlock(desc, flags);
}
[GIT pull] scheduler fix for 4.12
Linus,
please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
A single scheduler fix:
Prevent idle task from ever being preempted. That makes sure that
synchronize_rcu_tasks() which is ignoring idle task does not pretend that
no task is stuck in preempted state. If that happens and idle was
preempted on a ftrace trampoline the machine crashes due to inconsistent
state.
Thanks,
tglx
-->
Steven Rostedt (VMware) (1):
sched/core: Call __schedule() from do_idle() without enabling preemption
kernel/sched/core.c | 25 +
kernel/sched/idle.c | 2 +-
kernel/sched/sched.h | 2 ++
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 759f4bd52cd6..803c3bc274c4 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3502,6 +3502,31 @@ asmlinkage __visible void __sched schedule(void)
}
EXPORT_SYMBOL(schedule);
+/*
+ * synchronize_rcu_tasks() makes sure that no task is stuck in preempted
+ * state (have scheduled out non-voluntarily) by making sure that all
+ * tasks have either left the run queue or have gone into user space.
+ * As idle tasks do not do either, they must not ever be preempted
+ * (schedule out non-voluntarily).
+ *
+ * schedule_idle() is similar to schedule_preempt_disable() except that it
+ * never enables preemption because it does not call sched_submit_work().
+ */
+void __sched schedule_idle(void)
+{
+ /*
+* As this skips calling sched_submit_work(), which the idle task does
+* regardless because that function is a nop when the task is in a
+* TASK_RUNNING state, make sure this isn't used someplace that the
+* current task can be in any other state. Note, idle is always in the
+* TASK_RUNNING state.
+*/
+ WARN_ON_ONCE(current->state);
+ do {
+ __schedule(false);
+ } while (need_resched());
+}
+
#ifdef CONFIG_CONTEXT_TRACKING
asmlinkage __visible void __sched schedule_user(void)
{
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 2a25a9ec2c6e..ef63adce0c9c 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -265,7 +265,7 @@ static void do_idle(void)
smp_mb__after_atomic();
sched_ttwu_pending();
- schedule_preempt_disabled();
+ schedule_idle();
if (unlikely(klp_patch_pending(current)))
klp_update_patch_state(current);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7808ab050599..6dda2aab731e 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1467,6 +1467,8 @@ static inline struct cpuidle_state *idle_get_state(struct
rq *rq)
}
#endif
+extern void schedule_idle(void);
+
extern void sysrq_sched_debug_show(void);
extern void sched_init_granularity(void);
extern void update_max_interval(void);
Re: Using best practices for big software change possibilities
> How do you think about to resolve them by additional means besides mail > exchange? That can work. E.g. meeting at conferences often solved mail communication problems. For now, I still wonder why you were unsure about grouping the changes into one patch? Maybe there is something to be learned? signature.asc Description: PGP signature
[PATCH v5 2/3] ARM: dts: twl4030: Add missing madc reference for bci subnode
From: Marek Belisko
The twl4030_charger driver expects an iio channel to detect the
presence of an AC charger by looking at VAC (madc channel 11).
This definition is missing in the device tree.
Signed-off-by: Marek Belisko
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/twl4030.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 36ae9160b558..16533b62b0a2 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -23,6 +23,8 @@
compatible = "ti,twl4030-bci";
interrupts = <9>, <2>;
bci3v1-supply = <>;
+ io-channels = <_madc 11>;
+ io-channel-names = "vac";
};
watchdog {
--
2.12.2
[PATCH v5 1/3] drivers:power:twl4030-charger: remove nonstandard max_current sysfs attribute
Since we now support the standard 'input_current_limit' property by
commit 3fb319c2cdcd ("power: supply: twl4030-charger: add writable
INPUT_CURRENT_LIMIT property")
we can now remove the nonstandard 'max_current' sysfs attribute.
See Documentation/power/power_supply_class.txt line 125
Both are functionally equivalent. From ABI point of view it is just a rename
of the property.
This also removes the entry in
Documentation/ABI/testing/sysfs-class-power-twl4030
Signed-off-by: H. Nikolaus Schaller
---
.../ABI/testing/sysfs-class-power-twl4030 | 17 --
drivers/power/supply/twl4030_charger.c | 63 --
2 files changed, 80 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-class-power-twl4030
b/Documentation/ABI/testing/sysfs-class-power-twl4030
index be26af0f1895..b4fd32d210c5 100644
--- a/Documentation/ABI/testing/sysfs-class-power-twl4030
+++ b/Documentation/ABI/testing/sysfs-class-power-twl4030
@@ -1,20 +1,3 @@
-What: /sys/class/power_supply/twl4030_ac/max_current
- /sys/class/power_supply/twl4030_usb/max_current
-Description:
- Read/Write limit on current which may
- be drawn from the ac (Accessory Charger) or
- USB port.
-
- Value is in micro-Amps.
-
- Value is set automatically to an appropriate
- value when a cable is plugged or unplugged.
-
- Value can the set by writing to the attribute.
- The change will only persist until the next
- plug event. These event are reported via udev.
-
-
What: /sys/class/power_supply/twl4030_usb/mode
Description:
Changing mode for USB port.
diff --git a/drivers/power/supply/twl4030_charger.c
b/drivers/power/supply/twl4030_charger.c
index 2f82d0e9ec1b..785a07bc4f39 100644
--- a/drivers/power/supply/twl4030_charger.c
+++ b/drivers/power/supply/twl4030_charger.c
@@ -624,63 +624,6 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void
*arg)
return IRQ_HANDLED;
}
-/*
- * Provide "max_current" attribute in sysfs.
- */
-static ssize_t
-twl4030_bci_max_current_store(struct device *dev, struct device_attribute
*attr,
- const char *buf, size_t n)
-{
- struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
- int cur = 0;
- int status = 0;
- status = kstrtoint(buf, 10, );
- if (status)
- return status;
- if (cur < 0)
- return -EINVAL;
- if (dev == >ac->dev)
- bci->ac_cur = cur;
- else
- bci->usb_cur_target = cur;
-
- twl4030_charger_update_current(bci);
- return n;
-}
-
-/*
- * sysfs max_current show
- */
-static ssize_t twl4030_bci_max_current_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- int status = 0;
- int cur = -1;
- u8 bcictl1;
- struct twl4030_bci *bci = dev_get_drvdata(dev->parent);
-
- if (dev == >ac->dev) {
- if (!bci->ac_is_active)
- cur = bci->ac_cur;
- } else {
- if (bci->ac_is_active)
- cur = bci->usb_cur_target;
- }
- if (cur < 0) {
- cur = twl4030bci_read_adc_val(TWL4030_BCIIREF1);
- if (cur < 0)
- return cur;
- status = twl4030_bci_read(TWL4030_BCICTL1, );
- if (status < 0)
- return status;
- cur = regval2ua(cur, bcictl1 & TWL4030_CGAIN);
- }
- return scnprintf(buf, PAGE_SIZE, "%u\n", cur);
-}
-
-static DEVICE_ATTR(max_current, 0644, twl4030_bci_max_current_show,
- twl4030_bci_max_current_store);
-
static void twl4030_bci_usb_work(struct work_struct *data)
{
struct twl4030_bci *bci = container_of(data, struct twl4030_bci, work);
@@ -,14 +1054,10 @@ static int twl4030_bci_probe(struct platform_device
*pdev)
dev_warn(>dev, "failed to unmask interrupts: %d\n", ret);
twl4030_charger_update_current(bci);
- if (device_create_file(>usb->dev, _attr_max_current))
- dev_warn(>dev, "could not create sysfs file\n");
if (device_create_file(>usb->dev, _attr_mode))
dev_warn(>dev, "could not create sysfs file\n");
if (device_create_file(>ac->dev, _attr_mode))
dev_warn(>dev, "could not create sysfs file\n");
- if (device_create_file(>ac->dev, _attr_max_current))
- dev_warn(>dev, "could not create sysfs file\n");
twl4030_charger_enable_ac(bci, true);
if (!IS_ERR_OR_NULL(bci->transceiver))
@@ -1150,9 +1089,7 @@ static int twl4030_bci_remove(struct platform_device
*pdev)
iio_channel_release(bci->channel_vac);
- device_remove_file(>usb->dev, _attr_max_current);
device_remove_file(>usb->dev, _attr_mode);
- device_remove_file(>ac->dev, _attr_max_current);
device_remove_file(>ac->dev, _attr_mode);
/* mask interrupts */
[PATCH v5 0/3] More fixes for twl4030 charger
Changes V5: * reworked max_current removal patch (comments by Sebastian Reichel) * resubmit missing madc connection for AC power detection * resubmit patch for irq allocation and -EPROBE_DEFER * rebased on 4.12-rc1 Changes V4: * resent commit (original one did contain material not upstream) 2017-04-14 21:29:39: 2017-04-14 20:26:00: Changes V3: * worked in comments by Sebsatian Reichel * clarifications of some commit messages * rebased on v4.11rc-6 It took a while (18 months) until we propose an updated patch for upstream... 2015-11-02 12:27:39: Changes V2: * worked in comments by Nishanth Menon * added another patch which solves a probing/boot stall problem (irq allocation vs. -EPROBE_DEFER) V1: 4.3-rc1 introduced a new charger driver for the twl4030. This patch set fixes some issues. While making twl4030 changes from 4.3 operable we have found some issues during testing on GTA04 and OpenPandora. H. Nikolaus Schaller (2): drivers:power:twl4030-charger: remove nonstandard max_current sysfs attribute drivers:power:twl4030-charger: add deferred probing for phy and iio Marek Belisko (1): ARM: dts: twl4030: Add missing madc reference for bci subnode .../ABI/testing/sysfs-class-power-twl4030 | 17 arch/arm/boot/dts/twl4030.dtsi | 2 + drivers/power/supply/twl4030_charger.c | 100 + 3 files changed, 24 insertions(+), 95 deletions(-) -- 2.12.2
[PATCH v5 3/3] drivers:power:twl4030-charger: add deferred probing for phy and iio
This fixes an issue if both this twl4030_charger driver and
phy-twl4030-usb are compiled as modules and loaded in random order.
It has been observed on GTA04 and OpenPandora devices that in worst
case the boot process hangs and in best case the AC detection fails
with a warning.
Therefore we add deferred probing checks for the usb_phy and the
iio channel for AC detection.
For implementing this we must reorder code because we can't safely
return -EPROBE_DEFER after allocating any devm managed interrupt
(it might already/still be enabled without working interrupt handler).
So the check for required resources that may abort probing by
returning -EPROBE_DEFER, must come first.
Signed-off-by: H. Nikolaus Schaller
---
drivers/power/supply/twl4030_charger.c | 37 --
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/power/supply/twl4030_charger.c
b/drivers/power/supply/twl4030_charger.c
index 785a07bc4f39..945eabdbbc89 100644
--- a/drivers/power/supply/twl4030_charger.c
+++ b/drivers/power/supply/twl4030_charger.c
@@ -984,6 +984,28 @@ static int twl4030_bci_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, bci);
+ if (bci->dev->of_node) {
+ struct device_node *phynode;
+
+ phynode = of_find_compatible_node(bci->dev->of_node->parent,
+ NULL, "ti,twl4030-usb");
+ if (phynode) {
+ bci->transceiver = devm_usb_get_phy_by_node(
+ bci->dev, phynode, >usb_nb);
+ if (IS_ERR(bci->transceiver) &&
+ PTR_ERR(bci->transceiver) == -EPROBE_DEFER)
+ return -EPROBE_DEFER; /* PHY not ready */
+ }
+ }
+
+ bci->channel_vac = iio_channel_get(>dev, "vac");
+ if (IS_ERR(bci->channel_vac)) {
+ if (PTR_ERR(bci->channel_vac) == -EPROBE_DEFER)
+ return -EPROBE_DEFER; /* iio not ready */
+ dev_warn(>dev, "could not request vac iio channel");
+ bci->channel_vac = NULL;
+ }
+
bci->ac = devm_power_supply_register(>dev, _bci_ac_desc,
NULL);
if (IS_ERR(bci->ac)) {
@@ -1017,25 +1039,10 @@ static int twl4030_bci_probe(struct platform_device
*pdev)
return ret;
}
- bci->channel_vac = iio_channel_get(>dev, "vac");
- if (IS_ERR(bci->channel_vac)) {
- bci->channel_vac = NULL;
- dev_warn(>dev, "could not request vac iio channel");
- }
-
INIT_WORK(>work, twl4030_bci_usb_work);
INIT_DELAYED_WORK(>current_worker, twl4030_current_worker);
bci->usb_nb.notifier_call = twl4030_bci_usb_ncb;
- if (bci->dev->of_node) {
- struct device_node *phynode;
-
- phynode = of_find_compatible_node(bci->dev->of_node->parent,
- NULL, "ti,twl4030-usb");
- if (phynode)
- bci->transceiver = devm_usb_get_phy_by_node(
- bci->dev, phynode, >usb_nb);
- }
/* Enable interrupts now. */
reg = ~(u32)(TWL4030_ICHGLOW | TWL4030_ICHGEOC | TWL4030_TBATOR2 |
--
2.12.2
[RFC 1/3] DTS: gta04: add serdev nodes for w2sg00x4, w2cbw etc.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap3-gta04.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 430b438e0ee9..45f0c109960f 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -472,16 +472,34 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+ bluetooth: w2cbw003 {
+ compatible = "wi2wi,w2cbw003-bluetooth";
+ vdd-supply = <>;
+ };
};
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+ gps: w2sg0004 {
+ compatible = "wi2wi,w2sg0004";
+ lna-supply = <>; /* LNA regulator */
+ on-off-gpios = < 17 GPIO_ACTIVE_HIGH>;/* GPIO_145:
trigger for turning on/off w2sg0004 */
+ };
};
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+ rs232: trs3386 {
+ status = "disabled";
+ compatible = "ti,trs3386-mctrl";
+ gpios = <0>,/* ... */
+ < 21 0>; /* DTR: GPIO_21 */
+ };
};
{
--
2.12.2
[RFC 3/3] misc: Add w2cbw003 (wifi/bluetooth) power control driver
Add driver for Wi2Wi W2CBW003 WiFi and Bluetooth module
where the Bluetooth interface is connected through uart.
Uses the new serdev API to glue with tty and turn on/off the
module if the tty port (/dev/ttyBTn) is opened.
Note that this is only for the Bluetooth side. The WLAN
(libertas) sdio driver should be abe to enable the same vdd
regulator. So that the device is powered on if either WiFi or
Bluetooth is activated (or both) and powered down if neither
is in use.
Signed-off-by: H. Nikolaus Schaller
---
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/w2cbw003-bluetooth.c | 390 ++
3 files changed, 398 insertions(+)
create mode 100644 drivers/misc/w2cbw003-bluetooth.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 7f97ef8fb6cd..90ce23bef77b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -525,4 +525,11 @@ config W2SG0004_DEBUG
help
Enable driver debugging mode of W2SG0004 GPS.
+config W2CBW003
+ tristate "W2CBW003 power on/off control"
+ depends on GPIOLIB
+ help
+ Enable on/off power control of W2CBW003 if the /dev/tty$n for
+ Bluetooth is opened.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 0e88e06e5ee0..f6d3f096c5e0 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -51,6 +51,7 @@ obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_W2SG0004) += w2sg0004.o
+obj-$(CONFIG_W2CBW003) += w2cbw003-bluetooth.o
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
diff --git a/drivers/misc/w2cbw003-bluetooth.c
b/drivers/misc/w2cbw003-bluetooth.c
new file mode 100644
index ..3bcfd51bbf09
--- /dev/null
+++ b/drivers/misc/w2cbw003-bluetooth.c
@@ -0,0 +1,390 @@
+/*
+ * w2scbw003.c
+ * Driver for power controlling the w2cbw003 WiFi/Bluetooth chip.
+ *
+ * powers on the chip if the tty port associated/connected
+ * to the bluetooth subsystem is opened (e.g. hciattach /dev/ttyBT0)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#undef pr_debug
+#define pr_debug printk
+
+struct w2cbw_data {
+ struct regulator *vdd_regulator;
+ struct serdev_device *uart;/* the uart connected to the
chip */
+ struct tty_driver *tty_drv;/* this is the user space tty */
+ struct device *dev;/* returned by
tty_port_register_device() */
+ struct tty_port port;
+ int open_count; /* how often we were opened */
+};
+
+static struct w2cbw_data *w2cbw_by_minor[1];
+
+static void w2cbw_set_power(void *pdata, int val)
+{
+ struct w2cbw_data *data = (struct w2cbw_data *) pdata;
+
+ pr_debug("%s(...,%x)\n", __func__, val);
+
+ if (val != 0)
+ WARN_ON(regulator_enable(data->vdd_regulator));
+ else
+ regulator_disable(data->vdd_regulator);
+}
+
+/* called each time data is received by the UART (i.e. sent by the w2cbw003) */
+
+static int w2cbw_uart_receive_buf(struct serdev_device *serdev, const unsigned
char *rxdata,
+ size_t count)
+{
+ struct w2cbw_data *data = (struct w2cbw_data *)
serdev_device_get_drvdata(serdev);
+
+// pr_debug("%s() characters\n", __func__, count);
+
+ if (data->open_count > 0) {
+ int n;
+
+ pr_debug("w2cbw003: uart->tty %d chars\n", count);
+ n = tty_insert_flip_string(>port, rxdata, count); /* pass
to user-space */
+ if (n != count)
+ pr_debug("w2cbw003: did loose %d characters\n", count -
n);
+ tty_flip_buffer_push(>port);
+ return n;
+ }
+
+ /* nobody is listenig - ignore incoming data */
+ return count;
+}
+
+static struct serdev_device_ops serdev_ops = {
+ .receive_buf = w2cbw_uart_receive_buf,
+#if 0
+ .write_wakeup = w2cbw_uart_wakeup,
+#endif
+};
+
+static struct w2cbw_data *w2cbw_get_by_minor(unsigned int minor)
+{
+ return w2cbw_by_minor[minor];
+}
+
+static int w2cbw_tty_install(struct tty_driver *driver, struct tty_struct *tty)
+{
+ struct w2cbw_data *data;
+ int retval;
+
+ pr_debug("%s() tty = %p\n", __func__, tty);
+
+ data = w2cbw_get_by_minor(tty->index);
+ pr_debug("%s() data = %p\n", __func__, data);
+
+ if (!data)
+ return -ENODEV;
+
+ retval = tty_standard_install(driver, tty);
+ if (retval)
+ goto error_init_termios;
+
+ tty->driver_data = data;
+
+ return 0;
+
+error_init_termios:
+ tty_port_put(>port);
+ return retval;
+}
+
+static int w2cbw_tty_open(struct tty_struct *tty, struct
[RFC 0/3] misc: new serdev based drivers for w2sg00x4 GPS module and w2cbw003 wifi/bluetooth
Since our proposed API was not acceptable and the new serdev API has arrived in 4.11 kernels, we finally took the challenge to update the w2sg and w2cbw drivers to use the serdev API. The approach is to write a "man in the middle" driver which is on one side a serdev client which directly controls the UART where the device is connected to and on the other side presents a new tty port so that user-space software can talk to the chips as if they would directly talk to the UART of the SoC (e.g. ttyO1). This is similar to connecting to a remote serial device e.g. through USB (ttyACM) or Bluetooth UART profiles. For example gpsd or hciattach expect a /dev/tty they can control (flow control, baud rate etc.). Here is the result of our first hack which is working as a demo on GTA04 devices (and the w2cbw driver can also be used to control a GTA04 variant with WL1837). Since it is just a demo hack, the code is not yet cleaned up, nor does it completely pass check-patch, nor follows 100% the coding styles. And certainly has some bugs. The most significant issue is that calling tty_port_register_device() inside of the serdev probe() function makes the serdev probe() function to be entered a second time. This does not lead to big problems since we currently have minor = 0 and this makes the second call assume the device is not available. But we have no idea why this happens and how it can be prevented. Another observation is that the man-in-the-middle approach means copying and double buffering the data. This seems to add some delay, especially if we run the w2cbw003 bluetooth interface with its max. speed of 3 Mbit/s. So this is still work in progress and more a demo than quite some work away ffrom upstreaming. Therefore, we are asking for comments if the general direction is ok and a polished driver would be acceptable. And if there are solutions for the duplicate probe() and double-buffering delays. H. Nikolaus Schaller (3): DTS: gta04: add serdev nodes for w2sg00x4, w2cbw etc. misc: Add w2sg0004 (gps receiver) power control driver misc: Add w2cbw003 (wifi/bluetooth) power control driver .../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 20 + .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/omap3-gta04.dtsi | 18 + drivers/misc/Kconfig | 23 + drivers/misc/Makefile | 2 + drivers/misc/w2cbw003-bluetooth.c | 390 + drivers/misc/w2sg0004.c| 646 + include/linux/w2sg0004.h | 27 + 8 files changed, 1127 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt create mode 100644 drivers/misc/w2cbw003-bluetooth.c create mode 100644 drivers/misc/w2sg0004.c create mode 100644 include/linux/w2sg0004.h -- 2.12.2
Re: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the switch structure
On Sun, May 21, 2017 at 08:07:08AM +, Levy, Amir (Jer) wrote: > On Sun, May 21 2017, 11:00 AM, Mika Westerberg wrote: > > On Sun, May 21, 2017 at 10:40:41AM +0300, Mika Westerberg wrote: > > > On Sun, May 21, 2017 at 07:35:21AM +0200, Lukas Wunner wrote: > > > > On Sun, May 21, 2017 at 05:29:47AM +, Levy, Amir (Jer) wrote: > > > > > On Sun, May 21 2017, 07:47 AM, Lukas Wunner wrote: > > > > > > On Thu, May 18, 2017 at 05:39:08PM +0300, Mika Westerberg wrote: > > > > > > > + > > > > > > > + default: > > > > > > > + sw->generation = 1; > > > > > > > + break; > > > > > > > > > > > > If someone adds an entry for, say, a new TB3 controller to > > > > > > nhi_ids[] but forgets to update this function, the controller is > > > > > > assigned the wrong generation number. It might be better to > > > > > > make TB3 the default and list each TB1 controller instead since > > > > > > it's less likely for Intel to introduce an older gen chip. > > > > > > > > > > > > Generally I think it's problematic to require that multiple > > > > > > files are touched whenever a new controller is added. Isn't the > > > > > > generation number or link speed (10/20/40) stored in some > > > > > > register in PCI config space (VSEC 0x1234) or TB config space? > > > > > > > > > > How about setting information, that isn't available from PCI, in > > > > > pci_device_id.driver_data when initializing nhi_ids[]? > > > > > > > > Right, that would also be possible, though reading the generation > > > > number from a register would be more elegant, if such a register exists. > > > > > > I don't think there is such register but I can put this information to > > > the driver_data instead. > > > > Actually these are Thunderbolt switch IDs, not NHI PCI IDs so I don't think > > driver_data is the right place after all. So if no objections, I'll update > > the > > function to default to TBT3 but keep the switch case and add the TBT1 IDs + > > Win Ridge there. > > There is correlation between switch ID to NHI ID. Indeed but what if you have a device with a Port Ridge TBT controller (switch) connected to the host? Here we want to get the generation of whatever Thunderbolt switch, not just root switch (where NHI ID would indeed suffice).
[RFC 2/3] misc: Add w2sg0004 (gps receiver) power control driver
Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart.
Use serdev API hooks to monitor and forward the UART traffic to /dev/BTn
and turn on/off the module. It also detects if the module is turned on (sends
data)
but should be off, e.g. if it was already turned on during boot or
power-on-reset.
Additionally, rfkill block/unblock can be used to control an external LNA
(and power down the module if not needed).
The driver concept is based on code developed by NeilBrown
but simplified and adapted to use the new serdev API introduced in 4.11.
Signed-off-by: H. Nikolaus Schaller
---
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 20 +
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/misc/Kconfig | 16 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c| 646 +
include/linux/w2sg0004.h | 27 +
6 files changed, 711 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
create mode 100644 drivers/misc/w2sg0004.c
create mode 100644 include/linux/w2sg0004.h
diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
new file mode 100644
index ..b7125c7a598c
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
@@ -0,0 +1,20 @@
+Wi2Wi GPS module connected through UART
+
+Should be a subnode of the SoC UART it is connected to (serdev).
+
+Required properties:
+- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
+- on-off-gpio: the GPIO that controls the module's on-off toggle input
+
+Optional properties:
+- lna-suppy: an (optional) LNA regulator that is enabled together with the
GPS receiver
+
+Example:
+
+ {
+ gps: w2sg0004 {
+ compatible = "wi2wi,w2sg0004";
+ lna-supply = <>; /* LNA regulator */
+ on-off-gpios = < 17 GPIO_ACTIVE_HIGH>;/* GPIO_145:
trigger for turning on/off w2sg0004 */
+};
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c03d20140366..c56b3181b266 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -345,6 +345,7 @@ voipac Voipac Technologies s.r.o.
wd Western Digital Corp.
wetek WeTek Electronics, limited.
wexler Wexler
+wi2wi Wi2Wi, Inc.
winbond Winbond Electronics corp.
winstarWinstar Display Corp.
wlfWolfson Microelectronics
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 60f876b03586..7f97ef8fb6cd 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -509,4 +509,20 @@ source "drivers/misc/mic/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
source "drivers/misc/cxl/Kconfig"
+
+config W2SG0004
+ tristate "W2SG00x4 on/off control"
+ depends on GPIOLIB && SERIAL_DEV_BUS
+ help
+ Enable on/off control of W2SG00x4 GPS moduled connected
+ to some SoC UART to allow powering up/down if the /dev/ttyGPSn
+ is opened/closed.
+ It also provides a rfkill gps name to control the LNA power.
+
+config W2SG0004_DEBUG
+ bool "W2SG0004 on/off debugging"
+ depends on W2SG0004
+ help
+ Enable driver debugging mode of W2SG0004 GPS.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 81ef3e67acc9..0e88e06e5ee0 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_SRAM_EXEC) += sram-exec.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index ..1b335317c8ac
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,646 @@
+/*
+ * w2sg0004.c
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'. A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control
Re: Using best practices for big software change possibilities
>> How do you think about to resolve them by additional means besides mail >> exchange? > > That can work. I am curious to find out which other communication means could really help here. > E.g. meeting at conferences often solved mail communication problems. I find my resources too limited at the moment to attend conferences on site. How are the chances for further clarification by ordinary telephone calls? > For now, I still wonder why you were unsure about grouping the changes > into one patch? I am varying the patch granularity for affected software areas to some degree. But I came also places along where I got an impression for higher uncertainty. > Maybe there is something to be learned? This is also generally possible. Would you like to extend the scope for the change pattern around questionable error messages from a single source file to whole subsystem trees in Linux? Regards, Markus
Re: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the switch structure
On Sun, May 21, 2017 at 09:55:55AM +, Bernat, Yehezkel wrote: > > > > -Original Message- > > From: Levy, Amir (Jer) > > Sent: Sunday, May 21, 2017 11:07 > > To: Mika Westerberg ; Lukas Wunner > > > > Cc: Greg Kroah-Hartman ; Andreas Noever > > ; Jamet, Michael ; > > Bernat, Yehezkel ; Andy Lutomirski > > ; mario.limoncie...@dell.com; > > jared.doming...@dell.com; Andy Shevchenko > > ; linux-kernel@vger.kernel.org > > Subject: RE: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the > > switch structure > > > > On Sun, May 21 2017, 11:00 AM, Mika Westerberg wrote: > > > On Sun, May 21, 2017 at 10:40:41AM +0300, Mika Westerberg wrote: > > > > On Sun, May 21, 2017 at 07:35:21AM +0200, Lukas Wunner wrote: > > > > > On Sun, May 21, 2017 at 05:29:47AM +, Levy, Amir (Jer) wrote: > > > > > > On Sun, May 21 2017, 07:47 AM, Lukas Wunner wrote: > > > > > > > On Thu, May 18, 2017 at 05:39:08PM +0300, Mika Westerberg wrote: > > > > > > > > + > > > > > > > > + default: > > > > > > > > + sw->generation = 1; > > > > > > > > + break; > > > > > > > > > > > > > > If someone adds an entry for, say, a new TB3 controller to > > > > > > > nhi_ids[] but forgets to update this function, the controller > > > > > > > is assigned the wrong generation number. It might be better > > > > > > > to make TB3 the default and list each TB1 controller instead > > > > > > > since it's less likely for Intel to introduce an older gen chip. > > > > > > > > > > > > > > Generally I think it's problematic to require that multiple > > > > > > > files are touched whenever a new controller is added. Isn't > > > > > > > the generation number or link speed (10/20/40) stored in some > > > > > > > register in PCI config space (VSEC 0x1234) or TB config space? > > > > > > > > > > > > How about setting information, that isn't available from PCI, in > > > > > > pci_device_id.driver_data when initializing nhi_ids[]? > > > > > > > > > > Right, that would also be possible, though reading the generation > > > > > number from a register would be more elegant, if such a register > > > > > exists. > > > > > > > > I don't think there is such register but I can put this information > > > > to the driver_data instead. > > > > > > Actually these are Thunderbolt switch IDs, not NHI PCI IDs so I don't > > > think driver_data is the right place after all. So if no objections, > > > I'll update the function to default to TBT3 but keep the switch case > > > and add the TBT1 IDs + Win Ridge there. > > > > There is correlation between switch ID to NHI ID. > > I'm not sure defaulting to TBT3 is a good idea. ICM message format can > be changed, DMA port can be different, nothing guaranties correct > operation of the driver with newer unknown controllers. Fair enough :) Then we just need to remember to update the function here as new generations get added and tested. I suppose you don't know either if we could use the revision or similar field in the switch config space to determine generation somehow?
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 17/05/17 16:28, Jan Kiszka wrote:
This is an upstream port of an IIO driver for the TI ADC108S102 and
ADC128S102. The former can be found on the Intel Galileo Gen2 and the
Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
included.
Due to the lack of regulators under ACPI, we hard-code the voltage
provided to the VA pin of the ADC to 5 V, the value used on Galileo and
IOT2000. For DT usage, the regulator "vref-supply" provides this
information. Note that DT usage has not been tested.
Original author: Bogdan Pricop
Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
Todor Minchev .
Signed-off-by: Jan Kiszka
Still an issue wrt to it being obviously correct in the ordering in probe
and remove.
As a reviewer I want to be able to run through each step in probe and
compare with remove to ensure they occur in the opposite order and
reverse all the steps in probe. Where ever it deviates from that I have
to think about it and we all know the last thing a reviewer with a big
backlog of patches wants to do is to think hard ;)
Anyhow, I've fixed up and applied to the togreg branch of iio.git and
pushed out as testing for the autobuilders to play with it.
Please check I haven't made a mess of it.
Thanks,
Jonathan
---
Changes in v6:
- plug race condition in driver unregistration
.../devicetree/bindings/iio/adc/ti-adc108s102.txt | 18 ++
drivers/iio/adc/Kconfig| 12 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ti-adc108s102.c| 344 +
4 files changed, 375 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
create mode 100644 drivers/iio/adc/ti-adc108s102.c
diff --git a/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
b/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
new file mode 100644
index ..b4a9f58f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti-adc108s102.txt
@@ -0,0 +1,18 @@
+* Texas Instruments' ADC108S102 and ADC128S102 ADC chip
+
+Required properties:
+ - compatible: Should be "ti,adc108s102"
+ - reg: spi chip select number for the device
+ - vref-supply: The regulator supply for ADC reference voltage
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+adc@0 {
+ compatible = "ti,adc108s102";
+ reg = <0>;
+ vref-supply = <_supply>;
+ spi-max-frequency = <100>;
+};
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 401f47b51d83..2cc37c4da504 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -691,6 +691,18 @@ config TI_ADC12138
This driver can also be built as a module. If so, the module will be
called ti-adc12138.
+config TI_ADC108S102
+ tristate "Texas Instruments ADC108S102 and ADC128S102 driver"
+ depends on SPI
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for Texas Instruments ADC108S102 and
+ ADC128S102 ADC.
+
+ To compile this driver as a module, choose M here: the module will
+ be called ti-adc108s102.
+
config TI_ADC128S052
tristate "Texas Instruments ADC128S052/ADC122S021/ADC124S021"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 9339bec4babe..948b6b9b72c3 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_STM32_ADC) += stm32-adc.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
+obj-$(CONFIG_TI_ADC108S102) += ti-adc108s102.o
obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
obj-$(CONFIG_TI_ADC161S626) += ti-adc161s626.o
obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
diff --git a/drivers/iio/adc/ti-adc108s102.c b/drivers/iio/adc/ti-adc108s102.c
new file mode 100644
index ..c8bc10da8ab3
--- /dev/null
+++ b/drivers/iio/adc/ti-adc108s102.c
@@ -0,0 +1,344 @@
+/*
+ * TI ADC108S102 SPI ADC driver
+ *
+ * Copyright (c) 2013-2015 Intel Corporation.
+ * Copyright (c) 2017 Siemens AG
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * This IIO device driver is designed to work with the following
+ * analog to digital converters from Texas Instruments:
+ * ADC108S102
+ * ADC128S102
+ * The communication with ADC chip is via the SPI bus (mode 3).
+ */
+
+#include
Re: [RFC 2/3] misc: Add w2sg0004 (gps receiver) power control driver
> Am 21.05.2017 um 12:44 schrieb H. Nikolaus Schaller :
>
> Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart.
>
> Use serdev API hooks to monitor and forward the UART traffic to /dev/BTn
s/BTn/GPSn/
> and turn on/off the module. It also detects if the module is turned on (sends
> data)
> but should be off, e.g. if it was already turned on during boot or
> power-on-reset.
>
> Additionally, rfkill block/unblock can be used to control an external LNA
> (and power down the module if not needed).
>
> The driver concept is based on code developed by NeilBrown
> but simplified and adapted to use the new serdev API introduced in 4.11.
>
> Signed-off-by: H. Nikolaus Schaller
> ---
> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 20 +
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> drivers/misc/Kconfig | 16 +
> drivers/misc/Makefile | 1 +
> drivers/misc/w2sg0004.c| 646 +
> include/linux/w2sg0004.h | 27 +
> 6 files changed, 711 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> create mode 100644 drivers/misc/w2sg0004.c
> create mode 100644 include/linux/w2sg0004.h
>
> diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> new file mode 100644
> index ..b7125c7a598c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> @@ -0,0 +1,20 @@
> +Wi2Wi GPS module connected through UART
> +
> +Should be a subnode of the SoC UART it is connected to (serdev).
> +
> +Required properties:
> +- compatible:wi2wi,w2sg0004 or wi2wi,w2sg0084
> +- on-off-gpio: the GPIO that controls the module's on-off toggle input
> +
> +Optional properties:
> +- lna-suppy: an (optional) LNA regulator that is enabled together with the
> GPS receiver
> +
> +Example:
> +
> + {
> + gps: w2sg0004 {
> + compatible = "wi2wi,w2sg0004";
> + lna-supply = <>; /* LNA regulator */
> + on-off-gpios = < 17 GPIO_ACTIVE_HIGH>;/* GPIO_145:
> trigger for turning on/off w2sg0004 */
> +};
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index c03d20140366..c56b3181b266 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -345,6 +345,7 @@ voipacVoipac Technologies s.r.o.
> wdWestern Digital Corp.
> wetek WeTek Electronics, limited.
> wexlerWexler
> +wi2wiWi2Wi, Inc.
> winbond Winbond Electronics corp.
> winstar Winstar Display Corp.
> wlf Wolfson Microelectronics
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 60f876b03586..7f97ef8fb6cd 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -509,4 +509,20 @@ source "drivers/misc/mic/Kconfig"
> source "drivers/misc/genwqe/Kconfig"
> source "drivers/misc/echo/Kconfig"
> source "drivers/misc/cxl/Kconfig"
> +
> +config W2SG0004
> + tristate "W2SG00x4 on/off control"
> + depends on GPIOLIB && SERIAL_DEV_BUS
> + help
> + Enable on/off control of W2SG00x4 GPS moduled connected
> + to some SoC UART to allow powering up/down if the /dev/ttyGPSn
> + is opened/closed.
> + It also provides a rfkill gps name to control the LNA power.
> +
> +config W2SG0004_DEBUG
> + bool "W2SG0004 on/off debugging"
> + depends on W2SG0004
> + help
> + Enable driver debugging mode of W2SG0004 GPS.
> +
> endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 81ef3e67acc9..0e88e06e5ee0 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_SRAM_EXEC) += sram-exec.o
> obj-y += mic/
> obj-$(CONFIG_GENWQE) += genwqe/
> obj-$(CONFIG_ECHO)+= echo/
> +obj-$(CONFIG_W2SG0004) += w2sg0004.o
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE)+= cxl/
> obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
> diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
> new file mode 100644
> index ..1b335317c8ac
> --- /dev/null
> +++ b/drivers/misc/w2sg0004.c
> @@ -0,0 +1,646 @@
> +/*
> + * w2sg0004.c
> + * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
> + *
> + * This receiver has an ON/OFF pin which must be toggled to
> + * turn the device 'on' of 'off'. A high->low->high toggle
> + * will switch the device on if it is off, and off if it is on.
> + *
> + * To enable receiving on/off requests we register with the
> + * UART power management notifications.
> + *
> + * It is not possible to directly detect the state of the device.
> + * However when it
Re: [PATCH v3] staging: iio: light: Replace symbolic permissions as per coding style
On 20/05/17 19:36, Brian Masney wrote: On Sat, May 20, 2017 at 06:55:02PM +0100, Jonathan Cameron wrote: On 19/05/17 10:37, surenderpols...@gmail.com wrote: From: Surender Polsani Fixed the following checkpatch.pl warnings: octal permissions are more preferable than symbolic permissions Replaced DEVICE_ATTR family macros with DEVICE_ATTR_RW family as suggested by Greg K-H. Changed attributes and function names where ever required to satisfy internal macro definitions like __ATTR__RW(). Signed-off-by: Surender Polsani Nicely presented patch, but it runs into the fact that some of these shouldn't exist as hand rolled attrs in the first place. Some of theses should be handled through the various info_mask and event_info_mask bitmaps + read_raw etc. This would be a much less mechanical change however... See inline and I'll try and pick out which ones. Brian is working on this driver as well at the moment so there may well be some clashes. Perhaps you two could confer on who will target what? Saves everyone time to work together! You can apply this if you'd like. I just got 7 different hardware samples from Jon this week that are supported by this driver. I haven't gotten far yet with coding since I'm currently working on getting them all setup so that it will be easy for me to test my upcoming driver changes. For my first patch series, I'm planning to migrate the driver to use IIO channels, cleaning up the I2C calls, and runtime power management support. Hopefully I'll have this to you for next weekend. I've applied this patch (with a lot of fuzz as the driver had changed under it). Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to see what we messed up. Jonathan Brian -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KEYS: Delete an error message for a failed memory allocation in get_derived_key()
From: Markus Elfring
Date: Sun, 21 May 2017 11:23:55 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring
---
security/keys/encrypted-keys/encrypted.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/security/keys/encrypted-keys/encrypted.c
b/security/keys/encrypted-keys/encrypted.c
index 1ca895e7e56a..ad57914452c1 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -385,10 +385,9 @@ static int get_derived_key(u8 *derived_key, enum
derived_key_type key_type,
derived_buf_len = HASH_SIZE;
derived_buf = kzalloc(derived_buf_len, GFP_KERNEL);
- if (!derived_buf) {
- pr_err("encrypted_key: out of memory\n");
+ if (!derived_buf)
return -ENOMEM;
- }
+
if (key_type)
strcpy(derived_buf, "AUTH_KEY");
else
--
2.13.0
[tip:x86/urgent] x86/boot: Use CROSS_COMPILE prefix for readelf
Commit-ID: 3780578761921f094179c6289072a74b2228c602
Gitweb: http://git.kernel.org/tip/3780578761921f094179c6289072a74b2228c602
Author: Rob Landley
AuthorDate: Sat, 20 May 2017 15:03:29 -0500
Committer: Thomas Gleixner
CommitDate: Sun, 21 May 2017 13:04:27 +0200
x86/boot: Use CROSS_COMPILE prefix for readelf
The boot code Makefile contains a straight 'readelf' invocation. This
causes build warnings in cross compile environments, when there is no
unprefixed readelf accessible via $PATH.
Add the missing $(CROSS_COMPILE) prefix.
[ tglx: Rewrote changelog ]
Fixes: 98f78525371b ("x86/boot: Refuse to build with data relocations")
Signed-off-by: Rob Landley
Acked-by: Kees Cook
Cc: Jiri Kosina
Cc: Paul Bolle
Cc: "H.J. Lu"
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/ced18878-693a-9576-a024-113ef39a2...@landley.net
Signed-off-by: Thomas Gleixner
---
arch/x86/boot/compressed/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index 44163e8..2c860ad 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -94,7 +94,7 @@ vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
quiet_cmd_check_data_rel = DATAREL $@
define cmd_check_data_rel
for obj in $(filter %.o,$^); do \
- readelf -S $$obj | grep -qF .rel.local && { \
+ ${CROSS_COMPILE}readelf -S $$obj | grep -qF .rel.local && { \
echo "error: $$obj has data relocations!" >&2; \
exit 1; \
} || true; \
[PATCH] LSM: Make security_hook_heads a local variable.
A sealable memory allocator patch was proposed at
http://lkml.kernel.org/r/20170519103811.2183-1-igor.sto...@huawei.com ,
and is waiting for a follow-on patch showing how any of the kernel
can be changed to use this new subsystem. So, here it is for LSM hooks.
The LSM hooks ("struct security_hook_heads security_hook_heads" and
"struct security_hook_list ...[]") will benefit from this allocator via
protection using set_memory_ro()/set_memory_rw(), and it will remove
CONFIG_SECURITY_WRITABLE_HOOKS config option.
This means that these structures will be allocated at run time using
smalloc(), and therefore the address of these structures will be
determined at run time rather than compile time.
But currently, LSM_HOOK_INIT() macro depends on the address of
security_hook_heads being known at compile time. But we already
initialize security_hook_heads as an array of "struct list_head".
Therefore, let's use index number (or relative offset from the head
of security_hook_heads) instead of absolute address of
security_hook_heads so that LSM_HOOK_INIT() macro does not need to
know absolute address of security_hook_heads. Then, security_add_hooks()
will be able to allocate and copy "struct security_hook_list ...[]" using
smalloc().
Signed-off-by: Tetsuo Handa
Cc: Kees Cook
Cc: Paul Moore
Cc: Stephen Smalley
Cc: Casey Schaufler
Cc: James Morris
Cc: Igor Stoppa
Cc: Greg KH
---
include/linux/lsm_hooks.h | 6 +++---
security/security.c | 10 --
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e..865c11d 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1884,8 +1884,8 @@ struct security_hook_heads {
*/
struct security_hook_list {
struct list_headlist;
- struct list_head*head;
union security_list_options hook;
+ const unsigned int idx;
char*lsm;
};
@@ -1896,9 +1896,9 @@ struct security_hook_list {
* text involved.
*/
#define LSM_HOOK_INIT(HEAD, HOOK) \
- { .head = _hook_heads.HEAD, .hook = { .HEAD = HOOK } }
+ { .idx = offsetof(struct security_hook_heads, HEAD) / \
+ sizeof(struct list_head), .hook = { .HEAD = HOOK } }
-extern struct security_hook_heads security_hook_heads;
extern char *lsm_names;
extern void security_add_hooks(struct security_hook_list *hooks, int count,
diff --git a/security/security.c b/security/security.c
index 54b1e39..d6883ce 100644
--- a/security/security.c
+++ b/security/security.c
@@ -33,7 +33,7 @@
/* Maximum number of letters for an LSM name string */
#define SECURITY_NAME_MAX 10
-struct security_hook_heads security_hook_heads __lsm_ro_after_init;
+static struct security_hook_heads security_hook_heads __lsm_ro_after_init;
char *lsm_names;
/* Boot-time LSM user choice */
static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
@@ -152,10 +152,16 @@ void __init security_add_hooks(struct security_hook_list
*hooks, int count,
char *lsm)
{
int i;
+ struct list_head *list = (struct list_head *) _hook_heads;
for (i = 0; i < count; i++) {
+ const unsigned int idx = hooks[i].idx;
+
+ if (WARN_ON(idx >= sizeof(security_hook_heads) /
+ sizeof(struct list_head)))
+ continue;
hooks[i].lsm = lsm;
- list_add_tail_rcu([i].list, hooks[i].head);
+ list_add_tail_rcu([i].list, [idx]);
}
if (lsm_append(lsm, _names) < 0)
panic("%s - Cannot get early memory.\n", __func__);
--
1.8.3.1
RE: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the switch structure
> -Original Message- > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Sent: Sunday, May 21, 2017 13:47 > To: Bernat, Yehezkel > Cc: Levy, Amir (Jer) ; Lukas Wunner > ; Greg Kroah-Hartman ; > Andreas Noever ; Jamet, Michael > ; Andy Lutomirski ; > mario.limoncie...@dell.com; jared.doming...@dell.com; Andy Shevchenko > ; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the > switch structure > > On Sun, May 21, 2017 at 09:55:55AM +, Bernat, Yehezkel wrote: > > > > > > > -Original Message- > > > From: Levy, Amir (Jer) > > > Sent: Sunday, May 21, 2017 11:07 > > > To: Mika Westerberg ; Lukas Wunner > > > > > > Cc: Greg Kroah-Hartman ; Andreas > Noever > > > ; Jamet, Michael > > > ; Bernat, Yehezkel > > > ; Andy Lutomirski ; > > > mario.limoncie...@dell.com; jared.doming...@dell.com; Andy > > > Shevchenko ; > > > linux-kernel@vger.kernel.org > > > Subject: RE: [PATCH 18/24] thunderbolt: Store Thunderbolt generation > > > in the switch structure > > > > > > On Sun, May 21 2017, 11:00 AM, Mika Westerberg wrote: > > > > On Sun, May 21, 2017 at 10:40:41AM +0300, Mika Westerberg wrote: > > > > > On Sun, May 21, 2017 at 07:35:21AM +0200, Lukas Wunner wrote: > > > > > > On Sun, May 21, 2017 at 05:29:47AM +, Levy, Amir (Jer) wrote: > > > > > > > On Sun, May 21 2017, 07:47 AM, Lukas Wunner wrote: > > > > > > > > On Thu, May 18, 2017 at 05:39:08PM +0300, Mika Westerberg > wrote: > > > > > > > > > + > > > > > > > > > + default: > > > > > > > > > + sw->generation = 1; > > > > > > > > > + break; > > > > > > > > > > > > > > > > If someone adds an entry for, say, a new TB3 controller to > > > > > > > > nhi_ids[] but forgets to update this function, the > > > > > > > > controller is assigned the wrong generation number. It > > > > > > > > might be better to make TB3 the default and list each TB1 > > > > > > > > controller instead since it's less likely for Intel to > > > > > > > > introduce an > older gen chip. > > > > > > > > > > > > > > > > Generally I think it's problematic to require that > > > > > > > > multiple files are touched whenever a new controller is > > > > > > > > added. Isn't the generation number or link speed > > > > > > > > (10/20/40) stored in some register in PCI config space (VSEC > 0x1234) or TB config space? > > > > > > > > > > > > > > How about setting information, that isn't available from > > > > > > > PCI, in pci_device_id.driver_data when initializing nhi_ids[]? > > > > > > > > > > > > Right, that would also be possible, though reading the > > > > > > generation number from a register would be more elegant, if such a > register exists. > > > > > > > > > > I don't think there is such register but I can put this > > > > > information to the driver_data instead. > > > > > > > > Actually these are Thunderbolt switch IDs, not NHI PCI IDs so I > > > > don't think driver_data is the right place after all. So if no > > > > objections, I'll update the function to default to TBT3 but keep > > > > the switch case and add the TBT1 IDs + Win Ridge there. > > > > > > There is correlation between switch ID to NHI ID. > > > > I'm not sure defaulting to TBT3 is a good idea. ICM message format can > > be changed, DMA port can be different, nothing guaranties correct > > operation of the driver with newer unknown controllers. > > Fair enough :) Then we just need to remember to update the function here > as new generations get added and tested. > > I suppose you don't know either if we could use the revision or similar field > in > the switch config space to determine generation somehow? Nothing that I'm aware of. Still, I like the idea of having a table-like construct somewhere in the code to centralize the handling of various controller-specific info (generation, DMA port, maybe more things in the future).
Re: is alpha jensen support dead?
> Hi all, > > it seems like the Alpha Jense build (the only one using pci-noop.c) > and thus being a different build than all the later PCI capable > system has been broken since at least: > > commit 6aca0503847f6329460b15b3ab2b0e30bb752793 > Author: Christian Borntraeger > Date: Tue Feb 2 21:46:33 2016 -0800 > > alpha/dma: use common noop dma ops > > which switches pci-noop.c to use generic code, but fat fingered a symbol > and didn't wire up the Kconfig. > > Is there any value in keeping it alive? Especially as there probably > isn't any build coverage.. I do not have any experience with Jensens. > Btw, how well is alpha working these days? It looks like there hasn't > been any maintainer activity for about two years. However, I keep PC164, DS10, DS10L, DS20 alive and plan to revice my XP1000 too. A 21264-base half embedded system worked fine until I broke a connector on it so hoping to revive it too. PC164, DS10, DS10L worked fine with 4.1 for me, others are on earlier kernels. -- Meelis Roos (mr...@linux.ee)
Re: [PATCH v2 5/6] gpio-exar/8250-exar: Make set of exported GPIOs configurable
On 2017-05-18 19:43, Andy Shevchenko wrote:
> On Thu, May 18, 2017 at 5:59 PM, Jan Kiszka wrote:
>> On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
>> rest is required to operate the UART. To allow modeling this case,
>> expand the platform device data structure to specify a (consecutive) pin
>> subset for exporting by the gpio-exar driver.
>
>> + unsigned int first_gpio;
>
> Perhaps pin?
> Or shift?
>
> Because first_gpio a bit confusing with Linux side of GPIO.
Ack, going for "pin".
>
>> - unsigned int bank = offset / 8;
>> - unsigned int addr;
>> + struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
>> + unsigned int bank, addr;
>>
>> + offset += exar_gpio->first_gpio;
>> + bank = offset / 8;
>
> Can't we instead do something like the following:
>
> struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
> unsigned int bank = (offset + exar_gpio->pin) / 8;
> unsigned int line = (offset + exar_gpio->pin) % 8;
>
OK, I'm using this pattern now:
unsigned int addr = (offset + exar_gpio->first_pin) / 8 ?
EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
unsigned int bit = (offset + exar_gpio->first_pin) % 8;
>
>> + pdata.first_gpio = first_gpio;
>> + pdata.ngpio = ngpio;
>
> Still thinking about device properties ("ngpios" and something like
> "exar8250,gpio-start").
Changed back to properties, removing all platform data.
But what's the purpose of prefixing the name here? This does not have
anything to do with device trees. It's a private parameter channel
between the creating device driver and the gpio driver, and there will
be no other bindings.
>
>> + unsigned int first_gpio;
>> + unsigned int ngpio;
>
> u16 ?
>
If we do that, then we would rather have to choose u8. But this is
pointless restriction. I prefer to stay with the native type.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH v2 1/6] gpio: exar: Fix passing in of parent PCI device
On 2017-05-18 19:14, Andy Shevchenko wrote: > On Thu, May 18, 2017 at 5:59 PM, Jan Kiszka wrote: >> This fixes reloading of the GPIO driver for the same platform device >> instance as created by the exar UART driver: First of all, the driver >> sets drvdata to its own value during probing and does not restore the >> original value on exit. But this won't help anyway as the core clears >> drvdata after the driver left. >> >> Use stable platform_data instead. > > Okay, basically what we are trying to do here is to reinvent part of > MFD framework. > > I'd like to hear Linus' and others opinions if it worth to use it instead. > I've looked into MFD modeling, but it would only make sense if we break up the exar driver, change its xr17v35x part into a platform device and create a dual-cell MFD for the PCI device. I don't think that would be beneficial here. There are also dependencies between the UART part and the MPIOs, specifically during init. All that would create a lot of churn to the existing exar code. I'm now passing the parent reference via device.parent instead of using platform data. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
gpio-exar: Why filtering out Commtech devices?
Hi Sudip, why do we carry if (pcidev->vendor != PCI_VENDOR_ID_EXAR) return -ENODEV; in gpio_exar_probe? This effectively prevents that EXAR_DEVICE(COMMTECH, COMMTECH_4222PCIE, pbn_exar_XR17V35x), EXAR_DEVICE(COMMTECH, COMMTECH_4224PCIE, pbn_exar_XR17V35x), EXAR_DEVICE(COMMTECH, COMMTECH_4228PCIE, pbn_exar_XR17V35x), gain GPIO support. Do those devices lack access to the pins? Or can we drop the filter. I don't have access to those devices, just wondering because the code is not explaining the reason. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH 18/24] thunderbolt: Store Thunderbolt generation in the switch structure
On Sun, May 21, 2017 at 11:18:01AM +, Bernat, Yehezkel wrote: > Nothing that I'm aware of. OK. > Still, I like the idea of having a table-like construct somewhere in > the code to centralize the handling of various controller-specific > info (generation, DMA port, maybe more things in the future). Yup, I guess that's something we could try out in the next version of the series.
Re: [PATCH v2 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support
On 17/05/17 12:35, Eugen Hristev wrote:
On 17.05.2017 10:47, Peter Rosin wrote:
On 2017-05-16 20:03, Jonathan Cameron wrote:
As we are only left with one area of questions.
+static const struct at91_adc_trigger at91_adc_trigger_list[] = {
+{
+.name = "external-rising",
+.trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE,
+},
+{
+.name = "external-falling",
+.trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL,
+},
+{
+.name = "external-any",
+.trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY,
+},
Hmm. Should this be a userspace configurable option? Feels rather like
it is an element of the hardware - reflecting the characteristics of
some
hardware device sat on the pin.
The user can choose from sysfs which trigger
is best suited for the use case, since all
three triggers are provided and can be connected to the buffer.
It reflects more the triggering capability of the ADC rather than
any different hardware device sitting on the pin
I am also in favour of a userspace configurable option. For sure it's
hardware related but on our board we only provide a trigger pin, we
don't know which hardware the customer will put on this pin.
hmm. OK I'm persuaded I think.
Could do this with devicetree overlays or similar.
So follow up question is whether this is the right interface.
Can all 3 run at once sensibly? If not are we not looking at a control
parameter for a single trigger?
There is a single trigger hardware pin, but can work in one of the three
modes. Do you suggest I should change it to a single trigger, but then
we need some kind of sysfs entry to control it ?
Or perhaps change the trigger to be exclusive to the device/buffer, in
which case just one trigger can be used anyway with the current_trigger
option in buffer.
If somehow more than one trigger would be enabled in the same time,
only the last enabled one will work, since I write the corresponding
trigger edge configuration value in the ADC register. So in fact these three
triggers are mutually exclusive, as enabling one disables the
other, however, it's not transparent to the user.
Ah that definitely suggests to me it should be a sysfs attribute associated
with the trigger rather than 3 separate triggers. The interpretation
of those triggers would require userspace to have some knowledge of what
is going on, so I don't think we have any problems by requiring it instead
to know about a sysfs attribute.
These kind of different edge triggers used to be in device tree in
older at91 driver.
I have given it thought and decided to let just the driver know about
them. Since they are bound to the ADC IP block and not related to any
hardware description of the board or the special connectivity that
the driver might be interested about. I mean the driver knows the
trigger works this way because it's part of the block, and device tree
cannot change this, so the portability of the driver is not affected
and related to SoC design only.
Sort of (I think..) As I understand it we are still talking about an
external pin? A possible usecase for this sort of thing would be
combining with an external sequencer with an analog mux. In that
case only one of the options will make any sense. (this is the
hardware equivalent of what Peter Rosin's mux subsystem puts
under software control)
The ADTRG is a pin directly connected to the SoC. Since we have
multiple analog channels as input, the mux would be useful if the use
case would imply many more inputs, and then some overload on userspace
to differentiate between the muxed values since the conversion will
happen on the same channel...
This is done by having the channels represented at the end
point - i.e. userspace sees a device representing the inputs to the mux.
The question of how it works is of no interest to userspace at all.
The ADTRG will simply tell the SoC when to do the conversion, with
respect to the charging delay which is a few clock cycles. So the
ADTRG is a digital input and depending on which signal we connect,
and which type of edge we want to catch, we can configure it
via the three triggers (or change to a single parametrized trigger).
The ADC block inside the SoC can also be connected to the PWM signal,
and that trigger is yet to be implemented in the driver (I will do it
in a future patch). So the ADTRG can be connected to an external PWM,
or some kind of signal that is already resemblant with which kind of
conversion speed or intervals between conversions that we want to have
on the analog channels.
Sure, but in all these cases it is a feature of the board so arguably
the configuration should a devicetree question rather than a userspace
one. The unknown edge case (wired out to a terminal) is the only one
where it should be in the domain of userspace.
Particularly interesting is tht there is an internal pwm option. If
that's the case, why would anyone want to use an external one unless
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 2017-05-21 12:47, Jonathan Cameron wrote: > On 17/05/17 16:28, Jan Kiszka wrote: >> This is an upstream port of an IIO driver for the TI ADC108S102 and >> ADC128S102. The former can be found on the Intel Galileo Gen2 and the >> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is >> included. >> >> Due to the lack of regulators under ACPI, we hard-code the voltage >> provided to the VA pin of the ADC to 5 V, the value used on Galileo and >> IOT2000. For DT usage, the regulator "vref-supply" provides this >> information. Note that DT usage has not been tested. >> >> Original author: Bogdan Pricop >> Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel: >> Todor Minchev . >> >> Signed-off-by: Jan Kiszka > Still an issue wrt to it being obviously correct in the ordering in probe > and remove. > > As a reviewer I want to be able to run through each step in probe and > compare with remove to ensure they occur in the opposite order and > reverse all the steps in probe. Where ever it deviates from that I have > to think about it and we all know the last thing a reviewer with a big > backlog of patches wants to do is to think hard ;) > > Anyhow, I've fixed up and applied to the togreg branch of iio.git and > pushed out as testing for the autobuilders to play with it. > > Please check I haven't made a mess of it. Forgot to push? Not finding it in togreg, which is 5 days old. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH v2] iio: adc: bcm_iproc_adc: swap primary and secondary isr handler's
On 16/05/17 07:52, Raveendra Padasalagi wrote:
The third argument of devm_request_threaded_irq() is the primary
handler. It is called in hardirq context and checks whether the
interrupt is relevant to the device. If the primary handler returns
IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is
scheduled to run in process context.
bcm_iproc_adc.c uses the secondary handler as the primary one
and the other way around. So this patch fixes the same, along with
re-naming the secondary handler and primary handler names properly.
Tested on the BCM9583XX iProc SoC based boards.
Fixes: 4324c97ecedc ("iio: Add driver for Broadcom iproc-static-adc")
Reported-by: Pavel Roskin
Signed-off-by: Raveendra Padasalagi
Cc: sta...@vger.kernel.org
Applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
---
Changes in v2:
- Added Cc tag in the Signed-off area to send the patch to stable kernel
- Fixes tag corrected with proper formatting
drivers/iio/adc/bcm_iproc_adc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
index 21d38c8..7f4f9c4 100644
--- a/drivers/iio/adc/bcm_iproc_adc.c
+++ b/drivers/iio/adc/bcm_iproc_adc.c
@@ -143,7 +143,7 @@ static void iproc_adc_reg_dump(struct iio_dev *indio_dev)
iproc_adc_dbg_reg(dev, adc_priv, IPROC_SOFT_BYPASS_DATA);
}
-static irqreturn_t iproc_adc_interrupt_handler(int irq, void *data)
+static irqreturn_t iproc_adc_interrupt_thread(int irq, void *data)
{
u32 channel_intr_status;
u32 intr_status;
@@ -167,7 +167,7 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq,
void *data)
return IRQ_NONE;
}
-static irqreturn_t iproc_adc_interrupt_thread(int irq, void *data)
+static irqreturn_t iproc_adc_interrupt_handler(int irq, void *data)
{
irqreturn_t retval = IRQ_NONE;
struct iproc_adc_priv *adc_priv;
@@ -181,7 +181,7 @@ static irqreturn_t iproc_adc_interrupt_thread(int irq, void
*data)
adc_priv = iio_priv(indio_dev);
regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, _status);
- dev_dbg(_dev->dev, "iproc_adc_interrupt_thread(),INTRPT_STS:%x\n",
+ dev_dbg(_dev->dev,
"iproc_adc_interrupt_handler(),INTRPT_STS:%x\n",
intr_status);
intr_channels = (intr_status & IPROC_ADC_INTR_MASK) >> IPROC_ADC_INTR;
@@ -566,8 +566,8 @@ static int iproc_adc_probe(struct platform_device *pdev)
}
ret = devm_request_threaded_irq(>dev, adc_priv->irqno,
- iproc_adc_interrupt_thread,
iproc_adc_interrupt_handler,
+ iproc_adc_interrupt_thread,
IRQF_SHARED, "iproc-adc", indio_dev);
if (ret) {
dev_err(>dev, "request_irq error %d\n", ret);
Re: [PATCH -next] drm/vgem: Fix return value check in vgem_init()
On Sun, May 21, 2017 at 01:19:39AM +, Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function platform_device_register_simple() returns
> ERR_PTR() and never returns NULL. The NULL test in the return value
> check should be replaced with IS_ERR().
>
> Fixes: 315f0242aa2b ("drm/vgem: Convert to a struct drm_device subclass")
This is wrong, the bug was introduced in
af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
not that it matters since it is the same tag.
> Signed-off-by: Wei Yongjun
Checked it is an ERR_PTR return on failure, so
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 21/05/17 12:59, Jan Kiszka wrote: On 2017-05-21 12:47, Jonathan Cameron wrote: On 17/05/17 16:28, Jan Kiszka wrote: This is an upstream port of an IIO driver for the TI ADC108S102 and ADC128S102. The former can be found on the Intel Galileo Gen2 and the Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is included. Due to the lack of regulators under ACPI, we hard-code the voltage provided to the VA pin of the ADC to 5 V, the value used on Galileo and IOT2000. For DT usage, the regulator "vref-supply" provides this information. Note that DT usage has not been tested. Original author: Bogdan Pricop Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel: Todor Minchev . Signed-off-by: Jan Kiszka Still an issue wrt to it being obviously correct in the ordering in probe and remove. As a reviewer I want to be able to run through each step in probe and compare with remove to ensure they occur in the opposite order and reverse all the steps in probe. Where ever it deviates from that I have to think about it and we all know the last thing a reviewer with a big backlog of patches wants to do is to think hard ;) Anyhow, I've fixed up and applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Please check I haven't made a mess of it. Forgot to push? Not finding it in togreg, which is 5 days old. As it says, pushed out as testing... Togreg is non rebasing so only gets pushed out publicly once all the trivial stuff the autobuilders find has been sorted. Depending on how busy I am it can be a few days before I get a chance to push out togreg, whereas testing goes every few patches when I'm merging stuff. Thanks, Jonathan Jan
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 21/05/17 13:17, Jonathan Cameron wrote: On 21/05/17 12:59, Jan Kiszka wrote: On 2017-05-21 12:47, Jonathan Cameron wrote: On 17/05/17 16:28, Jan Kiszka wrote: This is an upstream port of an IIO driver for the TI ADC108S102 and ADC128S102. The former can be found on the Intel Galileo Gen2 and the Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is included. Due to the lack of regulators under ACPI, we hard-code the voltage provided to the VA pin of the ADC to 5 V, the value used on Galileo and IOT2000. For DT usage, the regulator "vref-supply" provides this information. Note that DT usage has not been tested. Original author: Bogdan Pricop Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel: Todor Minchev . Signed-off-by: Jan Kiszka Still an issue wrt to it being obviously correct in the ordering in probe and remove. As a reviewer I want to be able to run through each step in probe and compare with remove to ensure they occur in the opposite order and reverse all the steps in probe. Where ever it deviates from that I have to think about it and we all know the last thing a reviewer with a big backlog of patches wants to do is to think hard ;) Anyhow, I've fixed up and applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Please check I haven't made a mess of it. Forgot to push? Not finding it in togreg, which is 5 days old. As it says, pushed out as testing... Togreg is non rebasing so only gets pushed out publicly once all the trivial stuff the autobuilders find has been sorted. Depending on how busy I am it can be a few days before I get a chance to push out togreg, whereas testing goes every few patches when I'm merging stuff. Mind you I hadn't pushed that for half an hour or so hence that might have been out of date too ;) Jonathan Thanks, Jonathan Jan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: ccree: add CRYPTO dependency
On Fri, May 19, 2017 at 11:04 AM, Arnd Bergmann wrote:
> A rare randconfig build error shows up when we have CONFIG_CRYPTO=m
> in combination with a built-in CCREE driver:
>
> crypto/hmac.o: In function `hmac_update':
> hmac.c:(.text.hmac_update+0x28): undefined reference to `crypto_shash_update'
> crypto/hmac.o: In function `hmac_setkey':
> hmac.c:(.text.hmac_setkey+0x90): undefined reference to `crypto_shash_digest'
> hmac.c:(.text.hmac_setkey+0x154): undefined reference to `crypto_shash_update'
> drivers/staging/ccree/ssi_cipher.o: In function `ssi_blkcipher_setkey':
> ssi_cipher.c:(.text.ssi_blkcipher_setkey+0x350): undefined reference to
> `crypto_shash_digest'
> drivers/staging/ccree/ssi_cipher.o: In function `ssi_blkcipher_exit':
> ssi_cipher.c:(.text.ssi_blkcipher_exit+0xd4): undefined reference to
> `crypto_destroy_tfm'
> drivers/staging/ccree/ssi_cipher.o: In function `ssi_blkcipher_init':
> ssi_cipher.c:(.text.ssi_blkcipher_init+0x1b0): undefined reference to
> `crypto_alloc_shash'
> drivers/staging/ccree/ssi_cipher.o: In function `ssi_ablkcipher_free':
> ssi_cipher.c:(.text.ssi_ablkcipher_free+0x48): undefined reference to
> `crypto_unregister_alg'
> drivers/staging/ccree/ssi_cipher.o: In function `ssi_ablkcipher_alloc':
> ssi_cipher.c:(.text.ssi_ablkcipher_alloc+0x138): undefined reference to
> `crypto_register_alg'
> ssi_cipher.c:(.text.ssi_ablkcipher_alloc+0x274): undefined reference to
> `crypto_blkcipher_type'
>
> We actually need to depend on both CRYPTO and CRYPTO_HW here to avoid the
> problem, since CRYPTO_HW is a bool symbol and by itself that does not
> force CCREE to be a loadable module when the core cryto support is modular.
>
> Fixes: 50cfbbb7e627 ("staging: ccree: add ahash support")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/staging/ccree/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
> index ae627049c499..4be87f503e3b 100644
> --- a/drivers/staging/ccree/Kconfig
> +++ b/drivers/staging/ccree/Kconfig
> @@ -1,6 +1,6 @@
> config CRYPTO_DEV_CCREE
> tristate "Support for ARM TrustZone CryptoCell C7XX family of Crypto
> accelerators"
> - depends on CRYPTO_HW && OF && HAS_DMA
> + depends on CRYPTO && CRYPTO_HW && OF && HAS_DMA
> default n
> select CRYPTO_HASH
> select CRYPTO_BLKCIPHER
> --
> 2.9.0
>
Thank you and
Acked-By: Gilad Ben-Yossef
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
Re: [PATCH 2/9] timers: provide a "modern" variant of timers
On Sun, May 21, 2017 at 9:00 AM, Christoph Hellwig wrote: > On Thu, May 18, 2017 at 10:57:31AM +0200, Arnd Bergmann wrote: >> How expensive would it be to add another field to timer_list and >> just have both pointers? > > That would add 4/8 bytes to every structure containing a timer, > so I'd rather avoid it if possible. I didn't expect too many timers to be in allocated structures at the same time on most systems, but I haven't researched this at all. We should probably update the comment about the cacheline alignment though: when most users embed the timer_list in some other structure, it's not valid at all, and forcing timer_list to be cacheline aligned would waste way more space than an extra field. > But one option might be to inflict this onto users of outdated compilers > and use the union for modern ones. Good idea, this sounds better than the alternatives at least. The remaining users of those old compilers certainly don't care that much about micro-optimizing the kernel anyway. Arnd
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 2017-05-21 14:18, Jonathan Cameron wrote: > On 21/05/17 13:17, Jonathan Cameron wrote: >> On 21/05/17 12:59, Jan Kiszka wrote: >>> On 2017-05-21 12:47, Jonathan Cameron wrote: On 17/05/17 16:28, Jan Kiszka wrote: > This is an upstream port of an IIO driver for the TI ADC108S102 and > ADC128S102. The former can be found on the Intel Galileo Gen2 and the > Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is > included. > > Due to the lack of regulators under ACPI, we hard-code the voltage > provided to the VA pin of the ADC to 5 V, the value used on Galileo > and > IOT2000. For DT usage, the regulator "vref-supply" provides this > information. Note that DT usage has not been tested. > > Original author: Bogdan Pricop > Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel: > Todor Minchev . > > Signed-off-by: Jan Kiszka Still an issue wrt to it being obviously correct in the ordering in probe and remove. As a reviewer I want to be able to run through each step in probe and compare with remove to ensure they occur in the opposite order and reverse all the steps in probe. Where ever it deviates from that I have to think about it and we all know the last thing a reviewer with a big backlog of patches wants to do is to think hard ;) Anyhow, I've fixed up and applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Please check I haven't made a mess of it. >>> >>> Forgot to push? Not finding it in togreg, which is 5 days old. >>> >> As it says, pushed out as testing... Togreg is non rebasing so only >> gets pushed out publicly once all the trivial stuff the autobuilders >> find has been sorted. >> >> Depending on how busy I am it can be a few days before I get a chance >> to push out togreg, whereas testing goes every few patches when I'm >> merging stuff. > Mind you I hadn't pushed that for half an hour or so hence that might > have been out of date too ;) OK, now I see what went wrong: Please have a second look at commit 52d4de2441af... ;) Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
[PATCH 00/13] Linksys WRT3200ACM (Rango) support
Hi everyone This series adds support for the latest model in Linksys WRT AC series of routers. The WRT3200ACM was released in October 2016 and the code name is Rango. As it comes with a flash chip twice as big the dts Imre Kaloz has written for OpenWrt isn't based on armada-385-linksys.dtsi to avoid conflicts. Nonetheless its part of the same family, so the bigger part of this series is dedicated to reorganize / modernize / cleanup / somewhat future proof the armada-385-linksys.dtsi and it's dependants so the dts for the Rango addition can use the same dtsi. Key differences to the earlier Armada-385 based devices in the series is a bigger flash chip, next generation wireless modules in the mini pcie slots as well as a Marvell SD8887. Finally the CPU is clocked at 1866 GHz by default. The series depends on Linux 4.12-rc1 and is targeted for 4.13. Ralph Ralph Sennhauser (13): ARM: dts: armada-385-linksys: flatten dtsi ARM: dts: armada-385-linksys: label nodes ARM: dts: armada-385-linksys: flatten dependants ARM: dts: armada-385-linksys: drop redundant properties in dependants ARM: dts: armada-385-linksys: bm pools by label order ARM: dts: armada-385-linksys: usb3 label cleanup ARM: dts: armada-385-linksys: drop leagcy DSA bindings ARM: dts: armada-385-linksys: use binary unit prefixes ARM: dts: armada-385-linksys: partition layout is board specific ARM: dts: armada-385-linksys: group pins in pinctrl ARM: dts: armada-385-linksys: fixup button node names clk: mvebu: add support for 1866MHz variants ARM: dts: mvebu: add support for Linksys WRT3200ACM (Rango) arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/armada-385-linksys-caiman.dts | 187 +++- arch/arm/boot/dts/armada-385-linksys-cobra.dts | 187 +++- arch/arm/boot/dts/armada-385-linksys-rango.dts | 203 + arch/arm/boot/dts/armada-385-linksys-shelby.dts | 187 +++- arch/arm/boot/dts/armada-385-linksys.dtsi | 362 drivers/clk/mvebu/armada-38x.c | 3 +- 7 files changed, 695 insertions(+), 435 deletions(-) create mode 100644 arch/arm/boot/dts/armada-385-linksys-rango.dts -- 2.10.2
[PATCH 02/13] ARM: dts: armada-385-linksys: label nodes
Add labels to nodes used by dependants. Also rename node gpio_keys to
gpio-keys to mach the style of the rest of the file as well as the
documented example.
Signed-off-by: Ralph Sennhauser
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 481e4a3..b7f0a16 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -79,7 +79,7 @@
gpio = < 18 GPIO_ACTIVE_HIGH>;
};
- gpio_keys {
+ gpio_keys: gpio-keys {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
@@ -99,7 +99,7 @@
};
};
- gpio-leds {
+ gpio_leds: gpio-leds {
compatible = "gpio-leds";
pinctrl-0 = <_led_pin _led_pin>;
pinctrl-names = "default";
@@ -210,7 +210,7 @@
reg = <0x4c>;
};
- pca9635@68 {
+ expander0: pca9635@68 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "nxp,pca9635";
--
2.10.2
[PATCH 13/13] ARM: dts: mvebu: add support for Linksys WRT3200ACM (Rango)
The Linksys WRT3200ACM (Rango) is the lates Armada-385 based router in
the Linksys WRT AC Series which got released in October 2016.
The file armada-385-linksys-rango.dts is loosly based off of a DTS
authored by Imre Kaloz.
As Rango is part of the armada-385-linksys family of boards use the
armada-385-linksys.dtsi as basis. As for functional differences to Imre
Kaloz dts, the wlan LEDs aren't connected to the expander chip pca9635
but directly to GPIOs. Then mpp47 controls the USB2.0 port and not the
USB3.0 port, so use the correct GPIO mpp44 for it.
Other changes can be categorized as just cleanup / reorganization due to
using the armada-385-linksys.dtsi.
URL:
https://github.com/openwrt/openwrt/blob/0abc3fa5a996daf7dafdc7794ccfe3fa7e955c5a/target/linux/mvebu/files/arch/arm/boot/dts/armada-385-linksys-rango.dts
Signed-off-by: Ralph Sennhauser
---
Notes:
The sdhci node is taken as is, the current node lets one use the
wireless part of the attached sd8887. There is an issue with the
initalization of the bluetooth firmware though. Haven't had the time
to investigate that in depth so far but shouldn't hold up the Rango
addition.
The non-removable property might be more appropriate than broken-cd
though.
Checkpatch complains about the line length of the URL, though not much
room there. Checkpatch also complains about the vendor prefix linksys
not being documented, however this follows the examples given by the
other boards.
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-linksys-rango.dts | 203 +
2 files changed, 204 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-linksys-rango.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c5e1d9..6be2974 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -999,6 +999,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-linksys-rango.dtb \
armada-385-linksys-shelby.dtb \
armada-385-synology-ds116.dtb \
armada-385-turris-omnia.dtb \
diff --git a/arch/arm/boot/dts/armada-385-linksys-rango.dts
b/arch/arm/boot/dts/armada-385-linksys-rango.dts
new file mode 100644
index 000..86f3207
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-linksys-rango.dts
@@ -0,0 +1,203 @@
+/*
+ * Device Tree file for the Linksys WRT3200ACM (Rango)
+ *
+ * Copyright (C) 2016 Imre Kaloz
+ *
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include
+#include
+#include "armada-385-linksys.dtsi"
+
+/ {
+ model = "Linksys WRT3200ACM";
+ compatible = "linksys,rango", "linksys,armada385", "marvell,armada385",
+"marvell,armada380";
+};
+
+ {
+ wan_amber@0 {
+ label = "rango:amber:wan";
+ reg = <0x0>;
+ };
+
+ wan_white@1 {
+ label = "rango:white:wan";
+ reg = <0x1>;
+ };
+
+ usb2@5 {
+ label = "rango:white:usb2";
+ reg = <0x5>;
+ };
+
+ usb3_1@6 {
+ label = "rango:white:usb3_1";
+ reg = <0x6>;
+ };
+
+ usb3_2@7 {
+ label = "rango:white:usb3_2";
+ reg = <0x7>;
+ };
+
+ wps_white@8 {
+
[PATCH 11/13] ARM: dts: armada-385-linksys: fixup button node names
Buttons don't have a reg property; drop pseudo address and fixup names
of individual button nodes. Also drop #address-cells and #size-cells
properties.
Signed-off-by: Ralph Sennhauser
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 1bb974a..e1f355f 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -81,18 +81,16 @@
gpio_keys: gpio-keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
pinctrl-0 = <_keys_pins>;
pinctrl-names = "default";
- button@1 {
+ wps {
label = "WPS";
linux,code = ;
gpios = < 24 GPIO_ACTIVE_LOW>;
};
- button@2 {
+ reset {
label = "Factory Reset Button";
linux,code = ;
gpios = < 29 GPIO_ACTIVE_LOW>;
--
2.10.2
[PATCH 03/13] ARM: dts: armada-385-linksys: flatten dependants
Flatten dts of individual boards to match the new style used in
armada-385-linksys.dtsi and for the Rango addition.
* Caiman - Linksys WRT1200AC v1 & v2
* Cobra - Linksys WRT1900AC v2
* Shelby - Linksys WRT1900ACS v1 & v2
Signed-off-by: Ralph Sennhauser
---
Notes:
power and sata in _leds don't use references when they could,
feels like overdoing things even though it violates one of the guiding
principles of not recreating structure. If someone thinks such a
change is meaningful I don't mind submitting a followup patch, though
would look odd with the Rango dts.
---
arch/arm/boot/dts/armada-385-linksys-caiman.dts | 99 -
arch/arm/boot/dts/armada-385-linksys-cobra.dts | 99 -
arch/arm/boot/dts/armada-385-linksys-shelby.dts | 99 -
3 files changed, 138 insertions(+), 159 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
index f3cee91..765c939 100644
--- a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
@@ -44,71 +44,64 @@
model = "Linksys WRT1200AC";
compatible = "linksys,caiman", "linksys,armada385", "marvell,armada385",
"marvell,armada380";
+};
- soc {
- internal-regs{
- i2c@11000 {
-
- pca9635@68 {
- #address-cells = <1>;
- #size-cells = <0>;
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
- wan_amber@0 {
- label = "caiman:amber:wan";
- reg = <0x0>;
- };
+ wan_amber@0 {
+ label = "caiman:amber:wan";
+ reg = <0x0>;
+ };
- wan_white@1 {
- label = "caiman:white:wan";
- reg = <0x1>;
- };
+ wan_white@1 {
+ label = "caiman:white:wan";
+ reg = <0x1>;
+ };
- wlan_2g@2 {
- label = "caiman:white:wlan_2g";
- reg = <0x2>;
- };
+ wlan_2g@2 {
+ label = "caiman:white:wlan_2g";
+ reg = <0x2>;
+ };
- wlan_5g@3 {
- label = "caiman:white:wlan_5g";
- reg = <0x3>;
- };
+ wlan_5g@3 {
+ label = "caiman:white:wlan_5g";
+ reg = <0x3>;
+ };
- usb2@5 {
- label = "caiman:white:usb2";
- reg = <0x5>;
- };
+ usb2@5 {
+ label = "caiman:white:usb2";
+ reg = <0x5>;
+ };
- usb3_1@6 {
- label = "caiman:white:usb3_1";
- reg = <0x6>;
- };
+ usb3_1@6 {
+ label = "caiman:white:usb3_1";
+ reg = <0x6>;
+ };
- usb3_2@7 {
- label = "caiman:white:usb3_2";
- reg = <0x7>;
- };
+ usb3_2@7 {
+ label = "caiman:white:usb3_2";
+ reg = <0x7>;
+ };
- wps_white@8 {
- label = "caiman:white:wps";
- reg = <0x8>;
- };
+ wps_white@8 {
+ label = "caiman:white:wps";
+ reg = <0x8>;
+ };
- wps_amber@9 {
- label = "caiman:amber:wps";
- reg = <0x9>;
- };
- };
- };
- };
+ wps_amber@9 {
+ label = "caiman:amber:wps";
+ reg = <0x9>;
};
+};
- gpio-leds {
- power {
- label = "caiman:white:power";
- };
+_leds {
+ power {
+ label = "caiman:white:power";
+ };
-
[PATCH 01/13] ARM: dts: armada-385-linksys: flatten dtsi
Since the addition of the spi reference two styles are used. Use
references instead of recreating the same structure over and over again.
This helps to distinguish which are changes to the underlying nodes and
which are new additions and helps helps maintainability in general.
Verified the resulting dtb to be binary identical.
Signed-off-by: Ralph Sennhauser
---
Notes:
Care has been taken to change nothing but flatten and sorting
references by name.
Sorting by internal reg no longer makes sense, would be a pain to
maintain order at least.
Comments have at least one level of indentation, they aren't really
meta comments anyway.
The armada-xp-linksys-mamba.dts already makes much better use of this
style.
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 414 +++---
1 file changed, 206 insertions(+), 208 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 2306c45..481e4a3 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -61,214 +61,6 @@
MBUS_ID(0x09, 0x19) 0 0xf110 0x1
MBUS_ID(0x09, 0x15) 0 0xf111 0x1
MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
-
- internal-regs {
- i2c@11000 {
- pinctrl-names = "default";
- pinctrl-0 = <_pins>;
- status = "okay";
-
- tmp421@4c {
- compatible = "ti,tmp421";
- reg = <0x4c>;
- };
-
- pca9635@68 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "nxp,pca9635";
- reg = <0x68>;
- };
- };
-
- /* J10: VCC, NC, RX, NC, TX, GND */
- serial@12000 {
- status = "okay";
- };
-
- ethernet@7 {
- status = "okay";
- phy-mode = "rgmii-id";
- buffer-manager = <>;
- bm,pool-long = <2>;
- bm,pool-short = <3>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
- ethernet@34000 {
- status = "okay";
- phy-mode = "sgmii";
- buffer-manager = <>;
- bm,pool-long = <0>;
- bm,pool-short = <1>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
- mdio@72004 {
- status = "okay";
-
- switch@0 {
- compatible = "marvell,mv88e6085";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- label = "lan4";
- };
-
- port@1 {
- reg = <1>;
- label = "lan3";
- };
-
- port@2 {
- reg = <2>;
- label = "lan2";
- };
-
- port@3 {
- reg = <3>;
- label = "lan1";
- };
-
- port@4 {
-
[PATCH 04/13] ARM: dts: armada-385-linksys: drop redundant properties in dependants
Drop redundant declaration of #address-cells and #size-cells.
Signed-off-by: Ralph Sennhauser
---
arch/arm/boot/dts/armada-385-linksys-caiman.dts | 3 ---
arch/arm/boot/dts/armada-385-linksys-cobra.dts | 3 ---
arch/arm/boot/dts/armada-385-linksys-shelby.dts | 3 ---
3 files changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
index 765c939..05e854a 100644
--- a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
@@ -47,9 +47,6 @@
};
{
- #address-cells = <1>;
- #size-cells = <0>;
-
wan_amber@0 {
label = "caiman:amber:wan";
reg = <0x0>;
diff --git a/arch/arm/boot/dts/armada-385-linksys-cobra.dts
b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
index 2ae1e71..5b1662b 100644
--- a/arch/arm/boot/dts/armada-385-linksys-cobra.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
@@ -47,9 +47,6 @@
};
{
- #address-cells = <1>;
- #size-cells = <0>;
-
wan_amber@0 {
label = "cobra:amber:wan";
reg = <0x0>;
diff --git a/arch/arm/boot/dts/armada-385-linksys-shelby.dts
b/arch/arm/boot/dts/armada-385-linksys-shelby.dts
index 74f4273..a909371 100644
--- a/arch/arm/boot/dts/armada-385-linksys-shelby.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-shelby.dts
@@ -47,9 +47,6 @@
};
{
- #address-cells = <1>;
- #size-cells = <0>;
-
wan_amber@0 {
label = "shelby:amber:wan";
reg = <0x0>;
--
2.10.2
[PATCH 05/13] ARM: dts: armada-385-linksys: bm pools by label order
Which pools we assing doesn't matter. Use the order which doesen't leave
a chance for questions for first time readers.
Signed-off-by: Ralph Sennhauser
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index b7f0a16..932fca4 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -180,8 +180,8 @@
status = "okay";
phy-mode = "rgmii-id";
buffer-manager = <>;
- bm,pool-long = <2>;
- bm,pool-short = <3>;
+ bm,pool-long = <0>;
+ bm,pool-short = <1>;
fixed-link {
speed = <1000>;
full-duplex;
@@ -192,8 +192,8 @@
status = "okay";
phy-mode = "sgmii";
buffer-manager = <>;
- bm,pool-long = <0>;
- bm,pool-short = <1>;
+ bm,pool-long = <2>;
+ bm,pool-short = <3>;
fixed-link {
speed = <1000>;
full-duplex;
--
2.10.2
[PATCH 06/13] ARM: dts: armada-385-linksys: usb3 label cleanup
Now that we use the reference for the USB3.0 port update the node name
and labels for the phy and vbus to match the label used by
armada-38x.dtsi.
Signed-off-by: Ralph Sennhauser
---
Notes:
Going by documentation regulator-name is only of informative nature so
changing it should be a non issue.
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 932fca4..6cc1ec7 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -63,16 +63,16 @@
MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
};
- usb3_phy: usb3_phy {
+ usb3_1_phy: usb3_1-phy {
compatible = "usb-nop-xceiv";
- vcc-supply = <_xhci0_vbus>;
+ vcc-supply = <_1_vbus>;
};
- reg_xhci0_vbus: xhci0-vbus {
+ usb3_1_vbus: usb3_1-vbus {
compatible = "regulator-fixed";
pinctrl-names = "default";
- pinctrl-0 = <_vbus_pins>;
- regulator-name = "xhci0-vbus";
+ pinctrl-0 = <_1_vbus_pins>;
+ regulator-name = "usb3_1-vbus";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
enable-active-high;
@@ -371,7 +371,7 @@
marvell,function = "gpio";
};
- xhci0_vbus_pins: xhci0-vbus-pins {
+ usb3_1_vbus_pins: usb3_1-vbus-pins {
marvell,pins = "mpp50";
marvell,function = "gpio";
};
@@ -393,5 +393,5 @@
_1 {
status = "okay";
- usb-phy = <_phy>;
+ usb-phy = <_1_phy>;
};
--
2.10.2
[PATCH 07/13] ARM: dts: armada-385-linksys: drop leagcy DSA bindings
The new ones work so there is little reason to keep the legacy bindings.
Use the rework as the oportunity to drop the legacy node.
Signed-off-by: Ralph Sennhauser
---
Notes:
There is little harm in keeping them but probably no value either, so
use the cleanup series to get rid of them.
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 47 ---
1 file changed, 47 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 6cc1ec7..f1d6b77 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -115,53 +115,6 @@
linux,default-trigger = "disk-activity";
};
};
-
- dsa@0 {
- status = "disabled";
-
- compatible = "marvell,dsa";
- #address-cells = <2>;
- #size-cells = <0>;
-
- dsa,ethernet = <>;
- dsa,mii-bus = <>;
-
- switch@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0x0 0>; /* MDIO address 0, switch 0 in tree */
-
- port@0 {
- reg = <0>;
- label = "lan4";
- };
-
- port@1 {
- reg = <1>;
- label = "lan3";
- };
-
- port@2 {
- reg = <2>;
- label = "lan2";
- };
-
- port@3 {
- reg = <3>;
- label = "lan1";
- };
-
- port@4 {
- reg = <4>;
- label = "wan";
- };
-
- port@5 {
- reg = <5>;
- label = "cpu";
- };
- };
- };
};
{
--
2.10.2
[PATCH 08/13] ARM: dts: armada-385-linksys: use binary unit prefixes
Use IEEE 1541-2002 unit prefixes for sizes.
Signed-off-by: Ralph Sennhauser
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index f1d6b77..4049eaf 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -52,7 +52,7 @@
memory {
device_type = "memory";
- reg = <0x 0x2000>; /* 512 MB */
+ reg = <0x 0x2000>; /* 512 MiB */
};
soc {
@@ -180,50 +180,50 @@
partition@0 {
label = "u-boot";
- reg = <0x000 0x20>; /* 2MB */
+ reg = <0x000 0x20>; /* 2MiB */
read-only;
};
partition@10 {
label = "u_env";
- reg = <0x20 0x4>;/* 256KB */
+ reg = <0x20 0x4>;/* 256KiB */
};
partition@14 {
label = "s_env";
- reg = <0x24 0x4>;/* 256KB */
+ reg = <0x24 0x4>;/* 256KiB */
};
partition@90 {
label = "devinfo";
- reg = <0x90 0x10>; /* 1MB */
+ reg = <0x90 0x10>; /* 1MiB */
read-only;
};
/* kernel1 overlaps with rootfs1 by design */
partition@a0 {
label = "kernel1";
- reg = <0xa0 0x280>; /* 40MB */
+ reg = <0xa0 0x280>; /* 40MiB */
};
partition@100 {
label = "rootfs1";
- reg = <0x100 0x220>; /* 34MB */
+ reg = <0x100 0x220>; /* 34MiB */
};
/* kernel2 overlaps with rootfs2 by design */
partition@320 {
label = "kernel2";
- reg = <0x320 0x280>; /* 40MB */
+ reg = <0x320 0x280>; /* 40MiB */
};
partition@380 {
label = "rootfs2";
- reg = <0x380 0x220>; /* 34MB */
+ reg = <0x380 0x220>; /* 34MiB */
};
/*
-* 38MB, last MB is for the BBT, not writable
+* 38MiB, last MiB is for the BBT, not writable
*/
partition@5a0 {
label = "syscfg";
@@ -238,7 +238,7 @@
*/
partition@18 {
label = "unused_area";
- reg = <0x28 0x68>; /* 6.5MB */
+ reg = <0x28 0x68>; /* 6.5MiB */
};
};
--
2.10.2
[PATCH 12/13] clk: mvebu: add support for 1866MHz variants
The Linksys WRT3200ACM CPU is clocked at 1866MHz. Add 1866MHz to
the list of supported CPU frequencies.
Noticed by the following warning:
[0.00] Selected CPU frequency (16) unsupported
Signed-off-by: Ralph Sennhauser
---
drivers/clk/mvebu/armada-38x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mvebu/armada-38x.c b/drivers/clk/mvebu/armada-38x.c
index 8bccf4e..6a92eb6 100644
--- a/drivers/clk/mvebu/armada-38x.c
+++ b/drivers/clk/mvebu/armada-38x.c
@@ -49,7 +49,8 @@ static const u32 armada_38x_cpu_frequencies[] __initconst = {
0, 0, 0, 0,
1066 * 1000 * 1000, 0, 0, 0,
1332 * 1000 * 1000, 0, 0, 0,
- 1600 * 1000 * 1000,
+ 1600 * 1000 * 1000, 0, 0, 0,
+ 1866 * 1000 * 1000
};
static u32 __init armada_38x_get_cpu_freq(void __iomem *sar)
--
2.10.2
[PATCH 10/13] ARM: dts: armada-385-linksys: group pins in pinctrl
A pin group per node is sufficient, further specialisation only serves
as documentation which can be a comment just as well. This simplifies
configuring pins for nodes in dependants.
Also use labels which end up right by the node they are intended for.
Signed-off-by: Ralph Sennhauser
---
arch/arm/boot/dts/armada-385-linksys.dtsi | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi
b/arch/arm/boot/dts/armada-385-linksys.dtsi
index 485abff..1bb974a 100644
--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -83,7 +83,7 @@
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
- pinctrl-0 = <_pin>;
+ pinctrl-0 = <_keys_pins>;
pinctrl-names = "default";
button@1 {
@@ -101,7 +101,7 @@
gpio_leds: gpio-leds {
compatible = "gpio-leds";
- pinctrl-0 = <_led_pin _led_pin>;
+ pinctrl-0 = <_leds_pins>;
pinctrl-names = "default";
power {
@@ -247,18 +247,15 @@
};
{
- keys_pin: keys-pin {
+ gpio_keys_pins: gpio-keys-pins {
+ /* mpp24: wps, mpp29: reset */
marvell,pins = "mpp24", "mpp29";
marvell,function = "gpio";
};
- power_led_pin: power-led-pin {
- marvell,pins = "mpp55";
- marvell,function = "gpio";
- };
-
- sata_led_pin: sata-led-pin {
- marvell,pins = "mpp54";
+ gpio_leds_pins: gpio-leds-pins {
+ /* mpp54: sata, mpp55: power */
+ marvell,pins = "mpp54", "mpp55";
marvell,function = "gpio";
};
--
2.10.2
[PATCH 09/13] ARM: dts: armada-385-linksys: partition layout is board specific
Move the partition layout to individual boards. The Linksys WRT 3200 ACM
(Rango) comes with a 256MiB nand flash chip and different layout.
Signed-off-by: Ralph Sennhauser
---
Dismissed alternatives:
a) Partition layouts as fragments for use with overlay. While the only
alternative which might be worth considering it depends on optional
overlay support. So should be selected by the target or at least be in
the defconfig. Also feels like the mechanism wasn't intended to be
used like this. Also bloats the dtbS.
b) Adding a separate node for each variant would require to delete the
others in the individual dts, just not enabling them isn't enough.
c) Use partition layout dtsi which can be included separately. Two more
dtsi for now.
d) Delete and recreate partitions / nand node for Rango.
e) Make partitions child nodes of a partition-layout node to ease
defining custom layouts. Somewhat big of a change
---
arch/arm/boot/dts/armada-385-linksys-caiman.dts | 67 +
arch/arm/boot/dts/armada-385-linksys-cobra.dts | 67 +
arch/arm/boot/dts/armada-385-linksys-shelby.dts | 67 +
arch/arm/boot/dts/armada-385-linksys.dtsi | 64 +--
4 files changed, 202 insertions(+), 63 deletions(-)
diff --git a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
index 05e854a..ee669ae 100644
--- a/arch/arm/boot/dts/armada-385-linksys-caiman.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-caiman.dts
@@ -102,3 +102,70 @@
label = "caiman:white:sata";
};
};
+
+ {
+ /* 128MiB */
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x000 0x20>; /* 2MiB */
+ read-only;
+ };
+
+ partition@10 {
+ label = "u_env";
+ reg = <0x20 0x4>;/* 256KiB */
+ };
+
+ partition@14 {
+ label = "s_env";
+ reg = <0x24 0x4>;/* 256KiB */
+ };
+
+ partition@90 {
+ label = "devinfo";
+ reg = <0x90 0x10>; /* 1MiB */
+ read-only;
+ };
+
+ /* kernel1 overlaps with rootfs1 by design */
+ partition@a0 {
+ label = "kernel1";
+ reg = <0xa0 0x280>; /* 40MiB */
+ };
+
+ partition@100 {
+ label = "rootfs1";
+ reg = <0x100 0x220>; /* 34MiB */
+ };
+
+ /* kernel2 overlaps with rootfs2 by design */
+ partition@320 {
+ label = "kernel2";
+ reg = <0x320 0x280>; /* 40MiB */
+ };
+
+ partition@380 {
+ label = "rootfs2";
+ reg = <0x380 0x220>; /* 34MiB */
+ };
+
+ /*
+* 38MiB, last MiB is for the BBT, not writable
+*/
+ partition@5a0 {
+ label = "syscfg";
+ reg = <0x5a0 0x260>;
+ };
+
+ /*
+* Unused area between "s_env" and "devinfo".
+* Moved here because otherwise the renumbered
+* partitions would break the bootloader
+* supplied bootargs
+*/
+ partition@18 {
+ label = "unused_area";
+ reg = <0x28 0x68>; /* 6.5MiB */
+ };
+};
diff --git a/arch/arm/boot/dts/armada-385-linksys-cobra.dts
b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
index 5b1662b..5169ca8 100644
--- a/arch/arm/boot/dts/armada-385-linksys-cobra.dts
+++ b/arch/arm/boot/dts/armada-385-linksys-cobra.dts
@@ -102,3 +102,70 @@
label = "cobra:white:sata";
};
};
+
+ {
+ /* 128MiB */
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x000 0x20>; /* 2MiB */
+ read-only;
+ };
+
+ partition@10 {
+ label = "u_env";
+ reg = <0x20 0x4>;/* 256KiB */
+ };
+
+ partition@14 {
+ label = "s_env";
+ reg = <0x24 0x4>;/* 256KiB */
+ };
+
+ partition@90 {
+ label = "devinfo";
+ reg = <0x90 0x10>; /* 1MiB */
+ read-only;
+ };
+
+ /* kernel1 overlaps with rootfs1 by design */
+ partition@a0 {
+ label = "kernel1";
+ reg = <0xa0 0x280>; /* 40MiB */
+ };
+
+ partition@100 {
+ label = "rootfs1";
+ reg = <0x100 0x220>; /* 34MiB */
+ };
+
+ /* kernel2 overlaps with rootfs2 by design */
+ partition@320 {
+ label = "kernel2";
+ reg = <0x320 0x280>; /* 40MiB */
+ };
+
+ partition@380 {
+ label = "rootfs2";
+ reg = <0x380 0x220>; /* 34MiB */
+
Re: [v4 1/1] mm: Adaptive hash table scaling
Hi Andi, Thank you for looking at this. I mentioned earlier, I would not want to impose a cap. However, if you think that for example dcache needs a cap, there is already a mechanism for that via high_limit argument, so the client can be changed to provide that cap. However, this particular patch addresses scaling problem for everyone by making it scale with memory at a slower pace. Thank you, Pasha On 05/20/2017 10:07 PM, Andi Kleen wrote: Pavel Tatashin writes: Allow hash tables to scale with memory but at slower pace, when HASH_ADAPT is provided every time memory quadruples the sizes of hash tables will only double instead of quadrupling as well. This algorithm starts working only when memory size reaches a certain point, currently set to 64G. This is example of dentry hash table size, before and after four various memory configurations: IMHO the scale is still too aggressive. I find it very unlikely that a 1TB machine really needs 256MB of hash table because number of used files are unlikely to directly scale with memory. Perhaps should just cap it at some large size, e.g. 32M -Andi -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org;> em...@kvack.org
Re: [PATCH V3] acpi: apei: check for pending errors when probing GHES entries
On Thu, May 18, 2017 at 03:22:42PM -0600, Tyler Baicar wrote: > Check for pending errors when probing GHES entries. It is possible > that a fatal error is already pending at this point, so we should > handle it as soon as the driver is probed. This also avoids a > potential issue if there was an interrupt that was already > cleared for an error since the GHES driver wasn't present. > > V3: Check for pending errors of all GHES types > > Signed-off-by: Tyler Baicar > --- > drivers/acpi/apei/ghes.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > index d0855c0..5347230 100644 > --- a/drivers/acpi/apei/ghes.c > +++ b/drivers/acpi/apei/ghes.c > @@ -1039,6 +1039,9 @@ static int ghes_probe(struct platform_device *ghes_dev) > } > platform_set_drvdata(ghes_dev, ghes); > > + /* Handle any pending errors right away */ > + ghes_proc(ghes); > + > return 0; > err_edac_unreg: > ghes_edac_unregister(ghes); Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [PATCH 02/24] thunderbolt: Do not try to read UID if DROM offset is read as 0
On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg wrote: > At least Falcon Ridge when in host mode does not have any kind of DROM > available and reading DROM offset returns 0 for these. Do not try to > read DROM any further in that case. > > Signed-off-by: Mika Westerberg > Reviewed-by: Yehezkel Bernat > Reviewed-by: Michael Jamet > --- > drivers/thunderbolt/eeprom.c | 3 +++ > 1 file changed, 3 insertions(+) > Hi Mika, nice work, it is nice to see Intel contribute to the Thunderbolt driver (I can second Lukas's 'jaw drop' comment)! I will try to read through everything today, but maybe the last few patches will get pushed back to next weekend. > diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c > index 6392990c984d..e4e64b130514 100644 > --- a/drivers/thunderbolt/eeprom.c > +++ b/drivers/thunderbolt/eeprom.c > @@ -276,6 +276,9 @@ int tb_drom_read_uid_only(struct tb_switch *sw, u64 *uid) > if (res) > return res; > > + if (drom_offset == 0) > + return -ENODEV; > + I think that this will make tb_switch_resume bail out on the root switch, which is not good. Since the uid is only used to detect whether a different device was plugged in while the system was suspended I think that we can safely ignore the uid on the root switch: - don't read it in tb_drom_read (route == 0 is already special cased anyways) - add a special case for the root switch to tb_switch_resume and don't read the uid - just assume that it did not change (should be impossible anyways) What do you think? Andreas > /* read uid */ > res = tb_eeprom_read_n(sw, drom_offset, data, 9); > if (res) > -- > 2.11.0 >
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 21/05/17 13:44, Jan Kiszka wrote: On 2017-05-21 14:18, Jonathan Cameron wrote: On 21/05/17 13:17, Jonathan Cameron wrote: On 21/05/17 12:59, Jan Kiszka wrote: On 2017-05-21 12:47, Jonathan Cameron wrote: On 17/05/17 16:28, Jan Kiszka wrote: This is an upstream port of an IIO driver for the TI ADC108S102 and ADC128S102. The former can be found on the Intel Galileo Gen2 and the Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is included. Due to the lack of regulators under ACPI, we hard-code the voltage provided to the VA pin of the ADC to 5 V, the value used on Galileo and IOT2000. For DT usage, the regulator "vref-supply" provides this information. Note that DT usage has not been tested. Original author: Bogdan Pricop Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel: Todor Minchev . Signed-off-by: Jan Kiszka Still an issue wrt to it being obviously correct in the ordering in probe and remove. As a reviewer I want to be able to run through each step in probe and compare with remove to ensure they occur in the opposite order and reverse all the steps in probe. Where ever it deviates from that I have to think about it and we all know the last thing a reviewer with a big backlog of patches wants to do is to think hard ;) Anyhow, I've fixed up and applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Please check I haven't made a mess of it. Forgot to push? Not finding it in togreg, which is 5 days old. As it says, pushed out as testing... Togreg is non rebasing so only gets pushed out publicly once all the trivial stuff the autobuilders find has been sorted. Depending on how busy I am it can be a few days before I get a chance to push out togreg, whereas testing goes every few patches when I'm merging stuff. Mind you I hadn't pushed that for half an hour or so hence that might have been out of date too ;) OK, now I see what went wrong: Please have a second look at commit 52d4de2441af... ;) Jan Gah! Thanks. I knew I did that initially but thought I'd unwound the mess. Seems not - here goes again for trying not to be an idiot. Thanks for pointing this mess out. J
Re: linux-next 20170519 - semaphores broken
Hi valdis,
On 05/20/2017 10:18 PM, valdis.kletni...@vt.edu wrote:
Seeing problems with programs that use semaphores. The one
that I'm getting bit by is jackd. strace says:
getuid()= 967
semget(0x282929, 0, 000)= 229376
semop(229376, [{0, -1, SEM_UNDO}], 1) = -1 EIDRM (Identifier removed)
write(2, "JACK semaphore error: semop (Ide"..., 49JACK semaphore error: semop
(Identifier removed)
) = 49
Bisects down to this commit, and reverting it from 20170519 makes things work
again. No idea why this causes indigestion, there's probably something subtly
wrong here
Duh, thanks.
There was another report that got a 99% improvement, which I did not
understand.
Probable root cause:
sma = container_of(ipc_rcu_alloc(size), struct sem_array,
sem_perm);
if (!sma)
return -ENOMEM;
memset(sma, 0, size);
sma->sem_perm.refcount was initialized by ipc_rcu_alloc.
And due to the SEM_UNDO, the refcount is relevant.
Thanks for bisecting it, I'll update the patch.
--
Manfred
Re: [PATCH v6] iio: adc: Add support for TI ADC108S102 and ADC128S102
On 21/05/17 15:06, Jonathan Cameron wrote: On 21/05/17 13:44, Jan Kiszka wrote: On 2017-05-21 14:18, Jonathan Cameron wrote: On 21/05/17 13:17, Jonathan Cameron wrote: On 21/05/17 12:59, Jan Kiszka wrote: On 2017-05-21 12:47, Jonathan Cameron wrote: On 17/05/17 16:28, Jan Kiszka wrote: This is an upstream port of an IIO driver for the TI ADC108S102 and ADC128S102. The former can be found on the Intel Galileo Gen2 and the Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is included. Due to the lack of regulators under ACPI, we hard-code the voltage provided to the VA pin of the ADC to 5 V, the value used on Galileo and IOT2000. For DT usage, the regulator "vref-supply" provides this information. Note that DT usage has not been tested. Original author: Bogdan Pricop Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel: Todor Minchev . Signed-off-by: Jan Kiszka Still an issue wrt to it being obviously correct in the ordering in probe and remove. As a reviewer I want to be able to run through each step in probe and compare with remove to ensure they occur in the opposite order and reverse all the steps in probe. Where ever it deviates from that I have to think about it and we all know the last thing a reviewer with a big backlog of patches wants to do is to think hard ;) Anyhow, I've fixed up and applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Please check I haven't made a mess of it. Forgot to push? Not finding it in togreg, which is 5 days old. As it says, pushed out as testing... Togreg is non rebasing so only gets pushed out publicly once all the trivial stuff the autobuilders find has been sorted. Depending on how busy I am it can be a few days before I get a chance to push out togreg, whereas testing goes every few patches when I'm merging stuff. Mind you I hadn't pushed that for half an hour or so hence that might have been out of date too ;) OK, now I see what went wrong: Please have a second look at commit 52d4de2441af... ;) Jan Gah! Thanks. I knew I did that initially but thought I'd unwound the mess. Seems not - here goes again for trying not to be an idiot. Thanks for pointing this mess out. Should now all be fixed up. I pulled the messed up patch to the tip and split it up into the original two patches. 'looks' right now I think but if you wouldn't mind having a quick look that would be great. Jonathan J -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] iio: adc: sun4i-gpadc-iio: fix parent device being used in devm function
On 18/05/17 07:51, Maxime Ripard wrote:
On Thu, May 18, 2017 at 08:36:07AM +0200, Quentin Schulz wrote:
For the sake of DT binding stability, this IIO driver is a child of an
MFD driver for Allwinner A10, A13 and A31 because there already exists a
DT binding for this IP. The MFD driver has a DT node but the IIO driver
does not.
The IIO device registers the temperature sensor in the thermal framework
using the DT node of the parent, the MFD device, so the thermal
framework could match the phandle to the MFD device in the DT and the
struct device used to register in the thermal framework.
devm_thermal_zone_of_sensor_register was previously used to register the
thermal sensor with the parent struct device of the IIO device,
representing the MFD device. By doing so, we registered actually the
parent in the devm routine and not the actual IIO device.
This lead to the devm unregister function not being called when the IIO
module driver is removed. It resulted in the thermal framework still
polling the get_temp function of the IIO module while the device doesn't
exist anymore, thus generated a kernel panic.
Use the non-devm function instead and do the unregister manually in the
remove function.
Fixes: d1caa9905538 ("iio: adc: add support for Allwinner SoCs ADC")
Signed-off-by: Quentin Schulz
Reported-by: Corentin Labbe
Reviewed-by: Maxime Ripard
Maxime
Thanks to all involved with tracking this one down.
Jonathan
Re: [PATCH v7 01/26] ptrace,x86: Make user_64bit_mode() available to 32-bit builds
On Fri, May 05, 2017 at 11:16:59AM -0700, Ricardo Neri wrote: > In its current form, user_64bit_mode() can only be used when CONFIG_X86_64 > is selected. This implies that code built with CONFIG_X86_64=n cannot use > it. If a piece of code needs to be built for both CONFIG_X86_64=y and > CONFIG_X86_64=n and wants to use this function, it needs to wrap it in > an #ifdef/#endif; potentially, in multiple places. > > This can be easily avoided with a single #ifdef/#endif pair within > user_64bit_mode() itself. > > Suggested-by: Borislav Petkov > Cc: Dave Hansen > Cc: Adam Buchbinder > Cc: Colin Ian King > Cc: Lorenzo Stoakes > Cc: Qiaowei Ren > Cc: Arnaldo Carvalho de Melo > Cc: Masami Hiramatsu > Cc: Adrian Hunter > Cc: Kees Cook > Cc: Thomas Garnier > Cc: Peter Zijlstra > Cc: Borislav Petkov > Cc: Dmitry Vyukov > Cc: Ravi V. Shankar > Cc: x...@kernel.org > Signed-off-by: Ricardo Neri > --- > arch/x86/include/asm/ptrace.h | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [PATCH v7 02/26] x86/mm: Relocate page fault error codes to traps.h
On Fri, May 05, 2017 at 11:17:00AM -0700, Ricardo Neri wrote:
> Up to this point, only fault.c used the definitions of the page fault error
> codes. Thus, it made sense to keep them within such file. Other portions of
> code might be interested in those definitions too. For instance, the User-
> Mode Instruction Prevention emulation code will use such definitions to
> emulate a page fault when it is unable to successfully copy the results
> of the emulated instructions to user space.
>
> While relocating the error code enumeration, the prefix X86_ is used to
> make it consistent with the rest of the definitions in traps.h. Of course,
> code using the enumeration had to be updated as well. No functional changes
> were performed.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: Andy Lutomirski
> Cc: "Kirill A. Shutemov"
> Cc: Josh Poimboeuf
> Cc: Dave Hansen
> Cc: Paul Gortmaker
> Cc: x...@kernel.org
> Reviewed-by: Andy Lutomirski
> Signed-off-by: Ricardo Neri
> ---
> arch/x86/include/asm/traps.h | 18 +
> arch/x86/mm/fault.c | 88
> +---
> 2 files changed, 52 insertions(+), 54 deletions(-)
...
> @@ -1382,7 +1362,7 @@ __do_page_fault(struct pt_regs *regs, unsigned long
> error_code,
>* space check, thus avoiding the deadlock:
>*/
> if (unlikely(!down_read_trylock(>mmap_sem))) {
> - if ((error_code & PF_USER) == 0 &&
> + if ((error_code & X86_PF_USER) == 0 &&
if (!(error_code & X86_PF_USER))
With that fixed:
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
RE: [PATCH v3 1/2] PCI/portdrv: add support for different MSI interrupts for PCIe port services
Hi Christoph > -Original Message- > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci- > ow...@vger.kernel.org] On Behalf Of Christoph Hellwig > Sent: 21 May 2017 09:33 > To: Gabriele Paoloni > Cc: bhelg...@google.com; helg...@kernel.org; Linuxarm; linux- > p...@vger.kernel.org; lu...@wunner.de; linux-kernel@vger.kernel.org; > mika.westerb...@linux.intel.com; h...@infradead.org; liudongdong (C) > Subject: Re: [PATCH v3 1/2] PCI/portdrv: add support for different MSI > interrupts for PCIe port services > > > +* > > +* pci_irq_vector() below is able to handle entry > diff erently > > +* depending on MSI vs MSI-x case > > +* > > */ > > One more instance of this comment left :) I thought that in your previous review you meant to say that we should avoid 2 instances of the same comment (in this patchset I only have this instance as I have removed the same comment from patch 2/2...) > > > pcie_capability_read_word(dev, PCI_EXP_FLAGS, ); > > entry = (reg16 & PCI_EXP_FLAGS_IRQ) >> 9; > > @@ -100,7 +107,10 @@ static int pcie_port_enable_msix(struct pci_dev > *dev, int *irqs, int mask) > > * MSI/MSI-X vectors assigned to the port is going to be > used > > * for AER, where "For MSI-X, the value in this register > > * indicates which MSI-X Table entry is used to generate > the > > -* interrupt message." > > +* interrupt message." and "For MSI, the value > > +* in this field indicates the offset between the base > Message > > +* Data and the interrupt message that is generated." > > +* > > */ > > And while this is getting a little too deep into nitpicking: we > usually > don't add empty lines to the end of comments. Ok I can remove the extra line and send out patch v4... Many thanks Gab
[PATCH 00/11 linux-next] super magic values consolidation
This small patchset reorganizes magic.h and fixes filesystems which defined locally super magic values. Fabian Frederick (11): uapi: reorganize magic.h exofs: use magic.h ceph: use magic.h orangefs: use magic.h ubifs: use magic.h jfs: use magic.h ocfs2: use magic.h fuse: use magic.h freevxfs: use magic.h fs: define hfs super magic values globally hfsplus: export super magic value fs/ceph/super.h| 4 +- fs/exofs/common.h | 6 +-- fs/freevxfs/vxfs.h | 6 +-- fs/fuse/control.c | 3 +- fs/fuse/inode.c| 3 +- fs/hfs/hfs.h | 4 +- fs/hfsplus/hfsplus_raw.h | 2 +- fs/hfsplus/part_tbl.c | 2 - fs/jfs/jfs_incore.h| 6 +-- fs/ocfs2/ocfs2_fs.h| 5 +-- fs/orangefs/protocol.h | 3 +- fs/ubifs/ubifs.h | 4 +- include/uapi/linux/magic.h | 104 ++--- 13 files changed, 65 insertions(+), 87 deletions(-) -- 2.9.3
[PATCH 02/11 linux-next] exofs: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h
instead of a local definition.
Signed-off-by: Fabian Frederick
---
fs/exofs/common.h | 6 +-
include/uapi/linux/magic.h | 1 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/fs/exofs/common.h b/fs/exofs/common.h
index 7d88ef5..fb988f9 100644
--- a/fs/exofs/common.h
+++ b/fs/exofs/common.h
@@ -37,6 +37,7 @@
#define __EXOFS_COM_H__
#include
+#include
#include
#include
@@ -79,11 +80,6 @@ enum {
#define EXOFS_BLKSHIFT 12
#define EXOFS_BLKSIZE (1UL << EXOFS_BLKSHIFT)
-/
- * superblock-related things
- /
-#define EXOFS_SUPER_MAGIC 0x5DF5
-
/*
* The file system control block - stored in object EXOFS_SUPER_ID's data.
* This is where the in-memory superblock is stored on disk.
diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
index e3bb43b..1265355 100644
--- a/include/uapi/linux/magic.h
+++ b/include/uapi/linux/magic.h
@@ -26,6 +26,7 @@
#define EXT2_SUPER_MAGIC 0xEF53
#define EXT3_SUPER_MAGIC 0xEF53
#define EXT4_SUPER_MAGIC 0xEF53
+#define EXOFS_SUPER_MAGIC 0x5DF5
#define F2FS_SUPER_MAGIC 0xF2F52010
#define FUTEXFS_SUPER_MAGIC0xBAD1DEA
#define HOSTFS_SUPER_MAGIC 0x00c0ffee
--
2.9.3
[PATCH 01/11 linux-next] uapi: reorganize magic.h
-Sort magic.h in alphabetical order as there were no real logic in this file. -Replace all spaces with tabs -Remove excessive comments for reiserfs Signed-off-by: Fabian Frederick --- include/uapi/linux/magic.h | 92 -- 1 file changed, 40 insertions(+), 52 deletions(-) diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index e230af2..e3bb43b 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -3,86 +3,74 @@ #define ADFS_SUPER_MAGIC 0xadf5 #define AFFS_SUPER_MAGIC 0xadff -#define AFS_SUPER_MAGIC0x5346414F +#define AFS_SUPER_MAGIC0x5346414F +#define ANON_INODE_FS_MAGIC0x09041934 #define AUTOFS_SUPER_MAGIC 0x0187 +#define BALLOON_KVM_MAGIC 0x13661366 +#define BDEVFS_MAGIC 0x62646576 +#define BINFMTFS_MAGIC 0x42494e4d +#define BPF_FS_MAGIC 0xcafe4a11 +#define BTRFS_SUPER_MAGIC 0x9123683E +#define BTRFS_TEST_MAGIC 0x73727279 +#define CGROUP2_SUPER_MAGIC0x63677270 +#define CGROUP_SUPER_MAGIC 0x27e0eb #define CODA_SUPER_MAGIC 0x73757245 #define CRAMFS_MAGIC 0x28cd3d45 /* some random number */ #define CRAMFS_MAGIC_WEND 0x453dcd28 /* magic number with the wrong endianess */ -#define DEBUGFS_MAGIC 0x64626720 -#define SECURITYFS_MAGIC 0x73636673 -#define SELINUX_MAGIC 0xf97cff8c -#define SMACK_MAGIC0x43415d53 /* "SMAC" */ -#define RAMFS_MAGIC0x858458f6 /* some random number */ -#define TMPFS_MAGIC0x01021994 -#define HUGETLBFS_MAGIC0x958458f6 /* some random number */ -#define SQUASHFS_MAGIC 0x73717368 +#define DAXFS_MAGIC0x64646178 +#define DEBUGFS_MAGIC 0x64626720 +#define DEVPTS_SUPER_MAGIC 0x1cd1 #define ECRYPTFS_SUPER_MAGIC 0xf15f +#define EFIVARFS_MAGIC 0xde5e81e4 #define EFS_SUPER_MAGIC0x414A53 #define EXT2_SUPER_MAGIC 0xEF53 #define EXT3_SUPER_MAGIC 0xEF53 -#define XENFS_SUPER_MAGIC 0xabba1974 #define EXT4_SUPER_MAGIC 0xEF53 -#define BTRFS_SUPER_MAGIC 0x9123683E -#define NILFS_SUPER_MAGIC 0x3434 #define F2FS_SUPER_MAGIC 0xF2F52010 +#define FUTEXFS_SUPER_MAGIC0xBAD1DEA +#define HOSTFS_SUPER_MAGIC 0x00c0ffee #define HPFS_SUPER_MAGIC 0xf995e849 +#define HUGETLBFS_MAGIC0x958458f6 /* some random number */ #define ISOFS_SUPER_MAGIC 0x9660 #define JFFS2_SUPER_MAGIC 0x72b6 -#define PSTOREFS_MAGIC 0x6165676C -#define EFIVARFS_MAGIC 0xde5e81e4 -#define HOSTFS_SUPER_MAGIC 0x00c0ffee -#define OVERLAYFS_SUPER_MAGIC 0x794c7630 - -#define MINIX_SUPER_MAGIC 0x137F /* minix v1 fs, 14 char names */ -#define MINIX_SUPER_MAGIC2 0x138F /* minix v1 fs, 30 char names */ #define MINIX2_SUPER_MAGIC 0x2468 /* minix v2 fs, 14 char names */ #define MINIX2_SUPER_MAGIC20x2478 /* minix v2 fs, 30 char names */ #define MINIX3_SUPER_MAGIC 0x4d5a /* minix v3 fs, 60 char names */ - +#define MINIX_SUPER_MAGIC 0x137F /* minix v1 fs, 14 char names */ +#define MINIX_SUPER_MAGIC2 0x138F /* minix v1 fs, 30 char names */ #define MSDOS_SUPER_MAGIC 0x4d44 /* MD */ +#define MTD_INODE_FS_MAGIC 0x11307854 #define NCP_SUPER_MAGIC0x564c /* Guess, what 0x564c is :-) */ #define NFS_SUPER_MAGIC0x6969 +#define NILFS_SUPER_MAGIC 0x3434 +#define NSFS_MAGIC 0x6e736673 #define OPENPROM_SUPER_MAGIC 0x9fa1 +#define OVERLAYFS_SUPER_MAGIC 0x794c7630 +#define PIPEFS_MAGIC 0x50495045 +#define PROC_SUPER_MAGIC 0x9fa0 +#define PSTOREFS_MAGIC 0x6165676C #define QNX4_SUPER_MAGIC 0x002f /* qnx4 fs detection */ #define QNX6_SUPER_MAGIC 0x68191122 /* qnx6 fs detection */ - +#define RAMFS_MAGIC0x858458f6 /* some random number */ +#define RDTGROUP_SUPER_MAGIC 0x7655821 +#define REISER2FS_JR_SUPER_MAGIC_STRING"ReIsEr3Fs" +#define REISER2FS_SUPER_MAGIC_STRING "ReIsEr2Fs" #define REISERFS_SUPER_MAGIC 0x52654973 /* used by gcc */ - /* used by file system utilities that - look at the superblock, etc. */ #define REISERFS_SUPER_MAGIC_STRING"ReIsErFs" -#define REISER2FS_SUPER_MAGIC_STRING "ReIsEr2Fs" -#define REISER2FS_JR_SUPER_MAGIC_STRING"ReIsEr3Fs" - +#define SECURITYFS_MAGIC 0x73636673 +#define SELINUX_MAGIC 0xf97cff8c +#define SMACK_MAGIC0x43415d53 /* "SMAC" */ #define SMB_SUPER_MAGIC0x517B -#define CGROUP_SUPER_MAGIC 0x27e0eb -#define CGROUP2_SUPER_MAGIC0x63677270 - -#define RDTGROUP_SUPER_MAGIC 0x7655821 - -#define STACK_END_MAGIC0x57AC6E9D - -#define TRACEFS_MAGIC
[PATCH 03/11 linux-next] ceph: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h instead of a local definition. Signed-off-by: Fabian Frederick --- fs/ceph/super.h| 4 +--- include/uapi/linux/magic.h | 1 + 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/ceph/super.h b/fs/ceph/super.h index a973acd..8be85c4 100644 --- a/fs/ceph/super.h +++ b/fs/ceph/super.h @@ -15,6 +15,7 @@ #include #include #include +#include #include @@ -22,9 +23,6 @@ #include #endif -/* f_type in struct statfs */ -#define CEPH_SUPER_MAGIC 0x00c36400 - /* large granularity for statfs utilization stats to facilitate * large volume sizes on 32-bit machines. */ #define CEPH_BLOCK_SHIFT 22 /* 4 MB */ diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index 1265355..507f3c3 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -12,6 +12,7 @@ #define BPF_FS_MAGIC 0xcafe4a11 #define BTRFS_SUPER_MAGIC 0x9123683E #define BTRFS_TEST_MAGIC 0x73727279 +#define CEPH_SUPER_MAGIC 0x00c36400 #define CGROUP2_SUPER_MAGIC0x63677270 #define CGROUP_SUPER_MAGIC 0x27e0eb #define CODA_SUPER_MAGIC 0x73757245 -- 2.9.3
[PATCH 04/11 linux-next] orangefs: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h instead of a local definition. Signed-off-by: Fabian Frederick --- fs/orangefs/protocol.h | 3 +-- include/uapi/linux/magic.h | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/orangefs/protocol.h b/fs/orangefs/protocol.h index 48bcc1b..a511ac6 100644 --- a/fs/orangefs/protocol.h +++ b/fs/orangefs/protocol.h @@ -3,6 +3,7 @@ #include #include #include +#include /* pvfs2-config.h ***/ #define ORANGEFS_VERSION_MAJOR 2 @@ -80,8 +81,6 @@ typedef __u64 ORANGEFS_ds_position; typedef __s32 ORANGEFS_error; typedef __s64 ORANGEFS_offset; -#define ORANGEFS_SUPER_MAGIC 0x20030528 - /* * ORANGEFS error codes are a signed 32-bit integer. Error codes are negative, but * the sign is stripped before decoding. diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index 507f3c3..a83c48f 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -47,6 +47,7 @@ #define NILFS_SUPER_MAGIC 0x3434 #define NSFS_MAGIC 0x6e736673 #define OPENPROM_SUPER_MAGIC 0x9fa1 +#define ORANGEFS_SUPER_MAGIC 0x20030528 #define OVERLAYFS_SUPER_MAGIC 0x794c7630 #define PIPEFS_MAGIC 0x50495045 #define PROC_SUPER_MAGIC 0x9fa0 -- 2.9.3
[PATCH 06/11 linux-next] jfs: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h
instead of a local definition.
Signed-off-by: Fabian Frederick
---
fs/jfs/jfs_incore.h| 6 +-
include/uapi/linux/magic.h | 1 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/fs/jfs/jfs_incore.h b/fs/jfs/jfs_incore.h
index 1f26d19..64b9152 100644
--- a/fs/jfs/jfs_incore.h
+++ b/fs/jfs/jfs_incore.h
@@ -23,16 +23,12 @@
#include
#include
#include
+#include
#include "jfs_types.h"
#include "jfs_xtree.h"
#include "jfs_dtree.h"
/*
- * JFS magic number
- */
-#define JFS_SUPER_MAGIC 0x3153464a /* "JFS1" */
-
-/*
* JFS-private inode information
*/
struct jfs_inode_info {
diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
index b651a02..905eaa2 100644
--- a/include/uapi/linux/magic.h
+++ b/include/uapi/linux/magic.h
@@ -34,6 +34,7 @@
#define HPFS_SUPER_MAGIC 0xf995e849
#define HUGETLBFS_MAGIC0x958458f6 /* some random number */
#define ISOFS_SUPER_MAGIC 0x9660
+#define JFS_SUPER_MAGIC0x3153464a /* "JFS1" */
#define JFFS2_SUPER_MAGIC 0x72b6
#define MINIX2_SUPER_MAGIC 0x2468 /* minix v2 fs, 14 char names */
#define MINIX2_SUPER_MAGIC20x2478 /* minix v2 fs, 30 char names */
--
2.9.3
[PATCH 05/11 linux-next] ubifs: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h instead of a local definition. Signed-off-by: Fabian Frederick --- fs/ubifs/ubifs.h | 4 +--- include/uapi/linux/magic.h | 1 + 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index 298b4d8..abc60d5 100644 --- a/fs/ubifs/ubifs.h +++ b/fs/ubifs/ubifs.h @@ -38,6 +38,7 @@ #include #include #include +#include #ifdef CONFIG_UBIFS_FS_ENCRYPTION #include #else @@ -49,9 +50,6 @@ /* Version of this UBIFS implementation */ #define UBIFS_VERSION 1 -/* UBIFS file system VFS magic number */ -#define UBIFS_SUPER_MAGIC 0x24051905 - /* Number of UBIFS blocks per VFS page */ #define UBIFS_BLOCKS_PER_PAGE (PAGE_SIZE / UBIFS_BLOCK_SIZE) #define UBIFS_BLOCKS_PER_PAGE_SHIFT (PAGE_SHIFT - UBIFS_BLOCK_SHIFT) diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index a83c48f..b651a02 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -70,6 +70,7 @@ #define SYSFS_MAGIC0x62656572 #define TMPFS_MAGIC0x01021994 #define TRACEFS_MAGIC 0x74726163 +#define UBIFS_SUPER_MAGIC 0x24051905 #define UDF_SUPER_MAGIC0x15013346 /* Since UDF 2.01 is ISO 13346 based... */ #define USBDEVICE_SUPER_MAGIC 0x9fa2 #define V9FS_MAGIC 0x01021997 -- 2.9.3
[PATCH 07/11 linux-next] ocfs2: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h instead of a local definition. Signed-off-by: Fabian Frederick --- fs/ocfs2/ocfs2_fs.h| 5 ++--- include/uapi/linux/magic.h | 1 + 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/ocfs2/ocfs2_fs.h b/fs/ocfs2/ocfs2_fs.h index 44d178b..5bb4a89 100644 --- a/fs/ocfs2/ocfs2_fs.h +++ b/fs/ocfs2/ocfs2_fs.h @@ -25,6 +25,8 @@ #ifndef _OCFS2_FS_H #define _OCFS2_FS_H +#include + /* Version */ #define OCFS2_MAJOR_REV_LEVEL 0 #define OCFS2_MINOR_REV_LEVEL 90 @@ -56,9 +58,6 @@ #define OCFS2_MIN_BLOCKSIZE512 #define OCFS2_MAX_BLOCKSIZEOCFS2_MIN_CLUSTERSIZE -/* Filesystem magic number */ -#define OCFS2_SUPER_MAGIC 0x7461636f - /* Object signatures */ #define OCFS2_SUPER_BLOCK_SIGNATURE"OCFSV2" #define OCFS2_INODE_SIGNATURE "INODE01" diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index 905eaa2..2621eaf 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -47,6 +47,7 @@ #define NFS_SUPER_MAGIC0x6969 #define NILFS_SUPER_MAGIC 0x3434 #define NSFS_MAGIC 0x6e736673 +#define OCFS2_SUPER_MAGIC 0x7461636f #define OPENPROM_SUPER_MAGIC 0x9fa1 #define ORANGEFS_SUPER_MAGIC 0x20030528 #define OVERLAYFS_SUPER_MAGIC 0x794c7630 -- 2.9.3
[PATCH 10/11 linux-next] fs: define hfs super magic values globally
hfs values were defined twice (in hfs and hfsplus) This patch exports values globally and include magic.h in hfs.h and hfsplus_raw.h where other magic are going to be exported as well. Signed-off-by: Fabian Frederick --- fs/hfs/hfs.h | 4 ++-- fs/hfsplus/hfsplus_raw.h | 1 + fs/hfsplus/part_tbl.c | 2 -- include/uapi/linux/magic.h | 2 ++ 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/hfs/hfs.h b/fs/hfs/hfs.h index 6f194d0..4a10a84 100644 --- a/fs/hfs/hfs.h +++ b/fs/hfs/hfs.h @@ -9,6 +9,8 @@ #ifndef _HFS_H #define _HFS_H +#include + /* offsets to various blocks */ #define HFS_DD_BLK 0 /* Driver Descriptor block */ #define HFS_PMAP_BLK 1 /* First block of partition map */ @@ -18,8 +20,6 @@ #define HFS_DRVR_DESC_MAGIC0x4552 /* "ER": driver descriptor map */ #define HFS_OLD_PMAP_MAGIC 0x5453 /* "TS": old-type partition map */ #define HFS_NEW_PMAP_MAGIC 0x504D /* "PM": new-type partition map */ -#define HFS_SUPER_MAGIC0x4244 /* "BD": HFS MDB (super block) */ -#define HFS_MFS_SUPER_MAGIC0xD2D7 /* MFS MDB (super block) */ /* various FIXED size parameters */ #define HFS_SECTOR_SIZE512/* size of an HFS sector */ diff --git a/fs/hfsplus/hfsplus_raw.h b/fs/hfsplus/hfsplus_raw.h index 8298d09..80554d4 100644 --- a/fs/hfsplus/hfsplus_raw.h +++ b/fs/hfsplus/hfsplus_raw.h @@ -14,6 +14,7 @@ #define _LINUX_HFSPLUS_RAW_H #include +#include /* Some constants */ #define HFSPLUS_SECTOR_SIZE512 diff --git a/fs/hfsplus/part_tbl.c b/fs/hfsplus/part_tbl.c index 63164eb..12d3e0b 100644 --- a/fs/hfsplus/part_tbl.c +++ b/fs/hfsplus/part_tbl.c @@ -26,8 +26,6 @@ #define HFS_DRVR_DESC_MAGIC0x4552 /* "ER": driver descriptor map */ #define HFS_OLD_PMAP_MAGIC 0x5453 /* "TS": old-type partition map */ #define HFS_NEW_PMAP_MAGIC 0x504D /* "PM": new-type partition map */ -#define HFS_SUPER_MAGIC0x4244 /* "BD": HFS MDB (super block) */ -#define HFS_MFS_SUPER_MAGIC0xD2D7 /* MFS MDB (super block) */ /* * The new style Mac partition map diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index e61d5af..8690964 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -32,6 +32,8 @@ #define FUSE_CTL_SUPER_MAGIC 0x65735543 #define FUSE_SUPER_MAGIC 0x65735546 #define FUTEXFS_SUPER_MAGIC0xBAD1DEA +#define HFS_SUPER_MAGIC0x4244 /* "BD": HFS MDB (super block) */ +#define HFS_MFS_SUPER_MAGIC0xD2D7 /* MFS MDB (super block) */ #define HOSTFS_SUPER_MAGIC 0x00c0ffee #define HPFS_SUPER_MAGIC 0xf995e849 #define HUGETLBFS_MAGIC0x958458f6 /* some random number */ -- 2.9.3
[PATCH 09/11 linux-next] freevxfs: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h instead of a local definition. Signed-off-by: Fabian Frederick --- fs/freevxfs/vxfs.h | 6 +- include/uapi/linux/magic.h | 1 + 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/freevxfs/vxfs.h b/fs/freevxfs/vxfs.h index a41ea0b..3bde7dd 100644 --- a/fs/freevxfs/vxfs.h +++ b/fs/freevxfs/vxfs.h @@ -38,11 +38,7 @@ * superblocks of the Veritas Filesystem. */ #include - -/* - * Superblock magic number (vxfs_super->vs_magic). - */ -#define VXFS_SUPER_MAGIC 0xa501FCF5 +#include /* * The root inode. diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index 6afc4b2..e61d5af 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -78,6 +78,7 @@ #define UDF_SUPER_MAGIC0x15013346 /* Since UDF 2.01 is ISO 13346 based... */ #define USBDEVICE_SUPER_MAGIC 0x9fa2 #define V9FS_MAGIC 0x01021997 +#define VXFS_SUPER_MAGIC 0xa501FCF5 #define XENFS_SUPER_MAGIC 0xabba1974 #define ZSMALLOC_MAGIC 0x58295829 -- 2.9.3
[PATCH 08/11 linux-next] fuse: use magic.h
Filesystems generally use SUPER_MAGIC values from magic.h
instead of a local definition.
Signed-off-by: Fabian Frederick
---
fs/fuse/control.c | 3 +--
fs/fuse/inode.c| 3 +--
include/uapi/linux/magic.h | 2 ++
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/fuse/control.c b/fs/fuse/control.c
index b9ea99c..9015c15 100644
--- a/fs/fuse/control.c
+++ b/fs/fuse/control.c
@@ -10,8 +10,7 @@
#include
#include
-
-#define FUSE_CTL_SUPER_MAGIC 0x65735543
+#include
/*
* This is non-NULL when the single instance of the control filesystem
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index 5a1b58f..5362761 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Miklos Szeredi ");
MODULE_DESCRIPTION("Filesystem in Userspace");
@@ -49,8 +50,6 @@ MODULE_PARM_DESC(max_user_congthresh,
"Global limit for the maximum congestion threshold an "
"unprivileged user can set");
-#define FUSE_SUPER_MAGIC 0x65735546
-
#define FUSE_DEFAULT_BLKSIZE 512
/** Maximum number of outstanding background requests */
diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
index 2621eaf..6afc4b2 100644
--- a/include/uapi/linux/magic.h
+++ b/include/uapi/linux/magic.h
@@ -29,6 +29,8 @@
#define EXT4_SUPER_MAGIC 0xEF53
#define EXOFS_SUPER_MAGIC 0x5DF5
#define F2FS_SUPER_MAGIC 0xF2F52010
+#define FUSE_CTL_SUPER_MAGIC 0x65735543
+#define FUSE_SUPER_MAGIC 0x65735546
#define FUTEXFS_SUPER_MAGIC0xBAD1DEA
#define HOSTFS_SUPER_MAGIC 0x00c0ffee
#define HPFS_SUPER_MAGIC 0xf995e849
--
2.9.3
[PATCH 11/11 linux-next] hfsplus: export super magic value
Filesystems generally use SUPER_MAGIC values from magic.h instead of a local definition. Signed-off-by: Fabian Frederick --- fs/hfsplus/hfsplus_raw.h | 1 - include/uapi/linux/magic.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/hfsplus/hfsplus_raw.h b/fs/hfsplus/hfsplus_raw.h index 80554d4..246d22d 100644 --- a/fs/hfsplus/hfsplus_raw.h +++ b/fs/hfsplus/hfsplus_raw.h @@ -22,7 +22,6 @@ #define HFSPLUS_VOLHEAD_SECTOR 2 #define HFSPLUS_VOLHEAD_SIG 0x482b #define HFSPLUS_VOLHEAD_SIGX0x4858 -#define HFSPLUS_SUPER_MAGIC 0x482b #define HFSPLUS_MIN_VERSION 4 #define HFSPLUS_CURRENT_VERSION 5 diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h index 8690964..c0df8e1 100644 --- a/include/uapi/linux/magic.h +++ b/include/uapi/linux/magic.h @@ -34,6 +34,7 @@ #define FUTEXFS_SUPER_MAGIC0xBAD1DEA #define HFS_SUPER_MAGIC0x4244 /* "BD": HFS MDB (super block) */ #define HFS_MFS_SUPER_MAGIC0xD2D7 /* MFS MDB (super block) */ +#define HFSPLUS_SUPER_MAGIC 0x482b #define HOSTFS_SUPER_MAGIC 0x00c0ffee #define HPFS_SUPER_MAGIC 0xf995e849 #define HUGETLBFS_MAGIC0x958458f6 /* some random number */ -- 2.9.3
DEADLOCK: bisected to d215aab82d81974f438bfbc80aa437132f3c37c3 ("cpu/hotplug: Convert hotplug locking to percpu rwsem")
Hello
Since linux-next-20170517 at least I got the following DEADLOCK warning:
[4.311614]
[4.316919] WARNING: possible recursive locking detected
[4.37] 4.12.0-rc1-next-20170517+ #273 Not tainted
[4.327360]
[4.332665] swapper/0/1 is trying to acquire lock:
[4.337451] (cpu_hotplug_lock.rw_sem){++}, at: []
stop_machine+0x1c/0x3c
[4.345468]
but task is already holding lock:
[4.351294] (cpu_hotplug_lock.rw_sem){++}, at: []
static_key_slow_inc+0x14/0x24
[4.359911]
other info that might help us debug this:
[4.366431] Possible unsafe locking scenario:
[4.372344]CPU0
[4.374789]
[4.377233] lock(cpu_hotplug_lock.rw_sem);
[4.381504] lock(cpu_hotplug_lock.rw_sem);
[4.385775]
*** DEADLOCK ***
[4.391691] May be due to missing lock nesting notation
[4.398472] 5 locks held by swapper/0/1:
[4.402390] #0: (net_mutex){+.+.+.}, at: []
register_pernet_subsys+0x28/0x48
[4.410491] #1: (register_ipv4_hooks){+.+.+.}, at: []
ipv4_hooks_register+0xdc/0x1e0
[4.419285] #2: (defrag4_mutex){+.+.+.}, at: []
nf_defrag_ipv4_enable+0x48/0x8c
[4.427643] #3: (cpu_hotplug_lock.rw_sem){++}, at: []
static_key_slow_inc+0x14/0x24
[4.436694] #4: (jump_label_mutex){+.+...}, at: []
__static_key_slow_inc+0x78/0xec
[4.445312]
stack backtrace:
[4.449669] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.12.0-rc1-next-20170517+ #273
[4.457402] Hardware name: Allwinner sun8i Family
[4.462100] Backtrace:
[4.464557] [] (dump_backtrace) from []
(show_stack+0x18/0x1c)
[4.472121] r7:c0c2dbd0 r6: r5:2093 r4:c0c2dbd0
[4.477780] [] (show_stack) from []
(dump_stack+0xac/0xd8)
[4.485002] [] (dump_stack) from []
(__lock_acquire+0xbc0/0x19f0)
[4.492829] r10:ef05b200 r9:c0d8779c r8: r7:c0c2dcc0 r6:
r5:c1480500
[4.500649] r4:c0d8779c r3:6093
[4.504228] [] (__lock_acquire) from []
(lock_acquire+0x74/0x90)
[4.511967] r10:c0b37858 r9:c0c55348 r8:0001 r7:0001 r6:6013
r5:
[4.519786] r4:e000
[4.522324] [] (lock_acquire) from []
(get_online_cpus+0x58/0xe0)
[4.530140] r8:c0959570 r7:c01cc998 r6:c0c18ff4 r5: r4:c0c19644
[4.536838] [] (get_online_cpus) from []
(stop_machine+0x1c/0x3c)
[4.544662] r7:c09bd668 r6: r5:ef04dce8 r4:c010f964
[4.550320] [] (stop_machine) from []
(patch_text+0x2c/0x34)
[4.557709] r7:c09bd668 r6:c1498a14 r5:c0c58b64 r4:c06ad878
[4.563367] [] (patch_text) from []
(arch_jump_label_transform+0x28/0x44)
[4.571886] [] (arch_jump_label_transform) from []
(__jump_label_update+0x94/0x9c)
[4.581181] r5:c0c58b64 r4:c0c58a68
[4.584758] [] (__jump_label_update) from []
(jump_label_update+0x94/0x130)
[4.593448] r7:c09bd668 r6:eea252c0 r5:c1498a14 r4:c0c58b64
[4.599105] [] (jump_label_update) from []
(__static_key_slow_inc+0xd8/0xec)
[4.607881] r7:c09bd668 r6:eea252c0 r5:c0c57964 r4:c1498a14
[4.613538] [] (__static_key_slow_inc) from []
(static_key_slow_inc+0x1c/0x24)
[4.622486] r5:c0c57964 r4:c1498a14
[4.626067] [] (static_key_slow_inc) from []
(nf_register_net_hook+0x148/0x1a8)
[4.635102] r5:c0c57964 r4:c0c501c0
[4.638682] [] (nf_register_net_hook) from []
(nf_register_net_hooks+0x40/0x78)
[4.647721] r9:c0c55348 r8:0002 r7:c0c4fd00 r6:c0c57b15 r5:
r4:c0c55348
[4.655461] [] (nf_register_net_hooks) from []
(nf_defrag_ipv4_enable+0x74/0x8c)
[4.664587] r9:c0c578ae r8:0009 r7:0009 r6:c0c57b15 r5:c0c4fd00
r4:
[4.672319] [] (nf_defrag_ipv4_enable) from []
(ipv4_hooks_register+0x1a4/0x1e0)
[4.681441] r5:c0c4fd00 r4:eea25180
[4.685022] [] (ipv4_hooks_register) from []
(nf_ct_l3proto_pernet_register+0x30/0x3c)
[4.694666] r7:ef0dc800 r6:c0c4fd00 r5:c0c4fd00 r4:
[4.700325] [] (nf_ct_l3proto_pernet_register) from []
(ipv4_net_init+0x30/0x68)
[4.709452] [] (ipv4_net_init) from []
(ops_init+0x104/0x16c)
[4.716926] r5:eea25180 r4:c0c552a0
[4.720506] [] (ops_init) from []
(register_pernet_operations+0x108/0x1ac)
[4.729111] r9:c0c43cb4 r8:ef04de70 r7:c0c4fcd0 r6:c0c552a0 r5:
r4:c0c4fd00
[4.736852] [] (register_pernet_operations) from []
(register_pernet_subsys+0x34/0x48)
[4.746497] r9: r8:c0c607c0 r7:c0b37850 r6:c0c552a0 r5:c0c4fc44
r4:c0c4fc40
[4.754241] [] (register_pernet_subsys) from []
(nf_conntrack_l3proto_ipv4_init+0x38/0xb4)
[4.764232] r7:c0b37850 r6:e000 r5:c0b2cf24 r4:
[4.769893] [] (nf_conntrack_l3proto_ipv4_init) from []
(do_one_initcall+0x5c/0x198)
[4.779361] r5:c0b2cf24 r4:c0c0f4cc
[4.782942] [] (do_one_initcall) from []
(kernel_init_freeable+0x254/0x2e8)
[4.791635] r9:0007
Re: [PATCH] ACPI / GED: use late init to allow other drivers init
Hi Rafael, On 5/15/2017 6:59 AM, Rafael J. Wysocki wrote: > On Mon, May 15, 2017 at 4:36 AM, Sinan Kaya wrote: >> Hi Rafael, >> >> On 5/11/2017 10:52 AM, Rafael J. Wysocki wrote: OK. I'll reach out to Harb and let's see where the proposal goes. >>> It looks like this is about operation regions after all, however, so _DEP >>> as is >>> should be sufficient here. >>> >>> There is some limited _DEP support in the ACPI layer, but we were missing >>> a way to represent those dependencies in the driver core. >>> >>> That can be done through device_link objects now, so we may be able to >>> support >>> _DEP in a more meaningful way, but the cases when _DEP is used for something >>> different from operation regions in practice need to be treated with >>> caution. >>> >>> >> >> _DEP could certainly help here. However, _DEP doesn't answer the loose >> binding question. >> If one driver is missing in one operating system, _GED driver will never >> load due >> to unsatisfied dependency. This forces us into all or none condition. We >> have operating >> systems that we need to support and do not have vendor I2C or GPIO drivers. >> That's why, >> we are hesitant to place _DEP into ACPI tables. > > _DEP as defined in the spec should be fine still. > > Quoting directly: > > "_DEP evaluates to a package and designates device objects that OSPM > should assign a higher > priority in start ordering due to future operation region accesses. > > To increase the likelihood that an SPB operation region handler is > available when needed, OSPM > needs to know in advance which methods will access it -- _DEP provides > OSPM with this > information. While the _DEP keyword may be used to determine start > ordering, only the _REG > method (Section 6.5.4) callbacks can be relied upon to determine > whether a region is accessible at a > given point in time." > > So according to the above, _DEP is advisory only and you need _REG. > > In theory, because I'm not sure if _REG actually works. I have been testing _REG this week. It seems to be working just fine. We are transitioning our FW to use _REG. Our experience with _DEP in other operating systems is a hard dependency rather than a soft dependency. We have observed some drivers not loading if the driver providing the dependency is not present at all. That's why, I have been taking my time evaluating this. > >> The problem is that there is no concept of per event dependency. This could >> have helped >> us figure out if such an interrupt should be enabled or not. >> >> Another solution for operating regions is _REG if FW wants to ignore the >> event during >> boot. This is the one we are looking into at this moment for non-critical >> events. >> >> late_init proposed in this patch helps for built-in drivers such as GHES >> where we do >> not want to ignore events. Since GHES is not an actual device, this has to >> be solved >> in ACPI. > > For built-in things it would be better to have explicit initialization > ordering, eg. initializing both GHES and GED from one initcall in the > right order. > > Using different initcall levels for them is sort of OK, but then it is > not quite clear from the code what the specific ordering requirement > is, so please add a comment describing that at least. We are doing two things in this front. The first thing is to change GHES so that the events that happen before boot are handled properly. Tyler Baicar has a patch for this. This is the right fix. The second one is this patch. This one is more of a general solution. We can live without this patch if Tyler's patch is included at this moment. This one is to prevent future problems. I can certainly move the init function around. Maybe, have one acpi_driver_init that calls ghes_init() followed by ged_init(). Please let me know your preference. > > Thanks, > Rafael > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: DEADLOCK: bisected to d215aab82d81974f438bfbc80aa437132f3c37c3 ("cpu/hotplug: Convert hotplug locking to percpu rwsem")
On Sun, 21 May 2017, Corentin Labbe wrote:
> Since linux-next-20170517 at least I got the following DEADLOCK warning:
> [4.311614]
> [4.316919] WARNING: possible recursive locking detected
> [4.37] 4.12.0-rc1-next-20170517+ #273 Not tainted
> [4.327360]
> [4.332665] swapper/0/1 is trying to acquire lock:
> [4.337451] (cpu_hotplug_lock.rw_sem){++}, at: []
> stop_machine+0x1c/0x3c
The offending commit has been removed from -next. We are working on a
replacement.
Thanks,
tglx
Re: [v4 1/1] mm: Adaptive hash table scaling
On Sun, May 21, 2017 at 08:58:25AM -0400, Pasha Tatashin wrote: > Hi Andi, > > Thank you for looking at this. I mentioned earlier, I would not want to > impose a cap. However, if you think that for example dcache needs a cap, > there is already a mechanism for that via high_limit argument, so the client Lots of arguments are not the solution. Today this only affects a few highend systems, but we'll see much more large memory systems in the future. We don't want to have all these users either waste their memory, or apply magic arguments. > can be changed to provide that cap. However, this particular patch addresses > scaling problem for everyone by making it scale with memory at a slower > pace. Yes your patch goes in the right direction and should be applied. Just could be even more aggressive. Long term probably all these hash tables need to be converted to rhash to dynamically resize. -Andi
Re: [PATCH 05/11 linux-next] ubifs: use magic.h
Fabian, Am 21.05.2017 um 17:41 schrieb Fabian Frederick: > Filesystems generally use SUPER_MAGIC values from magic.h > instead of a local definition. > > Signed-off-by: Fabian Frederick > --- > fs/ubifs/ubifs.h | 4 +--- > include/uapi/linux/magic.h | 1 + > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h > index 298b4d8..abc60d5 100644 > --- a/fs/ubifs/ubifs.h > +++ b/fs/ubifs/ubifs.h > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > #ifdef CONFIG_UBIFS_FS_ENCRYPTION > #include > #else > @@ -49,9 +50,6 @@ > /* Version of this UBIFS implementation */ > #define UBIFS_VERSION 1 > > -/* UBIFS file system VFS magic number */ > -#define UBIFS_SUPER_MAGIC 0x24051905 > - > /* Number of UBIFS blocks per VFS page */ > #define UBIFS_BLOCKS_PER_PAGE (PAGE_SIZE / UBIFS_BLOCK_SIZE) > #define UBIFS_BLOCKS_PER_PAGE_SHIFT (PAGE_SHIFT - UBIFS_BLOCK_SHIFT) > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h > index a83c48f..b651a02 100644 > --- a/include/uapi/linux/magic.h > +++ b/include/uapi/linux/magic.h > @@ -70,6 +70,7 @@ > #define SYSFS_MAGIC 0x62656572 > #define TMPFS_MAGIC 0x01021994 > #define TRACEFS_MAGIC0x74726163 > +#define UBIFS_SUPER_MAGIC0x24051905 > #define UDF_SUPER_MAGIC 0x15013346 /* Since UDF 2.01 is > ISO 13346 based... */ > #define USBDEVICE_SUPER_MAGIC0x9fa2 > #define V9FS_MAGIC 0x01021997 > Acked-by: Richard Weinberger Thanks, //richard
Re: RFC: better timer interface
On Tue, 16 May 2017, Arnd Bergmann wrote: > On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote: > > Yes, that sounds useful to me as well. As you said it's an independent > > but somewhat related change. I can add it to my series, but I'll > > need a suggestions for a good and short name. That already was the > > hardest part for the setup side :) > > If we keep the unusual *_timer() naming (rather than timer_*() as hrtimer > has), we could use one of > > a) start_timer(struct timer_list *timer, unsigned long ms); > b) restart_timer(struct timer_list *timer, unsigned long ms); > c) mod_timer_ms(struct timer_list *timer, unsigned long ms); > mod_timer_sec(struct timer_list *timer, unsigned long sec); Please make new functions prefixed with timer_ and get rid of that old interface completely. It's horrible. timer_init() timer_start(timer, ms, abs) timer_start_on(timer, ms, abs, cpu) timer_cancel(timer, sync) Is all what's required to make up a new milliseconds based interface. We really do not need all that mod/restart/ whatever variants. Where is the point of those? Thanks, tglx
[git pull] vfs.git fixes
Fix for unsafe_put_user() (no callers currently in mainline, but anyone starting to use it will step into that) + osf_wait4() infoleak fix. The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus for you to fetch changes up to a8c39544a6eb2093c04afd5005b6192bd0e880c6: osf_wait4(): fix infoleak (2017-05-21 13:10:07 -0400) Al Viro (2): fix unsafe_put_user() osf_wait4(): fix infoleak arch/alpha/kernel/osf_sys.c| 6 -- arch/x86/include/asm/uaccess.h | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-)
Re: [PATCH 1/4] net-next: stmmac: Convert new_state to bool
From: Corentin Labbe Date: Fri, 19 May 2017 09:03:32 +0200 > This patch convert new_state from int to bool since it store only 1 or 0 > > Signed-off-by: Corentin Labbe You must also change it to use the values "true" and "false" as well. Thanks.
Re: [PATCH net-next v2] ibmveth: Support to enable LSO/CSO for Trunk VEA.
From: Sivakumar Krishnasamy Date: Fri, 19 May 2017 05:30:38 -0400 ... > Signed-off-by: Sivakumar Krishnasamy Applied, thanks for the more detailed commit message.
Re: [PATCH 04/24] thunderbolt: Add MSI-X support
On Thu, May 18, 2017 at 4:38 PM, Mika Westerberg
wrote:
> Intel Thunderbolt controllers support up to 16 MSI-X vectors. Using
Is that true for all generations? If so can we remove the legacy path?
> MSI-X is preferred over MSI or legacy interrupt and may bring additional
> performance because there is no need to check the status registers which
> interrupt was triggered.
>
> While there we convert comments in structs tb_ring and tb_nhi to follow
> kernel-doc format more closely.
>
> This code is based on the work done by Amir Levy and Michael Jamet.
>
> Signed-off-by: Michael Jamet
> Signed-off-by: Mika Westerberg
> Reviewed-by: Yehezkel Bernat
> ---
> drivers/thunderbolt/ctl.c | 4 +-
> drivers/thunderbolt/nhi.c | 159
> -
> drivers/thunderbolt/nhi.h | 56 +++
> drivers/thunderbolt/nhi_regs.h | 9 +++
> 4 files changed, 196 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
> index 1031d97407a8..889a32dd21e7 100644
> --- a/drivers/thunderbolt/ctl.c
> +++ b/drivers/thunderbolt/ctl.c
> @@ -488,11 +488,11 @@ struct tb_ctl *tb_ctl_alloc(struct tb_nhi *nhi,
> hotplug_cb cb, void *cb_data)
> if (!ctl->frame_pool)
> goto err;
>
> - ctl->tx = ring_alloc_tx(nhi, 0, 10);
> + ctl->tx = ring_alloc_tx(nhi, 0, 10, RING_FLAG_NO_SUSPEND);
> if (!ctl->tx)
> goto err;
>
> - ctl->rx = ring_alloc_rx(nhi, 0, 10);
> + ctl->rx = ring_alloc_rx(nhi, 0, 10, RING_FLAG_NO_SUSPEND);
> if (!ctl->rx)
> goto err;
>
> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
> index a8c20413dbda..17f3b1bdb7da 100644
> --- a/drivers/thunderbolt/nhi.c
> +++ b/drivers/thunderbolt/nhi.c
> @@ -21,6 +21,12 @@
>
> #define RING_TYPE(ring) ((ring)->is_tx ? "TX ring" : "RX ring")
>
> +/*
> + * Minimal number of vectors when we use MSI-X. Two for control channel
> + * Rx/Tx and the rest four are for cross domain DMA paths.
> + */
> +#define MSIX_MIN_VECS 6
> +#define MSIX_MAX_VECS 16
>
> static int ring_interrupt_index(struct tb_ring *ring)
> {
> @@ -239,8 +245,82 @@ int __ring_enqueue(struct tb_ring *ring, struct
> ring_frame *frame)
> return ret;
> }
>
> +static irqreturn_t ring_msix(int irq, void *data)
> +{
> + struct tb_ring *ring = data;
> +
> + schedule_work(>work);
> + return IRQ_HANDLED;
> +}
> +
> +static void ring_map_unmap_msix(struct tb_ring *ring, bool map)
> +{
This function does the same as ring_interrupt_active just for msix,
right? Can we rename one (or both) to express that?
For example rename ring_interrput_active -> ring_map_unmap_msi. Or
just roll this one into ring_interrupt_active and do the right thing
internally.
> + u32 step, shift, ivr, misc;
> + int index;
> +
> + if (ring->irq <= 0)
> + return;
> +
> + if (ring->is_tx)
> + index = ring->hop;
> + else
> + index = ring->hop + ring->nhi->hop_count;
> +
> + /*
> +* Ask the hardware to clear interrupt status bits automatically
> +* since we already know which interrupt was triggered.
> +*/
> + misc = ioread32(ring->nhi->iobase + REG_DMA_MISC);
> + if (!(misc & REG_DMA_MISC_INT_AUTO_CLEAR)) {
> + misc |= REG_DMA_MISC_INT_AUTO_CLEAR;
> + iowrite32(misc, ring->nhi->iobase + REG_DMA_MISC);
> + }
> +
> + step = index / REG_INT_VEC_ALLOC_REGS * REG_INT_VEC_ALLOC_BITS;
> + shift = index % REG_INT_VEC_ALLOC_REGS * REG_INT_VEC_ALLOC_BITS;
> + ivr = ioread32(ring->nhi->iobase + REG_INT_VEC_ALLOC_BASE + step);
> + ivr &= ~(REG_INT_VEC_ALLOC_MASK << shift);
> + if (map)
> + ivr |= ring->vector << shift;
> + iowrite32(ivr, ring->nhi->iobase + REG_INT_VEC_ALLOC_BASE + step);
> +}
> +
> +static int ring_request_msix(struct tb_ring *ring, bool no_suspend)
> +{
> + struct tb_nhi *nhi = ring->nhi;
> + unsigned long irqflags;
> + int ret;
> +
> + if (!nhi->pdev->msix_enabled)
> + return 0;
> +
> + ret = ida_simple_get(>msix_ida, 0, MSIX_MAX_VECS, GFP_KERNEL);
> + if (ret < 0)
> + return ret;
> +
> + ring->vector = ret;
> +
> + ring->irq = pci_irq_vector(ring->nhi->pdev, ring->vector);
> + if (ring->irq < 0)
> + return ring->irq;
> +
> + irqflags = no_suspend ? IRQF_NO_SUSPEND : 0;
> + return request_irq(ring->irq, ring_msix, irqflags, "thunderbolt",
> ring);
> +}
> +
> +static void ring_release_msix(struct tb_ring *ring)
> +{
> + if (ring->irq <= 0)
> + return;
> +
> + free_irq(ring->irq, ring);
> + ida_simple_remove(>nhi->msix_ida, ring->vector);
> + ring->vector = 0;
> + ring->irq = 0;
> +}
> +
> static struct tb_ring *ring_alloc(struct tb_nhi *nhi, u32 hop, int
Re: [PATCH 2/9] timers: provide a "modern" variant of timers
On Thu, 18 May 2017, Christoph Hellwig wrote:
> On Thu, May 18, 2017 at 10:24:48AM +0200, Christoph Hellwig wrote:
> > > b) give the union a name (breaks any reference to timer_list->func in C
> > > code):
> > >
> > > + union {
> > > + void(*func)(struct timer_list *timer);
> > > + void(*function)(unsigned long);
> > > + } u;
> >
> > I'll look into that, as it seems a lot safer, and places outside
> > the timer code shouldn't really touch it (although I bet they do,
> > so more fixes for this series..)
>
> Meh. All the old init_timer users set function directly, so
> I guess we need to use the other approach.
There is another possibility. Create a coccinelle script which wraps all
timer.function = f;
timer->function = f;
assignements into a helper timer_set_function(timer, func) and ask Linus to
run it right before the next -rc. That handles everything in tree and the
few new instances in next can be addressed with patches sent to the
maintainers.
Thanks,
tglx
Re: linux-next 20170519 - semaphores broken
Hi Kees,
On 05/21/2017 07:20 AM, Kees Cook wrote:
On Sat, May 20, 2017 at 1:18 PM, wrote:
Seeing problems with programs that use semaphores. The one
that I'm getting bit by is jackd. strace says:
getuid()= 967
semget(0x282929, 0, 000)= 229376
semop(229376, [{0, -1, SEM_UNDO}], 1) = -1 EIDRM (Identifier removed)
write(2, "JACK semaphore error: semop (Ide"..., 49JACK semaphore error: semop
(Identifier removed)
) = 49
Bisects down to this commit, and reverting it from 20170519 makes things work
again. No idea why this causes indigestion, there's probably something subtly
wrong here
commit 337f43326737b5eb28eb13f43c27a5788da0f913
Author: Manfred Spraul
Date: Fri May 19 07:39:23 2017 +1000
ipc: merge ipc_rcu and kern_ipc_perm
ipc has two management structures that exist for every id:
- struct kern_ipc_perm, it contains e.g. the permissions.
- struct ipc_rcu, it contains the rcu head for rcu handling and
the refcount.
I think I found the cause of this. Prior to this change, the RCU (with
refcount) is located ahead of the struct sem_array. After this change,
the RCU and refcount is within it, so this is happening:
sma = container_of(ipc_rcu_alloc(size), struct sem_array, sem_perm);
if (!sma)
return -ENOMEM;
memset(sma, 0, size);
ipc_rcu_alloc() initializes the refcount to 1, and the memset bumps it
back to zero.
Correct.
A work-around would be to wrap the memset() like this:
struct ipc_kern_perm perm;
...
perm = sma->sem_perm;
memset(sma, 0, size);
sma->sem_perm = perm;
No!
The quick workaround would be to move the memset into ipc_rcu_alloc().
I actually have a series that changes things much more, and moves the
refcount set to ipc_addid() which is the only place it needs to happen
(though this requires fixing up the mistaken rcu freeing on error
paths). Here's the lightly tested series, on top of -next:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/gcc-plugin/randstruct-next-20170519-ipc
Manfred, I think I could get to the same results in fewer logical
steps, but I'm curious to see what you think of what I've got first.
Mainly I've done the following things:
- remove unneeded RCU free calls (since the IPC memory is only exposed
to RCUness once ipc_addid() succeeds.
This is the step that I'm not 100% sure about:
What about the security_sem_alloc?
Is it possible that a security module relies on the RCU?
My first idea would be an embedded rcu protected linked list of the
allocations.
Since the destruction is security_sem_free(); kvfree() such a list would
not work anyway.
-> not possible.
But are there other reasons why it might be important to do a call_rcu()?
- move refcount init into ipc_addid() since it only needs to be
initialized from that point on
Ok.
- remove utility allocators since now nothing special needs to be done
in the general case
Yes!
The functions predate kvfree, they do not make any sense.
- result is no requirement of ipc_kern_perms position in ipc
structures and cleaner code, IMO
Yes.
The series looks good to me, with the exception of the security interface.
I think your changes are safe, but for that part I'm not certain.
I'll try to do a deeper review/test during the next week, then I would
Ack the patches.
--
Manfred
Re: RFC: better timer interface
On Sun, 21 May 2017, Thomas Gleixner wrote: > On Tue, 16 May 2017, Arnd Bergmann wrote: > > On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote: > > > Yes, that sounds useful to me as well. As you said it's an independent > > > but somewhat related change. I can add it to my series, but I'll > > > need a suggestions for a good and short name. That already was the > > > hardest part for the setup side :) > > > > If we keep the unusual *_timer() naming (rather than timer_*() as hrtimer > > has), we could use one of > > > > a) start_timer(struct timer_list *timer, unsigned long ms); > > b) restart_timer(struct timer_list *timer, unsigned long ms); > > c) mod_timer_ms(struct timer_list *timer, unsigned long ms); > > mod_timer_sec(struct timer_list *timer, unsigned long sec); > > Please make new functions prefixed with timer_ and get rid of that old > interface completely. It's horrible. > > timer_init() > timer_start(timer, ms, abs) I'm not even sure, whether we need absolute timer wheel timers at all, because most use cases are relative to now. But it's easy enough to provide them. All we need for that is something like unsigned long time_msec; which gets incremented every tick by the appropriate amount of milliseconds. Having that would also allow to replace all the end = jiffies + msec_to_jiffies(xxx); while (time_before(jiffies, end)) constructs with a milliseconds based machinery. So we can remove all *_to_jiffies() interfaces over time. Thanks, tglx
Re: [PATCH 2/9] timers: provide a "modern" variant of timers
On Sun, May 21, 2017 at 07:57:53PM +0200, Thomas Gleixner wrote:
> On Thu, 18 May 2017, Christoph Hellwig wrote:
> > On Thu, May 18, 2017 at 10:24:48AM +0200, Christoph Hellwig wrote:
> > > > b) give the union a name (breaks any reference to timer_list->func in C
> > > > code):
> > > >
> > > > + union {
> > > > + void(*func)(struct timer_list *timer);
> > > > + void(*function)(unsigned long);
> > > > + } u;
> > >
> > > I'll look into that, as it seems a lot safer, and places outside
> > > the timer code shouldn't really touch it (although I bet they do,
> > > so more fixes for this series..)
> >
> > Meh. All the old init_timer users set function directly, so
> > I guess we need to use the other approach.
>
> There is another possibility. Create a coccinelle script which wraps all
>
> timer.function = f;
> timer->function = f;
>
> assignements into a helper timer_set_function(timer, func) and ask Linus to
> run it right before the next -rc. That handles everything in tree and the
> few new instances in next can be addressed with patches sent to the
> maintainers.
FWIW, there was another possible approach - I toyed with that several years
ago, but it didn't go anywhere. Namely, make timer.function take void *
*and* turn the setup part into setup(timer, callback, argument), verifying
that
* callback(argument) will be acceptable expression for C typechecking
* callback returns void
* argument is a pointer type
then cast callback to void (*)(void *) and argument to void *. That way
we get rid of any boilerplate in callbacks and get sane typechecking...
Re: [PATCH 2/7] genirq/affinity: assign vectors to all present CPUs
On Fri, 19 May 2017, Christoph Hellwig wrote:
> - /* Stabilize the cpumasks */
> - get_online_cpus();
How is that protected against physical CPU hotplug? Physical CPU hotplug
manipulates the present mask.
> - nodes = get_nodes_in_cpumask(cpu_online_mask, );
> + nodes = get_nodes_in_cpumask(cpu_present_mask, );
> +static int __init irq_build_cpumap(void)
> +{
> + int node, cpu;
> +
> + for (node = 0; node < nr_node_ids; node++) {
> + if (!zalloc_cpumask_var(_to_present_cpumask[node],
> + GFP_KERNEL))
> + panic("can't allocate early memory\n");
> + }
>
> - return min(cpus, vecs) + resv;
> + for_each_present_cpu(cpu) {
> + node = cpu_to_node(cpu);
> + cpumask_set_cpu(cpu, node_to_present_cpumask[node]);
> + }
This mask needs updating on physical hotplug as well.
Thanks,
tglx
