Re: 5.1.0-rc4: Oops in __rpc_execute() when trying to boot from NFS
Hi Trond, On 11/4/2019 9:50 PM, Trond Myklebust wrote: > On Tue, 2019-04-09 at 19:54 +0200, Daniel Mack wrote: >> On 9/4/2019 6:55 PM, Trond Myklebust wrote: >>> On Tue, 2019-04-09 at 18:25 +0200, Daniel Mack wrote: On 8/4/2019 8:51 PM, Trond Myklebust wrote: > On Mon, 2019-04-08 at 19:01 +0200, Daniel Mack wrote: >> Hi, >> >> I'm seeing the Oops below when trying to boot 5.1.0-rc4 on an >> ARM >> PXA3xx >> platform. v5.0 did not show this effect with the same >> cmdline. >> > Please do bisect if that is at all practical. I'm having > trouble > interpreting this Oops. Here you go: 009a82f6437490c262584d65a14094a818bcb747 is the first bad commit commit 009a82f6437490c262584d65a14094a818bcb747 Author: Trond Myklebust Date: Sat Mar 9 12:07:17 2019 -0500 SUNRPC: Micro-optimise when the task is known not to be sleeping In cases where we know the task is not sleeping, try to optimise away the indirect call to task->tk_action() by replacing it with a direct call. Only change tail calls, to allow gcc to perform tail call elimination. >>> >>> Ah... It looks like we explicitly turn off tail call optimisation >>> in >>> some ARM configs, so this might be a stack overflow. >>> >>> Does your config file have THUMB2_AVOID_R_ARM_THM_JUMP11 set? >> >> Nope. I don't even have THUMB2_KERNEL. >> >> In the meantime, I tried to trace that with some printks, but the bug >> appears evasive, and the backtrace changes as soon as I modify the >> timing. Hmm. >> >> Happy to test patches if you have any idea. >> > > Could you please try pulling the 'testing' branch from > http://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=shortlog;h=refs/heads/testing > > i.e. 'git pull git://git.linux-nfs.org/projects/trondmy/linux-nfs.git > testing' > > to see if that suffices to fix the issue you're reporting? Yes, that revert in your branch fixes the problem. All fine again! Thanks, Daniel
Re: 4f4fd7c579: mdadm-selftests.10ddf-fail-two-spares.fail
> On Apr 11, 2019, at 7:38 PM, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 4f4fd7c5798bbdd5a03a60f6269cf1177fbd11ef ("Don't jump to
> compute_result state from check_result state")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase: mdadm-selftests
> with following parameters:
>
> disk: 1HDD
> test_prefix: 10
>
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +-+++
> | | 81ba6abd2b | 4f4fd7c579 |
> +-+++
> | boot_successes | 1 | 0 |
> | boot_failures | 3 | 4 |
> | BUG:kernel_reboot-without-warning_in_test_stage | 3 | 4 |
> | mdadm-selftests.10ddf-fail-two-spares.fail | 0 | 4 |
> +-+++
>
> [ 165.841336 ] Testing on linux-5.1.0-rc3-00023-g4f4fd7c kernel
> [ 165.841339 ]
> [ 167.302289 ] md/raid:md126: not clean -- starting background reconstruction
> [ 167.304321 ] md/raid:md126: device loop13 operational as raid disk 3
> [ 167.306055 ] md/raid:md126: device loop12 operational as raid disk 2
> [ 167.308044 ] md/raid:md126: device loop11 operational as raid disk 1
> [ 167.309522 ] md/raid:md126: device loop10 operational as raid disk 0
> [ 167.320733 ] md/raid:md126: raid level 6 active with 4 out of 4 devices,
> algorithm 10
> [ 167.327158 ] md126: detected capacity change from 0 to 33554432
> [ 167.409736 ] md: resync of RAID array md126
> [ 167.561148 ] md/raid10:md125: not clean -- starting background
> reconstruction
> [ 167.563142 ] md/raid10:md125: active with 4 out of 4 devices
> [ 167.568822 ] md125: detected capacity change from 0 to 33554432
> [ 167.588867 ] md: delaying resync of md125 until md126 has finished (they
> share one or more physical units)
> [ 168.171556 ] md: md126: resync done.
> [ 168.202995 ] md: resync of RAID array md125
> [ 168.438884 ] md: md125: resync done.
> [ 168.998162 ] md/raid10:md125: Disk failure on loop11, disabling device.
> [ 168.998162 ] md/raid10:md125: Operation continuing on 3 devices.
> [ 169.044560 ] md/raid:md126: Disk failure on loop11, disabling device.
> [ 169.044560 ] md/raid:md126: Operation continuing on 3 devices.
> [ 169.104982 ] md: recovery of RAID array md125
> [ 169.129051 ] md: delaying recovery of md126 until md125 has finished (they
> share one or more physical units)
> [ 170.016071 ] md/raid10:md125: Disk failure on loop12, disabling device.
> [ 170.016071 ] md/raid10:md125: Operation continuing on 2 devices.
> [ 170.031796 ] md/raid:md126: Disk failure on loop12, disabling device.
> [ 170.031796 ] md/raid:md126: Operation continuing on 2 devices.
> [ 170.123425 ] md: md125: recovery interrupted.
> [ 170.127705 ] md: recovery of RAID array md126
> [ 170.132003 ] md: delaying recovery of md125 until md126 has finished (they
> share one or more physical units)
> [ 177.280292 ] md: md126: recovery done.
> [ 177.286369 ] md: recovery of RAID array md125
> [ 177.304563 ] md: delaying recovery of md126 until md125 has finished (they
> share one or more physical units)
> [ 183.347549 ] md: md125: recovery done.
> [ 183.350452 ] md: recovery of RAID array md126
> [ 183.368340 ] md: delaying recovery of md125 until md126 has finished (they
> share one or more physical units)
> [ 190.512654 ] md: md126: recovery done.
> [ 190.519633 ] md: recovery of RAID array md125
> [ 197.641803 ] md: md125: recovery done.
> [ 198.039343 ] tests/10ddf-fail-two-spares... FAILED - see /var/tmp/log for
> details
>
>
> To reproduce:
>
># build kernel
> cd linux
> cp config-5.1.0-rc3-00023-g4f4fd7c .config
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
>
>
>git clone https://github.com/intel/lkp-tests.git
>cd lkp-tests
>find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
> bin/lkp qemu -k -m modules.cgz job-script # job-script is
> attached in this email
>
>
>
>
> Thanks,
> Rong Chen
>
>
Thanks for the report. We are discussing this patch. We may
revert it.
Song
Re: [PATCH 1/6] arch: riscv: add support for building DTB files from DT source data
On Thu, Apr 11, 2019 at 05:08:11PM -0700, Paul Walmsley wrote: > However: the vast majority of users -- even embedded users -- will not use > a kernel with a bundled DTB. This is because it irrevocably ties that > kernel binary to one specific board type. I hope it is obvious why this > would be a non-starter for Linux distributions, and, more generally, > anyone who wants their kernels to be usable on multiple boards. Those > distributors would need to ship one kernel binary per board, or bloat > their kernels with DTBs and come up with some new mechanism to select one. Yes, that is the point why the DTB usually comes with the firmware. In my case I need it because by nommu M-mode Linux port targeted to the Kendrye _is_ the firmware and there is nothing else running on that tiny system. But why are you submitting the DTB files if there is not ways use them from the kernel? That is what I was wondering about.
Re: [PATCH] locking/lockdep: Make lockdep_register_key() ignore 'debug_locks'
* Bart Van Assche wrote:
> If lockdep_register_key() and lockdep_unregister_key() are called with
> debug_locks == false then the following warning is reported:
>
> WARNING: CPU: 2 PID: 15145 at kernel/locking/lockdep.c:4920
> lockdep_unregister_key+0x1ad/0x240
>
> That warning is reported because lockdep_unregister_key() ignores the
> value of 'debug_locks' and because the behavior of lockdep_register_key()
> depends on whether or not 'debug_locks' is set. Fix this inconsistency
> by making lockdep_register_key() unconditionally register lock keys.
>
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Waiman Long
> Cc: shenghui
> Reported-by: shenghui
> Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer
> in use") # v5.1-rc1.
> Signed-off-by: Bart Van Assche
> ---
> kernel/locking/lockdep.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index d2d65bbfae01..a228509b62f1 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -1027,15 +1027,16 @@ void lockdep_register_key(struct lock_class_key *key)
> hash_head = keyhashentry(key);
>
> raw_local_irq_save(flags);
> - if (!graph_lock())
> - goto restore_irqs;
> + arch_spin_lock(_lock);
> + current->lockdep_recursion = 1;
> hlist_for_each_entry_rcu(k, hash_head, hash_entry) {
> if (WARN_ON_ONCE(k == key))
> goto out_unlock;
> }
> hlist_add_head_rcu(>hash_entry, hash_head);
> out_unlock:
> - graph_unlock();
> + current->lockdep_recursion = 0;
> + arch_spin_unlock(_lock);
> restore_irqs:
> raw_local_irq_restore(flags);
> }
So why don't we add a debug_locks test to lockdep_unregister_key()
instead? The general principle to bring lockdep to a screeching halt when
bugs are detected, ASAP.
Thanks,
Ingo
RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
> On Wed, Apr 10, 2019 at 3:24 AM Reshetova, Elena
> wrote:
> >
> >
> > > > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > > > > index 7bc105f47d21..38ddc213a5e9 100644
> > > > > > --- a/arch/x86/entry/common.c
> > > > > > +++ b/arch/x86/entry/common.c
> > > > > > @@ -35,6 +35,12 @@
> > > > > > #define CREATE_TRACE_POINTS
> > > > > > #include
> > > > > >
> > > > > > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > > > > > +#include
> > > > > > +
> > > > > > +void *alloca(size_t size);
> > > > > > +#endif
> > > > > > +
> > > > > > #ifdef CONFIG_CONTEXT_TRACKING
> > > > > > /* Called on entry from user mode with IRQs off. */
> > > > > > __visible inline void enter_from_user_mode(void)
> > > > > > @@ -273,6 +279,13 @@ __visible void do_syscall_64(unsigned long nr,
> struct
> > > > pt_regs *regs)
> > > > > > {
> > > > > > struct thread_info *ti;
> > > > > >
> > > > > > +#ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > > > > > + size_t offset = ((size_t)prandom_u32()) % 256;
> > > > > > + char *ptr = alloca(offset);
> > > > > > +
> > > > > > + asm volatile("":"=m"(*ptr));
> > > > > > +#endif
> > > > > > +
> > > > > > enter_from_user_mode();
> > > > > > local_irq_enable();
> > > > > > ti = current_thread_info();
> > > > >
> > > > > Would it make sense to also do this for the compat syscalls
> > > > > (do_fast_syscall_32, do_int80_syscall_32)?
> > > >
> > > > Could someone please include the full patch, with justification and
> > > > performance impact analysis etc.? Can only find the code part of the
> > > > thread on lkml, which leaves out this context.
> > > >
> > >
> > > Sorry, this is very weird, I cannot find it either from lkml, but it was
> > > sent there
> > > to begin with (and as visible from reply-to headers).
> > >
> > > Do you want me to resent original version or with "do_fast_syscall_32,
> > > do_int80_syscall_32" additions (I am finishing testing them now).
> >
> > I will resend the original x86_64 now since this is the one I tested and
> > measured properly. The 32 bit changes seem to work fine inside my 32 bit VM,
> > but since I don't have any real 32 bit HW, I am hesitant to send them out
> > without
> > real HW testing and measuring.
> >
> > This is the asm code for 32 bits (note it requires __builtin_alloca
> > definition and not
> just alloca,
> > so I will change the 64 bit version to use it also):
> >
> > #ifdef CONFIG_RANDOMIZE_KSTACK_OFFSET
> > size_t offset = ((size_t)prandom_u32()) % 256;
> > 0xc10025b6 call 0xc146f7d0
> > 0xc10025bb movzbl %al,%eax
> > char *ptr = __builtin_alloca(offset);
> > 0xc10025be add$0x12,%eax
> > 0xc10025c1 and$0x1fc,%eax
> > 0xc10025c6 sub%eax,%esp
> > 0xc10025c8 lea0x27(%esp),%eax
> > 0xc10025cc and$0xfff0,%eax
> >
> > Also, the result is 47 different random offsets produced,
> > which is slightly better than 33 offsets for x86_64.
> >
>
> I would suggest that you macro-ify this thing:
>
> #ifdef WHATEVER
> #define add_random_stack_offset() do { void *addr = ... } while (0)
> #else
> #define add_random_stack_offset() do {} while (0)
> #endif
>
> since you'll end up with more than one call site.
Sure, will do. So, you are ok for this to be also called from do_fast_syscall_32
and do_int80_syscall_32? I can send the resulting patch, just cannot test on any
real 32 bit HW, only VM.
Best Regards,
Elena.
Re: [PATCH v2] ARM: sun8i: h3: bluetooth for Banana Pi M2 Zero board
Hi, On Mon, 8 Apr 2019 10:14:04 +0200 Maxime Ripard wrote: > On Sun, Apr 07, 2019 at 10:23:21PM +0200, Andreas Kemnade wrote: > > ping > > > > On Fri, 1 Mar 2019 19:52:12 +0100 > > Andreas Kemnade wrote: > > > > > The Banana Pi M2 Zero board has an AP6212 BT+Wifi combo chip > > > with broadcom internals attached to UART1 and some gpios. > > > This addition is in line with similar boards > > > > > > Signed-off-by: Andreas Kemnade > > I never received that patch, who did you send it to? > Seems that I only have sent you the first version of that patch. Somehow I must have left you out during copy and paste of adresses. Regards, Andreas pgpbCG1S1ElL4.pgp Description: OpenPGP digital signature
Re: disabling secondary CPU hangs / system fails to suspend with kernel 4.19+
Hi, good news: starting with 5.0.6 suspend is working again. Best regards Thomas Am 29.03.19 um 10:22 schrieb Thomas Müller: > Hi, > > Am 18.03.19 um 12:57 schrieb Peter Zijlstra: >> On Fri, Mar 15, 2019 at 09:21:02PM +0100, Thomas Müller wrote: >>> I've just re-tested with runlevel 3. >>> Not a real VGA console, but at least no Wayland or Gnome to interfere... >>> >>> `echo 0 > /sys/...` just blocks and no message whatsoever is visible in >>> dmesg. >>> >>> I've executed `echo 0 > ...` in the background to keep my console >>> functional and I can e.g. echo >>> something to /dev/kmsg and it shows up, so reading/updating the log buffer >>> appears to be working >>> just fine. >> >> Damn.. Thanks for trying. I'll see if I can come up with something, but >> I'm out of idea for now :/ >> > Any new ideas so far? > > For reference: > I've just tested a vanilla 5.0.5 with localmodconfig (attached)... same > behavior :( > > > Best regards > Thomas >
[PATCH 1/3] dt-bindings: spi: Add spi-mux-gpio
Add binding documentation for spi-mux-gpio which is a slightly more
complicated hardware implementation of using gpios to steer SPI chip
selects.
Signed-off-by: Chris Packham
---
.../devicetree/bindings/spi/spi-mux-gpio.txt | 45 +++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-mux-gpio.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-mux-gpio.txt
b/Documentation/devicetree/bindings/spi/spi-mux-gpio.txt
new file mode 100644
index ..a32f25321d37
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-mux-gpio.txt
@@ -0,0 +1,45 @@
+SPI bus gpio multiplexer
+
+The SPI bus gpio multiplexer can be used to implement more complicated access
+logic than can be supported with the cs-gpios property of a SPI bus.
+
+In the example below we have a SoC with a single SPI CS that is gated by the
+state of a gpio to select the desired SPI device.
+
+ +--+ CS+-+ CS0 ++
+ | || |--||
+ | || \ / | ++
+ | SoC|| + |
+ | | GPIO | / \ | CS1 ++
+ | || |--||
+ +--++-+ ++
+
+Required properties:
+- compatible - must be "spi-mux-gpio"
+- gpios- gpios used to implement the multiplexing logic
+- spi-parent-bus - parent spi bus to use
+
+Optional properties:
+- spi-parent-cs - chip select on parent bus to use. Defaults to 0 if not
+ specified.
+
+Example for a multiplexer with a single gpio:
+
+ spi-mux {
+ compatible = "spi-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpios = < 1 0>;
+ spi-parent-bus = <>;
+ spi-parent-cs = <0>;
+
+ spi-dev@0 {
+ compatible = "...";
+ reg = <0>;
+ }
+
+ spi-dev@1 {
+ compatible = "...";
+ reg = <1>;
+ }
+ };
--
2.21.0
[PATCH 2/3] spi: Make of_find_spi_controller_by_node visible
Drop the static and add of_find_spi_controller_by_node() to spi.h. Also
move it outside of the CONFIG_OF_DYNAMIC so it is available with just
CONFIG_OF.
Signed-off-by: Chris Packham
---
drivers/spi/spi.c | 7 ---
include/linux/spi/spi.h | 7 +++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 93986f879b09..19929163a45b 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -3531,16 +3531,14 @@ struct spi_device *of_find_spi_device_by_node(struct
device_node *node)
return dev ? to_spi_device(dev) : NULL;
}
EXPORT_SYMBOL_GPL(of_find_spi_device_by_node);
-#endif /* IS_ENABLED(CONFIG_OF) */
-#if IS_ENABLED(CONFIG_OF_DYNAMIC)
static int __spi_of_controller_match(struct device *dev, const void *data)
{
return dev->of_node == data;
}
/* the spi controllers are not using spi_bus, so we find it with another way */
-static struct spi_controller *of_find_spi_controller_by_node(struct
device_node *node)
+struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
{
struct device *dev;
@@ -3555,7 +3553,10 @@ static struct spi_controller
*of_find_spi_controller_by_node(struct device_node
/* reference got in class_find_device */
return container_of(dev, struct spi_controller, dev);
}
+EXPORT_SYMBOL_GPL(of_find_spi_controller_by_node);
+#endif /* IS_ENABLED(CONFIG_OF) */
+#if IS_ENABLED(CONFIG_OF_DYNAMIC)
static int of_spi_notify(struct notifier_block *nb, unsigned long action,
void *arg)
{
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 662b336aa2e4..e763290767ea 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -1334,6 +1334,8 @@ spi_transfer_is_last(struct spi_controller *ctlr, struct
spi_transfer *xfer)
extern struct spi_device *
of_find_spi_device_by_node(struct device_node *node);
+extern struct spi_controller *
+of_find_spi_controller_by_node(struct device_node *node);
#else
static inline struct spi_device *
@@ -1342,6 +1344,11 @@ of_find_spi_device_by_node(struct device_node *node)
return NULL;
}
+static inline struct spi_controller *
+of_find_spi_controller_by_node(struct device_node *node)
+{
+ return NULL;
+}
#endif /* IS_ENABLED(CONFIG_OF) */
/* Compatibility layer */
--
2.21.0
[PATCH 0/3] spi: SPI bus multiplexer
Hi All, I have a hardware design where a single SPI chip select is steered by a GPIO being asserted or de-asserted. On older kernels I was able to (ab)use a gpio-hog and cs-gpios to deal with this. Unfortunately recent changes have stopped my hacks from working. I've tried adapting cs-gpios to work with my particular hardware but I came to the realisation that the current cs-gpios support assumes a 1:1 mapping of gpio to SPI device whereas my hardware used the state of the gpio selecting the device i.e. a 1:2 mapping. This is my attempt to implement a driver to deal with this. One nice property is that it is pretty much self contained. The only change to the core SPI infrastructure is exposing a function I needed to lookup the spi_controller instance. Chris Packham (3): dt-bindings: spi: Add spi-mux-gpio spi: Make of_find_spi_controller_by_node visible spi: Add SPI bus gpio multiplexer .../devicetree/bindings/spi/spi-mux-gpio.txt | 46 + drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/spi-mux-gpio.c| 169 ++ drivers/spi/spi.c | 7 +- include/linux/spi/spi.h | 7 + 6 files changed, 234 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/spi-mux-gpio.txt create mode 100644 drivers/spi/spi-mux-gpio.c -- 2.21.0
[PATCH 3/3] spi: Add SPI bus gpio multiplexer
This add support for a gpio based multiplexer for SPI buses. This can be
used in situations where the cs-gpios property does not work with the
hardware design. In particular this support situations where a single
gpio is used to select between two possible devices.
Signed-off-by: Chris Packham
---
drivers/spi/Kconfig| 7 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-mux-gpio.c | 169 +
3 files changed, 177 insertions(+)
create mode 100644 drivers/spi/spi-mux-gpio.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f761655e2a36..bfb4bd5bc2f3 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -426,6 +426,13 @@ config SPI_MT65XX
say Y or M here.If you are not sure, say N.
SPI drivers for Mediatek MT65XX and MT81XX series ARM SoCs.
+config SPI_MUX_GPIO
+ tristate "SPI bus gpio multiplexer"
+ help
+ This selects the SPI bus gpio multiplexer.
+ If you have a hardware design that requires multiplexing
+ on the SPI bus say Y or M here. If you are not sure, say N.
+
config SPI_NPCM_PSPI
tristate "Nuvoton NPCM PSPI Controller"
depends on ARCH_NPCM || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d8fc03c9faa2..32d831374e1f 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi-mpc52xx.o
obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o
obj-$(CONFIG_SPI_MXIC) += spi-mxic.o
obj-$(CONFIG_SPI_MXS) += spi-mxs.o
+obj-$(CONFIG_SPI_MUX_GPIO) += spi-mux-gpio.o
obj-$(CONFIG_SPI_NPCM_PSPI)+= spi-npcm-pspi.o
obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o
obj-$(CONFIG_SPI_NXP_FLEXSPI) += spi-nxp-fspi.o
diff --git a/drivers/spi/spi-mux-gpio.c b/drivers/spi/spi-mux-gpio.c
new file mode 100644
index ..3666863a4e3f
--- /dev/null
+++ b/drivers/spi/spi-mux-gpio.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Allied Telesis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct spi_mux_gpio {
+ struct gpio_descs *gpios;
+ struct spi_controller *ctlr;
+ struct spi_controller *parent_ctlr;
+ int chip_select;
+};
+
+static void spi_mux_set_cs(struct spi_device *spi, bool enable)
+{
+ DECLARE_BITMAP(values, BITS_PER_TYPE(spi->chip_select));
+ struct spi_mux_gpio *mux = spi_master_get_devdata(spi->controller);
+ struct spi_device spidev = *spi;
+
+ values[0] = spi->chip_select;
+
+ gpiod_set_array_value_cansleep(mux->gpios->ndescs,
+ mux->gpios->desc,
+ mux->gpios->info, values);
+
+ spidev.controller = mux->parent_ctlr;
+ spidev.master = mux->parent_ctlr;
+ spidev.chip_select = mux->chip_select;
+
+ mux->parent_ctlr->set_cs(, enable);
+}
+
+static int spi_mux_transfer_one(struct spi_controller *ctlr,
+ struct spi_device *spi,
+ struct spi_transfer *transfer)
+{
+ struct spi_mux_gpio *mux = spi_master_get_devdata(ctlr);
+ struct spi_device spidev = *spi;
+
+ spidev.controller = mux->parent_ctlr;
+ spidev.master = mux->parent_ctlr;
+ spidev.chip_select = mux->chip_select;
+
+ return mux->parent_ctlr->transfer_one(mux->parent_ctlr, ,
transfer);
+
+}
+
+static int spi_mux_setup(struct spi_device *spi)
+{
+ struct spi_mux_gpio *mux = spi_master_get_devdata(spi->controller);
+ struct spi_device spidev = *spi;
+
+ spidev.controller = mux->parent_ctlr;
+ spidev.master = mux->parent_ctlr;
+ spidev.chip_select = mux->chip_select;
+
+ return mux->parent_ctlr->setup();
+}
+
+static int spi_mux_gpio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *parent;
+ struct spi_controller *parent_ctlr;
+ struct spi_controller *ctlr;
+ struct spi_mux_gpio *mux;
+ struct gpio_descs *gpios;
+ int ret;
+
+ gpios = devm_gpiod_get_array(>dev, NULL, GPIOD_OUT_LOW);
+ if (IS_ERR(gpios))
+ return PTR_ERR(gpios);
+
+ parent = of_parse_phandle(np, "spi-parent-bus", 0);
+ if (!parent)
+ return -ENODEV;
+
+ parent_ctlr = of_find_spi_controller_by_node(parent);
+ if (!parent_ctlr) {
+ ret = -EPROBE_DEFER;
+ goto err_put_node;
+ }
+
+ ctlr = spi_alloc_master(>dev, sizeof(*mux));
+ if (!ctlr) {
+ ret = -ENOMEM;
+ goto err_put_device;
+ }
+ mux = spi_master_get_devdata(ctlr);
+ platform_set_drvdata(pdev, mux);
+
+ ctlr->mode_bits = parent_ctlr->mode_bits;
+ ctlr->bits_per_word_mask =
Re: [PATCH] clocksource/drivers/timer-ti-dm: Remove omap_dm_timer_set_load_start
On Thu, Apr 11, 2019 at 01:56:57PM -0700, Tony Lindgren wrote: > Hi, > > * Daniel Lezcano [190411 19:21]: > > On 10/04/2019 22:07, Tony Lindgren wrote: > > > Hi, > > > > > > * Daniel Lezcano [190410 17:02]: > > >> can you ask for an acked-by before pulling a patch in your tree? > > > > > > I certainly do ask and wait for acks where possible :) > > > > Ok, I may have missed them. > > > > > Note that I have not applied this patch. I just added > > > Keerthy to Cc on this thread so maybe you misread the > > > message earlier. My comment "seems like no other > > > takers" was for Ladislav regarding somebody picking up > > > his earlier work, not for picking up this patch :) > > > > Actually I was referring to the commit 592ea6bd1fad. Anyway as stated > > above I could have miss your call. > > Hmm so commit 592ea6bd1fad was part of the PWM timer series > that was posted several times from late 2017 to end of > February 2018. I did not get any timer related acks or > comments so I applied it together with the PWM timer > changes. > > I'm guessing you may have accidentally checked out some > older deja-vu branch from about a year ago? Commit > 592ea6bd1fad is not related to this fix.. :) > Just for the record, I said this patch fixes 592ea6bd1fad because 592ea6bd1fad should have been marked this function as static, which would have exposed that this function was unused and it could have been removed at that time. I know it is a bit of a stretch for this commit (would be more appropriate for 008258d995a6 to have it) but that was my logic behind it. Not opposed to having it removed before committing. Thanks, Nathan > Regards, > > Tony > > >
[PATCH v3] ARM: sun8i: h3: bluetooth for Banana Pi M2 Zero board
The Banana Pi M2 Zero board has an AP6212 BT+Wifi combo chip
with Broadcom internals attached to UART1 and some gpios.
This addition is in line with similar boards.
Signed-off-by: Andreas Kemnade
---
changes in v3: spelling fixes
changes in v2: remove pinctrl things
arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
index 1db2541135a7..57432d0500b1 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
@@ -69,6 +69,8 @@
compatible = "mmc-pwrseq-simple";
pinctrl-names = "default";
reset-gpios = <_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
+ clocks = < 1>;
+ clock-names = "ext_clock";
};
};
@@ -122,7 +124,20 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins>, <_rts_cts_pins>;
+ uart-has-rtscts;
status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = < 1>;
+ clock-names = "lpo";
+ vbat-supply = <_vcc3v3>;
+ vddio-supply = <_vcc3v3>;
+ device-wakeup-gpios = < 6 13 GPIO_ACTIVE_HIGH>; /* PG13 */
+ host-wakeup-gpios = < 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
+ shutdown-gpios = < 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
+ };
+
};
_otg {
--
2.11.0
linux-next: manual merge of the staging tree with the imx-mxs tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
Documentation/devicetree/bindings/vendor-prefixes.txt
between commit:
189733b0a7e4 ("dt-bindings: Add vendor prefix for Rakuten Kobo, Inc.")
from the imx-mxs tree and commit:
2e5cee6c7622 ("dt-bindings: Add vendor prefix for Kionix, Inc.")
from the staging tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
index 5f2b185a04e6,93753f447c20..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -211,7 -210,7 +211,8 @@@ kiebackpeterKieback & Peter Gmb
kinetic Kinetic Technologies
kingdisplay King & Display Technology Co., Ltd.
kingnovel Kingnovel Technology Co., Ltd.
+ kionixKionix, Inc.
+kobo Rakuten Kobo Inc.
koe Kaohsiung Opto-Electronics Inc.
kosagiSutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
pgpJOXYs0IKzM.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/3] clocksource/drivers/timer-milbeaut: Fix to enable one-shot timer
Hi, Thank you for your comment. On 2019/04/12 5:08, Daniel Lezcano wrote: On 25/03/2019 04:05, Sugaya Taichi wrote: Fix mlb_set_oneshot_state() to enable one-shot timer. The function should stop and start a timer, but "start" statement was dropped. Kick the register to start one-shot timer. Can you add the "Fixes" tag please. I got it, will resend with correct form. Thanks, Sugaya Taichi Signed-off-by: Sugaya Taichi --- drivers/clocksource/timer-milbeaut.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clocksource/timer-milbeaut.c b/drivers/clocksource/timer-milbeaut.c index f2019a8..9fd5d08 100644 --- a/drivers/clocksource/timer-milbeaut.c +++ b/drivers/clocksource/timer-milbeaut.c @@ -80,6 +80,8 @@ static int mlb_set_state_oneshot(struct clock_event_device *clk) u32 val = MLB_TMR_TMCSR_CSL_DIV2; writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS); + val |= MLB_TMR_TMCSR_CNTE | MLB_TMR_TMCSR_TRG | MLB_TMR_TMCSR_INTE; + writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS); return 0; }
[PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC CPUs
The nohz idle balancer runs on the lowest idle CPU. This can
interfere with isolated CPUs, so confine it to HK_FLAG_MISC
housekeeping CPUs.
HK_FLAG_SCHED is not used for this because it is not set anywhere
at the moment. This could be folded into HK_FLAG_SCHED once that
option is fixed.
The problem was observed with increased jitter on an application
running on CPU0, caused by nohz idle load balancing being run on
CPU1 (an SMT sibling).
Signed-off-by: Nicholas Piggin
---
kernel/sched/fair.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fdab7eb6f351..d29ca323214d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq)
* - When one of the busy CPUs notice that there may be an idle rebalancing
* needed, they will kick the idle load balancer, which then does idle
* load balancing for all the idle CPUs.
+ * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
+ * anywhere yet.
*/
static inline int find_new_ilb(void)
{
- int ilb = cpumask_first(nohz.idle_cpus_mask);
+ int ilb;
- if (ilb < nr_cpu_ids && idle_cpu(ilb))
- return ilb;
+ for_each_cpu_and(ilb, nohz.idle_cpus_mask,
+ housekeeping_cpumask(HK_FLAG_MISC)) {
+ if (idle_cpu(ilb))
+ return ilb;
+ }
return nr_cpu_ids;
}
/*
- * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
- * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
- * CPU (if there is one).
+ * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
+ * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
*/
static void kick_ilb(unsigned int flags)
{
--
2.20.1
Re: [PATCH v6 06/12] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
On 11/04/19 8:30 PM, Tony Lindgren wrote:
> Hi,
>
> * Lokesh Vutla [190410 04:15]:
>> +Example:
>> +
>> +The following example demonstrates both interrupt router node and the
>> consumer
>> +node(main gpio) on the AM654 SoC:
>> +
>> +main_intr: interrupt-controller0 {
>> +compatible = "ti,sci-intr";
>> +ti,intr-trigger-type = <1>;
>> +interrupt-controller;
>> +interrupt-parent = <>;
>> +#interrupt-cells = <3>;
>> +ti,sci = <>;
>> +ti,sci-dst-id = <56>;
>> +ti,sci-rm-range-girq = <0x1>;
>> +};
>
> To me it seems there should not be too many of these interrupt
> controller nodes for each SoC. Maybe you're already planning on
> doing it, but I suggest that you just add more specific compatibles
> and then look up the dst-id from a mapping table in the driver
> similar to what patch 04/12 in this series is already doing.
>
> That way you don't need to add custom TI specific (firmware
> defined) device tree properties listed above ;)
I am tired of arguing on this. We did close this topic in the previous version
of this series. Why do you want to keep re visiting the same. Sorry, I am not
going change unless I receive a Nack from Marc or Rob.
Thanks and regards,
Lokesh
[no subject]
ВНИМАНИЕ; В вашем почтовом ящике превышен лимит хранилища, который составляет 5 ГБ, как определено администратором, который в настоящее время работает на 10,9 ГБ. Возможно, вы не сможете отправлять или получать новую почту, пока вы не подтвердите свою почту. Чтобы подтвердить свой почтовый ящик, отправьте следующую информацию ниже: название: Имя пользователя: пароль: Подтвердите Пароль: Эл. адрес: Телефон: Если вы не сможете подтвердить свой почтовый ящик, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Код подтверждения: en: 006,524.RU Техническая поддержка почты © 2019 благодарю вас Системный администратор.
Re: [PATCH v6 04/12] firmware: ti_sci: Add RM mapping table for am654
On 11/04/19 8:24 PM, Tony Lindgren wrote:
> Hi,
>
> * Lokesh Vutla [190410 04:15]:
>> From: Peter Ujfalusi
>> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> index b56a02c10ae6..6f0cd31c1520 100644
>> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> @@ -24,7 +24,8 @@ relationship between the TI-SCI parent node to the child
>> node.
>>
>> Required properties:
>> ---
>> -- compatible: should be "ti,k2g-sci"
>> +- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC
>> +should be "ti,am654-sci" for for TI AM654 SoC
>> - mbox-names:
>> "rx" - Mailbox corresponding to receive path
>> "tx" - Mailbox corresponding to transmit path
>> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
>> index d303f5a14da9..88e461498def 100644
>> --- a/drivers/firmware/ti_sci.c
>> +++ b/drivers/firmware/ti_sci.c
>> @@ -2297,10 +2297,33 @@ static const struct ti_sci_desc ti_sci_pmmc_k2g_desc
>> = {
>> /* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
>> .max_msgs = 20,
>> .max_msg_size = 64,
>> +.rm_type_map = NULL,
>> +};
>> +
>> +static struct ti_sci_rm_type_map ti_sci_am654_rm_type_map[] = {
>> +{.dev_id = 56, .type = 0x00b}, /* GIC_IRQ */
>> +{.dev_id = 179, .type = 0x000}, /* MAIN_NAV_UDMASS_IA0 */
>> +{.dev_id = 187, .type = 0x009}, /* MAIN_NAV_RA */
>> +{.dev_id = 188, .type = 0x006}, /* MAIN_NAV_UDMAP */
>> +{.dev_id = 194, .type = 0x007}, /* MCU_NAV_UDMAP */
>> +{.dev_id = 195, .type = 0x00a}, /* MCU_NAV_RA */
>> +{.dev_id = 0, .type = 0x000}, /* end of table */
>> +};
>> +
>> +/* Description for AM654 */
>> +static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
>> +.default_host_id = 12,
>> +/* Conservative duration */
>> +.max_rx_timeout_ms = 1,
>> +/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
>> +.max_msgs = 20,
>> +.max_msg_size = 60,
>> +.rm_type_map = ti_sci_am654_rm_type_map,
>> };
>>
>> static const struct of_device_id ti_sci_of_match[] = {
>> {.compatible = "ti,k2g-sci", .data = _sci_pmmc_k2g_desc},
>> +{.compatible = "ti,am654-sci", .data = _sci_pmmc_am654_desc},
>> { /* Sentinel */ },
>> };
>> MODULE_DEVICE_TABLE(of, ti_sci_of_match);
>
> Great, this approach with mapping table in the driver based on
> the compatible looks good to me and avoids stuffing the IDs
> into device tree:
>
> Acked-by: Tony Lindgren
>
Thanks, but I don't think you understood what the patch is actually doing.
Please look at the rest of the series on how this table is being used.
Thanks and regards,
Lokesh
Re: [PATCH v4 0/5] init: Do not select DEBUG_KERNEL by default
On 4/12/2019 12:05 AM, Josh Triplett wrote: Can you point to the typo? I did, in my response to the patch itself: s/Miscellaneous/miscellaneous/ in the new option's description, since it isn't at the start of a sentence. Thanks, your emails arrived out of order. I got them now.
Re: [PATCH v4 0/5] init: Do not select DEBUG_KERNEL by default
On Thu, Apr 11, 2019 at 11:13:42PM -0400, Sinan Kaya wrote: > On 4/11/2019 11:02 PM, Josh Triplett wrote: > > I noticed one minor typo in patch 1/5, with that fixed, for the whole > > series: > > Can you point to the typo? I did, in my response to the patch itself: s/Miscellaneous/miscellaneous/ in the new option's description, since it isn't at the start of a sentence.
[PATCH v1] clk: mediatek: fix clk-gate flag setting
CLK_SET_RATE_PARENT would be dropped.
Merge two flag setting together to correct the error.
Fixes: 5a1cc4c27ad2 ("clk: mediatek: Add flags to mtk_gate")
Cc:
Signed-off-by: Weiyi Lu
---
drivers/clk/mediatek/clk-gate.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 9628d4e7690b..85daf826619a 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -169,11 +169,10 @@ struct clk *mtk_clk_register_gate(
return ERR_PTR(-ENOMEM);
init.name = name;
- init.flags = CLK_SET_RATE_PARENT;
+ init.flags = flags | CLK_SET_RATE_PARENT;
init.parent_names = parent_name ? _name : NULL;
init.num_parents = parent_name ? 1 : 0;
init.ops = ops;
- init.flags = flags;
cg->regmap = regmap;
cg->set_ofs = set_ofs;
--
2.18.0
Re: [PATCH] x86/tsc: mark tsc reliable on CoffeeLake
On 2019/4/8 8:03 PM, Thomas Gleixner wrote: > On Mon, 8 Apr 2019, You-Sheng Yang wrote: >> +/* >> + * On Intel CoffeeLake, tsc may be marked unstable unexpectedly after >> + * entering PC10. >> + */ >> +if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && >> +(boot_cpu_data.x86_model == INTEL_FAM6_KABYLAKE_MOBILE || >> + boot_cpu_data.x86_model == INTEL_FAM6_KABYLAKE_DESKTOP) && >> +boot_cpu_data.x86_stepping >= 0x0a) >> +tsc_clocksource_reliable = 1; > > No. We are not starting that family/model/stepping game especially not > with random stepping cutoffs which are pulled out of thin air. That's > going to spiral out of control sooner than later. What about we simply disable clocksource watchdog if this is an invariant TSC? > There must be a better way to do that. Rafael? > > Thanks, > > tglx You-Sheng Yang signature.asc Description: OpenPGP digital signature
Re: your mail
Peter Zijlstra's on April 11, 2019 8:53 pm:
> Was this supposed to be patch 6/5 of your previous series?
Dang, I screwed up the headers? Thanks for the ping, I will resend.
It is standalone. It seems more suited to the scheduler tree than the
timers one, but your call.
It is generally of more use when CPU0 is _not_ a housekeeping one,
and that's where I've done most testing, but I don't see any hard
dependency.
Thanks,
Nick
>
> On Thu, Apr 11, 2019 at 04:05:36PM +1000, Nicholas Piggin wrote:
>> Date: Tue, 9 Apr 2019 20:23:16 +1000
>> Subject: [PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC
>> CPUs
>>
>> The nohz idle balancer runs on the lowest idle CPU. This can
>> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
>> housekeeping CPUs.
>>
>> HK_FLAG_SCHED is not used for this because it is not set anywhere
>> at the moment. This could be folded into HK_FLAG_SCHED once that
>> option is fixed.
>>
>> The problem was observed with increased jitter on an application
>> running on CPU0, caused by nohz idle load balancing being run on
>> CPU1 (an SMT sibling).
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>> kernel/sched/fair.c | 16 ++--
>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index fdab7eb6f351..d29ca323214d 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq)
>> * - When one of the busy CPUs notice that there may be an idle rebalancing
>> * needed, they will kick the idle load balancer, which then does idle
>> * load balancing for all the idle CPUs.
>> + * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
>> + * anywhere yet.
>> */
>>
>> static inline int find_new_ilb(void)
>> {
>> -int ilb = cpumask_first(nohz.idle_cpus_mask);
>> +int ilb;
>>
>> -if (ilb < nr_cpu_ids && idle_cpu(ilb))
>> -return ilb;
>> +for_each_cpu_and(ilb, nohz.idle_cpus_mask,
>> + housekeeping_cpumask(HK_FLAG_MISC)) {
>> +if (idle_cpu(ilb))
>> +return ilb;
>> +}
>>
>> return nr_cpu_ids;
>> }
>>
>> /*
>> - * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
>> - * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
>> - * CPU (if there is one).
>> + * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
>> + * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
>> */
>> static void kick_ilb(unsigned int flags)
>> {
>> --
>> 2.20.1
>>
>
[locking/rwsem] f03c360396: WARNING:at_init/main.c:#start_kernel
FYI, we noticed the following commit (built with gcc-7):
commit: f03c36039664fc53ebf6d8322c46aaf8e373f70c ("locking/rwsem: Merge owner
into count on x86-64")
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.locking/core
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
|| 1878939138 | f03c360396 |
++++
| boot_successes | 0 | 0 |
| boot_failures | 4 | 9 |
| BUG:kernel_hang_in_boot-around-mounting-root_stage | 3 | 5 |
| BUG:kernel_reboot-without-warning_in_test_stage| 1 ||
| WARNING:at_init/main.c:#start_kernel | 0 | 9 |
| RIP:start_kernel | 0 | 9 |
++++
[4.777899] WARNING: CPU: 0 PID: 0 at init/main.c:663
start_kernel+0x366/0x512
[4.777906] Modules linked in:
[4.777920] CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc4-00083-gf03c360
#2
[4.777929] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[4.777943] RIP: 0010:start_kernel+0x366/0x512
[4.777957] Code: 01 00 e8 f2 85 00 00 e8 84 cd 01 00 e8 0e 48 02 00 e8 34
2b 8b fe 9c 58 0f ba e0 09 73 0e 48 c7 c7 e0 08 a0 99 e8 2c 91 bd fd <0f> 0b c6
05 4b c0 b9 ff 00 e8 64 d2 cb fd fb e8 c9 ca 02 00 e8 87
[4.777966] RSP: :9a207ed8 EFLAGS: 00010282
[4.777977] RAX: dc08 RBX: 8881f699cb00 RCX: 9896f4d5
[4.777986] RDX: RSI: RDI: 988f0c4b
[4.777995] RBP: 13440fdb R08: fbfff35085ae R09: fbfff35085ae
[4.778003] R10: 0001 R11: fbfff35085ad R12: 9ad812e0
[4.778011] R13: R14: R15:
[4.778020] FS: () GS:9a2a7000()
knlGS:
[4.778029] CS: 0010 DS: ES: CR0: 80050033
[4.778037] CR2: CR3: 0001e884c000 CR4: 06b0
[4.778046] Call Trace:
[4.778063] ? mem_encrypt_init+0x1/0x1
[4.778080] ? memcpy_orig+0x16/0x110
[4.778093] secondary_startup_64+0xb6/0xc0
[4.778116] random: get_random_bytes called from
print_oops_end_marker+0x34/0x47 with crng_init=0
[4.778128] ---[ end trace 8182026d66b2a4ad ]---
To reproduce:
# build kernel
cd linux
cp config-5.1.0-rc4-00083-gf03c360 .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Rong Chen
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.1.0-rc4 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70300
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
[PATCH v2] fpga: dfl: Add lockdep classes for pdata->lock
struct dfl_feature_platform_data (and it's mutex) is used
by both fme and port devices, and when lockdep is enabled it
complains about nesting between these locks. Tell lockdep about
the difference so it can track each class separately.
Here's the lockdep complaint:
[ 409.680668] WARNING: possible recursive locking detected
[ 409.685983] 5.1.0-rc3.fpga+ #1 Tainted: GE
[ 409.691469]
[ 409.696779] fpgaconf/9348 is trying to acquire lock:
[ 409.701746] a443fe2e (>lock){+.+.}, at:
port_enable_set+0x24/0x60 [dfl_afu]
[ 409.710006]
[ 409.710006] but task is already holding lock:
[ 409.715837] 63b78782 (>lock){+.+.}, at:
fme_pr_ioctl+0x21d/0x330 [dfl_fme]
[ 409.724012]
[ 409.724012] other info that might help us debug this:
[ 409.730535] Possible unsafe locking scenario:
[ 409.730535]
[ 409.736457]CPU0
[ 409.738910]
[ 409.741360] lock(>lock);
[ 409.744679] lock(>lock);
[ 409.747999]
[ 409.747999] *** DEADLOCK ***
[ 409.747999]
[ 409.753920] May be due to missing lock nesting notation
[ 409.753920]
[ 409.760704] 4 locks held by fpgaconf/9348:
[ 409.764805] #0: 63b78782 (>lock){+.+.}, at:
fme_pr_ioctl+0x21d/0x330 [dfl_fme]
[ 409.773408] #1: 213c8a66 (>mutex){+.+.}, at:
fpga_region_program_fpga+0x24/0x200 [fpga_region]
[ 409.783489] #2: fe63afb9 (>ref_mutex){+.+.}, at:
fpga_mgr_lock+0x15/0x40 [fpga_mgr]
[ 409.792354] #3: 0b2285c5 (>mutex){+.+.}, at:
__fpga_bridge_get+0x26/0xa0 [fpga_bridge]
[ 409.801740]
[ 409.801740] stack backtrace:
[ 409.806102] CPU: 45 PID: 9348 Comm: fpgaconf Kdump: loaded Tainted: G
E 5.1.0-rc3.fpga+ #1
[ 409.815658] Hardware name: Intel Corporation S2600BT/S2600BT, BIOS
SE5C620.86B.01.00.0763.022420181017 02/24/2018
[ 409.825911] Call Trace:
[ 409.828369] dump_stack+0x5e/0x8b
[ 409.831686] __lock_acquire+0xf3d/0x10e0
[ 409.835612] ? find_held_lock+0x3c/0xa0
[ 409.839451] lock_acquire+0xbc/0x1d0
[ 409.843030] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.847823] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.852616] __mutex_lock+0x86/0x970
[ 409.856195] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.860989] ? port_enable_set+0x24/0x60 [dfl_afu]
[ 409.865777] ? __mutex_unlock_slowpath+0x4b/0x290
[ 409.870486] port_enable_set+0x24/0x60 [dfl_afu]
[ 409.875106] fpga_bridges_disable+0x36/0x50 [fpga_bridge]
[ 409.880502] fpga_region_program_fpga+0xea/0x200 [fpga_region]
[ 409.886338] fme_pr_ioctl+0x13e/0x330 [dfl_fme]
[ 409.890870] fme_ioctl+0x66/0xe0 [dfl_fme]
[ 409.894973] do_vfs_ioctl+0xa9/0x720
[ 409.898548] ? lockdep_hardirqs_on+0xf0/0x1a0
[ 409.902907] ksys_ioctl+0x60/0x90
[ 409.906225] __x64_sys_ioctl+0x16/0x20
[ 409.909981] do_syscall_64+0x5a/0x220
[ 409.913644] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 409.918698] RIP: 0033:0x7f9d31b9b8d7
[ 409.922276] Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48
[ 409.941020] RSP: 002b:7ffe4cae0d68 EFLAGS: 0202 ORIG_RAX:
0010
[ 409.948588] RAX: ffda RBX: 7f9d32ade6a0 RCX: 7f9d31b9b8d7
[ 409.955719] RDX: 7ffe4cae0df0 RSI: b680 RDI: 0003
[ 409.962852] RBP: 0003 R08: 7f9d2b70a177 R09: 7ffe4cae0e40
[ 409.969984] R10: 7ffe4cae0160 R11: 0202 R12: 7ffe4cae0df0
[ 409.977115] R13: b680 R14: R15: 7ffe4cae0f60
Signed-off-by: Scott Wood
---
v2: Removed incorrect "static" from a local variable
drivers/fpga/dfl.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 2c09e502e721..56dd39dcdcdf 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -40,6 +40,13 @@ enum dfl_fpga_devt_type {
DFL_FPGA_DEVT_MAX,
};
+static struct lock_class_key dfl_pdata_keys[DFL_ID_MAX];
+
+static const char *dfl_pdata_key_strings[DFL_ID_MAX] = {
+ "dfl-fme-pdata",
+ "dfl-port-pdata",
+};
+
/**
* dfl_dev_info - dfl feature device information.
* @name: name string of the feature platform device.
@@ -443,11 +450,16 @@ static int build_info_commit_dev(struct
build_feature_devs_info *binfo)
struct platform_device *fdev = binfo->feature_dev;
struct dfl_feature_platform_data *pdata;
struct dfl_feature_info *finfo, *p;
+ enum dfl_id_type type;
int ret, index = 0;
if (!fdev)
return 0;
+ type = feature_dev_id_type(fdev);
+ if (WARN_ON_ONCE(type >= DFL_ID_MAX))
+ return -EINVAL;
+
/*
* we do not need to care for the memory which is associated with
* the platform device. After calling platform_device_unregister(),
@@ -463,6 +475,8 @@ static int
Re: [PATCH 0/4] Allow CPU0 to be nohz full
Paul E. McKenney's on April 12, 2019 1:42 am: > On Tue, Apr 09, 2019 at 07:21:54PM +1000, Nicholas Piggin wrote: >> Thomas Gleixner's on April 6, 2019 3:54 am: >> > On Fri, 5 Apr 2019, Nicholas Piggin wrote: >> >> Thomas Gleixner's on April 5, 2019 12:36 am: >> >> > On Thu, 4 Apr 2019, Nicholas Piggin wrote: >> >> > >> >> >> I've been looking at ways to fix suspend breakage with CPU0 as a >> >> >> nohz CPU. I started looking at various things like allowing CPU0 >> >> >> to take over do_timer again temporarily or allowing nohz full >> >> >> to be stopped at runtime (that is quite a significant change for >> >> >> little real benefit). The problem then was having the housekeeping >> >> >> CPU go offline. >> >> >> >> >> >> So I decided to try just allowing the freeze to occur on non-zero >> >> >> CPU. This seems to be a lot simpler to get working, but I guess >> >> >> some archs won't be able to deal with this? Would it be okay to >> >> >> make it opt-in per arch? >> >> > >> >> > It needs to be opt in. x86 will fall on its nose with that. >> >> >> >> Okay I can add that. >> >> >> >> > Now the real interesting question is WHY do we need that at all? >> >> >> >> Why full nohz for CPU0? Basically this is how their job system was >> >> written and used, testing nohz full was a change that came much later >> >> as an optimisation. >> >> >> >> I don't think there is a fundamental reason an equivalent system >> >> could not be made that uses a different CPU for housekeeping, but I >> >> was assured the change would be quite difficult for them. >> >> >> >> If we can support it, it seems nice if you can take a particular >> >> configuration and just apply nohz_full to your application processors >> >> without any other changes. >> > >> > This wants an explanation in the patches. >> >> Okay. >> >> > And patch 4 has in the changelog: >> > >> >nohz_full has been successful at significantly reducing jitter for a >> >large supercomputer customer, but their job control system requires CPU0 >> >to be for housekeeping. >> > >> > which just makes me dazed and confused :) >> > >> > Other than some coherent explanation and making it opt in, I don't think >> > there is a fundamental issue with that. >> >> I will try to make the changelogs less jibberish then :) > > Maybe this is all taken care of now, but do the various clocks stay > synchronized with wall-clock time if all CPUs are in nohz_full mode? > At one time, at least one CPU needed to keep its scheduler-clock > interrupt going in order to keep things in sync. Ah, may not have been clear in the changelog -- the series still requires at least one CPU present at boot time to be a housekeeper that keeps things running. So conceptually this doesn't change anything about runtime behaviour, the main change is the boot-time handoff from CPU0. > The ppc timebase register might make it possible to do this without any > scheduler-clock interrupts, but figured I should check. ;-) I dont know all this code too well, but if we really wanted to push things, I think nohz-full could be more aggressive in shutting down the tick and possibly even avoiding a housekeeping CPU completely, but you would have to do that work on user->kernel switch too. Likely the complexity and overhead is not worthwhile. Other thing is you might be able to avoid the jiffies tick completely and change jiffies to read from timebase register. Lot of interesting things we could try. Thanks, Nick
[PATCH 1/1] pinctrl: Add alternative way for specifying register bases
The orginal PINCTRL_MTK_PARIS/PINCTRL_MTK_MOORE need more effort for
specifying register bases when porting platform driver:
1. Write mt_pinctrl_register_base_name[] array in pinctrl-mt.c
to specify names of register bases, for exmaple:
static const char * const mt6765_pinctrl_register_base_names[] = {
"iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4", "iocfg5",
"iocfg6", "iocfg7",
};
2. Write reg = <...>, ..., <...>; in mt.dts to specify register
bases. Each member of reg contain address range cloned from
pre-generated devicetree node.
3. Write reg-names = "...", ..., "..."; in mt.dts to specify
names of register bases. The sequence of names in reg-names shall match
sequence of names that specified in pinctrl-mt.c.
Besides, the seqeunce of names in reg-names shall also match sequence of
address range in reg, for exmaple:
pio: pinctrl {
compatible = "mediatek,mt6765-pinctrl";
reg = <0 0x10005000 0 0x1000>,
<0 0x10002C00 0 0x200>,
<0 0x10002800 0 0x200>,
<0 0x10002A00 0 0x200>,
<0 0x10002000 0 0x200>,
<0 0x10002200 0 0x200>,
<0 0x10002400 0 0x200>,
<0 0x10002600 0 0x200>,
<0 0x1000b000 0 0x1000>;
reg-names = "iocfg0", "iocfg1", "iocfg2", "iocfg3",
"iocfg4", "iocfg5", "iocfg6", "iocfg7",
"eint";
To reduce porting effort, this patch add an alternative way for specifying
register bases:
1. Write reg_bases = <...>, ..., <...>; and reg_base_eint = <>;
in mt.dtsi where members in reg_bases and are labels for
pre-generated devicetree nodes, for example:
pio: pinctrl {
compatible = "mediatek,mt6765-pinctrl";
reg_bases = <>,
<>,
<>,
<>,
<>,
<>,
<>,
<>,
<>;
reg_base_eint = <>;
Since this pre-generated nodes had already specify address range,
it is not necessary to specify address range again in pinctrl node.
Using this way, porting effort is reduced and therefore typo can occur with
less chance.
Change-Id: I55f5e328919f4f736ca4b9f8d1593e069f179637
---
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +---
drivers/pinctrl/mediatek/pinctrl-paris.c | 62
2 files changed, 54 insertions(+), 27 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index b1c3684..16b4863 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "mtk-eint.h"
#include "pinctrl-mtk-common-v2.h"
@@ -310,7 +311,7 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned
long eint_n)
int mtk_build_eint(struct mtk_pinctrl *hw, struct platform_device *pdev)
{
- struct device_node *np = pdev->dev.of_node;
+ struct device_node *np = pdev->dev.of_node, *node;
struct resource *res;
if (!IS_ENABLED(CONFIG_EINT_MTK))
@@ -323,13 +324,19 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct
platform_device *pdev)
if (!hw->eint)
return -ENOMEM;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "eint");
- if (!res) {
- dev_err(>dev, "Unable to get eint resource\n");
- return -ENODEV;
+ node = of_parse_phandle(np, "reg_base_eint", 0);
+ if (node) {
+ hw->eint->base = of_iomap(node, 0);
+ } else {
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "eint");
+ if (!res) {
+ dev_err(>dev, "Unable to get eint resource\n");
+ return -ENODEV;
+ }
+ hw->eint->base = devm_ioremap_resource(>dev, res);
}
- hw->eint->base = devm_ioremap_resource(>dev, res);
if (IS_ERR(hw->eint->base))
return PTR_ERR(hw->eint->base);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index b59e108..8ddb995 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -9,6 +9,7 @@
*Hongzhou.Yang
*/
+#include
#include
#include
#include "pinctrl-paris.h"
@@ -815,10 +816,11 @@ static int mtk_pctrl_build_state(struct platform_device
*pdev)
int mtk_paris_pinctrl_probe(struct platform_device *pdev,
const struct mtk_pin_soc *soc)
{
+
[PATCH v4 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address
dma_ranges field of PCI host bridge structure has resource entries in
sorted order of address range given through dma-ranges DT property. This
list is the accessible DMA address range. So that this resource list will
be processed and reserve IOVA address to the inaccessible address holes in
the list.
This method is similar to PCI IO resources address ranges reserving in
IOMMU for each EP connected to host bridge.
Signed-off-by: Srinath Mannam
Based-on-patch-by: Oza Pawandeep
Reviewed-by: Oza Pawandeep
---
drivers/iommu/dma-iommu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d19f3d6..fb42d7c 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -212,6 +212,7 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
struct resource_entry *window;
unsigned long lo, hi;
+ phys_addr_t start = 0, end;
resource_list_for_each_entry(window, >windows) {
if (resource_type(window->res) != IORESOURCE_MEM)
@@ -221,6 +222,24 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+ /* Get reserved DMA windows from host bridge */
+ resource_list_for_each_entry(window, >dma_ranges) {
+ end = window->res->start - window->offset;
+resv_iova:
+ if (end - start) {
+ lo = iova_pfn(iovad, start);
+ hi = iova_pfn(iovad, end);
+ reserve_iova(iovad, lo, hi);
+ }
+ start = window->res->end - window->offset + 1;
+ /* If window is last entry */
+ if (window->node.next == >dma_ranges &&
+ end != DMA_BIT_MASK(sizeof(dma_addr_t) * BITS_PER_BYTE)) {
+ end = DMA_BIT_MASK(sizeof(dma_addr_t) * BITS_PER_BYTE);
+ goto resv_iova;
+ }
+ }
}
static int iova_reserve_iommu_regions(struct device *dev,
--
2.7.4
Re: [PATCH v4 0/5] init: Do not select DEBUG_KERNEL by default
On 4/11/2019 11:02 PM, Josh Triplett wrote: I noticed one minor typo in patch 1/5, with that fixed, for the whole series: Can you point to the typo?
[PATCH v4 0/3] PCIe Host request to reserve IOVA
Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those SOCs has to list resource entries of allowed address ranges given in dma-ranges DT property in sorted order. This sorted list of resources will be processed and reserve IOVA address for inaccessible address holes while initializing IOMMU domain. This patch set is based on Linux-5.0-rc2. Changes from v3: - Addressed Robin Murphy review comments. - pcie-iproc: parse dma-ranges and make sorted resource list. - dma-iommu: process list and reserve gaps between entries Changes from v2: - Patch set rebased to Linux-5.0-rc2 Changes from v1: - Addressed Oza review comments. Srinath Mannam (3): PCI: Add dma_ranges window list iommu/dma: Reserve IOVA for PCIe inaccessible DMA address PCI: iproc: Add sorted dma ranges resource entries to host bridge drivers/iommu/dma-iommu.c | 19 drivers/pci/controller/pcie-iproc.c | 44 - drivers/pci/probe.c | 3 +++ include/linux/pci.h | 1 + 4 files changed, 66 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH] memory: ti-emif-sram: move driver-specific asm-offset.h to drivers/memory/
is only generated and included by drivers/memory/, so it does not need to reside in the globally visible include/generated/. Signed-off-by: Masahiro Yamada --- I will apply this to linux-kbuild since this depends on another patch there. drivers/memory/.gitignore| 1 + drivers/memory/Makefile | 5 +++-- drivers/memory/ti-emif-sram-pm.S | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 drivers/memory/.gitignore diff --git a/drivers/memory/.gitignore b/drivers/memory/.gitignore new file mode 100644 index ..cbca8b028437 --- /dev/null +++ b/drivers/memory/.gitignore @@ -0,0 +1 @@ +ti-emif-asm-offsets.h diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 91ae4eb0e913..2eb0a5b44bb9 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -28,9 +28,10 @@ ti-emif-sram-objs:= ti-emif-pm.o ti-emif-sram-pm.o AFLAGS_ti-emif-sram-pm.o :=-Wa,-march=armv7-a -drivers/memory/ti-emif-sram-pm.o: include/generated/ti-emif-asm-offsets.h +$(obj)/ti-emif-sram-pm.o: $(obj)/ti-emif-asm-offsets.h -include/generated/ti-emif-asm-offsets.h: drivers/memory/emif-asm-offsets.s FORCE +$(obj)/ti-emif-asm-offsets.h: $(obj)/emif-asm-offsets.s FORCE $(call filechk,offsets,__TI_EMIF_ASM_OFFSETS_H__) targets += emif-asm-offsets.s +clean-files += ti-emif-asm-offsets.h diff --git a/drivers/memory/ti-emif-sram-pm.S b/drivers/memory/ti-emif-sram-pm.S index a5369181e5c2..615cd6247739 100644 --- a/drivers/memory/ti-emif-sram-pm.S +++ b/drivers/memory/ti-emif-sram-pm.S @@ -14,12 +14,12 @@ * GNU General Public License for more details. */ -#include #include #include #include #include "emif.h" +#include "ti-emif-asm-offsets.h" #define EMIF_POWER_MGMT_WAIT_SELF_REFRESH_8192_CYCLES 0x00a0 #define EMIF_POWER_MGMT_SR_TIMER_MASK 0x00f0 -- 2.17.1
Re: [PATCH 4/6] x86, mm: make split_mem_range() more easy to read
On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote: >Find a mostly untested patch which implements this below. I just booted it >in a 64bit guest and it did not explode. > >It removes 55 lines of code instead of adding 35 and reduces the binary >size by 408 bytes on 64bit and 128 bytes on 32bit. > >Note, it's a combo of changes (including your patch 1/6) and needs to be >split up. It would be nice if you have time to split it up into separate >patches, add proper changelogs and test the heck out of it on both 32 and >64 bit. If you don't have time, please let me know. I tried to test mem hotplug with this applied. On x86_64, this looks good. It split ranges well. While I found some problem on testing mem hotplug on x86_32. I start up a guest memory and trying to plug 1G memory. The original memory split range looks good: [0.004260] ywtest: [mem 0x-0x0010] [0.004261] ywtest: [mem 0x-0x000f] page size 4k [0.004268] ywtest: [mem 0x3720-0x3740] [0.004269] ywtest: [mem 0x3720-0x373f] page size 2M [0.004271] ywtest: [mem 0x2000-0x3720] [0.004272] ywtest: [mem 0x2000-0x371f] page size 2M [0.004280] ywtest: [mem 0x0010-0x2000] [0.004281] ywtest: [mem 0x0010-0x001f] page size 4k [0.004281] ywtest: [mem 0x0020-0x1fff] page size 2M [0.004292] ywtest: [mem 0x3740-0x375fe000] [0.004293] ywtest: [mem 0x3740-0x375fdfff] page size 4k While I can't online the new added memory device. And the new memory device's range is out of 4G, which is a little bit strange. > >Thanks, > > tglx > -- Wei Yang Help you, Help me
Re: [PATCH 15/17] fpga: dfl: fme: add power management support
On Thu, Apr 11, 2019 at 03:07:35PM -0500, Alan Tull wrote:
> On Sun, Mar 24, 2019 at 10:24 PM Wu Hao wrote:
>
> Hi Hao,
>
> >
> > This patch adds support for power management private feature under
> > FPGA Management Engine (FME), sysfs interfaces are introduced for
> > different power management functions, users could use these sysfs
> > interface to get current number of consumed power, throttling
>
> How about
> s/number/measurement/
> ?
Sounds better. : )
>
> > thresholds, threshold status and other information, and configure
> > different value for throttling thresholds too.
> >
> > Signed-off-by: Luwei Kang
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
> > ---
> > Documentation/ABI/testing/sysfs-platform-dfl-fme | 56 +
> > drivers/fpga/dfl-fme-main.c | 257
> > +++
> > 2 files changed, 313 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > index d3aeb88..4b6448f 100644
> > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > @@ -100,3 +100,59 @@ Description: Read-only. Read this file to get
> > the policy of temperature
> > threshold1. It only supports two value (policy):
> > 0 - AP2 state (90% throttling)
> > 1 - AP1 state (50% throttling)
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/consumed
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. It returns current power consumed by FPGA.
>
> What are the units?
>
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold1
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-Write. Read/Write this file to get/set current power
> > + threshold1 in Watts.
>
> Perhaps document error codes here and for threshold2 below.
>
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold2
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-Write. Read/Write this file to get/set current power
> > + threshold2 in Watts.
> > +
> > +What:
> > /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold1_status
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. It returns 1 if power consumption reaches the
> > + threshold1, otherwise 0.
>
> I'm used to things like this requiring user to reset the status, so it
> may be worth making it explicit that it will return to zero if
> consumption drops below threshold if that's what's happening here.
> If it's correct, perhaps could just say something like 'returns 1 if
> power consumption is currently at or above threshold1, otherwise 0'
>
> > +
> > +What:
> > /sys/bus/platform/devices/dfl-fme.0/power_mgmt/threshold2_status
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. It returns 1 if power consumption reaches the
> > + threshold2, otherwise 0.
>
> Same here.
Sure, will fix all above comments in this sysfs doc.
>
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/ltr
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. Read this file to get current Latency Tolerance
> > + Reporting (ltr) value, it's only valid for integrated
> > + solution as it blocks CPU on low power state.
>
> If we're not on the integrated solution, it returns a value but it is
> not really real?
Currently only integrated solution is implementing this private feature, other
devices e.g. Intel PAC card is not using this private feature, so user will
not see these sysfs interfaces at all.
If in the future, other devices want
>
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/xeon_limit
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. Read this file to get power limit for xeon, it
> > + is only valid for integrated solution.
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/power_mgmt/fpga_limit
> > +Date: March 2019
> > +KernelVersion: 5.2
> > +Contact: Wu Hao
> > +Description: Read-only. Read this file to get power limit for fpga, it
> > + is only valid for integrated solution.
> > diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> > index 449a17d..dafa6580 100644
> > --- a/drivers/fpga/dfl-fme-main.c
> > +++ b/drivers/fpga/dfl-fme-main.c
> > @@ -415,6 +415,259 @@ static const struct dfl_feature_ops
> > fme_thermal_mgmt_ops = {
> >
Re: [PATCH v4 0/5] init: Do not select DEBUG_KERNEL by default
On Fri, Apr 12, 2019 at 01:43:50AM +, Sinan Kaya wrote:
> CONFIG_DEBUG_KERNEL has been designed to just enable Kconfig options.
> Kernel code generatoin should not depend on CONFIG_DEBUG_KERNEL.
>
> Proposed alternative plan: let's add a new symbol, something like
> DEBUG_MISC ("Miscellaneous debug code that should be under a more
> specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
> "default DEBUG_KERNEL" but allow itself to be turned off, and then
> mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
> "#ifdef CONFIG_DEBUG_MISC".
>
> Sinan Kaya (5):
> init: Introduce DEBUG_MISC option
> powerpc: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
> mips: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
> xtensa: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
> net: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
I noticed one minor typo in patch 1/5, with that fixed, for the whole
series:
Reviewed-by: Josh Triplett
Re: [PATCH v4 1/5] init: Introduce DEBUG_MISC option
On Fri, Apr 12, 2019 at 01:43:51AM +, Sinan Kaya wrote:
> Introduce DEBUG_MISC ("Miscellaneous debug code that should be under a more
> specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
> "default DEBUG_KERNEL" but allow itself to be turned off, and then
> mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
> "#ifdef CONFIG_DEBUG_MISC".
>
> Signed-off-by: Sinan Kaya
Minor typo below; with that:
Reviewed-by: Josh Triplett
And thank you!
> ---
> lib/Kconfig.debug | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 0d9e81779e37..2f80ebaa6d9a 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -438,6 +438,15 @@ config DEBUG_KERNEL
> Say Y here if you are developing drivers or trying to debug and
> identify kernel problems.
>
> +config DEBUG_MISC
> + bool "Miscellaneous debug code"
> + default DEBUG_KERNEL
> + depends on DEBUG_KERNEL
> + help
> + Say Y here if you need to enable Miscellaneous debug code that should
Nit: s/Miscellaneous/miscellaneous/
> + be under a more specific debug option but isn't.
> +
> +
> menu "Memory Debugging"
>
> source "mm/Kconfig.debug"
> --
> 2.21.0
>
Re: [PATCH v5 6/9] clk: mediatek: Add flags support for mtk_gate data
On Thu, 2019-04-11 at 13:19 -0700, Stephen Boyd wrote:
> Quoting Weiyi Lu (2019-03-04 21:05:43)
> > On some Mediatek platforms, there are critical clocks of
> > clock gate type.
> > To register clock gate with flags CLK_IS_CRITICAL,
> > we need to add the flags field in mtk_gate data and register APIs.
> >
> > Signed-off-by: Weiyi Lu
>
> This patch doesn't apply, because it's already there via commit
> 5a1cc4c27ad2 ("clk: mediatek: Add flags to mtk_gate").
>
Got it, but just catch a minor defect by 5a1cc4c27ad2 ("clk: mediatek:
Add flags to mtk_gate").
init.flags = CLK_SET_RATE_PARENT;
...
init.flags = flags;
I'll send a fix later.
Thanks for the help on the MT8183 clk series.
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] module: Make srcu_struct ptr array as read-only
On Thu, Apr 11, 2019 at 10:14:22PM -0400, Joel Fernandes wrote:
> On Thu, Apr 11, 2019 at 02:31:55PM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 11, 2019 at 04:24:21PM -0400, Joel Fernandes (Google) wrote:
> > > Since commit title ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
> > > modules"), modules that call DEFINE_{STATIC,}SRCU will have a new array
> > > of srcu_struct pointers, which is used by srcu code to initialize and
> > > clean up these structures and save valuable per-cpu reserved space.
> > >
> > > There is no reason for this array of pointers to be writable, and can
> > > cause security or other hidden bugs. Mark these are read-only after the
> > > module init has completed.
> > >
> > > Tested with the following diff to ensure array not writable:
> > >
> > > (diff is a bit reduced to avoid patch command getting confused)
> > > a/kernel/module.c
> > > b/kernel/module.c
> > > -3506,6 +3506,14 static noinline int do_init_module [snip]
> > > rcu_assign_pointer(mod->kallsyms, >core_kallsyms);
> > > #endif
> > > module_enable_ro(mod, true);
> > > +
> > > + if (mod->srcu_struct_ptrs) {
> > > + // Check if srcu_struct_ptrs access is possible
> > > + char x = *(char *)mod->srcu_struct_ptrs;
> > > + *(char *)mod->srcu_struct_ptrs = 0;
> > > + *(char *)mod->srcu_struct_ptrs = x;
> > > + }
> > > +
> > > mod_tree_remove_init(mod);
> > > disable_ro_nx(>init_layout);
> > > module_arch_freeing_init(mod);
> > >
> > > Cc: Rasmus Villemoes
> > > Cc: paul...@linux.vnet.ibm.com
> > > Cc: rost...@goodmis.org
> > > Cc: mathieu.desnoy...@efficios.com
> > > Cc: r...@vger.kernel.org
> > > Cc: kernel-harden...@lists.openwall.com
> > > Cc: kernel-t...@android.com
> > > Signed-off-by: Joel Fernandes (Google)
> >
> > Queued for testing and further review, thank you, Joel!
>
> Thanks a lot! I also just saw you added the rcutorture module to be built as
> a part kselftests which is really cool ;-)
Just a smoke test, really, but it will be interesting to see how
it goes. ;-)
Thanx, Paul
RE: [EXT] Re: [PATCH V7 2/4] firmware: imx: enable imx scu general irq function
Best Regards! Anson Huang > -Original Message- > From: Aisheng Dong > Sent: 2019年4月12日 10:26 > To: Anson Huang ; Shawn Guo > ; alexandre.bell...@bootlin.com > Cc: robh...@kernel.org; mark.rutl...@arm.com; s.ha...@pengutronix.de; > ker...@pengutronix.de; feste...@gmail.com; a.zu...@towertech.it; > alexandre.bell...@bootlin.com; ulf.hans...@linaro.org; sb...@kernel.org; > Peng Fan ; Daniel Baluta ; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-...@vger.kernel.org; dl-linux-imx i...@nxp.com> > Subject: RE: [EXT] Re: [PATCH V7 2/4] firmware: imx: enable imx scu general > irq function > > > From: Anson Huang > > Sent: Friday, April 12, 2019 9:06 AM > > > > Hello, Alexandre > > As i.MX SCU general irq function is picked up by Shawn, could you > > please also pick up below i.MX SC RTC alarm support patch ? > > https://patchwork.kernel.org/patch/10890525/ > > > > No, it can't go through Alexandre's tree due to dependency issue. > > Shawn, > Do you think you can pick it up? Alexandre already gave the Ack. > > AFAIK there's no other SCU RTC patches since v5.1-rc1 in Alexandre's tree. Yes, need to make sure the dependency is handled, the RTC alarm patch MUST be picked up ONLY when scu irq patch is ready, NOT sure how to handle this case for such scenario? Anson. > > Regards > Dong Aisheng > > > > On Tue, Apr 09, 2019 at 04:59:55AM +, Anson Huang wrote: > > > > The System Controller Firmware (SCFW) controls RTC, thermal and > > > > WDOG etc., these resources' interrupt function are managed by SCU. > > > > When any IRQ pending, SCU will notify Linux via MU general > > > > interrupt channel #3, and Linux kernel needs to call SCU APIs to > > > > get IRQ status and notify each module to handle the interrupt. > > > > > > > > Since there is no data transmission for SCU IRQ notification, so > > > > doorbell mode is used for this MU channel, and SCU driver will use > > > > notifier mechanism to broadcast to every module which registers > > > > the SCU block notifier. > > > > > > > > Signed-off-by: Anson Huang > > > > Reviewed-by: Dong Aisheng > > > > > > Applied, thanks.
RE: [EXT] Re: [PATCH V7 2/4] firmware: imx: enable imx scu general irq function
> From: Anson Huang > Sent: Friday, April 12, 2019 9:06 AM > > Hello, Alexandre > As i.MX SCU general irq function is picked up by Shawn, could you please > also pick up below i.MX SC RTC alarm support patch ? > https://patchwork.kernel.org/patch/10890525/ > No, it can't go through Alexandre's tree due to dependency issue. Shawn, Do you think you can pick it up? Alexandre already gave the Ack. AFAIK there's no other SCU RTC patches since v5.1-rc1 in Alexandre's tree. Regards Dong Aisheng > > On Tue, Apr 09, 2019 at 04:59:55AM +, Anson Huang wrote: > > > The System Controller Firmware (SCFW) controls RTC, thermal and WDOG > > > etc., these resources' interrupt function are managed by SCU. When > > > any IRQ pending, SCU will notify Linux via MU general interrupt > > > channel #3, and Linux kernel needs to call SCU APIs to get IRQ > > > status and notify each module to handle the interrupt. > > > > > > Since there is no data transmission for SCU IRQ notification, so > > > doorbell mode is used for this MU channel, and SCU driver will use > > > notifier mechanism to broadcast to every module which registers the > > > SCU block notifier. > > > > > > Signed-off-by: Anson Huang > > > Reviewed-by: Dong Aisheng > > > > Applied, thanks.
Re: [PATCH] module: Make srcu_struct ptr array as read-only
On Thu, Apr 11, 2019 at 02:31:55PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 11, 2019 at 04:24:21PM -0400, Joel Fernandes (Google) wrote:
> > Since commit title ("srcu: Allocate per-CPU data for DEFINE_SRCU() in
> > modules"), modules that call DEFINE_{STATIC,}SRCU will have a new array
> > of srcu_struct pointers, which is used by srcu code to initialize and
> > clean up these structures and save valuable per-cpu reserved space.
> >
> > There is no reason for this array of pointers to be writable, and can
> > cause security or other hidden bugs. Mark these are read-only after the
> > module init has completed.
> >
> > Tested with the following diff to ensure array not writable:
> >
> > (diff is a bit reduced to avoid patch command getting confused)
> > a/kernel/module.c
> > b/kernel/module.c
> > -3506,6 +3506,14 static noinline int do_init_module [snip]
> > rcu_assign_pointer(mod->kallsyms, >core_kallsyms);
> > #endif
> > module_enable_ro(mod, true);
> > +
> > + if (mod->srcu_struct_ptrs) {
> > + // Check if srcu_struct_ptrs access is possible
> > + char x = *(char *)mod->srcu_struct_ptrs;
> > + *(char *)mod->srcu_struct_ptrs = 0;
> > + *(char *)mod->srcu_struct_ptrs = x;
> > + }
> > +
> > mod_tree_remove_init(mod);
> > disable_ro_nx(>init_layout);
> > module_arch_freeing_init(mod);
> >
> > Cc: Rasmus Villemoes
> > Cc: paul...@linux.vnet.ibm.com
> > Cc: rost...@goodmis.org
> > Cc: mathieu.desnoy...@efficios.com
> > Cc: r...@vger.kernel.org
> > Cc: kernel-harden...@lists.openwall.com
> > Cc: kernel-t...@android.com
> > Signed-off-by: Joel Fernandes (Google)
>
> Queued for testing and further review, thank you, Joel!
Thanks a lot! I also just saw you added the rcutorture module to be built as
a part kselftests which is really cool ;-)
thanks,
- Joel
Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
On Thu, 2019-04-11 at 15:34 -0700, Linus Torvalds wrote: > On Thu, Apr 11, 2019 at 3:13 PM Benjamin Herrenschmidt > wrote: > > > > Minor nit... I would have said "All readX() and writeX() accesses > > _from > > the same CPU_ to the same peripheral... and then s/the CPU/this > > CPU. > > Maybe talk about "same thread" rather than "same cpu", with the > understanding that scheduling/preemption has to include the > appropriate cross-CPU IO barrier? Works for me, but why not spell all this out in the document ? We know, but others might not. Cheers, Ben.
Re: [PATCH] pinctrl: Add kernel config PINCTRL_MTK_V2
Dear reviewer, The points of Sean are right. Please forget this patch proposal. On Thu, 2019-04-11 at 15:04 -0700, Sean Wang wrote: > Hi, Light > > On Thu, Apr 11, 2019 at 2:32 AM Light Hsieh wrote: > > > > Since no single Mediatek chip use code for PINCTRL_MTK and code for > > PINCTRL_MTK_MOORE/PINCTRL_MTK_PARIS simultaneously, it is better to use > > different config to determine if related code will be built or not on > > building non-generic kernel. > > > > Add kernel config PINCTRL_MTK_V2 selected by either PINCTRL_MTK_MOORE > > or PINCTRL_MTK_PARIS. > > Use PINCTRL_MTK and PINCTRL_MTK_V2 to control building of > > drivers/pinctrl/medaitek/. > > Remove selection of EINT_MTK from PINCTRL_MTK since code for EINT_MTK is > > only related to PINCTRL_MTK_MOORE/PINCTRL_MTK_PARIS, i.e. PINCTL_MTK_V2. > > > > PINCTRL_MTK also depends on EINT_MTK such as the symbol > mtk_eint_do_init, it is a commonlibrary for the two kinds of the > pinctrl core. > Yes, you are right. It is my fault that I don't see some mtk_eint_* functions originally in pinctrl-mtk-common.c had been moved to mtk-eint.c since kernel-4.18 and now pinctrl-mtk-common.c depends on mtk-eint.c. > > --- > > drivers/pinctrl/Makefile | 3 ++- > > drivers/pinctrl/mediatek/Kconfig | 15 --- > > 2 files changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile > > index 712184b..fcee0e0 100644 > > --- a/drivers/pinctrl/Makefile > > +++ b/drivers/pinctrl/Makefile > > @@ -65,6 +65,7 @@ obj-$(CONFIG_PINCTRL_SUNXI) += sunxi/ > > obj-y += ti/ > > obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/ > > obj-$(CONFIG_ARCH_VT8500) += vt8500/ > > -obj-y += mediatek/ > > +obj-$(CONFIG_PINCTRL_MTK) += mediatek/ > > +obj-$(CONFIG_PINCTRL_MTK_V2) += mediatek/ > > I would think it is good if deciding V1 or not should be done inside > the vendor directory and the change also would cause COMPILE_TEST not > be applied to Agree. > > obj-$(CONFIG_PINCTRL_ZX) += zte/ > > obj-y += cirrus/ > > diff --git a/drivers/pinctrl/mediatek/Kconfig > > b/drivers/pinctrl/mediatek/Kconfig > > index a005cbc..5e26462 100644 > > --- a/drivers/pinctrl/mediatek/Kconfig > > +++ b/drivers/pinctrl/mediatek/Kconfig > > @@ -2,10 +2,15 @@ menu "MediaTek pinctrl drivers" > > depends on ARCH_MEDIATEK || COMPILE_TEST > > > > config EINT_MTK > > - bool "MediaTek External Interrupt Support" > > - depends on PINCTRL_MTK || PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || > > COMPILE_TEST > > + bool "MediaTek External Interrupt driver that is based on > > PINCTRL_MTK_V2" > > + depends on PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || COMPILE_TEST > > select GPIOLIB > > select IRQ_DOMAIN > > + help > > + Say yes here to enable support for MediaTek External Interrupt > > + (EINT) driver based on PINCTRL_MTK version 2. > > + This driver is combined with MediaTek Pinctrl driver version 2 > > + so PINCTRL_MTK_V2 shall be set first. > > > > config PINCTRL_MTK > > bool > > @@ -13,9 +18,11 @@ config PINCTRL_MTK > > select PINMUX > > select GENERIC_PINCONF > > select GPIOLIB > > - select EINT_MTK > > select OF_GPIO > > > > +config PINCTRL_MTK_V2 > > + bool "MediaTek Pinctrl Support V2" > > + > > config PINCTRL_MTK_MOORE > > bool > > depends on OF > > @@ -24,6 +31,7 @@ config PINCTRL_MTK_MOORE > > select GENERIC_PINMUX_FUNCTIONS > > select GPIOLIB > > select OF_GPIO > > + select PINCTRL_MTK_V2 > > > > config PINCTRL_MTK_PARIS > > bool > > @@ -33,6 +41,7 @@ config PINCTRL_MTK_PARIS > > select GPIOLIB > > select EINT_MTK > > select OF_GPIO > > + select PINCTRL_MTK_V2 > > > > # For ARMv7 SoCs > > config PINCTRL_MT2701 > > -- > > 1.8.1.1.dirty > >
Re: [PATCH] xfs: use struct_size() helper
On 4/11/19 7:19 PM, Darrick J. Wong wrote:
> [fixing linux-xfs cc]
>
Thanks for this.
> On Thu, Apr 11, 2019 at 06:37:58PM -0500, Gustavo A. R. Silva wrote:
>> Make use of the struct_size() helper instead of an open-coded version
>> in order to avoid any potential type mistakes, in particular in the
>> context in which this code is being used.
>>
>> So, replace code of the following form:
>>
>> sizeof(*alist) + context->count * sizeof(alist->al_offset[0]
>>
>> with:
>>
>> struct_size(alist, al_offset, context->count)
>>
>> and remove unnecessary variable arraytop.
>>
>> This code was detected with the help of Coccinelle.
>>
>> Signed-off-by: Gustavo A. R. Silva
>
> Has this been run through xfstests?
>
No. Is this a requirement?
Thanks
--
Gustavo
> --D
>
>> fs/xfs/xfs_attr_list.c | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c
>> index 3d213a7394c5..05e03348553e 100644
>> --- a/fs/xfs/xfs_attr_list.c
>> +++ b/fs/xfs/xfs_attr_list.c
>> @@ -553,7 +553,6 @@ xfs_attr_put_listent(
>> {
>> struct attrlist *alist = (struct attrlist *)context->alist;
>> attrlist_ent_t *aep;
>> -int arraytop;
>>
>> ASSERT(!context->seen_enough);
>> ASSERT(!(context->flags & ATTR_KERNOVAL));
>> @@ -572,10 +571,8 @@ xfs_attr_put_listent(
>> ((flags & XFS_ATTR_ROOT) == 0))
>> return;
>>
>> -arraytop = sizeof(*alist) +
>> -context->count * sizeof(alist->al_offset[0]);
>> context->firstu -= ATTR_ENTSIZE(namelen);
>> -if (context->firstu < arraytop) {
>> +if (context->firstu < struct_size(alist, al_offset, context->count)) {
>> trace_xfs_attr_list_full(context);
>> alist->al_more = 1;
>> context->seen_enough = 1;
>> --
>> 2.21.0
>>
Re: [PATCH 1/5] clk: rockchip: Turn on "aclk_dmac1" for suspend
hi,
在 2019/4/12 上午7:21, Douglas Anderson 写道:
Experimentally it can be seen that going into deep sleep (specifically
setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
appears to fail unless "aclk_dmac1" is on. The failure is that the
system never signals that it made it into suspend on the GLOBAL_PWROFF
pin and it just hangs.
NOTE that it's confirmed that it's the actual suspend that fails, not
one of the earlier calls to read/write registers. Specifically if you
comment out the "PMU_GLOBAL_INT_DISABLE" setting in
rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
rockchip_lpmode_enter() then you can exercise the whole suspend path
without any crashing.
This is currently not a problem with suspend upstream because there is
no current way to exercise the deep suspend code. However, anyone
trying to make it work will run into this issue.
This was not a problem on shipping rk3288-based Chromebooks because
those devices all ran on an old kernel based on 3.14. On that kernel
"aclk_dmac1" appears to be left on all the time.
There are several ways to skin this problem.
A) We could add "aclk_dmac1" to the list of critical clocks and that
apperas to work, but presumably that wastes power.
B) We could keep a list of "struct clk" objects to enable at suspend
time in clk-rk3288.c and use the standard clock APIs.
C) We could make the rk3288-pmu driver keep a list of clocks to enable
at suspend time. Presumably this would require a dts and bindings
change.
D) We could just whack the clock on in the existing syscore suspend
function where we whack a bunch of other clocks. This is particularly
easy because we know for sure that the clock's only parent
("aclk_cpu") is a critical clock so we don't need to do anything more
than ungate it.
In this case I have chosen D) because it seemed like the least work,
but any of the other options would presumably also work fine.
Signed-off-by: Douglas Anderson
---
drivers/clk/rockchip/clk-rk3288.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 5a67b7869960..b245367393cd 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -859,6 +859,9 @@ static const int rk3288_saved_cru_reg_ids[] = {
RK3288_CLKSEL_CON(10),
RK3288_CLKSEL_CON(33),
RK3288_CLKSEL_CON(37),
+
+ /* We turn aclk_dmac1 on for suspend; this will restore it */
+ RK3288_CLKGATE_CON(10),
};
static u32 rk3288_saved_cru_regs[ARRAY_SIZE(rk3288_saved_cru_reg_ids)];
@@ -874,6 +877,14 @@ static int rk3288_clk_suspend(void)
readl_relaxed(rk3288_cru_base + reg_id);
}
+ /*
+* Going into deep sleep (specifically setting PMU_CLR_DMA in
+* RK3288_PMU_PWRMODE_CON1) appears to fail unless
+* "aclk_dmac1" is on.
+*/
+ writel_relaxed(1 << (12 + 16),
+ rk3288_cru_base + RK3288_CLKGATE_CON(10));
+
/*
* Switch PLLs other than DPLL (for SDRAM) to slow mode to
* avoid crashes on resume. The Mask ROM on the system will
Thank you for your correction.
Reviewed-by: Elaine Zhang
Re: [PATCH 5/5] ARM: dts: rockchip: vdd_gpu off in suspend for rk3288-veyron
hi,
在 2019/4/12 上午7:21, Douglas Anderson 写道:
At some point long long ago the downstream GPU driver would crash if
we turned the GPU off during suspend. For some context you can see:
https://chromium-review.googlesource.com/#/c/215780/5..6/arch/arm/boot/dts/rk3288-pinky-rev2.dts
At some point in time not too long after that got fixed.
It's unclear why the GPU is left enabled during suspend on the
mainline kernel. Everything seems fine if I turn this off, so let's
do it.
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 279d7f4ecce0..1252522392c7 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -217,8 +217,7 @@
regulator-max-microvolt = <125>;
regulator-ramp-delay = <6001>;
regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <100>;
+ regulator-off-in-suspend;
};
};
Reviewed-by: Elaine Zhang
[PATCH 2/3] regulator: db8500-prcmu: Convert to use simplified DT parsing
Use regulator core's simplified DT parsing code to simplify the driver
implementation.
Signed-off-by: Axel Lin
---
drivers/regulator/db8500-prcmu.c | 139 ++-
1 file changed, 42 insertions(+), 97 deletions(-)
diff --git a/drivers/regulator/db8500-prcmu.c b/drivers/regulator/db8500-prcmu.c
index 863bd3de42a7..c2a3ccfc510e 100644
--- a/drivers/regulator/db8500-prcmu.c
+++ b/drivers/regulator/db8500-prcmu.c
@@ -214,6 +214,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VAPE] = {
.desc = {
.name = "db8500-vape",
+ .of_match = of_match_ptr("db8500_vape"),
.id = DB8500_REGULATOR_VAPE,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -223,6 +224,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VARM] = {
.desc = {
.name = "db8500-varm",
+ .of_match = of_match_ptr("db8500_varm"),
.id = DB8500_REGULATOR_VARM,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -232,6 +234,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VMODEM] = {
.desc = {
.name = "db8500-vmodem",
+ .of_match = of_match_ptr("db8500_vmodem"),
.id = DB8500_REGULATOR_VMODEM,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -241,6 +244,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VPLL] = {
.desc = {
.name = "db8500-vpll",
+ .of_match = of_match_ptr("db8500_vpll"),
.id = DB8500_REGULATOR_VPLL,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -250,6 +254,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VSMPS1] = {
.desc = {
.name = "db8500-vsmps1",
+ .of_match = of_match_ptr("db8500_vsmps1"),
.id = DB8500_REGULATOR_VSMPS1,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -259,6 +264,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VSMPS2] = {
.desc = {
.name = "db8500-vsmps2",
+ .of_match = of_match_ptr("db8500_vsmps2"),
.id = DB8500_REGULATOR_VSMPS2,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -271,6 +277,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VSMPS3] = {
.desc = {
.name = "db8500-vsmps3",
+ .of_match = of_match_ptr("db8500_vsmps3"),
.id = DB8500_REGULATOR_VSMPS3,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -280,6 +287,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_VRF1] = {
.desc = {
.name = "db8500-vrf1",
+ .of_match = of_match_ptr("db8500_vrf1"),
.id = DB8500_REGULATOR_VRF1,
.ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
@@ -289,6 +297,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_SWITCH_SVAMMDSP] = {
.desc = {
.name = "db8500-sva-mmdsp",
+ .of_match = of_match_ptr("db8500_sva_mmdsp"),
.id = DB8500_REGULATOR_SWITCH_SVAMMDSP,
.ops= _regulator_switch_ops,
.type = REGULATOR_VOLTAGE,
@@ -299,6 +308,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_SWITCH_SVAMMDSPRET] = {
.desc = {
.name = "db8500-sva-mmdsp-ret",
+ .of_match = of_match_ptr("db8500_sva_mmdsp_ret"),
.id = DB8500_REGULATOR_SWITCH_SVAMMDSPRET,
.ops= _regulator_switch_ops,
.type = REGULATOR_VOLTAGE,
@@ -310,6 +320,7 @@ dbx500_regulator_info[DB8500_NUM_REGULATORS] = {
[DB8500_REGULATOR_SWITCH_SVAPIPE] = {
.desc = {
.name = "db8500-sva-pipe",
+ .of_match = of_match_ptr("db8500_sva_pipe"),
.id = DB8500_REGULATOR_SWITCH_SVAPIPE,
.ops=
[PATCH 3/3] regulator: dbx500-prcmu: Remove unused fields from struct dbx500_regulator_info
The *dev is assigned but not used, remove it.
Current driver is using devm_regulator_register(), so no neeed to save
*rdev for clean up. Use a local variable instead.
Signed-off-by: Axel Lin
---
drivers/regulator/db8500-prcmu.c | 10 +-
drivers/regulator/dbx500-prcmu.h | 4
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/db8500-prcmu.c b/drivers/regulator/db8500-prcmu.c
index c2a3ccfc510e..eb317663f875 100644
--- a/drivers/regulator/db8500-prcmu.c
+++ b/drivers/regulator/db8500-prcmu.c
@@ -439,6 +439,7 @@ static int db8500_regulator_probe(struct platform_device
*pdev)
struct regulator_init_data *db8500_init_data;
struct dbx500_regulator_info *info;
struct regulator_config config = { };
+ struct regulator_dev *rdev;
int err, i;
db8500_init_data = dev_get_platdata(>dev);
@@ -446,17 +447,16 @@ static int db8500_regulator_probe(struct platform_device
*pdev)
for (i = 0; i < ARRAY_SIZE(dbx500_regulator_info); i++) {
/* assign per-regulator data */
info = _regulator_info[i];
- info->dev = >dev;
config.driver_data = info;
config.dev = >dev;
if (db8500_init_data)
config.init_data = _init_data[i];
- info->rdev = devm_regulator_register(>dev, >desc,
-);
- if (IS_ERR(info->rdev)) {
- err = PTR_ERR(info->rdev);
+ rdev = devm_regulator_register(>dev, >desc,
+ );
+ if (IS_ERR(rdev)) {
+ err = PTR_ERR(rdev);
dev_err(>dev, "failed to register %s: err %i\n",
info->desc.name, err);
return err;
diff --git a/drivers/regulator/dbx500-prcmu.h b/drivers/regulator/dbx500-prcmu.h
index c8e51ace9f06..6e20dab611ac 100644
--- a/drivers/regulator/dbx500-prcmu.h
+++ b/drivers/regulator/dbx500-prcmu.h
@@ -15,18 +15,14 @@
/**
* struct dbx500_regulator_info - dbx500 regulator information
- * @dev: device pointer
* @desc: regulator description
- * @rdev: regulator device pointer
* @is_enabled: status of the regulator
* @epod_id: id for EPOD (power domain)
* @is_ramret: RAM retention switch for EPOD (power domain)
*
*/
struct dbx500_regulator_info {
- struct device *dev;
struct regulator_desc desc;
- struct regulator_dev *rdev;
bool is_enabled;
u16 epod_id;
bool is_ramret;
--
2.17.1
Re: [PATCH 4/5] ARM: dts: rockchip: vcc33_ccd off in suspend for rk3288-veyron-chromebook
hi,
在 2019/4/12 上午7:21, Douglas Anderson 写道:
As per my comments when the device tree for rk3288-veyron-chromebook
first landed:
Technically I think vcc33_ccd can be off since we have
'needs-reset-on-resume' down in the EHCI port (this regulator is for
the USB webcam that's connected to the EHCI port).
...but leaving it on for now seems fine until we get suspend/resume
more solid.
It's probably about time to do it right.
[1]
https://lore.kernel.org/linux-arm-kernel/CAD=FV=u37yx8mqk75_x05zxonvdc3qrmhqp8tytdpwghqsu...@mail.gmail.com/
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index b9cc90f0f25c..fbef34578100 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -176,8 +176,7 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <330>;
+ regulator-off-in-suspend;
};
};
};
Reviewed-by: Elaine Zhang
[PATCH 1/3] regulator: db8500-prcmu: Constify regulator_ops
These regulator_ops variables never need to be modified, make them const so
compiler can put them to .rodata.
Signed-off-by: Axel Lin
---
drivers/regulator/db8500-prcmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/db8500-prcmu.c b/drivers/regulator/db8500-prcmu.c
index 7cec535cf0bc..863bd3de42a7 100644
--- a/drivers/regulator/db8500-prcmu.c
+++ b/drivers/regulator/db8500-prcmu.c
@@ -75,7 +75,7 @@ static int db8500_regulator_is_enabled(struct regulator_dev
*rdev)
}
/* db8500 regulator operations */
-static struct regulator_ops db8500_regulator_ops = {
+static const struct regulator_ops db8500_regulator_ops = {
.enable = db8500_regulator_enable,
.disable= db8500_regulator_disable,
.is_enabled = db8500_regulator_is_enabled,
@@ -200,7 +200,7 @@ static int db8500_regulator_switch_is_enabled(struct
regulator_dev *rdev)
return info->is_enabled;
}
-static struct regulator_ops db8500_regulator_switch_ops = {
+static const struct regulator_ops db8500_regulator_switch_ops = {
.enable = db8500_regulator_switch_enable,
.disable= db8500_regulator_switch_disable,
.is_enabled = db8500_regulator_switch_is_enabled,
--
2.17.1
Re: [PATCH] modpost: make KBUILD_MODPOST_WARN also configurable for external modules
On Tue, Apr 9, 2019 at 7:31 PM Jonas Gorski wrote:
>
> Hi,
>
> 本当に申し訳ありません, I got sidetracked and completely forgot about it. I
> actually still have my old tree with the suggested changes for v2.
>
> On Tue, 9 Apr 2019 at 11:01, Masahiro Yamada
> wrote:
> >
> > Hi.
> >
> > On Mon, Apr 8, 2019 at 5:03 PM Wiebe, Wladislav (Nokia - DE/Ulm)
> > wrote:
> > >
> > > Hi!
> > >
> > > On 07.04.2019 11:04, Masahiro Yamada wrote:
> > > > (+CC Jonas Gorski)
> > > >
> > > >
> > > > On Tue, Mar 26, 2019 at 6:58 PM Wiebe, Wladislav (Nokia - DE/Ulm)
> > > > wrote:
> > > >>
> > > >> Commit ea837f1c0503 ("kbuild: make modpost processing configurable")
> > > >> was intended to give KBUILD_MODPOST_WARN flexibility to be
> > > >> configurable.
> > > >> Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is
> > > >> set which happens per default when building modules out of the tree.
> > > >>
> > > >> This change gives the opportunity to define module build behaving also
> > > >> in case of out of tree builds and default will become exit on error.
> > > >> Errors which can be detected by the build should be trapped out of the
> > > >> box
> > > >> there, unless somebody wants to notice broken stuff later at runtime.
> > > >
> > > > If an external module refers to a symbol
> > > > provided by another external module,
> > > > this patch will turn the warning into the error by default,
> > > > which is probably a bad idea.
> > >
> > > Indeed, exactly this should happen. You should fix your external module
> > > dependencies by providing their symbols. Please use e.g.
> > > KBUILD_EXTRA_SYMBOLS instead of converting errors to warning and hoping
> > > that things will work.
> >
> > I know this option.
> > What I want to say is, this patch changes the behavior, and
> > may annoy some people.
> >
> > > Or how do you want to make sure module A still
> > > delivers all symbols needed by module B after an update/changes?
> > > Manually comparing the logs after an update or waiting until it turns
> > > out broken during run-time? I wouldn't say this is a good idea :-)
> >
> > OK, so the commit log should record both the behavior change
> > and workarounds.
> >
> > - If an external module being built refers to symbols
> > in another external module, Kbuild previously showed a warning,
> > but going forward it will turn it into an error.
> >
> > - To work around this, you should pass a symbol table via
> > KBUILD_EXTRA_SYMBOLS,
> > or KBUILD_EXTRA_SYMBOLS=1 to turn the error into a warning.
>
> This sounds like a good middle ground. When you do the effort of
> setting KBUILD_EXTRA_SYMBOLS, you are likely interested in proper
> dependency resolution and being notified if it fails.
>
> I would probably still use KBUILD_MODPOST_WARN=0 to force the warnings
> as errors, to have it as the central switch for the behaviour. So the
> behaviour would then become
>
> - If KBUILD_MODPOST_WARN is set to any value, set -w accordingly
> - else, set -w only when building for an external module and
> KBUILD_EXTRA_SYMBOLS is empty
>
> or
>
> ifdef KBUILD_MODPOST_WARN
> KBUILD_MODPOST_WARN:=$(filter-out 0,$(KBUILD_MODPOST_WARN))
> else
> KBUILD_MODPOST_WARN:=$(if $(KBUILD_EXTMOD),$(if
> $(KBUILD_EXTRA_SYMBOLS),,1))
> endif
Sorry, I think this is too complicated.
I applied this since it is simple.
https://patchwork.kernel.org/patch/10895465/
--
Best Regards
Masahiro Yamada
[PATCH v4 4/5] xtensa: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
---
arch/xtensa/include/asm/irqflags.h | 2 +-
arch/xtensa/kernel/smp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/xtensa/include/asm/irqflags.h
b/arch/xtensa/include/asm/irqflags.h
index 9b5e8526afe5..12890681587b 100644
--- a/arch/xtensa/include/asm/irqflags.h
+++ b/arch/xtensa/include/asm/irqflags.h
@@ -27,7 +27,7 @@ static inline unsigned long arch_local_irq_save(void)
{
unsigned long flags;
#if XTENSA_FAKE_NMI
-#if defined(CONFIG_DEBUG_KERNEL) && (LOCKLEVEL | TOPLEVEL) >= XCHAL_DEBUGLEVEL
+#if defined(CONFIG_DEBUG_MISC) && (LOCKLEVEL | TOPLEVEL) >= XCHAL_DEBUGLEVEL
unsigned long tmp;
asm volatile("rsr %0, ps\t\n"
diff --git a/arch/xtensa/kernel/smp.c b/arch/xtensa/kernel/smp.c
index 3699d6d3e479..83b244ce61ee 100644
--- a/arch/xtensa/kernel/smp.c
+++ b/arch/xtensa/kernel/smp.c
@@ -126,7 +126,7 @@ void secondary_start_kernel(void)
init_mmu();
-#ifdef CONFIG_DEBUG_KERNEL
+#ifdef CONFIG_DEBUG_MISC
if (boot_secondary_processors == 0) {
pr_debug("%s: boot_secondary_processors:%d; Hanging cpu:%d\n",
__func__, boot_secondary_processors, cpu);
--
2.21.0
[PATCH v4 3/5] mips: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly defined CONFIG_DEBUG_MISC instead to keep the current code. Signed-off-by: Sinan Kaya --- arch/mips/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 8d1dc6c71173..9fc8fadb8418 100644 --- a/arch/mips/kernel/setup.c +++ b/arch/mips/kernel/setup.c @@ -563,7 +563,7 @@ static void __init bootmem_init(void) offset = __pa_symbol(_text) - __pa_symbol(VMLINUX_LOAD_ADDRESS); memblock_free(__pa_symbol(VMLINUX_LOAD_ADDRESS), offset); -#if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO) +#if defined(CONFIG_DEBUG_MISC) && defined(CONFIG_DEBUG_INFO) /* * This information is necessary when debugging the kernel * But is a security vulnerability otherwise! -- 2.21.0
[PATCH v4 1/5] init: Introduce DEBUG_MISC option
Introduce DEBUG_MISC ("Miscellaneous debug code that should be under a more
specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
"default DEBUG_KERNEL" but allow itself to be turned off, and then
mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
"#ifdef CONFIG_DEBUG_MISC".
Signed-off-by: Sinan Kaya
---
lib/Kconfig.debug | 9 +
1 file changed, 9 insertions(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 0d9e81779e37..2f80ebaa6d9a 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -438,6 +438,15 @@ config DEBUG_KERNEL
Say Y here if you are developing drivers or trying to debug and
identify kernel problems.
+config DEBUG_MISC
+ bool "Miscellaneous debug code"
+ default DEBUG_KERNEL
+ depends on DEBUG_KERNEL
+ help
+ Say Y here if you need to enable Miscellaneous debug code that should
+ be under a more specific debug option but isn't.
+
+
menu "Memory Debugging"
source "mm/Kconfig.debug"
--
2.21.0
[PATCH v4 0/5] init: Do not select DEBUG_KERNEL by default
CONFIG_DEBUG_KERNEL has been designed to just enable Kconfig options.
Kernel code generatoin should not depend on CONFIG_DEBUG_KERNEL.
Proposed alternative plan: let's add a new symbol, something like
DEBUG_MISC ("Miscellaneous debug code that should be under a more
specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
"default DEBUG_KERNEL" but allow itself to be turned off, and then
mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
"#ifdef CONFIG_DEBUG_MISC".
Sinan Kaya (5):
init: Introduce DEBUG_MISC option
powerpc: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
mips: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
xtensa: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
net: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
arch/mips/kernel/setup.c | 2 +-
arch/powerpc/kernel/sysfs.c| 8
arch/xtensa/include/asm/irqflags.h | 2 +-
arch/xtensa/kernel/smp.c | 2 +-
lib/Kconfig.debug | 9 +
net/netfilter/core.c | 2 +-
6 files changed, 17 insertions(+), 8 deletions(-)
--
2.21.0
Re: [PATCH 1/3] Revert "clk: rockchip: mark noc and some special clk as critical on rk3288"
hi,
在 2019/4/12 上午6:05, Heiko Stübner 写道:
Hi,
Am Donnerstag, 11. April 2019, 17:26:41 CEST schrieb Doug Anderson:
On Wed, Apr 10, 2019 at 8:27 PM elaine.zhang wrote:
在 2019/4/10 下午11:34, Doug Anderson 写道:
On Tue, Apr 9, 2019 at 11:23 PM elaine.zhang wrote:
在 2019/4/10 上午4:47, Douglas Anderson 写道:
This reverts commit 55bb6a633c33caf68ab470907ecf945289cb733d.
The clocks that were enabled by that patch are pretty questionable.
Specifically looking at what has been shipping on rk3288-veyron
Chromebooks almost all of these clocks are safely turned off and cause
no apparent problems. If some boards need these clocks turned on for
some reason then it seems like we should figure out how to do that at
a board level.
NOTE: turning these clocks off doesn't seem to do a whole lot in terms
of power savings (checking the power on the logic rail). It appears
to save maybe 1-2mW. ...but still it seems like we should turn the
clocks off if they aren't needed.
Digging into the clocks here to describe why they shouldn't need to be
left on:
atclk: No documentation about this clock other than that it goes to
the CPU. CPU functions fine without it on.
jtag: Presumably this clock is only needed if you're debugging with
JTAG. It doesn't seem like it makes sense to waste power for every
rk3288 user. Perhaps this could be turned on with a CONFIG option?
pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two
clocks on only during kernel panics in order to access some coresight
registers. Since nothing in the upstream kernel does this we should
be able to leave them off safely.
hsicphy12m_xin12m: There is no indication of why this clock would need
to be turned on for boards that don't use HSIC.
pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn
these 4 clocks on only when doing DDR transitions and they are off
otherwise. I see no reason why they'd need to be on in the upstream
kernel which doesn't support DDRFreq.
pmu_hclk_otg0: A "chip design defect" is mentioned in the original
patch but no details. This clock has always been gated in shipping
veyron Chromebooks so presumably this chip defect doesn't affect all
boards.
Signed-off-by: Douglas Anderson
---
drivers/clk/rockchip/clk-rk3288.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 5a67b7869960..06287810474e 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -313,13 +313,13 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
COMPOSITE_NOMUX(0, "aclk_core_mp", "armclk", CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(0), 4, 4, DFLAGS |
CLK_DIVIDER_READ_ONLY,
RK3288_CLKGATE_CON(12), 6, GFLAGS),
- COMPOSITE_NOMUX(0, "atclk", "armclk", CLK_IGNORE_UNUSED,
+ COMPOSITE_NOMUX(0, "atclk", "armclk", 0,
RK3288_CLKSEL_CON(37), 4, 5, DFLAGS |
CLK_DIVIDER_READ_ONLY,
RK3288_CLKGATE_CON(12), 7, GFLAGS),
COMPOSITE_NOMUX(0, "pclk_dbg_pre", "armclk", CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(37), 9, 5, DFLAGS |
CLK_DIVIDER_READ_ONLY,
RK3288_CLKGATE_CON(12), 8, GFLAGS),
- GATE(0, "pclk_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED,
+ GATE(0, "pclk_dbg", "pclk_dbg_pre", 0,
RK3288_CLKGATE_CON(12), 9, GFLAGS),
GATE(0, "cs_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED,
RK3288_CLKGATE_CON(12), 10, GFLAGS),
@@ -647,7 +647,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
INVERTER(SCLK_HSADC, "sclk_hsadc", "sclk_hsadc_out",
RK3288_CLKSEL_CON(22), 7, IFLAGS),
- GATE(0, "jtag", "ext_jtag", CLK_IGNORE_UNUSED,
+ GATE(0, "jtag", "ext_jtag", 0,
RK3288_CLKGATE_CON(4), 14, GFLAGS),
CLK_IGNORE_UNUSED:
Whether to close the unused clk after clk init complete. not affect
there own enable/disable.
JTAG is not have device node, when need jtag to debug, may be the system
is crashed, there is no way to turn on this clk.
As I mentioned in the commit message this seems like the kind of thing
that should be controlled by a CONFIG_ option. It's a debug option
that's fine to have on all the time but consumes resources so some
people might want to turn it off.
Currently, CONFIG_ option is not implemented. We will refer to this suggestion.
For debug, I don't hope to remove the flag CLK_IGNORE_UNUSED.(The clk static
power is very small)
I'll leave it up to Heiko for what to do here. I agree that it's not
tons of power (this whole patch saved 1-2 mW on the INT rail) but I'd
still prefer for clocks to be off if they can. In general one could
also argue that keeping JTAG off by default could be good for
security.
...but I guess I have to wonder how you're doing JTAG on upstream
kernels without any extra
Re: [PATCH v2 1/3] security: Create "kernel hardening" config area
On Fri, Apr 12, 2019 at 3:01 AM Kees Cook wrote:
>
> Right now kernel hardening options are scattered around various Kconfig
> files. This can be a central place to collect these kinds of options
> going forward. This is initially populated with the memory initialization
> options from the gcc-plugins.
>
> Signed-off-by: Kees Cook
> ---
> scripts/gcc-plugins/Kconfig | 74 +++--
> security/Kconfig| 2 +
> security/Kconfig.hardening | 93 +
> 3 files changed, 102 insertions(+), 67 deletions(-)
> create mode 100644 security/Kconfig.hardening
>
> diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig
> index 74271dba4f94..84d471dea2b7 100644
> --- a/scripts/gcc-plugins/Kconfig
> +++ b/scripts/gcc-plugins/Kconfig
> @@ -13,10 +13,11 @@ config HAVE_GCC_PLUGINS
> An arch should select this symbol if it supports building with
> GCC plugins.
>
> -menuconfig GCC_PLUGINS
> - bool "GCC plugins"
> +config GCC_PLUGINS
> + bool
> depends on HAVE_GCC_PLUGINS
> depends on PLUGIN_HOSTCC != ""
> + default y
> help
> GCC plugins are loadable modules that provide extra features to the
> compiler. They are useful for runtime instrumentation and static
> analysis.
> @@ -25,6 +26,8 @@ menuconfig GCC_PLUGINS
>
> if GCC_PLUGINS
>
> +menu "GCC plugins"
> +
Just a tip to save "if" ... "endif" block.
If you like, you can write like follows:
menu "GCC plugins"
depends on GCC_PLUGINS
endmenu
instead of
if GCC_PLUGINS
menu "GCC plugins"
endmenu
fi
> +menu "Memory initialization"
> +
> +choice
> + prompt "Initialize kernel stack variables at function entry"
> + depends on GCC_PLUGINS
On second thought,
this 'depends on' is unnecessary
because INIT_STACK_NONE should be always visible.
> + default INIT_STACK_NONE
> + help
> + This option enables initialization of stack variables at
> + function entry time. This has the possibility to have the
> + greatest coverage (since all functions can have their
> + variables initialized), but the performance impact depends
> + on the function calling complexity of a given workload's
> + syscalls.
> +
> + This chooses the level of coverage over classes of potentially
> + uninitialized variables. The selected class will be
> + initialized before use in a function.
> +
> + config INIT_STACK_NONE
> + bool "no automatic initialization (weakest)"
> + help
> + Disable automatic stack variable initialization.
> + This leaves the kernel vulnerable to the standard
> + classes of uninitialized stack variable exploits
> + and information exposures.
> +
> + config GCC_PLUGIN_STRUCTLEAK_USER
> + bool "zero-init structs marked for userspace (weak)"
> + depends on GCC_PLUGINS
> + select GCC_PLUGIN_STRUCTLEAK
> + help
> + Zero-initialize any structures on the stack containing
> + a __user attribute. This can prevent some classes of
> + uninitialized stack variable exploits and information
> + exposures, like CVE-2013-2141:
> + https://git.kernel.org/linus/b9e146d8eb3b9eca
> +
> + config GCC_PLUGIN_STRUCTLEAK_BYREF
> + bool "zero-init structs passed by reference (strong)"
> + depends on GCC_PLUGINS
> + select GCC_PLUGIN_STRUCTLEAK
> + help
> + Zero-initialize any structures on the stack that may
> + be passed by reference and had not already been
> + explicitly initialized. This can prevent most classes
> + of uninitialized stack variable exploits and information
> + exposures, like CVE-2017-1000410:
> + https://git.kernel.org/linus/06e7e776ca4d3654
> +
> + config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
> + bool "zero-init anything passed by reference (very strong)"
> + depends on GCC_PLUGINS
> + select GCC_PLUGIN_STRUCTLEAK
> + help
> + Zero-initialize any stack variables that may be passed
> + by reference and had not already been explicitly
> + initialized. This is intended to eliminate all classes
> + of uninitialized stack variable exploits and information
> + exposures.
> +
> +endchoice
Another behavior change is
GCC_PLUGIN_STRUCTLEAK was previously enabled by all{yes,mod}config,
and in the compile-test coverage.
It will be disabled for all{yes,mod}config with this patch.
This is up to you. Just FYI.
--
Best Regards
Masahiro Yamada
Re: [PATCH v3] platform/chrome: cros_ec_spi: Transfer messages at high priority
On Wed, Apr 3, 2019 at 1:32 PM Douglas Anderson wrote:
> +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *ec_msg,
> +cros_ec_xfer_fn_t fn)
> +{
> + struct cros_ec_xfer_work_params params;
> +
> + INIT_WORK(, cros_ec_xfer_high_pri_work);
Sorry for the late review, but this should have been
INIT_WORK_ONSTACK(). Should it be a new patch, or is this in a
non-rebasing tree yet?
Otherwise, looks fine to me:
Reviewed-by: Brian Norris
Re: [PATCH] arm64: vdso: use $(LD) instead of $(CC) to link VDSO
Hi Nick, On Fri, Apr 12, 2019 at 3:20 AM Nick Desaulniers wrote: > > On Thu, Apr 11, 2019 at 2:30 AM Masahiro Yamada > wrote: > > > > We use $(LD) to link vmlinux, modules, decompressors, etc. > > > > VDSO is the only exceptional case where $(CC) is used as the linker > > driver, but I do not know why we need to do so. VDSO uses a special > > linker script, and does not link standard libraries at all. > > > > I changed the Makefile to use $(LD) rather than $(CC). I tested this, > > and VDSO worked for me. > > > > Users will be able to use their favorite linker (e.g. lld instead of > > of bfd) by passing LD= from the command line. > > > > My plan is to rewrite all VDSO Makefiles to use $(LD), then delete > > cc-ldoption. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > arch/arm64/kernel/vdso/Makefile | 13 +++-- > > 1 file changed, 3 insertions(+), 10 deletions(-) > > > > diff --git a/arch/arm64/kernel/vdso/Makefile > > b/arch/arm64/kernel/vdso/Makefile > > index a0af6bf6c11b..744b9dbaba03 100644 > > --- a/arch/arm64/kernel/vdso/Makefile > > +++ b/arch/arm64/kernel/vdso/Makefile > > @@ -12,17 +12,12 @@ obj-vdso := gettimeofday.o note.o sigreturn.o > > targets := $(obj-vdso) vdso.so vdso.so.dbg > > obj-vdso := $(addprefix $(obj)/, $(obj-vdso)) > > > > -ccflags-y := -shared -fno-common -fno-builtin > > Thanks for the patch; in general LGTM. Just some small questions: > > Looks like -shared and -fno-common are linker flags forwarded along, > but -fno-builtin is meant for the compiler, right? Definitely, -shared must be passed to the linker to create a shared object. It is listed in the linker option list: https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Link-Options.html#Link-Options I think -fno-common is a compiler flag instead of a linker one as far as I understand this: https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Code-Gen-Options.html#Code-Gen-Options -fno-builtin is a compiler flag: https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/C-Dialect-Options.html#C-Dialect-Options > Do we want to keep > that in ccflags? All source files in arch/arm64/kernel/vdso/ are written in assembly (gettimeofday.S note.S sigreturn.S). So, -fno-common -fno-builtin for ccflags-y are not used. That's why I dropped them. If we want to keep them just in case, it is fine with me too. > I'm not sure why it would have been added > intentionally; maybe Will knows? Maybe it's ok to drop. They have been here since the initial VDSO support by commit 9031fefde6f2a. Will, do you remember why you added these flags? > > -ccflags-y += -nostdlib -Wl,-soname=linux-vdso.so.1 \ > > - $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) > > +ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 \ > > + $(call ld-option, --hash-style=sysv) -n -T > > Forgive my ignorance, but the man page for ld makes it looks like the > -T argument requires a subsequent argument `scriptfile`. Is that what > `$(real-prereqs)` was doing below? If so, is dropping it in this patch > intentional? I just re-used cmd_ld in scripts/Makefile.lib It will be expanded like follows: cmd_ld = $(LD) $(ld_flags) $(real-prereqs) -o $@ -> $(LD) $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F)) $(real-prereqs) -o $@ -> $(LD) -shared -nostdlib -soname=linux-vdso.so.1 \ --hash-style=sysv -n -T \ $(obj)/vdso.lds $(obj-vdso) -o $(obj)/vdso.so.dbg -- Best Regards Masahiro Yamada
[PATCH] selftests: livepatch use TEST_PROGS for test shell scripts
TEST_PROGS variable is for test shell scripts and common clean target in lib.mk doesn't touch them. TEST_GEN_PROGS are removed by it. Fix it to use TEST_PROGS for test shell scripts and TEST_PROGS_EXTENDED for common functions.sh. Signed-off-by: Shuah Khan --- tools/testing/selftests/livepatch/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/livepatch/Makefile b/tools/testing/selftests/livepatch/Makefile index af4aee79bebb..fd405402c3ff 100644 --- a/tools/testing/selftests/livepatch/Makefile +++ b/tools/testing/selftests/livepatch/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 -TEST_GEN_PROGS := \ +TEST_PROGS_EXTENDED := functions.sh +TEST_PROGS := \ test-livepatch.sh \ test-callbacks.sh \ test-shadow-vars.sh -- 2.17.1
RE: [EXT] Re: [PATCH V7 2/4] firmware: imx: enable imx scu general irq function
Hello, Alexandre As i.MX SCU general irq function is picked up by Shawn, could you please also pick up below i.MX SC RTC alarm support patch ? https://patchwork.kernel.org/patch/10890525/ Best Regards! Anson Huang > -Original Message- > From: Shawn Guo [mailto:shawn...@kernel.org] > Sent: 2019年4月11日 15:33 > To: Anson Huang > Cc: robh...@kernel.org; mark.rutl...@arm.com; s.ha...@pengutronix.de; > ker...@pengutronix.de; feste...@gmail.com; a.zu...@towertech.it; > alexandre.bell...@bootlin.com; Aisheng Dong ; > ulf.hans...@linaro.org; sb...@kernel.org; Peng Fan ; > Daniel Baluta ; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > r...@vger.kernel.org; dl-linux-imx > Subject: [EXT] Re: [PATCH V7 2/4] firmware: imx: enable imx scu general irq > function > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > On Tue, Apr 09, 2019 at 04:59:55AM +, Anson Huang wrote: > > The System Controller Firmware (SCFW) controls RTC, thermal and WDOG > > etc., these resources' interrupt function are managed by SCU. When any > > IRQ pending, SCU will notify Linux via MU general interrupt channel > > #3, and Linux kernel needs to call SCU APIs to get IRQ status and > > notify each module to handle the interrupt. > > > > Since there is no data transmission for SCU IRQ notification, so > > doorbell mode is used for this MU channel, and SCU driver will use > > notifier mechanism to broadcast to every module which registers the > > SCU block notifier. > > > > Signed-off-by: Anson Huang > > Reviewed-by: Dong Aisheng > > Applied, thanks.
Re: [RFC PATCH v3 3/4] x86: Use HYPERVISOR_CALLBACK_VECTOR for acrn_guest upcall vector
On 2019年04月11日 21:55, Borislav Petkov wrote: On Wed, Apr 10, 2019 at 03:57:08PM +0800, Zhao, Yakui wrote: It is used to avoid that one function declaration has no definition when asm/acrnhyper.h is included and ACRN_GUEST is not enabled. And that is a problem because...? This is not a problem. I take a look at the header file of mshyperv.h and xen/events.h. It seems that they have no such extra conditional definition. To follow the same style, I will remove it. Do you have any suggestion about the header order? linux/ path includes still need to come first, of course. As said above: linux/ path first, then asm/ Feel free to look around the tree for inspiration :) I take a look at the file of vwmare.c/mshyperv.c under the directory of arch/x86/kernel/cpu. It seems that the header file only follows the order of: linux/ path first and then asm/. Anyway, I will follow your idea in previous email and use the alphabetic order. Thanks
Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
On 2019/4/11 9:02, Li, Aubrey wrote:
> On 2019/4/10 22:54, Andy Lutomirski wrote:
>> On Tue, Apr 9, 2019 at 8:40 PM Li, Aubrey wrote:
>>>
>>> On 2019/4/10 10:36, Li, Aubrey wrote:
On 2019/4/10 10:25, Andy Lutomirski wrote:
> On Tue, Apr 9, 2019 at 7:20 PM Li, Aubrey
> wrote:
>>
>> On 2019/4/10 9:58, Andy Lutomirski wrote:
>>> On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li
>>> wrote:
The architecture specific information of the running processes could
be useful to the userland. Add support to examine process architecture
specific information externally.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
Cc: Linux API
Cc: Alexey Dobriyan
Cc: Andrew Morton
---
fs/proc/array.c | 5 +
include/linux/proc_fs.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 2edbb657f859..331592a61718 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -401,6 +401,10 @@ static inline void task_thp_status(struct
seq_file *m, struct mm_struct *mm)
seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
}
+void __weak arch_proc_pid_status(struct seq_file *m, struct
task_struct *task)
+{
+}
>>>
>>> This pointlessly bloats other architectures. Do this instead in an
>>> appropriate header:
>>>
>>> #ifndef arch_proc_pid_status
>>> static inline void arch_proc_pid_status(...)
>>> {
>>> }
>>> #endif
>>>
>>
>> I saw a bunch of similar weak functions, is it not acceptable?
>>
>> fs/proc$ grep weak *.c
>> cpuinfo.c:__weak void arch_freq_prepare_all(void)
>> meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file
>> *m)
>> vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned
>> long long *size)
>> vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
>> vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64
>> *ppos)
>> vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count,
>> u64 *ppos)
>> vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
>> vmcore.c:ssize_t __weak
>
> I think they're acceptable, but I don't personally like them.
>
okay, let me try to see if I can refine it in an appropriate way.
>>>
>>> Hi Andy,
>>>
>>> Is this what you want?
>>>
>>> Thanks,
>>> -Aubrey
>>>
>>>
>>> diff --git a/arch/x86/include/asm/processor.h
>>> b/arch/x86/include/asm/processor.h
>>> index 2bb3a648fc12..82d77d3aefff 100644
>>> --- a/arch/x86/include/asm/processor.h
>>> +++ b/arch/x86/include/asm/processor.h
>>> @@ -990,5 +990,8 @@ enum l1tf_mitigations {
>>> };
>>>
>>> extern enum l1tf_mitigations l1tf_mitigation;
>>> +/* Add support for architecture specific output in /proc/pid/status */
>>> +void arch_proc_pid_status(struct seq_file *m, struct task_struct *task);
>>> +#define arch_proc_pid_status arch_proc_pid_status
>>>
>>> #endif /* _ASM_X86_PROCESSOR_H */
>>> diff --git a/fs/proc/array.c b/fs/proc/array.c
>>> index 2edbb657f859..fd65a6ba2864 100644
>>> --- a/fs/proc/array.c
>>> +++ b/fs/proc/array.c
>>> @@ -401,6 +401,11 @@ static inline void task_thp_status(struct seq_file *m,
>>> struct mm_struct *mm)
>>> seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
>>> }
>>>
>>> +/* Add support for architecture specific output in /proc/pid/status */
>>> +#ifndef arch_proc_pid_status
>>> +#define arch_proc_pid_status(m, task)
>>> +#endif
>>> +
>>> int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
>>> struct pid *pid, struct task_struct *task)
>>> {
>>> @@ -424,6 +429,7 @@ int proc_pid_status(struct seq_file *m, struct
>>> pid_namespace *ns,
>>> task_cpus_allowed(m, task);
>>> cpuset_task_status_allowed(m, task);
>>> task_context_switch_counts(m, task);
>>> + arch_proc_pid_status(m, task);
>>> return 0;
>>> }
>>>
>>
>> Yes. But I still think it would be nicer to separate the arch stuff
>> into its own file. Others might reasonably disagree with me.
>>
> I like arch_status, I proposed but no other arch shows interesting in it.
>
> I think the problem is similar for x86_status, it does not make sense for
> those x86 platform without AVX512 to have an empty arch file. I personally
> don't like [arch]_status because the code may become unclean if more arches
> added in future.
>
> Maybe it's too early to have a separated arch staff file for now.
Hi Andy,
Is it acceptable to you if I make the above change and post v15?
Thanks,
-Aubrey
Re: [PATCH v2] extcon: axp288: Add a depends on ACPI to the Kconfig entry
Dear all,
+ sta...@vger.kernel.org
It should be posted to sta...@vger.kernel.org
in order to merge it to stable tree.
Regards,
Chanwoo Choi
On 19. 4. 12. 오전 8:30, Chanwoo Choi wrote:
> On 19. 4. 4. 오후 11:17, Yue Haibing wrote:
>> From: YueHaibing
>>
>> As Hans de Goede pointed, using this driver without ACPI
>> makes little sense, so add ACPI dependency to Kconfig entry
>> to fix a build error while CONFIG_ACPI is not set.
>>
>> drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe':
>> drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to
>> incomplete type
>> put_device(>dev);
>>
>> Fixes: 0cf064db948a ("extcon: axp288: Convert to use
>> acpi_dev_get_first_match_dev()")
>> Reported-by: Hulk Robot
>> Suggested-by: Hans de Goede
>> Signed-off-by: YueHaibing
>> ---
>> v2: rework patch
>> ---
>> drivers/extcon/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>> index 1ed4b45..de06faf 100644
>> --- a/drivers/extcon/Kconfig
>> +++ b/drivers/extcon/Kconfig
>> @@ -30,7 +30,7 @@ config EXTCON_ARIZONA
>>
>> config EXTCON_AXP288
>> tristate "X-Power AXP288 EXTCON support"
>> -depends on MFD_AXP20X && USB_SUPPORT && X86
>> +depends on MFD_AXP20X && USB_SUPPORT && X86 && ACPI
>> select USB_ROLE_SWITCH
>> help
>>Say Y here to enable support for USB peripheral detection
>>
>
> Applied it. Thanks.
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
perf tools:Is there any tools to found out the max latency by irq or cpu idle
Hi,
I have a single thread application like this:
While (1) {
start = rdtsc();
sqrt (1024);
end = rdtsc();
cycles = end – start;
printf("cycles: %d-%02d-%02d %02d:%02d:%02d: %lu\n",
1900+timeinfo->tm_year, 1+timeinfo->tm_mon, timeinfo->tm_mday,
timeinfo->tm_hour, timeinfo->tm_min, timeinfo->tm_sec,
cycles);
}
It print the cycles of sqrt every second and run with taskset –c 1 ./sqrt.
The result of test is:
sqrt 2019-04-10 23:53:50: 43968
sqrt 2019-04-10 23:53:51: 44060
sqrt 2019-04-10 23:53:52: 49012
sqrt 2019-04-10 23:53:53: 38172
sqrt 2019-04-10 23:53:54: 131081408
sqrt 2019-04-10 23:53:55: 43600
sqrt 2019-04-10 23:53:56: 46704
sqrt 2019-04-10 23:53:57: 46880
sqrt 2019-04-10 23:53:58: 44332
……
sqrt 2019-04-10 02:17:15: 131081408
……
sqrt 2019-04-10 04:40:35: 131081408
……
Every 2hour23min there would be a large cycles. I use perf sched not found any
sched_switch events.
L2GW_2680:/home/fsp/zn # perf sched record -C 6-11 -o perf.sched
^C[ perf record: Woken up 64 times to write data ]
[ perf record: Captured and wrote 204.878 MB perf.sched (1911189 samples) ]
L2GW_2680:/home/fsp/zn # perf sched latency -i perf.sched
-
Task | Runtime ms | Switches | Average delay ms | Maximum
delay ms | Maximum delay at |
-
-
TOTAL: | 0.000 ms | 0 |
---
Is there any other tools of perf to found out the max latency by irq or cpu
idle ?
Re: [RFC PATCH v3 2/4] x86: Add the support of ACRN guest
On 2019年04月11日 21:49, Borislav Petkov wrote: On Wed, Apr 10, 2019 at 05:15:48PM +0800, Zhao, Yakui wrote: Currently the x2apic is not enabled in the first step. Next step it needs to check the cpu info reported by ACRN hypervisor to determine whether the x2apic should be supported. What "cpu info"? CPUID or something ACRN-specific? It is based on CPUID. The low-level ACRN hypervisor can return the different output of CPUID when several linux guests executes the CPUID instruction. Then it can control whether x2apic is supported in one linux guest. So we will leverage the X86_FEATURE_X2APIC bit from CPUID to indicate whether the x2apic is supported in linux guest when ACRN hypervisor is detected. Is this fine to you? Thanks
Re: [PATCH] extcon: arizona: Disable mic detect if running when driver is removed
Hi Charles,
On 19. 4. 5. 오전 1:33, Charles Keepax wrote:
> Microphone detection provides the button detection features on the
> Arizona CODECs as such it will be running if the jack is currently
> inserted. If the driver is unbound whilst the jack is still inserted
> this will cause warnings from the regulator framework as the MICVDD
> regulator is put but was never disabled.
>
> Correct this by disabling microphone detection on driver removal and if
> the microphone detection was running disable the regulator and put the
> runtime reference that was currently held.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index da0e9bc4262fa..9327479c719c2 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1726,6 +1726,16 @@ static int arizona_extcon_remove(struct
> platform_device *pdev)
> struct arizona_extcon_info *info = platform_get_drvdata(pdev);
> struct arizona *arizona = info->arizona;
> int jack_irq_rise, jack_irq_fall;
> + bool change;
> +
> + regmap_update_bits_check(arizona->regmap, ARIZONA_MIC_DETECT_1,
> + ARIZONA_MICD_ENA, 0,
> + );
> +
> + if (change) {
> + regulator_disable(info->micvdd);
> + pm_runtime_put(info->dev);
> + }>
> gpiod_put(info->micd_pol_gpio);
>
>
Applied it.
IMO, I think that this driver have to handle the exception handling
when regmap_update_bits_check() returns error or 'change' value
is not changed. This driver have same issue about exception handling
on multiple places. Please take it on separate patche.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] xfs: use struct_size() helper
[fixing linux-xfs cc]
On Thu, Apr 11, 2019 at 06:37:58PM -0500, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
>
> So, replace code of the following form:
>
> sizeof(*alist) + context->count * sizeof(alist->al_offset[0]
>
> with:
>
> struct_size(alist, al_offset, context->count)
>
> and remove unnecessary variable arraytop.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Has this been run through xfstests?
--D
> fs/xfs/xfs_attr_list.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c
> index 3d213a7394c5..05e03348553e 100644
> --- a/fs/xfs/xfs_attr_list.c
> +++ b/fs/xfs/xfs_attr_list.c
> @@ -553,7 +553,6 @@ xfs_attr_put_listent(
> {
> struct attrlist *alist = (struct attrlist *)context->alist;
> attrlist_ent_t *aep;
> - int arraytop;
>
> ASSERT(!context->seen_enough);
> ASSERT(!(context->flags & ATTR_KERNOVAL));
> @@ -572,10 +571,8 @@ xfs_attr_put_listent(
> ((flags & XFS_ATTR_ROOT) == 0))
> return;
>
> - arraytop = sizeof(*alist) +
> - context->count * sizeof(alist->al_offset[0]);
> context->firstu -= ATTR_ENTSIZE(namelen);
> - if (context->firstu < arraytop) {
> + if (context->firstu < struct_size(alist, al_offset, context->count)) {
> trace_xfs_attr_list_full(context);
> alist->al_more = 1;
> context->seen_enough = 1;
> --
> 2.21.0
>
[PATCH v3 2/2] power_supply: platform/chrome: wilco_ec: Add charging config driver
Add control of the charging algorithm used on Wilco devices. See Documentation/ABI/testing/sysfs-class-power-wilco for the userspace interface and other info. v3 changes: -Add this changelog -Fix commit message tags v2 changes: -Update Documentation to say KernelVersion 5.2 -Update Documentation to explain Trickle mode better. -rename things from using *PCC* to *CHARGE* -Split up conversions between POWER_SUPPLY_PROP_CHARGE_TYPE values and Wilco EC codes -Use devm_ flavor of power_supply_register(), which simplifies things -Add extra error checking on property messages received from the EC -Fix bug in memcpy() calls in properties.c -Refactor fill_property_id() -Add valid input checks to charge_type -Properly convert charge_type when get()ting Signed-off-by: Nick Crews --- .../ABI/testing/sysfs-class-power-wilco | 30 +++ drivers/platform/chrome/wilco_ec/Kconfig | 9 + drivers/platform/chrome/wilco_ec/Makefile | 2 + .../platform/chrome/wilco_ec/charge_config.c | 190 ++ drivers/platform/chrome/wilco_ec/core.c | 14 ++ drivers/platform/chrome/wilco_ec/properties.c | 134 drivers/platform/chrome/wilco_ec/properties.h | 68 +++ include/linux/platform_data/wilco-ec.h| 2 + 8 files changed, 449 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-power-wilco create mode 100644 drivers/platform/chrome/wilco_ec/charge_config.c create mode 100644 drivers/platform/chrome/wilco_ec/properties.c create mode 100644 drivers/platform/chrome/wilco_ec/properties.h diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco b/Documentation/ABI/testing/sysfs-class-power-wilco new file mode 100644 index ..7f3b01310476 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-power-wilco @@ -0,0 +1,30 @@ +What: /sys/class/power_supply/wilco_charger/charge_type +Date: April 2019 +KernelVersion: 5.2 +Description: + What charging algorithm to use: + + Standard: Fully charges battery at a standard rate. + Adaptive: Battery settings adaptively optimized based on + typical battery usage pattern. + Fast: Battery charges over a shorter period. + Trickle: Extends battery lifespan, intended for users who + primarily use their Chromebook while connected to AC. + Custom: A low and high threshold percentage is specified. + Charging begins when level drops below + charge_control_start_threshold, and ceases when + level is above charge_control_end_threshold. + +What: /sys/class/power_supply/wilco_charger/charge_control_start_threshold +Date: April 2019 +KernelVersion: 5.2 +Description: + Used when charge_type="Custom", as described above. Measured in + percentages. The valid range is [50, 95]. + +What: /sys/class/power_supply/wilco_charger/charge_control_end_threshold +Date: April 2019 +KernelVersion: 5.2 +Description: + Used when charge_type="Custom", as described above. Measured in + percentages. The valid range is [55, 100]. diff --git a/drivers/platform/chrome/wilco_ec/Kconfig b/drivers/platform/chrome/wilco_ec/Kconfig index e09e4cebe9b4..1c427830bd57 100644 --- a/drivers/platform/chrome/wilco_ec/Kconfig +++ b/drivers/platform/chrome/wilco_ec/Kconfig @@ -18,3 +18,12 @@ config WILCO_EC_DEBUGFS manipulation and allow for testing arbitrary commands. This interface is intended for debug only and will not be present on production devices. + +config WILCO_EC_CHARGE_CNTL + tristate "Enable charging control" + depends on WILCO_EC + help + If you say Y here, you get support to control the charging + routines performed by the Wilco Embedded Controller. + Further information can be found in + Documentation/ABI/testing/sysfs-class-power-wilco) diff --git a/drivers/platform/chrome/wilco_ec/Makefile b/drivers/platform/chrome/wilco_ec/Makefile index 063e7fb4ea17..7e980f56f793 100644 --- a/drivers/platform/chrome/wilco_ec/Makefile +++ b/drivers/platform/chrome/wilco_ec/Makefile @@ -4,3 +4,5 @@ wilco_ec-objs := core.o mailbox.o obj-$(CONFIG_WILCO_EC) += wilco_ec.o wilco_ec_debugfs-objs := debugfs.o obj-$(CONFIG_WILCO_EC_DEBUGFS) += wilco_ec_debugfs.o +wilco_ec_charging-objs := charge_config.o properties.o +obj-$(CONFIG_WILCO_EC_CHARGE_CNTL) += wilco_ec_charging.o diff --git a/drivers/platform/chrome/wilco_ec/charge_config.c b/drivers/platform/chrome/wilco_ec/charge_config.c new file mode 100644 index ..7c41b847396d --- /dev/null +++ b/drivers/platform/chrome/wilco_ec/charge_config.c @@ -0,0 +1,190 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Charging
[PATCH v3 1/2] power_supply: Add more charge types and CHARGE_CONTROL_* properties
Add "Standard", "Adaptive", and "Custom" modes to the charge_type
property, to expand the existing "Trickle" and "Fast" modes.
In addition, add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD
and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand
the existing CHARGE_CONTROL_* properties. I am adding them in order
to support a new Chrome OS device, but these properties should be
general enough that they can be used on other devices.
The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are
more tricky: "Adaptive" means that the charge controller uses some
custom algorithm to change the charge type automatically, with no
configuration needed. "Custom" means that the charge controller uses the
POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
other algorithm. For example, in the use case that I am supporting,
this means the battery begins charging when the percentage
level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
charging ceases when the percentage level goes above
POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD.
Signed-off-by: Nick Crews
---
drivers/power/supply/power_supply_sysfs.c | 4 +++-
include/linux/power_supply.h | 10 --
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index dce24f596160..6104a3f03d46 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -56,7 +56,7 @@ static const char * const power_supply_status_text[] = {
};
static const char * const power_supply_charge_type_text[] = {
- "Unknown", "N/A", "Trickle", "Fast"
+ "Unknown", "N/A", "Trickle", "Fast", "Standard", "Adaptive", "Custom"
};
static const char * const power_supply_health_text[] = {
@@ -274,6 +274,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+ POWER_SUPPLY_ATTR(charge_control_start_threshold),
+ POWER_SUPPLY_ATTR(charge_control_end_threshold),
POWER_SUPPLY_ATTR(input_current_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 2f9c201a54d1..d59205170232 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -40,11 +40,15 @@ enum {
POWER_SUPPLY_STATUS_FULL,
};
+/* What algorithm is the charger using? */
enum {
POWER_SUPPLY_CHARGE_TYPE_UNKNOWN = 0,
POWER_SUPPLY_CHARGE_TYPE_NONE,
- POWER_SUPPLY_CHARGE_TYPE_TRICKLE,
- POWER_SUPPLY_CHARGE_TYPE_FAST,
+ POWER_SUPPLY_CHARGE_TYPE_TRICKLE, /* slow speed */
+ POWER_SUPPLY_CHARGE_TYPE_FAST, /* fast speed */
+ POWER_SUPPLY_CHARGE_TYPE_STANDARD, /* normal speed */
+ POWER_SUPPLY_CHARGE_TYPE_ADAPTIVE, /* dynamically adjusted speed */
+ POWER_SUPPLY_CHARGE_TYPE_CUSTOM,/* use CHARGE_CONTROL_* props */
};
enum {
@@ -121,6 +125,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+ POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in percents! */
+ POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents! */
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
--
2.20.1
Re: [PATCH] clk: rockchip: rk3288: Limit use of USB PHY clock to USB
Hi Heiko,
On Thu, Apr 11, 2019 at 09:03:07PM +0200, Heiko Stübner wrote:
> Hi Matthias,
>
> Am Donnerstag, 11. April 2019, 19:59:17 CEST schrieb Matthias Kaehlcke:
> > The USB PHY clock can be configured as (grand) parent of uart0_sclk and
> > sclk_gpu. It has been observed that UART0 doesn't work reliably in high
> > speed mode with the PHY clock as input when certain USB devices are
> > plugged to the USB HOST1 port (see https://crrev.com/c/320543).
> >
> > Prefix the name of the PHY clock with a '.' in the non-USB muxes to
> > effectively remove the clock as input from these muxes.
> >
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > drivers/clk/rockchip/clk-rk3288.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/clk/rockchip/clk-rk3288.c
> > b/drivers/clk/rockchip/clk-rk3288.c
> > index 5a67b7869960..677bc5485201 100644
> > --- a/drivers/clk/rockchip/clk-rk3288.c
> > +++ b/drivers/clk/rockchip/clk-rk3288.c
> > @@ -200,8 +200,8 @@ PNAME(mux_aclk_cpu_src_p) = { "cpll_aclk_cpu",
> > "gpll_aclk_cpu" };
> > PNAME(mux_pll_src_cpll_gpll_p) = { "cpll", "gpll" };
> > PNAME(mux_pll_src_npll_cpll_gpll_p)= { "npll", "cpll", "gpll" };
> > PNAME(mux_pll_src_cpll_gpll_npll_p)= { "cpll", "gpll", "npll" };
> > -PNAME(mux_pll_src_cpll_gpll_usb480m_p) = { "cpll", "gpll",
> > "usbphy480m_src" };
> > -PNAME(mux_pll_src_cpll_gll_usb_npll_p) = { "cpll", "gpll",
> > "usbphy480m_src", "npll" };
> > +PNAME(mux_pll_src_cpll_gpll_usb480m_p) = { "cpll", "gpll",
> > ".usbphy480m_src" };
> > +PNAME(mux_pll_src_cpll_gll_usb_npll_p) = { "cpll", "gpll",
> > ".usbphy480m_src", "npll" };
>
> In general I like to have things like the clock-tree described fully
> and let the kernel handle correct sourcing ... but:
>
> As you write this seems like a systemic problem when just connecting
> random peripherals can create unstable clock source frequencies,
> so I tend to agree here ... but:
>
> Can we please find a more "talking" name for this ... because as with the
> above someone will find the "." and submit a fix for it ;-) .
>
> So just name it "unstable_dummy" or so?
I looked for some common pattern, but couldn't find one. I liked the
'.' since it leaves the name of the clock mostly intact, just hiding
it (similar to a leading '.' in a Linux file system). But I agree that
it might not be expressive enough. I still like the idea to keep the
clock name around for reference, maybe we could name it
"unstable:usbphy480m_src" or similar. If you don't object I'll send a
patch with this some time tomorrow.
Thanks
Matthias
[PATCH] selftests/harness: Add 30 second timeout per test
In order to keep tests from hanging forever, this adds an alarm signal
to each test run. This assumes an individual test doesn't take longer
than 30 seconds.
Signed-off-by: Kees Cook
---
tools/testing/selftests/kselftest_harness.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/kselftest_harness.h
b/tools/testing/selftests/kselftest_harness.h
index 2d90c98eeb67..941d9391377f 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -696,6 +696,7 @@ void __run_test(struct __test_metadata *t)
t->passed = 1;
t->trigger = 0;
printf("[ RUN ] %s\n", t->name);
+ alarm(30);
child_pid = fork();
if (child_pid < 0) {
printf("ERROR SPAWNING TEST CHILD\n");
@@ -744,6 +745,7 @@ void __run_test(struct __test_metadata *t)
}
}
printf("[ %4s ] %s\n", (t->passed ? "OK" : "FAIL"), t->name);
+ alarm(0);
}
static int test_harness_run(int __attribute__((unused)) argc,
--
2.17.1
--
Kees Cook
Re: [PATCH 1/6] arch: riscv: add support for building DTB files from DT source data
On Thu, 11 Apr 2019, Atish Patra wrote: > On 4/11/19 2:12 PM, Paul Walmsley wrote: > > On Thu, 11 Apr 2019, Christoph Hellwig wrote: > > > > > On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote: > > > > Similar to ARM64, add support for building DTB files from DT source > > > > data for RISC-V boards. > > > > > > > > This patch starts with the infrastructure needed for SiFive boards. > > > > Boards from other vendors would add support here in a similar form. > > > > > > What do we build it for? We'd really need something like this: > > > > > > http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e > > > http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1 > > > > > > To actually use the DT files. > > > > Those patches might be useful - I have not reviewed them closely - but > > they are not necessary. > > > > The FSBL already supplies a DTB to Linux. I assume the U-boot port works > > the same way. > > > > I am bit confused here. I thought the idea behind putting the the DTS in > kernel so that Kernel don't need to depend on DT passed from boot loaders. Some users will want to do that - mostly embedded device integrators and kernel developers. We should definitely support these use-cases. So the basic idea behind Christoph's patch to do that is good (I have not yet reviewed the code nor tested it). In fact, there has been an unofficial patch to do something similar for ARM for about a decade now. But for various reasons, some technical, some managerial - it was never merged. To be clear, I do agree that we should merge something like that for RISC-V. However: the vast majority of users -- even embedded users -- will not use a kernel with a bundled DTB. This is because it irrevocably ties that kernel binary to one specific board type. I hope it is obvious why this would be a non-starter for Linux distributions, and, more generally, anyone who wants their kernels to be usable on multiple boards. Those distributors would need to ship one kernel binary per board, or bloat their kernels with DTBs and come up with some new mechanism to select one. > Currently, DTB passed from FSBL is modified by OpenSBI/BBL before passing to > U-Boot or Linux. This should be avoided whenever possible. I'd be interested in hearing what OpenSBI is doing now to the DTB; perhaps there is a case where it makes sense. But in general, doing this makes development and maintenance quite difficult. Considre that different operating systems that may use the same SBI layer may use different DT data formats, or may not even use DT at all. And when the DT data format changes - as is happening now - a maintenance hassle is created, since then versions across multiple pieces of software may need to be synchronized. It is also very disconcerting as a kernel developer to have multiple pieces of software modifying one's DTB. The DT data is meant to represent hardware fact. DT is also used to pass in some non-hardware-related runtime configuration parameters, via the "chosen" node. But that's about it. So from that point of view, only the first-stage bootloader should be altering the DT data, and only then in very minimal ways. > If Linux kernel can boot from the DTS contained within its source code as is, > that would be much more helpful. If you are thinking about embedded system builders, and developers who only care about their test kernel being compatible with one board, I agree with you for those specific use-cases. Almost everyone else will pass in a separate DTB, specific to the board they are using, from U-Boot or Coreboot or GRUB. > > I haven't switched to U-boot yet for these driver tests, so I > > personally have been using the open-source FSBL > > (freedom-u540-c000-bootloader) with the following trivial patches > > applied: > > > > https://github.com/sifive/freedom-u540-c000-bootloader/tree/dev/paulw/supply-fsbl-dtb-v5.1-rc4 > > > The fsbl/ux00_fsbl.dtb file can be symlinked to the kernel DTB output, > > e.g., ~/linux/arch/riscv/boot/dts/sifive/hifive-unleashed-a00-fu540.dtb. > > This assumes that FSBL has to be rebuilt every time I want to change the DT. I > was hoping to avoid that. The FSBL is on its way out. It is just a short-term workaround until the various popular bootloader ports become more stable. After that happens, it's likely that almost no one to use the current SiFive FSBLs. We plan to transition our Freedom-U development environment away from it ourselves. The point of what I wrote to Christoph earlier is simply that everyone is already using DTB data that is passed in from an early bootloader, whether they realize it or not. So there is an existence proof that no additional patches are needed for the basics to function. It may not be functioning well in some cases, and may need patching; but that is a separate matter. - Paul
[PATCH] ARM: dts: rockchip: Add dynamic-power-coefficient for rk3288
The value was determined with the following method:
- take CPUs 1-3 offline
- for each OPP
- set cpufreq min and max freq to OPP freq
- start dhrystone benchmark
- measure CPU power consumption during 10s
- calculate Cx for OPPx
- Cx = (Px - P1) / (Vx²fx - V1²f1) [1]
using the following units: mW / Ghz / V [2]
- C = avg(C2, ..., Cn)
[1] see commit 4daa001a1773 ("arm64: dts: juno: Add cpu
dynamic-power-coefficient information")
[2] https://patchwork.kernel.org/patch/10493615/#22158551
FTR, these are the values for the different OPPs:
freq (kHz) mV Px (mW) Cx
126000 900 39
216000 900 66 370
312000 900 95 372
408000 900 122 363
60 900 177 359
696000 950 230 363
816000 1000297 361
1008000 1050404 362
120 1100528 362
1416000 1200770 377
1512000 1300984 385
1608000 13501156394
Signed-off-by: Matthias Kaehlcke
---
I couldn't find any really comprehensive information on determining
the dynamic-power-coefficient, the method used is my understanding
mostly derived from the sources mentioned above, the resulting value
is within a reasonable range and the range of the intermediate Cx
values is consistent. If someone knows better and things should be
done differently please share your knowledge :)
---
arch/arm/boot/dts/rk3288.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 23e9c5253019..f0d92b045c57 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -61,6 +61,7 @@
reg = <0x500>;
resets = < SRST_CORE0>;
operating-points-v2 = <_opp_table>;
+ dynamic-power-coefficient = <370>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
@@ -71,6 +72,7 @@
reg = <0x501>;
resets = < SRST_CORE1>;
operating-points = <_opp_table>;
+ dynamic-power-coefficient = <370>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
@@ -81,6 +83,7 @@
reg = <0x502>;
resets = < SRST_CORE2>;
operating-points = <_opp_table>;
+ dynamic-power-coefficient = <370>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
@@ -91,6 +94,7 @@
reg = <0x503>;
resets = < SRST_CORE3>;
operating-points = <_opp_table>;
+ dynamic-power-coefficient = <370>;
#cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = < ARMCLK>;
--
2.21.0.392.gf8f6787159e-goog
[PATCH v2 1/2] power_supply: Add more charge types and CHARGE_CONTROL_* properties
Add "Standard", "Adaptive", and "Custom" modes to the charge_type
property, to expand the existing "Trickle" and "Fast" modes.
In addition, add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD
and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand
the existing CHARGE_CONTROL_* properties. I am adding them in order
to support a new Chrome OS device, but these properties should be
general enough that they can be used on other devices.
The meaning of "Standard" is obvious, but "Adaptive" and "Custom" are
more tricky: "Adaptive" means that the charge controller uses some
custom algorithm to change the charge type automatically, with no
configuration needed. "Custom" means that the charge controller uses the
POWER_SUPPLY_PROP_CHARGE_CONTROL_* properties as configuration for some
other algorithm. For example, in the use case that I am supporting,
this means the battery begins charging when the percentage
level drops below POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD and
charging ceases when the percentage level goes above
POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD.
Signed-off-by: Nick Crews
---
drivers/power/supply/power_supply_sysfs.c | 4 +++-
include/linux/power_supply.h | 10 --
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index dce24f596160..6104a3f03d46 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -56,7 +56,7 @@ static const char * const power_supply_status_text[] = {
};
static const char * const power_supply_charge_type_text[] = {
- "Unknown", "N/A", "Trickle", "Fast"
+ "Unknown", "N/A", "Trickle", "Fast", "Standard", "Adaptive", "Custom"
};
static const char * const power_supply_health_text[] = {
@@ -274,6 +274,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+ POWER_SUPPLY_ATTR(charge_control_start_threshold),
+ POWER_SUPPLY_ATTR(charge_control_end_threshold),
POWER_SUPPLY_ATTR(input_current_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 2f9c201a54d1..d59205170232 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -40,11 +40,15 @@ enum {
POWER_SUPPLY_STATUS_FULL,
};
+/* What algorithm is the charger using? */
enum {
POWER_SUPPLY_CHARGE_TYPE_UNKNOWN = 0,
POWER_SUPPLY_CHARGE_TYPE_NONE,
- POWER_SUPPLY_CHARGE_TYPE_TRICKLE,
- POWER_SUPPLY_CHARGE_TYPE_FAST,
+ POWER_SUPPLY_CHARGE_TYPE_TRICKLE, /* slow speed */
+ POWER_SUPPLY_CHARGE_TYPE_FAST, /* fast speed */
+ POWER_SUPPLY_CHARGE_TYPE_STANDARD, /* normal speed */
+ POWER_SUPPLY_CHARGE_TYPE_ADAPTIVE, /* dynamically adjusted speed */
+ POWER_SUPPLY_CHARGE_TYPE_CUSTOM,/* use CHARGE_CONTROL_* props */
};
enum {
@@ -121,6 +125,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+ POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD, /* in percents! */
+ POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD, /* in percents! */
POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
--
2.20.1
[PATCH] selftests/seccomp: Handle namespace failures gracefully
When running without USERNS or PIDNS the seccomp test would hang since
it was waiting forever for the child to trigger the user notification
since it seems the glibc() abort handler makes a call to getpid(),
which would trap again. This changes the getpid filter to getppid, and
makes sure ASSERTs execute to stop from spawning the listener.
Reported-by: Shuah Khan
Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 43 ++-
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index f69d2ee29742..3a280b7efc87 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -3079,9 +3079,9 @@ TEST(user_notification_basic)
/* Check that we get -ENOSYS with no listener attached */
if (pid == 0) {
- if (user_trap_syscall(__NR_getpid, 0) < 0)
+ if (user_trap_syscall(__NR_getppid, 0) < 0)
exit(1);
- ret = syscall(__NR_getpid);
+ ret = syscall(__NR_getppid);
exit(ret >= 0 || errno != ENOSYS);
}
@@ -3096,12 +3096,12 @@ TEST(user_notification_basic)
EXPECT_EQ(seccomp(SECCOMP_SET_MODE_FILTER, 0, ), 0);
/* Check that the basic notification machinery works */
- listener = user_trap_syscall(__NR_getpid,
+ listener = user_trap_syscall(__NR_getppid,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
ASSERT_GE(listener, 0);
/* Installing a second listener in the chain should EBUSY */
- EXPECT_EQ(user_trap_syscall(__NR_getpid,
+ EXPECT_EQ(user_trap_syscall(__NR_getppid,
SECCOMP_FILTER_FLAG_NEW_LISTENER),
-1);
EXPECT_EQ(errno, EBUSY);
@@ -3110,7 +3110,7 @@ TEST(user_notification_basic)
ASSERT_GE(pid, 0);
if (pid == 0) {
- ret = syscall(__NR_getpid);
+ ret = syscall(__NR_getppid);
exit(ret != USER_NOTIF_MAGIC);
}
@@ -3128,7 +3128,7 @@ TEST(user_notification_basic)
EXPECT_GT(poll(, 1, -1), 0);
EXPECT_EQ(pollfd.revents, POLLOUT);
- EXPECT_EQ(req.data.nr, __NR_getpid);
+ EXPECT_EQ(req.data.nr, __NR_getppid);
resp.id = req.id;
resp.error = 0;
@@ -3160,7 +3160,7 @@ TEST(user_notification_kill_in_middle)
TH_LOG("Kernel does not support PR_SET_NO_NEW_PRIVS!");
}
- listener = user_trap_syscall(__NR_getpid,
+ listener = user_trap_syscall(__NR_getppid,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
ASSERT_GE(listener, 0);
@@ -3172,7 +3172,7 @@ TEST(user_notification_kill_in_middle)
ASSERT_GE(pid, 0);
if (pid == 0) {
- ret = syscall(__NR_getpid);
+ ret = syscall(__NR_getppid);
exit(ret != USER_NOTIF_MAGIC);
}
@@ -3282,7 +3282,7 @@ TEST(user_notification_closed_listener)
TH_LOG("Kernel does not support PR_SET_NO_NEW_PRIVS!");
}
- listener = user_trap_syscall(__NR_getpid,
+ listener = user_trap_syscall(__NR_getppid,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
ASSERT_GE(listener, 0);
@@ -3293,7 +3293,7 @@ TEST(user_notification_closed_listener)
ASSERT_GE(pid, 0);
if (pid == 0) {
close(listener);
- ret = syscall(__NR_getpid);
+ ret = syscall(__NR_getppid);
exit(ret != -1 && errno != ENOSYS);
}
@@ -3316,14 +3316,15 @@ TEST(user_notification_child_pid_ns)
ASSERT_EQ(unshare(CLONE_NEWUSER | CLONE_NEWPID), 0);
- listener = user_trap_syscall(__NR_getpid,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
+ listener = user_trap_syscall(__NR_getppid,
+SECCOMP_FILTER_FLAG_NEW_LISTENER);
ASSERT_GE(listener, 0);
pid = fork();
ASSERT_GE(pid, 0);
if (pid == 0)
- exit(syscall(__NR_getpid) != USER_NOTIF_MAGIC);
+ exit(syscall(__NR_getppid) != USER_NOTIF_MAGIC);
EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_RECV, ), 0);
EXPECT_EQ(req.pid, pid);
@@ -3355,7 +3356,8 @@ TEST(user_notification_sibling_pid_ns)
TH_LOG("Kernel does not support PR_SET_NO_NEW_PRIVS!");
}
- listener = user_trap_syscall(__NR_getpid,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
+ listener = user_trap_syscall(__NR_getppid,
+SECCOMP_FILTER_FLAG_NEW_LISTENER);
ASSERT_GE(listener, 0);
pid = fork();
@@ -3368,7 +3370,7 @@ TEST(user_notification_sibling_pid_ns)
ASSERT_GE(pid2, 0);
if (pid2 == 0)
-
[PATCH v2 2/2] power_supply: wilco_ec: Add charging config driver for Wilco EC
Add control of the charging algorithm used on Wilco devices.
See Documentation/ABI/testing/sysfs-class-power-wilco for the
userspace interface and other info.
Signed-off-by: Nick Crews
---
.../ABI/testing/sysfs-class-power-wilco | 30 +++
drivers/platform/chrome/wilco_ec/Kconfig | 9 +
drivers/platform/chrome/wilco_ec/Makefile | 2 +
.../platform/chrome/wilco_ec/charge_config.c | 190 ++
drivers/platform/chrome/wilco_ec/core.c | 14 ++
drivers/platform/chrome/wilco_ec/properties.c | 134
drivers/platform/chrome/wilco_ec/properties.h | 68 +++
include/linux/platform_data/wilco-ec.h| 2 +
8 files changed, 449 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-power-wilco
create mode 100644 drivers/platform/chrome/wilco_ec/charge_config.c
create mode 100644 drivers/platform/chrome/wilco_ec/properties.c
create mode 100644 drivers/platform/chrome/wilco_ec/properties.h
diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco
b/Documentation/ABI/testing/sysfs-class-power-wilco
new file mode 100644
index ..7f3b01310476
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-power-wilco
@@ -0,0 +1,30 @@
+What: /sys/class/power_supply/wilco_charger/charge_type
+Date: April 2019
+KernelVersion: 5.2
+Description:
+ What charging algorithm to use:
+
+ Standard: Fully charges battery at a standard rate.
+ Adaptive: Battery settings adaptively optimized based on
+ typical battery usage pattern.
+ Fast: Battery charges over a shorter period.
+ Trickle: Extends battery lifespan, intended for users who
+ primarily use their Chromebook while connected to AC.
+ Custom: A low and high threshold percentage is specified.
+ Charging begins when level drops below
+ charge_control_start_threshold, and ceases when
+ level is above charge_control_end_threshold.
+
+What:
/sys/class/power_supply/wilco_charger/charge_control_start_threshold
+Date: April 2019
+KernelVersion: 5.2
+Description:
+ Used when charge_type="Custom", as described above. Measured in
+ percentages. The valid range is [50, 95].
+
+What:
/sys/class/power_supply/wilco_charger/charge_control_end_threshold
+Date: April 2019
+KernelVersion: 5.2
+Description:
+ Used when charge_type="Custom", as described above. Measured in
+ percentages. The valid range is [55, 100].
diff --git a/drivers/platform/chrome/wilco_ec/Kconfig
b/drivers/platform/chrome/wilco_ec/Kconfig
index e09e4cebe9b4..1c427830bd57 100644
--- a/drivers/platform/chrome/wilco_ec/Kconfig
+++ b/drivers/platform/chrome/wilco_ec/Kconfig
@@ -18,3 +18,12 @@ config WILCO_EC_DEBUGFS
manipulation and allow for testing arbitrary commands. This
interface is intended for debug only and will not be present
on production devices.
+
+config WILCO_EC_CHARGE_CNTL
+ tristate "Enable charging control"
+ depends on WILCO_EC
+ help
+ If you say Y here, you get support to control the charging
+ routines performed by the Wilco Embedded Controller.
+ Further information can be found in
+ Documentation/ABI/testing/sysfs-class-power-wilco)
diff --git a/drivers/platform/chrome/wilco_ec/Makefile
b/drivers/platform/chrome/wilco_ec/Makefile
index 063e7fb4ea17..7e980f56f793 100644
--- a/drivers/platform/chrome/wilco_ec/Makefile
+++ b/drivers/platform/chrome/wilco_ec/Makefile
@@ -4,3 +4,5 @@ wilco_ec-objs := core.o mailbox.o
obj-$(CONFIG_WILCO_EC) += wilco_ec.o
wilco_ec_debugfs-objs := debugfs.o
obj-$(CONFIG_WILCO_EC_DEBUGFS) += wilco_ec_debugfs.o
+wilco_ec_charging-objs := charge_config.o properties.o
+obj-$(CONFIG_WILCO_EC_CHARGE_CNTL) += wilco_ec_charging.o
diff --git a/drivers/platform/chrome/wilco_ec/charge_config.c
b/drivers/platform/chrome/wilco_ec/charge_config.c
new file mode 100644
index ..7c41b847396d
--- /dev/null
+++ b/drivers/platform/chrome/wilco_ec/charge_config.c
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Charging control driver for the Wilco EC
+ *
+ * Copyright 2019 Google LLC
+ *
+ * See Documentation/ABI/testing/sysfs-class-power-wilco for
+ * userspace interface and other info.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "properties.h"
+
+#define DRV_NAME "wilco-ec-charging"
+
+/* Property IDs and related EC constants */
+#define PID_CHARGE_MODE0x0710
+#define PID_CHARGE_LOWER_LIMIT 0x0711
+#define PID_CHARGE_UPPER_LIMIT 0x0712
+
+enum charge_mode {
+ CHARGE_MODE_STD = 1,/* Used for Standard */
+ CHARGE_MODE_EXP = 2,/* Express Charge, used for
Re: [PATCH v4 0/4] Add device links to clocks
Quoting Miquel Raynal (2019-01-08 08:19:36) > Hello, > > While working on suspend to RAM feature, I ran into troubles multiple > times when clocks where not suspending/resuming at the desired time. I > had a look at the core and I think the same logic as in the > regulator's core may be applied here to (very easily) fix this issue: > using device links. > > The only additional change I had to do was to always (when available) > populate the device entry of the core clock structure so that it could > be used later. This is the purpose of patch 1. Patch 2 actually adds > support for device links. > > Here is a step-by-step explanation of how links are managed, following > Maxime Ripard's suggestion. > > > The order of probe has no importance because the framework already > handles orphaned clocks so let's be simple and say there are two root > clocks, not depending on anything, that are probed first: xtal0 and > xtal1. None of these clocks have a parent, there is no device link in > the game, yet. > >++++ >|||| >|||| >| xtal0 core || xtal1 core | >|||| >|||| >+---^^---++---^^---+ >|||| >|||| >++++ >|||| >| xtal0 clk|| xtal1 clk| >|||| >++++ > > Then, a peripheral clock periph0 is probed. His parent is xtal1. The > clock_register_*() call will run __clk_init_parent() and a link between > periph0's core and xtal1's core will be created and stored in > periph0's core->parent_clk_link entry. > >++++ >|||| >|||| >| xtal0 core || xtal1 core | >|||| >|||| >+---^^---++---^^---+ >|||| >|||| >++++ >|||| >| xtal0 clk|| xtal1 clk| >|||| >+++---^+ > | > | > +--+ > | ->parent_clk_link > | > ++ > || > || > | periph0 core | > || > || > +---^^---+ > || > || > ++ > || > | periph0 clk 0 | > || > ++ > > Then, device0 is probed and "get" the periph0 clock. clk_get() will be > called and a struct clk will be instantiated for device0 (called in > the figure clk 1). A link between device0 and the new clk 1 instance of > periph0 will be created and stored in the clk->consumer_link entry. > >++++ >|||| >|||| >| xtal0 core || xtal1 core | >|||| >|||| >+---^^---++---^^---+ >|||| >|||| >++++ >|||| >| xtal0 clk|| xtal1 clk| >|||| >+++---^+ > | > | > +--+ > | ->parent_clk_link > | > ++ > || > || > | periph0 core | > |<-+ > |
Re: [PATCH v2] extcon: axp288: Add a depends on ACPI to the Kconfig entry
On 19. 4. 4. 오후 11:17, Yue Haibing wrote:
> From: YueHaibing
>
> As Hans de Goede pointed, using this driver without ACPI
> makes little sense, so add ACPI dependency to Kconfig entry
> to fix a build error while CONFIG_ACPI is not set.
>
> drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe':
> drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to
> incomplete type
> put_device(>dev);
>
> Fixes: 0cf064db948a ("extcon: axp288: Convert to use
> acpi_dev_get_first_match_dev()")
> Reported-by: Hulk Robot
> Suggested-by: Hans de Goede
> Signed-off-by: YueHaibing
> ---
> v2: rework patch
> ---
> drivers/extcon/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 1ed4b45..de06faf 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -30,7 +30,7 @@ config EXTCON_ARIZONA
>
> config EXTCON_AXP288
> tristate "X-Power AXP288 EXTCON support"
> - depends on MFD_AXP20X && USB_SUPPORT && X86
> + depends on MFD_AXP20X && USB_SUPPORT && X86 && ACPI
> select USB_ROLE_SWITCH
> help
> Say Y here to enable support for USB peripheral detection
>
Applied it. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH 5/5] ARM: dts: rockchip: vdd_gpu off in suspend for rk3288-veyron
At some point long long ago the downstream GPU driver would crash if
we turned the GPU off during suspend. For some context you can see:
https://chromium-review.googlesource.com/#/c/215780/5..6/arch/arm/boot/dts/rk3288-pinky-rev2.dts
At some point in time not too long after that got fixed.
It's unclear why the GPU is left enabled during suspend on the
mainline kernel. Everything seems fine if I turn this off, so let's
do it.
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 279d7f4ecce0..1252522392c7 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -217,8 +217,7 @@
regulator-max-microvolt = <125>;
regulator-ramp-delay = <6001>;
regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <100>;
+ regulator-off-in-suspend;
};
};
--
2.21.0.392.gf8f6787159e-goog
[PATCH 3/5] ARM: dts: rockchip: Add DDR retention/poweroff to rk3288-veyron hogs
Even though upstream Linux doesn't yet go into deep enough suspend to
get DDR into self refresh, there is no harm in setting these pins up.
They'll only actually do something if we go into a deeper suspend but
leaving them configed always is fine.
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 4
arch/arm/boot/dts/rk3288-veyron.dtsi| 4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index 72c4754032e9..b9cc90f0f25c 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -229,6 +229,8 @@
{
pinctrl-0 = <
/* Common for sleep and wake, but no owners */
+ _retention
+ _pwroff
_pwroff
/* Wake only */
@@ -236,6 +238,8 @@
>;
pinctrl-1 = <
/* Common for sleep and wake, but no owners */
+ _retention
+ _pwroff
_pwroff
/* Sleep only */
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 5c67acc3e6d8..279d7f4ecce0 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -451,10 +451,14 @@
pinctrl-names = "default", "sleep";
pinctrl-0 = <
/* Common for sleep and wake, but no owners */
+ _retention
+ _pwroff
_pwroff
>;
pinctrl-1 = <
/* Common for sleep and wake, but no owners */
+ _retention
+ _pwroff
_pwroff
>;
--
2.21.0.392.gf8f6787159e-goog
[PATCH 2/5] ARM: rockchip: pm: Mark init functions __init
The functions rk3288_config_bootdata() and rk3288_suspend_init() are
only called in the context of rockchip_suspend_init() which is already
marked __init. We can mark them __init too.
Signed-off-by: Douglas Anderson
---
arch/arm/mach-rockchip/pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/pm.c b/arch/arm/mach-rockchip/pm.c
index 0592534e0b88..065b09e6f1eb 100644
--- a/arch/arm/mach-rockchip/pm.c
+++ b/arch/arm/mach-rockchip/pm.c
@@ -59,7 +59,7 @@ static inline u32 rk3288_l2_config(void)
return l2ctlr;
}
-static void rk3288_config_bootdata(void)
+static void __init rk3288_config_bootdata(void)
{
rkpm_bootdata_cpusp = rk3288_bootram_phy + (SZ_4K - 8);
rkpm_bootdata_cpu_code = __pa_symbol(cpu_resume);
@@ -230,7 +230,7 @@ static void rk3288_suspend_finish(void)
pr_err("%s: Suspend finish failed\n", __func__);
}
-static int rk3288_suspend_init(struct device_node *np)
+static int __init rk3288_suspend_init(struct device_node *np)
{
struct device_node *sram_np;
struct resource res;
--
2.21.0.392.gf8f6787159e-goog
[PATCH 4/5] ARM: dts: rockchip: vcc33_ccd off in suspend for rk3288-veyron-chromebook
As per my comments when the device tree for rk3288-veyron-chromebook
first landed:
> Technically I think vcc33_ccd can be off since we have
> 'needs-reset-on-resume' down in the EHCI port (this regulator is for
> the USB webcam that's connected to the EHCI port).
>
> ...but leaving it on for now seems fine until we get suspend/resume
> more solid.
It's probably about time to do it right.
[1]
https://lore.kernel.org/linux-arm-kernel/CAD=FV=u37yx8mqk75_x05zxonvdc3qrmhqp8tytdpwghqsu...@mail.gmail.com/
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index b9cc90f0f25c..fbef34578100 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -176,8 +176,7 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <330>;
+ regulator-off-in-suspend;
};
};
};
--
2.21.0.392.gf8f6787159e-goog
[PATCH 1/5] clk: rockchip: Turn on "aclk_dmac1" for suspend
Experimentally it can be seen that going into deep sleep (specifically
setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
appears to fail unless "aclk_dmac1" is on. The failure is that the
system never signals that it made it into suspend on the GLOBAL_PWROFF
pin and it just hangs.
NOTE that it's confirmed that it's the actual suspend that fails, not
one of the earlier calls to read/write registers. Specifically if you
comment out the "PMU_GLOBAL_INT_DISABLE" setting in
rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
rockchip_lpmode_enter() then you can exercise the whole suspend path
without any crashing.
This is currently not a problem with suspend upstream because there is
no current way to exercise the deep suspend code. However, anyone
trying to make it work will run into this issue.
This was not a problem on shipping rk3288-based Chromebooks because
those devices all ran on an old kernel based on 3.14. On that kernel
"aclk_dmac1" appears to be left on all the time.
There are several ways to skin this problem.
A) We could add "aclk_dmac1" to the list of critical clocks and that
apperas to work, but presumably that wastes power.
B) We could keep a list of "struct clk" objects to enable at suspend
time in clk-rk3288.c and use the standard clock APIs.
C) We could make the rk3288-pmu driver keep a list of clocks to enable
at suspend time. Presumably this would require a dts and bindings
change.
D) We could just whack the clock on in the existing syscore suspend
function where we whack a bunch of other clocks. This is particularly
easy because we know for sure that the clock's only parent
("aclk_cpu") is a critical clock so we don't need to do anything more
than ungate it.
In this case I have chosen D) because it seemed like the least work,
but any of the other options would presumably also work fine.
Signed-off-by: Douglas Anderson
---
drivers/clk/rockchip/clk-rk3288.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 5a67b7869960..b245367393cd 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -859,6 +859,9 @@ static const int rk3288_saved_cru_reg_ids[] = {
RK3288_CLKSEL_CON(10),
RK3288_CLKSEL_CON(33),
RK3288_CLKSEL_CON(37),
+
+ /* We turn aclk_dmac1 on for suspend; this will restore it */
+ RK3288_CLKGATE_CON(10),
};
static u32 rk3288_saved_cru_regs[ARRAY_SIZE(rk3288_saved_cru_reg_ids)];
@@ -874,6 +877,14 @@ static int rk3288_clk_suspend(void)
readl_relaxed(rk3288_cru_base + reg_id);
}
+ /*
+* Going into deep sleep (specifically setting PMU_CLR_DMA in
+* RK3288_PMU_PWRMODE_CON1) appears to fail unless
+* "aclk_dmac1" is on.
+*/
+ writel_relaxed(1 << (12 + 16),
+ rk3288_cru_base + RK3288_CLKGATE_CON(10));
+
/*
* Switch PLLs other than DPLL (for SDRAM) to slow mode to
* avoid crashes on resume. The Mask ROM on the system will
--
2.21.0.392.gf8f6787159e-goog
Re: [PATCH v2] gpio: merrifield: Fix build err without CONFIG_ACPI
On Friday, April 5, 2019 4:50:09 PM CEST Andy Shevchenko wrote:
> On Fri, Apr 05, 2019 at 10:21:12PM +0800, Yue Haibing wrote:
> > From: YueHaibing
> >
> > When building CONFIG_ACPI is not set
> > gcc warn this:
> >
> > drivers/gpio/gpio-merrifield.c: In function
> > mrfld_gpio_get_pinctrl_dev_name: drivers/gpio/gpio-merrifield.c:388:19:
> > error: dereferencing pointer to incomplete type struct acpi_device>
> >put_device(>dev);
> >
> >^
> >
> > Reported-by: Hulk Robot
> > Suggested-by: Andy Shevchenko
> > Fixes:d00d2109c367 ("gpio: merrifield: Convert to use
> > acpi_dev_get_first_match_dev()") Signed-off-by: YueHaibing
> >
>
> Thank you for an update, I have a comment below, but before sending v3, let
> Rafael to have a chance to look at it.
>
> > #ifdef CONFIG_ACPI
> > extern int acpi_platform_notify(struct device *dev, enum kobject_action
> > action);>
> > +
> > +static inline void put_acpi_device(struct acpi_device *adev)
> > +{
> > + put_device(>dev);
> > +}
>
> This should probably go to acpi_bus.h under acpi_dev_get_first_match_dev().
> And talking to Mika we agreed that naming would be better as acpi_dev_put().
Agreed on both accounts.
Thanks!
[PATCH v1 0/3] memory: Introduce NVIDIA Tegra30 EMC driver
Hello, This patchset adds driver for the External Memory Controller of NVIDIA Tegra30 SoC's. It performs memory hardware configuration that is required for changing DRAM frequency, thus providing facility for the memory frequency scaling on Tegra30. The memory scaling was tested using the Tegra's devfreq driver which is available in upstream, it dynamically changes memory clock rate based on memory clients activity. Dmitry Osipenko (3): dt-bindings: memory: Add binding for NVIDIA Tegra30 External Memory Controller memory: tegra: Introduce Tegra30 EMC driver ARM: dts: tegra30: Add External Memory Controller node .../memory-controllers/nvidia,tegra30-emc.txt | 257 arch/arm/boot/dts/tegra30.dtsi| 11 + drivers/memory/tegra/Kconfig | 10 + drivers/memory/tegra/Makefile |1 + drivers/memory/tegra/mc.c |3 - drivers/memory/tegra/mc.h | 30 +- drivers/memory/tegra/tegra30-emc.c| 1106 + drivers/memory/tegra/tegra30.c| 44 + 8 files changed, 1450 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt create mode 100644 drivers/memory/tegra/tegra30-emc.c -- 2.21.0
[PATCH v1 2/3] memory: tegra: Introduce Tegra30 EMC driver
Introduce driver for the External Memory Controller (EMC) found on Tegra30
chips, it controls the external DRAM on the board. The purpose of this
driver is to program memory timing for external memory on the EMC clock
rate change.
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/Kconfig | 10 +
drivers/memory/tegra/Makefile |1 +
drivers/memory/tegra/mc.c |3 -
drivers/memory/tegra/mc.h | 30 +-
drivers/memory/tegra/tegra30-emc.c | 1105
drivers/memory/tegra/tegra30.c | 44 ++
6 files changed, 1181 insertions(+), 12 deletions(-)
create mode 100644 drivers/memory/tegra/tegra30-emc.c
diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 34e0b70f5c5f..89c02a368c65 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -16,6 +16,16 @@ config TEGRA20_EMC
This driver is required to change memory timings / clock rate for
external memory.
+config TEGRA30_EMC
+ bool "NVIDIA Tegra30 External Memory Controller driver"
+ default y
+ depends on TEGRA_MC && ARCH_TEGRA_3x_SOC
+ help
+ This driver is for the External Memory Controller (EMC) found on
+ Tegra30 chips. The EMC controls the external DRAM on the board.
+ This driver is required to change memory timings / clock rate for
+ external memory.
+
config TEGRA124_EMC
bool "NVIDIA Tegra124 External Memory Controller driver"
default y
diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
index 3971a6b7c487..3d23c4261104 100644
--- a/drivers/memory/tegra/Makefile
+++ b/drivers/memory/tegra/Makefile
@@ -11,5 +11,6 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
obj-$(CONFIG_TEGRA20_EMC) += tegra20-emc.o
+obj-$(CONFIG_TEGRA30_EMC) += tegra30-emc.o
obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 31b47459c84d..52ede43f1e07 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -51,9 +51,6 @@
#define MC_EMEM_ADR_CFG 0x54
#define MC_EMEM_ADR_CFG_EMEM_NUMDEV BIT(0)
-#define MC_TIMING_CONTROL 0xfc
-#define MC_TIMING_UPDATE BIT(0)
-
static const struct of_device_id tegra_mc_of_match[] = {
#ifdef CONFIG_ARCH_TEGRA_2x_SOC
{ .compatible = "nvidia,tegra20-mc-gart", .data = _mc_soc },
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 887a3b07334f..90da9f62ce2b 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -9,20 +9,32 @@
#ifndef MEMORY_TEGRA_MC_H
#define MEMORY_TEGRA_MC_H
+#include
#include
#include
#include
-#define MC_INT_DECERR_MTS (1 << 16)
-#define MC_INT_SECERR_SEC (1 << 13)
-#define MC_INT_DECERR_VPR (1 << 12)
-#define MC_INT_INVALID_APB_ASID_UPDATE (1 << 11)
-#define MC_INT_INVALID_SMMU_PAGE (1 << 10)
-#define MC_INT_ARBITRATION_EMEM (1 << 9)
-#define MC_INT_SECURITY_VIOLATION (1 << 8)
-#define MC_INT_INVALID_GART_PAGE (1 << 7)
-#define MC_INT_DECERR_EMEM (1 << 6)
+#define MC_INT_DECERR_MTS BIT(16)
+#define MC_INT_SECERR_SEC BIT(13)
+#define MC_INT_DECERR_VPR BIT(12)
+#define MC_INT_INVALID_APB_ASID_UPDATE BIT(11)
+#define MC_INT_INVALID_SMMU_PAGE BIT(10)
+#define MC_INT_ARBITRATION_EMEMBIT(9)
+#define MC_INT_SECURITY_VIOLATION BIT(8)
+#define MC_INT_INVALID_GART_PAGE BIT(7)
+#define MC_INT_DECERR_EMEM BIT(6)
+
+#define MC_EMEM_ARB_OUTSTANDING_REQ0x94
+#define MC_EMEM_ARB_OUTSTANDING_REQ_MAX_MASK 0x1ff
+#define MC_EMEM_ARB_OUTSTANDING_REQ_HOLDOFF_OVERRIDE BIT(30)
+#define MC_EMEM_ARB_OUTSTANDING_REQ_LIMIT_ENABLE BIT(31)
+
+#define MC_EMEM_ARB_OVERRIDE 0xe8
+#define MC_EMEM_ARB_OVERRIDE_EACK_MASK 0x3
+
+#define MC_TIMING_CONTROL 0xfc
+#define MC_TIMING_UPDATE BIT(0)
static inline u32 mc_readl(struct tegra_mc *mc, unsigned long offset)
{
diff --git a/drivers/memory/tegra/tegra30-emc.c
b/drivers/memory/tegra/tegra30-emc.c
new file mode 100644
index ..38ebdb076ccd
--- /dev/null
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -0,0 +1,1105 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Tegra30 External Memory Controller driver
+ *
+ * Author: Dmitry Osipenko
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "mc.h"
+
+#define EMC_INTSTATUS 0x000
+#define EMC_INTMASK0x004
+#define
[PATCH v1 1/3] dt-bindings: memory: Add binding for NVIDIA Tegra30 External Memory Controller
Add device-tree binding for NVIDIA Tegra30 External Memory Controller.
The binding is based on the Tegra124 EMC binding since hardware is
similar, although there are couple significant differences.
Signed-off-by: Dmitry Osipenko
---
.../memory-controllers/nvidia,tegra30-emc.txt | 257 ++
1 file changed, 257 insertions(+)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
diff --git
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
new file mode 100644
index ..dffe396c5d79
--- /dev/null
+++
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.txt
@@ -0,0 +1,257 @@
+NVIDIA Tegra30 SoC EMC (external memory controller)
+
+
+Required properties :
+- compatible : Should be "nvidia,tegra30-emc".
+- reg : physical base address and length of the controller's registers.
+- #address-cells : Should be 1
+- #size-cells : Should be 0
+- interrupts : Should contain EMC General interrupt.
+- clocks : Should contain EMC clock.
+- nvidia,memory-controller : phandle of the MC driver.
+
+The node should contain a "emc-timings" subnode for each supported RAM type
+(see field RAM_CODE in register PMC_STRAPPING_OPT_A), with its unit address
+being its RAM_CODE.
+
+Required properties for "emc-timings" nodes :
+- nvidia,ram-code : Should contain the value of RAM_CODE this timing set is
+used for.
+
+Each "emc-timings" node should contain a "timing" subnode for every supported
+EMC clock rate. The "timing" subnodes should have the clock rate in Hz as
+their unit address.
+
+Required properties for "timing" nodes :
+- clock-frequency : Should contain the memory clock rate in Hz.
+- The following properties contain EMC timing characterization values
+(specified in the board documentation) :
+ - nvidia,emc-auto-cal-interval : EMC_AUTO_CAL_INTERVAL
+ - nvidia,emc-mode-1 : Mode Register 1
+ - nvidia,emc-mode-2 : Mode Register 2
+ - nvidia,emc-mode-reset : Mode Register 0
+ - nvidia,emc-zcal-cnt-long : EMC_ZCAL_WAIT_CNT after clock change
+ - nvidia,emc-cfg-dyn-self-ref : dynamic self-refresh enabled
+ - nvidia,emc-cfg-periodic-qrst : FBIO "read" FIFO periodic resetting enabled
+- nvidia,emc-configuration : EMC timing characterization data. These are the
+registers (see section "18.13.2 EMC Registers" in the TRM) whose values need to
+be specified, according to the board documentation:
+
+ EMC_RC
+ EMC_RFC
+ EMC_RAS
+ EMC_RP
+ EMC_R2W
+ EMC_W2R
+ EMC_R2P
+ EMC_W2P
+ EMC_RD_RCD
+ EMC_WR_RCD
+ EMC_RRD
+ EMC_REXT
+ EMC_WEXT
+ EMC_WDV
+ EMC_QUSE
+ EMC_QRST
+ EMC_QSAFE
+ EMC_RDV
+ EMC_REFRESH
+ EMC_BURST_REFRESH_NUM
+ EMC_PRE_REFRESH_REQ_CNT
+ EMC_PDEX2WR
+ EMC_PDEX2RD
+ EMC_PCHG2PDEN
+ EMC_ACT2PDEN
+ EMC_AR2PDEN
+ EMC_RW2PDEN
+ EMC_TXSR
+ EMC_TXSRDLL
+ EMC_TCKE
+ EMC_TFAW
+ EMC_TRPAB
+ EMC_TCLKSTABLE
+ EMC_TCLKSTOP
+ EMC_TREFBW
+ EMC_QUSE_EXTRA
+ EMC_FBIO_CFG6
+ EMC_ODT_WRITE
+ EMC_ODT_READ
+ EMC_FBIO_CFG5
+ EMC_CFG_DIG_DLL
+ EMC_CFG_DIG_DLL_PERIOD
+ EMC_DLL_XFORM_DQS0
+ EMC_DLL_XFORM_DQS1
+ EMC_DLL_XFORM_DQS2
+ EMC_DLL_XFORM_DQS3
+ EMC_DLL_XFORM_DQS4
+ EMC_DLL_XFORM_DQS5
+ EMC_DLL_XFORM_DQS6
+ EMC_DLL_XFORM_DQS7
+ EMC_DLL_XFORM_QUSE0
+ EMC_DLL_XFORM_QUSE1
+ EMC_DLL_XFORM_QUSE2
+ EMC_DLL_XFORM_QUSE3
+ EMC_DLL_XFORM_QUSE4
+ EMC_DLL_XFORM_QUSE5
+ EMC_DLL_XFORM_QUSE6
+ EMC_DLL_XFORM_QUSE7
+ EMC_DLI_TRIM_TXDQS0
+ EMC_DLI_TRIM_TXDQS1
+ EMC_DLI_TRIM_TXDQS2
+ EMC_DLI_TRIM_TXDQS3
+ EMC_DLI_TRIM_TXDQS4
+ EMC_DLI_TRIM_TXDQS5
+ EMC_DLI_TRIM_TXDQS6
+ EMC_DLI_TRIM_TXDQS7
+ EMC_DLL_XFORM_DQ0
+ EMC_DLL_XFORM_DQ1
+ EMC_DLL_XFORM_DQ2
+ EMC_DLL_XFORM_DQ3
+ EMC_XM2CMDPADCTRL
+ EMC_XM2DQSPADCTRL2
+ EMC_XM2DQPADCTRL2
+ EMC_XM2CLKPADCTRL
+ EMC_XM2COMPPADCTRL
+ EMC_XM2VTTGENPADCTRL
+ EMC_XM2VTTGENPADCTRL2
+ EMC_XM2QUSEPADCTRL
+ EMC_XM2DQSPADCTRL3
+ EMC_CTT_TERM_CTRL
+ EMC_ZCAL_INTERVAL
+ EMC_ZCAL_WAIT_CNT
+ EMC_MRS_WAIT_CNT
+ EMC_AUTO_CAL_CONFIG
+ EMC_CTT
+ EMC_CTT_DURATION
+ EMC_DYN_SELF_REF_CONTROL
+ EMC_FBIO_SPARE
+ EMC_CFG_RSV
+
+Example SoC include file:
+
+/ {
+ emc@7000f400 {
+ compatible = "nvidia,tegra30-emc";
+ reg = <0x7000f400 0x400>;
+ interrupts = ;
+ clocks = <_car TEGRA30_CLK_EMC>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nvidia,memory-controller =
[PATCH v1 3/3] ARM: dts: tegra30: Add External Memory Controller node
Add Add External Memory Controller node to the device-tree.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra30.dtsi | 11 +++
drivers/memory/tegra/tegra30-emc.c | 3 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index e074258d4518..92c4aeafab29 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -732,6 +732,17 @@
#reset-cells = <1>;
};
+ memory-controller@7000f400 {
+ compatible = "nvidia,tegra30-emc";
+ reg = <0x7000f400 0x400>;
+ interrupts = ;
+ clocks = <_car TEGRA30_CLK_EMC>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nvidia,memory-controller = <>;
+ };
+
fuse@7000f800 {
compatible = "nvidia,tegra30-efuse";
reg = <0x7000f800 0x400>;
diff --git a/drivers/memory/tegra/tegra30-emc.c
b/drivers/memory/tegra/tegra30-emc.c
index 38ebdb076ccd..defdb38bde54 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -980,7 +980,8 @@ static long emc_round_rate(unsigned long rate,
}
if (!timing) {
- dev_err(emc->dev, "no timing for rate %lu\n", rate);
+ dev_err(emc->dev, "no timing for rate %lu min %lu max %lu\n",
+ rate, min_rate, max_rate);
return -EINVAL;
}
--
2.21.0
[PATCH v1] clk: tegra20/30: Add custom EMC clock implementation
A proper External Memory Controller clock rounding and parent selection
functionality is required by the EMC drivers. It is not available using
the generic clock implementation, hence add a custom one. The clock rate
rounding shall be done by the EMC drivers because they have information
about available memory timings, so the drivers will have to register a
callback that will round the requested rate. EMC clock users won't be able
to request EMC clock by getting -EPROBE_DEFER until EMC driver is probed
and the callback is set up. The functionality is somewhat similar to the
clk-emc.c which serves Tegra124+ SoC's, the later HW generations support
more parent clock sources and the HW configuration and integration with
the EMC drivers differs a tad from the older gens, hence it's not really
worth to try to squash everything into a single source file.
Signed-off-by: Dmitry Osipenko
---
drivers/clk/tegra/Makefile | 2 +
drivers/clk/tegra/clk-tegra20-emc.c | 274
drivers/clk/tegra/clk-tegra20.c | 51 ++
drivers/clk/tegra/clk-tegra30.c | 35 ++--
drivers/clk/tegra/clk.h | 6 +
include/linux/clk/tegra.h | 3 +
6 files changed, 321 insertions(+), 50 deletions(-)
create mode 100644 drivers/clk/tegra/clk-tegra20-emc.c
diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 4812e45c2214..df966ca06788 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -17,7 +17,9 @@ obj-y += clk-tegra-fixed.o
obj-y += clk-tegra-super-gen4.o
obj-$(CONFIG_TEGRA_CLK_EMC)+= clk-emc.o
obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
+obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= clk-tegra20-emc.o
obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
+obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= clk-tegra20-emc.o
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += clk-tegra114.o
obj-$(CONFIG_ARCH_TEGRA_124_SOC) += clk-tegra124.o
obj-$(CONFIG_TEGRA_CLK_DFLL) += clk-tegra124-dfll-fcpu.o
diff --git a/drivers/clk/tegra/clk-tegra20-emc.c
b/drivers/clk/tegra/clk-tegra20-emc.c
new file mode 100644
index ..2cc8f16cd136
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra20-emc.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK 0xff
+#define CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT30
+#define CLK_SOURCE_EMC_2X_CLK_SRC_MASK 0xc000
+
+#define CLK_SOURCE_EMC 0x19c
+
+#define USE_PLLM_UDBIT(29)
+
+#define EMC_SRC_PLL_M 0
+#define EMC_SRC_PLL_C 1
+#define EMC_SRC_PLL_P 2
+#define EMC_SRC_CLK_M 3
+
+static const char * const emc_parent_clk_names[] = {
+ "pll_m", "pll_c", "pll_p", "clk_m",
+};
+
+struct tegra_clk_emc {
+ struct clk_hw hw;
+ void __iomem *ioaddr;
+ bool want_low_jitter;
+
+ long (*round_cb)(unsigned long, unsigned long, unsigned long, void *);
+ void *arg_cb;
+};
+
+static inline struct tegra_clk_emc *to_tegra_clk_emc(struct clk_hw *hw)
+{
+ return container_of(hw, struct tegra_clk_emc, hw);
+}
+
+static unsigned long emc_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+ u32 val, div;
+
+ val = readl_relaxed(emc->ioaddr);
+ div = val & CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+
+ return DIV_ROUND_UP(parent_rate * 2, div + 2);
+}
+
+static u8 emc_get_parent(struct clk_hw *hw)
+{
+ struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+
+ return readl_relaxed(emc->ioaddr) >> CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT;
+}
+
+static int emc_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+ u32 val, div;
+
+ val = readl_relaxed(emc->ioaddr);
+ div = val & CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+ val &= ~CLK_SOURCE_EMC_2X_CLK_SRC_MASK;
+ val |= index << CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT;
+
+ if (index == EMC_SRC_PLL_M && div == 0 && emc->want_low_jitter)
+ val |= USE_PLLM_UD;
+ else
+ val &= ~USE_PLLM_UD;
+
+ writel_relaxed(val, emc->ioaddr);
+
+ return 0;
+}
+
+static int emc_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct tegra_clk_emc *emc = to_tegra_clk_emc(hw);
+ unsigned int parent;
+ u32 val, div;
+
+ div = div_frac_get(rate, parent_rate, 8, 1, 0);
+
+ val = readl_relaxed(emc->ioaddr);
+ val &= ~CLK_SOURCE_EMC_2X_CLK_DIVISOR_MASK;
+ val |= div;
+
+ parent = val >> CLK_SOURCE_EMC_2X_CLK_SRC_SHIFT;
+
+ if (parent == EMC_SRC_PLL_M && div == 0 && emc->want_low_jitter)
+ val |= USE_PLLM_UD;
+ else
+ val &=
Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
On Thu, Apr 11, 2019 at 3:13 PM Benjamin Herrenschmidt wrote: > > Minor nit... I would have said "All readX() and writeX() accesses _from > the same CPU_ to the same peripheral... and then s/the CPU/this CPU. Maybe talk about "same thread" rather than "same cpu", with the understanding that scheduling/preemption has to include the appropriate cross-CPU IO barrier? Linus
Re: [PATCH v1 1/4] trace_events: Add trace_print_register to print register fields
On Thu, 11 Apr 2019 16:08:19 -0600
Raul E Rangel wrote:
> This is a hybrid method that combines the functionality of
> trace_print_flags_seq and trace_print_symbols_seq. It supports printing
> bit fields, enum fields, and numeric fields.
>
> Given the following register definition:
> * 0 - Enabled
> * 1 - Width, 0 = 1-bits, 1 = 4-bits
> * 2:3 - DMA, 0 = None, 1 = SDMA, 2 = ADMA, 3 = ADMA2
> * 4:7 - Timeout Counter
>
> The register fields could be defined as follows:
>
> const struct trace_print_field reg[] = {
> {1<<0, "ENABLED"},
> {
> .mask = 1<<1,
> .name = "WIDTH",
> .symbols = (const struct trace_print_flags[]) {
> {0, "1-BIT"},
> {1, "4-BIT"},
> {}
> }
> }, {
> .mask = 3<<2,
> .symbols = (const struct trace_print_flags[]) {
> {0, "NONE"},
> {1, "SDMA"},
> {2, "ADMA"},
> {3, "ADMA2"},
> {}
> }
> },
> {0xF<<4, "TIMEOUT"}
> }
>
> This would print out the following given value 0xAB:
>
> ENABLED: 1 | WIDTH: 4-BIT | ADMA | TIMEOUT: 0xA
>
Note the rational for the __print_symbolic and __print_flags is that
they show how to translate into something that perf and trace-cmd can
read from userspace.
How does perf or trace-cmd parse this? To add something like this, you
need them to have the same output as what is displayed by the trace
file otherwise NAK.
-- Steve
> See https://pastebin.com/x73d5cvL for this in action.
>
> Signed-off-by: Raul E Rangel
> ---
>
> include/linux/trace_events.h| 4 ++
> include/linux/tracepoint-defs.h | 6 ++
> include/trace/trace_events.h| 9 +++
> kernel/trace/trace_output.c | 121
> 4 files changed, 140 insertions(+)
>
> diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
> index 8a62731673f7..3c44909ce8b3 100644
> --- a/include/linux/trace_events.h
> +++ b/include/linux/trace_events.h
> @@ -23,6 +23,10 @@ const char *trace_print_flags_seq(struct trace_seq *p,
> const char *delim,
> const char *trace_print_symbols_seq(struct trace_seq *p, unsigned long val,
> const struct trace_print_flags
> *symbol_array);
>
> +const char *trace_print_register(struct trace_seq *p,
> + const struct trace_print_field fields[],
> + unsigned long val, unsigned long mask);
> +
> #if BITS_PER_LONG == 32
> const char *trace_print_flags_seq_u64(struct trace_seq *p, const char *delim,
> unsigned long long flags,
> diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
> index 49ba9cde7e4b..c3dc27c192f4 100644
> --- a/include/linux/tracepoint-defs.h
> +++ b/include/linux/tracepoint-defs.h
> @@ -16,6 +16,12 @@ struct trace_print_flags {
> const char *name;
> };
>
> +struct trace_print_field {
> + unsigned long mask;
> + const char *name;
> + const struct trace_print_flags *symbols;
> +};
> +
> struct trace_print_flags_u64 {
> unsigned long long mask;
> const char *name;
> diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
> index 4ecdfe2e3580..6adc32fcb1c3 100644
> --- a/include/trace/trace_events.h
> +++ b/include/trace/trace_events.h
> @@ -300,6 +300,14 @@ TRACE_MAKE_SYSTEM_STR();
> trace_print_symbols_seq(p, value, symbols); \
> })
>
> +#undef __print_register
> +#define __print_register(value, mask, field_array...)
> \
> + ({ \
> + static const struct trace_print_field fields[] =\
> + { field_array, {} };\
> + trace_print_register(p, value, mask, fields); \
> + })
> +
> #undef __print_flags_u64
> #undef __print_symbolic_u64
> #if BITS_PER_LONG == 32
> @@ -744,6 +752,7 @@ static inline void ftrace_test_probe_##call(void)
> \
>
> #undef __print_flags
> #undef __print_symbolic
> +#undef __print_register
> #undef __print_hex
> #undef __print_hex_str
> #undef __get_dynamic_array
> diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> index 54373d93e251..cd5727ad54c3 100644
> --- a/kernel/trace/trace_output.c
> +++ b/kernel/trace/trace_output.c
> @@ -124,6 +124,127 @@ trace_print_symbols_seq(struct trace_seq *p, unsigned
> long val,
> }
> EXPORT_SYMBOL(trace_print_symbols_seq);
>
> +/**
> + * trace_print_register - Prints all the fields of a register.
> + *
> + * This is a hybrid method that combines the functionality of
> + * trace_print_flags_seq and trace_print_symbols_seq. It supports printing
> + * bit fields, enum fields, and numeric fields.
> + *
> + * Given the following register definition:
> + * * 0 - Enabled
> + * * 1 - Width, 0 = 1-bits, 1
I have an important discussion with you.
[PATCH v1] PM / devfreq: Introduce driver for NVIDIA Tegra20
Add devfreq driver for NVIDIA Tegra20 SoC's. The driver periodically
reads out Memory Controller counters and adjusts memory frequency based
on the memory clients activity.
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS | 8 ++
drivers/devfreq/Kconfig | 10 ++
drivers/devfreq/Makefile | 1 +
drivers/devfreq/tegra20-devfreq.c | 177 ++
4 files changed, 196 insertions(+)
create mode 100644 drivers/devfreq/tegra20-devfreq.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 80b59db1b6e4..91f475ec4545 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10056,6 +10056,14 @@ F: include/linux/memblock.h
F: mm/memblock.c
F: Documentation/core-api/boot-time-mm.rst
+MEMORY FREQUENCY SCALING DRIVER FOR NVIDIA TEGRA20
+M: Dmitry Osipenko
+L: linux...@vger.kernel.org
+L: linux-te...@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git
+S: Maintained
+F: drivers/devfreq/tegra20-devfreq.c
+
MEMORY MANAGEMENT
L: linux...@kvack.org
W: http://www.linux-mm.org
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 6bae9688a52b..c2a1f791ca86 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -101,6 +101,16 @@ config ARM_TEGRA_DEVFREQ
It reads ACTMON counters of memory controllers and adjusts the
operating frequencies and voltages with OPP support.
+config ARM_TEGRA20_DEVFREQ
+ tristate "Tegra20 DEVFREQ Driver"
+ depends on TEGRA_MC && TEGRA20_EMC
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select PM_OPP
+ help
+ This adds the DEVFREQ driver for the Tegra20 family of SoCs.
+ It reads Memory Controller counters and adjusts the operating
+ frequencies and voltages with OPP support.
+
config ARM_RK3399_DMC_DEVFREQ
tristate "ARM RK3399 DMC DEVFREQ Driver"
depends on ARCH_ROCKCHIP
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 32b8d4d3f12c..6fcc5596b8b7 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
+obj-$(CONFIG_ARM_TEGRA20_DEVFREQ) += tegra20-devfreq.o
# DEVFREQ Event Drivers
obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/tegra20-devfreq.c
b/drivers/devfreq/tegra20-devfreq.c
new file mode 100644
index ..18c9aad7a9d7
--- /dev/null
+++ b/drivers/devfreq/tegra20-devfreq.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NVIDIA Tegra20 devfreq driver
+ *
+ * Author: Dmitry Osipenko
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "governor.h"
+
+#define MC_STAT_CONTROL0x90
+#define MC_STAT_EMC_CLOCK_LIMIT0xa0
+#define MC_STAT_EMC_CLOCKS 0xa4
+#define MC_STAT_EMC_CONTROL0xa8
+#define MC_STAT_EMC_COUNT 0xb8
+
+#define EMC_GATHER_CLEAR (1 << 8)
+#define EMC_GATHER_ENABLE (3 << 8)
+
+struct tegra_devfreq {
+ struct devfreq *devfreq;
+ struct clk *clk;
+ void __iomem *regs;
+};
+
+static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
+ u32 flags)
+{
+ struct tegra_devfreq *tegra = dev_get_drvdata(dev);
+ struct dev_pm_opp *opp;
+ unsigned long rate;
+ int err;
+
+ opp = devfreq_recommended_opp(dev, freq, flags);
+ if (IS_ERR(opp))
+ return PTR_ERR(opp);
+
+ rate = dev_pm_opp_get_freq(opp);
+ dev_pm_opp_put(opp);
+
+ err = clk_set_min_rate(tegra->clk, rate);
+ if (err)
+ return err;
+
+ err = clk_set_rate(tegra->clk, 0);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int tegra_devfreq_get_dev_status(struct device *dev,
+ struct devfreq_dev_status *stat)
+{
+ struct tegra_devfreq *tegra = dev_get_drvdata(dev);
+
+ stat->busy_time = readl_relaxed(tegra->regs + MC_STAT_EMC_COUNT);
+ stat->total_time = readl_relaxed(tegra->regs + MC_STAT_EMC_CLOCKS) / 8;
+ stat->current_frequency = clk_get_rate(tegra->clk);
+
+ writel_relaxed(EMC_GATHER_CLEAR, tegra->regs + MC_STAT_CONTROL);
+ writel_relaxed(EMC_GATHER_ENABLE, tegra->regs + MC_STAT_CONTROL);
+
+ return 0;
+}
+
+static struct devfreq_dev_profile tegra_devfreq_profile = {
+ .polling_ms = 500,
+ .target = tegra_devfreq_target,
+ .get_dev_status = tegra_devfreq_get_dev_status,
+};
+
+static struct tegra_mc
Inquiry 11/Apr/2019
Hi,friend, This is Daniel Murray and i am from Sinara Group Co.,LTD in Russia. We are glad to know about your company from the web and we are interested in your products. Could you kindly send us your Latest catalog and price list for our trial order. Thanks and Best Regards, Daniel Murray Purchasing Manager Sinara Group Co.,LTD
Re: [PATCH v2] init: Do not select DEBUG_KERNEL by default
On Thu, Apr 11, 2019 at 06:27:04PM -0400, Sinan Kaya wrote:
> On 4/11/2019 6:21 PM, Kees Cook wrote:
> > > Proposed alternative plan: let's add a new symbol, something like
> > > DEBUG_MISC ("Miscellaneous debug code that should be under a more
> > > specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
> > > "default DEBUG_KERNEL" but allow itself to be turned off, and then
> > > mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
> > > "#ifdef CONFIG_DEBUG_MISC".
> > >
> > > Does that sound like an appropriately rapid solution for this bug?
> > Sure, that sounds fine to me. Sinan can you take care of that for v4?
>
> Sure, let me work on this.
Thank you both! I really appreciate that.
Re: [PATCH v3] platform/chrome: wilco_ec: Add h1_gpio status to debugfs
Thanks for the comments Enric! I'll resend in a day or two.
On Thu, Apr 11, 2019 at 3:43 PM Enric Balletbo Serra
wrote:
>
> Hi Nick,
>
> Some comments below ...
>
> Missatge de Nick Crews del dia dj., 11 d’abr.
> 2019 a les 0:09:
> >
> > As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
> > tests, we need to ensure that the H1 chip is properly setting
> > some GPIO lines. The h1_gpio attribute exposes the state
> > of the lines:
> > - ENTRY_TO_FACT_MODE in BIT(0)
> > - SPI_CHROME_SEL in BIT(1)
> >
> > There are two reasons that I am exposing this in debugfs,
> > and not as a GPIO:
> > 1. This is only useful for testing, so end users shouldn't ever
> > care about this. In fact, if it passes the tests, then the value of
> > h1_gpio will always be 2, so it would be really uninteresting for users.
> > 2. This GPIO is not connected to, controlled by, or really even related
> > to the AP. The GPIO runs between the EC and the H1 security chip.
> >
> > Changes in v3:
> > - Fix documentation to correspond with formatting change in v2.
> > Changes in v2:
> > - Zero out the unused fields in the request.
> > - Format result as "%02x\n" instead of as a decimal.
>
> I don't really mind, but wouldn't be more clear prefix with 0x (0x%02x)?
I figured this would be easier for a program to parse, but you're right it
would be more clear. I can change it.
>
> >
> > Signed-off-by: Nick Crews
> > ---
> > drivers/platform/chrome/wilco_ec/debugfs.c | 64 +-
>
> ABI documentation missing.
Whoops, will do. The Documentation is out of date with the raw
attribute as well,
so I'll fix that too.
>
> > 1 file changed, 63 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c
> > b/drivers/platform/chrome/wilco_ec/debugfs.c
> > index 17c4c9068aaf..1b93243c8954 100644
> > --- a/drivers/platform/chrome/wilco_ec/debugfs.c
> > +++ b/drivers/platform/chrome/wilco_ec/debugfs.c
> > @@ -4,7 +4,7 @@
> > *
> > * Copyright 2019 Google LLC
> > *
> > - * There is only one attribute used for debugging, called raw.
> > + * The raw attribute is very useful for EC debugging.
> > * You can write a hexadecimal sentence to raw, and that series of bytes
> > * will be sent to the EC. Then, you can read the bytes of response
> > * by reading from raw.
> > @@ -30,6 +30,16 @@
> > * Note that the first 32 bytes of the received MBOX[] will be printed,
> > * even if some of the data is junk. It is up to you to know how many of
> > * the first bytes of data are the actual response.
> > + *
> > + * There is also another debugfs attribute, called h1_gpio.
> > + * As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
> > + * tests, we need to ensure that the H1 chip is properly setting
> > + * some GPIO lines. The h1_gpio attribute exposes the state
> > + * of the lines:
> > + * - ENTRY_TO_FACT_MODE in BIT(0)
> > + * - SPI_CHROME_SEL in BIT(1)
> > +
> > + * Output will formatted with "%02x\n".
> > */
> >
> > #include
> > @@ -189,6 +199,56 @@ static const struct file_operations fops_raw = {
> > .llseek = no_llseek,
> > };
> >
> > +#define CMD_KB_CHROME 0x88
> > +#define SUB_CMD_H1_GPIO0x0A
> > +
> > +struct h1_gpio_status_request {
> > + u8 cmd; /* Always CMD_KB_CHROME */
> > + u8 reserved;
> > + u8 sub_cmd; /* Always SUB_CMD_H1_GPIO */
> > +} __packed;
> > +
> > +struct hi_gpio_status_response {
> > + u8 status; /* 0 if allowed */
> > + u8 val; /* BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL
> > */
> > +} __packed;
> > +
> > +static ssize_t h1_gpio_read(struct file *file, char __user *user_buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + struct h1_gpio_status_request rq;
> > + struct hi_gpio_status_response rs;
> > + struct wilco_ec_message msg;
> > + char buf[4];
> > + int ret;
> > +
> > + memset(, 0, sizeof(rq));
> > + rq.cmd = CMD_KB_CHROME;
> > + rq.sub_cmd = SUB_CMD_H1_GPIO;
> > +
> > + memset(, 0, sizeof(msg));
> > + msg.type = WILCO_EC_MSG_LEGACY;
> > + msg.request_data =
> > + msg.request_size = sizeof(rq);
> > + msg.response_data =
> > + msg.response_size = sizeof(rs);
> > + ret = wilco_ec_mailbox(debug_info->ec, );
> > + if (ret < 0)
> > + return ret;
> > + if (rs.status)
> > + return -EIO;
> > +
> > + sprintf(buf, "%02x\n", rs.val);
> > +
> > + return simple_read_from_buffer(user_buf, count, ppos, buf,
> > sizeof(buf));
> > +}
> > +
> > +static const struct file_operations fops_h1_gpio = {
> > + .owner = THIS_MODULE,
> > + .read = h1_gpio_read,
> > + .llseek = no_llseek,
> > +};
> > +
>
> I think that I'd use the DEFINE_DEBUGFS_ATTRIBUTE here.
Will do.
>
> > /**
> > * wilco_ec_debugfs_probe() - Create the debugfs node
> > * @pdev: The platform device, probably
[PATCH v1 2/8] PM / devfreq: tegra: Replace readl-writel with relaxed versions
There is no need to insert memory barrier on each readl/writel
invocation, hence use the relaxed versions.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
index ec4ff55f5eea..d749399f67ae 100644
--- a/drivers/devfreq/tegra-devfreq.c
+++ b/drivers/devfreq/tegra-devfreq.c
@@ -191,23 +191,23 @@ static struct tegra_actmon_emc_ratio actmon_emc_ratios[]
= {
static u32 actmon_readl(struct tegra_devfreq *tegra, u32 offset)
{
- return readl(tegra->regs + offset);
+ return readl_relaxed(tegra->regs + offset);
}
static void actmon_writel(struct tegra_devfreq *tegra, u32 val, u32 offset)
{
- writel(val, tegra->regs + offset);
+ writel_relaxed(val, tegra->regs + offset);
}
static u32 device_readl(struct tegra_devfreq_device *dev, u32 offset)
{
- return readl(dev->regs + offset);
+ return readl_relaxed(dev->regs + offset);
}
static void device_writel(struct tegra_devfreq_device *dev, u32 val,
u32 offset)
{
- writel(val, dev->regs + offset);
+ writel_relaxed(val, dev->regs + offset);
}
static unsigned long do_percent(unsigned long val, unsigned int pct)
--
2.21.0
[PATCH v1 5/8] PM / devfreq: tegra: Don't set EMC clock rate to maximum on probe
There is no real benefit from doing so, hence let's drop that rate setting
for consistency.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
index ed67d7a48176..aefd4874b5a2 100644
--- a/drivers/devfreq/tegra-devfreq.c
+++ b/drivers/devfreq/tegra-devfreq.c
@@ -648,8 +648,6 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
return PTR_ERR(tegra->emc_clock);
}
- clk_set_rate(tegra->emc_clock, ULONG_MAX);
-
tegra->rate_change_nb.notifier_call = tegra_actmon_rate_notify_cb;
err = clk_notifier_register(tegra->emc_clock, >rate_change_nb);
if (err) {
--
2.21.0
[PATCH v1] ARM: dts: tegra30: Add ACTMON node
Add ACTMON node to the Tegra30's device-tree.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra30.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index d2b553f76719..e074258d4518 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -370,6 +370,17 @@
reg = <0x6000c000 0x150>; /* AHB Arbitration + Gizmo Controller
*/
};
+ actmon@6000c800 {
+ compatible = "nvidia,tegra30-actmon";
+ reg = <0x6000c800 0x400>;
+ interrupts = ;
+ clocks = <_car TEGRA30_CLK_ACTMON>,
+<_car TEGRA30_CLK_EMC>;
+ clock-names = "actmon", "emc";
+ resets = <_car TEGRA30_CLK_ACTMON>;
+ reset-names = "actmon";
+ };
+
gpio: gpio@6000d000 {
compatible = "nvidia,tegra30-gpio";
reg = <0x6000d000 0x1000>;
--
2.21.0
