* [PATCH 2/2] KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity
From: Marc Zyngier @ 2019-08-23 16:35 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Mark Rutland, Andrew Jones, kvm, Suzuki K Poulose, Andre Przywara,
kvmarm, Julien Grall, James Morse, linux-arm-kernel, Dave Martin,
Julien Thierry
In-Reply-To: <20190823163516.179768-1-maz@kernel.org>
From: Andre Przywara <andre.przywara@arm.com>
At the moment we initialise the target *mask* of a virtual IRQ to the
VCPU it belongs to, even though this mask is only defined for GICv2 and
quickly runs out of bits for many GICv3 guests.
This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
------
[ 5659.462377] UBSAN: Undefined behaviour in virt/kvm/arm/vgic/vgic-init.c:223:21
[ 5659.471689] shift exponent 32 is too large for 32-bit type 'unsigned int'
------
Also for GICv3 guests the reporting of TARGET in the "vgic-state" debugfs
dump is wrong, due to this very same problem.
Because there is no requirement to create the VGIC device before the
VCPUs (and QEMU actually does it the other way round), we can't safely
initialise mpidr or targets in kvm_vgic_vcpu_init(). But since we touch
every private IRQ for each VCPU anyway later (in vgic_init()), we can
just move the initialisation of those fields into there, where we
definitely know the VGIC type.
On the way make sure we really have either a VGICv2 or a VGICv3 device,
since the existing code is just checking for "VGICv3 or not", silently
ignoring the uninitialised case.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Dave Martin <dave.martin@arm.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
virt/kvm/arm/vgic/vgic-init.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index bdbc297d06fb..e621b5d45b27 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -8,6 +8,7 @@
#include <linux/cpu.h>
#include <linux/kvm_host.h>
#include <kvm/arm_vgic.h>
+#include <asm/kvm_emulate.h>
#include <asm/kvm_mmu.h>
#include "vgic.h"
@@ -164,12 +165,18 @@ static int kvm_vgic_dist_init(struct kvm *kvm, unsigned int nr_spis)
irq->vcpu = NULL;
irq->target_vcpu = vcpu0;
kref_init(&irq->refcount);
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V2) {
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->targets = 0;
irq->group = 0;
- } else {
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->mpidr = 0;
irq->group = 1;
+ break;
+ default:
+ kfree(dist->spis);
+ return -EINVAL;
}
}
return 0;
@@ -209,7 +216,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
irq->intid = i;
irq->vcpu = NULL;
irq->target_vcpu = vcpu;
- irq->targets = 1U << vcpu->vcpu_id;
kref_init(&irq->refcount);
if (vgic_irq_is_sgi(i)) {
/* SGIs */
@@ -219,11 +225,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
/* PPIs */
irq->config = VGIC_CONFIG_LEVEL;
}
-
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
- irq->group = 1;
- else
- irq->group = 0;
}
if (!irqchip_in_kernel(vcpu->kvm))
@@ -286,10 +287,19 @@ int vgic_init(struct kvm *kvm)
for (i = 0; i < VGIC_NR_PRIVATE_IRQS; i++) {
struct vgic_irq *irq = &vgic_cpu->private_irqs[i];
- if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
+ switch (dist->vgic_model) {
+ case KVM_DEV_TYPE_ARM_VGIC_V3:
irq->group = 1;
- else
+ irq->mpidr = kvm_vcpu_get_mpidr_aff(vcpu);
+ break;
+ case KVM_DEV_TYPE_ARM_VGIC_V2:
irq->group = 0;
+ irq->targets = 1U << idx;
+ break;
+ default:
+ ret = -EINVAL;
+ goto out;
+ }
}
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] KVM: arm/arm64: Only skip MMIO insn once
From: Marc Zyngier @ 2019-08-23 16:35 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Mark Rutland, Andrew Jones, kvm, Suzuki K Poulose, Andre Przywara,
kvmarm, Julien Grall, James Morse, linux-arm-kernel, Dave Martin,
Julien Thierry
In-Reply-To: <20190823163516.179768-1-maz@kernel.org>
From: Andrew Jones <drjones@redhat.com>
If after an MMIO exit to userspace a VCPU is immediately run with an
immediate_exit request, such as when a signal is delivered or an MMIO
emulation completion is needed, then the VCPU completes the MMIO
emulation and immediately returns to userspace. As the exit_reason
does not get changed from KVM_EXIT_MMIO in these cases we have to
be careful not to complete the MMIO emulation again, when the VCPU is
eventually run again, because the emulation does an instruction skip
(and doing too many skips would be a waste of guest code :-) We need
to use additional VCPU state to track if the emulation is complete.
As luck would have it, we already have 'mmio_needed', which even
appears to be used in this way by other architectures already.
Fixes: 0d640732dbeb ("arm64: KVM: Skip MMIO insn after emulation")
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
virt/kvm/arm/mmio.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c
index a8a6a0c883f1..6af5c91337f2 100644
--- a/virt/kvm/arm/mmio.c
+++ b/virt/kvm/arm/mmio.c
@@ -86,6 +86,12 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run)
unsigned int len;
int mask;
+ /* Detect an already handled MMIO return */
+ if (unlikely(!vcpu->mmio_needed))
+ return 0;
+
+ vcpu->mmio_needed = 0;
+
if (!run->mmio.is_write) {
len = run->mmio.len;
if (len > sizeof(unsigned long))
@@ -188,6 +194,7 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
run->mmio.is_write = is_write;
run->mmio.phys_addr = fault_ipa;
run->mmio.len = len;
+ vcpu->mmio_needed = 1;
if (!ret) {
/* We handled the access successfully in the kernel. */
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL] KVM/arm updates for 5.3-rc6
From: Marc Zyngier @ 2019-08-23 16:35 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Mark Rutland, Andrew Jones, kvm, Suzuki K Poulose, Andre Przywara,
kvmarm, Julien Grall, James Morse, linux-arm-kernel, Dave Martin,
Julien Thierry
Paolo, Radim,
One (hopefully last) set of fixes for KVM/arm for 5.3: an embarassing
MMIO emulation regression, and a UBSAN splat. Oh well...
Please pull,
M.
The following changes since commit 16e604a437c89751dc626c9e90cf88ba93c5be64:
KVM: arm/arm64: vgic: Reevaluate level sensitive interrupts on enable (2019-08-09 08:07:26 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.3-3
for you to fetch changes up to 2e16f3e926ed48373c98edea85c6ad0ef69425d1:
KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity (2019-08-23 17:23:01 +0100)
----------------------------------------------------------------
KVM/arm fixes for 5.3, take #3
- Don't overskip instructions on MMIO emulation
- Fix UBSAN splat when initializing PPI priorities
----------------------------------------------------------------
Andre Przywara (1):
KVM: arm/arm64: VGIC: Properly initialise private IRQ affinity
Andrew Jones (1):
KVM: arm/arm64: Only skip MMIO insn once
virt/kvm/arm/mmio.c | 7 +++++++
virt/kvm/arm/vgic/vgic-init.c | 30 ++++++++++++++++++++----------
2 files changed, 27 insertions(+), 10 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 3/3] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Dave Martin @ 2019-08-23 16:32 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, linux-mm, Andrew Morton,
Vincenzo Frascino, Will Deacon, Dave Hansen, linux-arm-kernel
In-Reply-To: <20190823161912.GJ29387@arrakis.emea.arm.com>
On Fri, Aug 23, 2019 at 05:19:13PM +0100, Catalin Marinas wrote:
> On Thu, Aug 22, 2019 at 05:37:23PM +0100, Dave P Martin wrote:
> > On Thu, Aug 22, 2019 at 04:55:32PM +0100, Catalin Marinas wrote:
> > > On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
[...]
> > > > sigaltstack() is interesting, since we don't support tagged stacks.
> > >
> > > We should support tagged SP with the new ABI as they'll be required for
> > > MTE. sigaltstack() and clone() are the two syscalls that come to mind
> > > here.
> > >
> > > > Do we keep the ss_sp tag in the kernel, but squash it when delivering
> > > > a signal to the alternate stack?
> > >
> > > We don't seem to be doing any untagging, so we just just use whatever
> > > the caller asked for. We may need a small test to confirm.
> >
> > If we want to support tagged SP, then I guess we shouldn't be squashing
> > the tag anywhere. A test for that would be sensible to have.
>
> I hacked the sas.c kselftest to use a tagged stack and works fine, the
> SP register has a tagged address on the signal handler.
Cool...
[...]
> > > > There is no foolproof rule, unless we can rewrite history...
> > >
> > > I would expect the norm to be the preservation of tags with a few
> > > exceptions. The only ones I think where we won't preserve the tags are
> > > mmap, mremap, brk (apart from the signal stuff already mentioned in the
> > > current tagged-pointers.rst doc).
> > >
> > > So I can remove this paragraph altogether and add a note in part 3 of
> > > the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
> > > the tag information.
> >
> > Deleting text is always a good idea ;)
>
> I'm going this route ;).
[reply deleted]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 2/3] fdt: add support for rng-seed
From: Will Deacon @ 2019-08-23 16:31 UTC (permalink / raw)
To: Theodore Y. Ts'o, Hsin-Yi Wang, linux-arm-kernel,
Russell King, Catalin Marinas, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Paul E . McKenney, Kate Stewart,
David S . Miller, Viresh Kumar, Marek Szyprowski, Arnd Bergmann,
Marc Zyngier, Julien Thierry, Greg Kroah-Hartman, Wei Li,
Anders Roxell, Rob Herring, Aaro Koskinen, Daniel Thompson,
Tim Chen, Rik van Riel, Waiman Long, Marcelo Tosatti,
Peter Zijlstra, Armijn Hemel, Grzegorz Halat, Len Brown,
Shaokun Zhang, Mike Rapoport, Kees Cook, Stephen Boyd,
Guenter Roeck, Andrew Morton, Mathieu Desnoyers, Alexey Dobriyan,
Yury Norov, Josh Poimboeuf, Jiri Kosina, Mukesh Ojha,
linux-kernel
In-Reply-To: <20190823160612.GJ8130@mit.edu>
On Fri, Aug 23, 2019 at 12:06:12PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Aug 23, 2019 at 04:41:59PM +0100, Will Deacon wrote:
> >
> > Given that these aren't functional changes, I've kept Ted's ack from v9
> > and I'll queue these via arm64 assuming they pass testing.
> >
> > Ted -- please shout if you're not happy about that, and I'll drop the
> > series.
>
> That's fine, thanks. I'm thinking about making some changes to
> add_hwgenerator_randomness(), but it's not going to be in the next
> merge window, and it's more important that we get the interfaces (the
> Kconfig options and add_bootloader_randomness() function prototype)
> right for ARM.
Well, on the off-chance that you do need it, I've stuck the series on its
own branch anyway so you can pull in elsewhere if necessary:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/rng
> Now to shanghai some volunteers to get this functionality working for
> x86 (at least for the UEFI and NERF bootloaders). :-)
Hehe, good luck!
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 3/3] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Catalin Marinas @ 2019-08-23 16:19 UTC (permalink / raw)
To: Dave Martin
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, linux-mm, Andrew Morton,
Vincenzo Frascino, Will Deacon, Dave Hansen, linux-arm-kernel
In-Reply-To: <20190822163723.GF27757@arm.com>
On Thu, Aug 22, 2019 at 05:37:23PM +0100, Dave P Martin wrote:
> On Thu, Aug 22, 2019 at 04:55:32PM +0100, Catalin Marinas wrote:
> > On Wed, Aug 21, 2019 at 07:46:51PM +0100, Dave P Martin wrote:
> > > On Wed, Aug 21, 2019 at 06:33:53PM +0100, Will Deacon wrote:
> > > > On Wed, Aug 21, 2019 at 05:47:30PM +0100, Catalin Marinas wrote:
> > > > > @@ -59,6 +63,11 @@ be preserved.
> > > > > The architecture prevents the use of a tagged PC, so the upper byte will
> > > > > be set to a sign-extension of bit 55 on exception return.
> > > > >
> > > > > +This behaviour is maintained when the AArch64 Tagged Address ABI is
> > > > > +enabled. In addition, with the exceptions above, the kernel will
> > > > > +preserve any non-zero tags passed by the user via syscalls and stored in
> > > > > +kernel data structures (e.g. ``set_robust_list()``, ``sigaltstack()``).
> > >
> > > sigaltstack() is interesting, since we don't support tagged stacks.
> >
> > We should support tagged SP with the new ABI as they'll be required for
> > MTE. sigaltstack() and clone() are the two syscalls that come to mind
> > here.
> >
> > > Do we keep the ss_sp tag in the kernel, but squash it when delivering
> > > a signal to the alternate stack?
> >
> > We don't seem to be doing any untagging, so we just just use whatever
> > the caller asked for. We may need a small test to confirm.
>
> If we want to support tagged SP, then I guess we shouldn't be squashing
> the tag anywhere. A test for that would be sensible to have.
I hacked the sas.c kselftest to use a tagged stack and works fine, the
SP register has a tagged address on the signal handler.
> > > > Hmm. I can see the need to provide this guarantee for things like
> > > > set_robust_list(), but the problem is that the statement above is too broad
> > > > and isn't strictly true: for example, mmap() doesn't propagate the tag of
> > > > its address parameter into the VMA.
> > > >
> > > > So I think we need to nail this down a bit more, but I'm having a really
> > > > hard time coming up with some wording :(
> > >
> > > Time for some creative vagueness?
> > >
> > > We can write a statement of our overall intent, along with examples of
> > > a few cases where the tag should and should not be expected to emerge
> > > intact.
> > >
> > > There is no foolproof rule, unless we can rewrite history...
> >
> > I would expect the norm to be the preservation of tags with a few
> > exceptions. The only ones I think where we won't preserve the tags are
> > mmap, mremap, brk (apart from the signal stuff already mentioned in the
> > current tagged-pointers.rst doc).
> >
> > So I can remove this paragraph altogether and add a note in part 3 of
> > the tagged-address-abi.rst document that mmap/mremap/brk do not preserve
> > the tag information.
>
> Deleting text is always a good idea ;)
I'm going this route ;).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ethernet: Delete unnecessary checks before the macro call “dev_kfree_skb”
From: Scott Branden @ 2019-08-23 16:10 UTC (permalink / raw)
To: Christophe JAILLET, Markus Elfring, netdev, linux-arm-kernel,
linux-stm32, intel-wired-lan, bcm-kernel-feedback-list,
UNGLinuxDriver, Alexandre Torgue, Alexios Zavras, Allison Randal,
Bryan Whitehead, Claudiu Manoil, David S. Miller, Doug Berger,
Douglas Miller, Florian Fainelli, Giuseppe Cavallaro,
Greg Kroah-Hartman, Jeff Kirsher, Jilayne Lovejoy, Jonathan Lemon,
Jose Abreu, Kate Stewart
Cc: kernel-janitors, LKML
In-Reply-To: <4ab7f2a5-f472-f462-9d4c-7c8d5237c44e@wanadoo.fr>
On 2019-08-23 7:08 a.m., Christophe JAILLET wrote:
> Hi,
>
> in this patch, there is one piece that looked better before. (see below)
>
> Removing the 'if (skb)' is fine, but concatening everything in one
> statement just to save 2 variables and a few LOC is of no use, IMHO,
> and the code is less readable.
Agreed.
>
> just my 2c.
>
>
> CJ
>
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index d3a0b614dbfa..8b19ddcdafaa 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -2515,19 +2515,14 @@ static int bcmgenet_dma_teardown(struct
> bcmgenet_priv *priv)
> static void bcmgenet_fini_dma(struct bcmgenet_priv *priv)
> {
> struct netdev_queue *txq;
> - struct sk_buff *skb;
> - struct enet_cb *cb;
> int i;
>
> bcmgenet_fini_rx_napi(priv);
> bcmgenet_fini_tx_napi(priv);
>
> - for (i = 0; i < priv->num_tx_bds; i++) {
> - cb = priv->tx_cbs + i;
> - skb = bcmgenet_free_tx_cb(&priv->pdev->dev, cb);
> - if (skb)
> - dev_kfree_skb(skb);
> - }
> + for (i = 0; i < priv->num_tx_bds; i++)
> + dev_kfree_skb(bcmgenet_free_tx_cb(&priv->pdev->dev,
> + priv->tx_cbs + i));
>
> for (i = 0; i < priv->hw_params->tx_queues; i++) {
> txq = netdev_get_tx_queue(priv->dev, priv->tx_rings[i].queue);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] arm64: meson-sm1: add support for DVFS
From: Jerome Brunet @ 2019-08-23 16:10 UTC (permalink / raw)
To: Neil Armstrong, khilman
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190822142455.12506-1-narmstrong@baylibre.com>
On Thu 22 Aug 2019 at 16:24, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Following DVFS support for the Amlogic G12A and G12B SoCs, this serie
> enables DVFS on the SM1 SoC for the SEI610 board.
>
> The SM1 Clock structure is slightly different because of the Cortex-A55
> core used, having the capability for each core of a same cluster to run
> at a different frequency thanks to the newly used DynamIQ Shared Unit.
>
> This is why SM1 has a CPU clock tree for each core and for DynamIQ Shared Unit,
> with a bypass mux to use the CPU0 instead of the dedicated trees.
>
> The DSU uses a new GP1 PLL as default clock, thus GP1 is added as read-only.
>
> The SM1 OPPs has been taken from the Amlogic Vendor tree, and unlike
> G12A only a single version of the SoC is available.
>
> Dependencies:
> - patch 6 is based on the "arm64: meson: add support for SM1 Power Domains" serie,
> but is not a strong dependency, it will work without
>
> Neil Armstrong (6):
> dt-bindings: clk: meson: add sm1 periph clock controller bindings
> clk: meson: g12a: add support for SM1 GP1 PLL
> clk: meson: g12a: add support for SM1 DynamIQ Shared Unit clock
> clk: meson: g12a: add support for SM1 CPU 1, 2 & 3 clocks
> clk: meson: g12a: expose SM1 CPU 1, 2 & 3 clocks
> arm64: dts: meson-sm1-sei610: enable DVFS
>
> .../bindings/clock/amlogic,gxbb-clkc.txt | 1 +
> .../boot/dts/amlogic/meson-sm1-sei610.dts | 59 +-
> arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 69 +++
> drivers/clk/meson/g12a.c | 544 ++++++++++++++++++
> drivers/clk/meson/g12a.h | 26 +-
> include/dt-bindings/clock/g12a-clkc.h | 3 +
> 6 files changed, 697 insertions(+), 5 deletions(-)
Series looks good to me overall.
Just drop patch 5 and expose every ID necessary directly with patch 1
(same goes for the GP1 clock ID)
>
> --
> 2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 2/3] fdt: add support for rng-seed
From: Theodore Y. Ts'o @ 2019-08-23 16:06 UTC (permalink / raw)
To: Will Deacon
Cc: Kate Stewart, Peter Zijlstra, Catalin Marinas, Mukesh Ojha,
Josh Poimboeuf, Grzegorz Halat, H . Peter Anvin, Guenter Roeck,
Marek Szyprowski, Rob Herring, Daniel Thompson, Anders Roxell,
Yury Norov, Marc Zyngier, Russell King, Aaro Koskinen,
Ingo Molnar, Viresh Kumar, Waiman Long, Paul E . McKenney, Wei Li,
Alexey Dobriyan, Julien Thierry, Len Brown, Kees Cook,
Arnd Bergmann, Rik van Riel, Stephen Boyd, Shaokun Zhang,
Mike Rapoport, Borislav Petkov, Hsin-Yi Wang, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, Marcelo Tosatti,
linux-kernel, Armijn Hemel, Jiri Kosina, Mathieu Desnoyers,
Andrew Morton, Tim Chen, David S . Miller
In-Reply-To: <20190823154158.wgcnxfzpcttpnhga@willie-the-truck>
On Fri, Aug 23, 2019 at 04:41:59PM +0100, Will Deacon wrote:
>
> Given that these aren't functional changes, I've kept Ted's ack from v9
> and I'll queue these via arm64 assuming they pass testing.
>
> Ted -- please shout if you're not happy about that, and I'll drop the
> series.
That's fine, thanks. I'm thinking about making some changes to
add_hwgenerator_randomness(), but it's not going to be in the next
merge window, and it's more important that we get the interfaces (the
Kconfig options and add_bootloader_randomness() function prototype)
right for ARM.
Now to shanghai some volunteers to get this functionality working for
x86 (at least for the UEFI and NERF bootloaders). :-)
Thanks!!
- Ted
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [stericsson:ab8500-gpadc 3/8] ab8500_fg.c:undefined reference to `iio_read_channel_processed'
From: kbuild test robot @ 2019-08-23 16:00 UTC (permalink / raw)
To: Linus Walleij; +Cc: kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/linusw/linux-stericsson.git ab8500-gpadc
head: b9fc9832627e121832ebbcb26426f700f4fde9db
commit: 2cd6e3713a7a4230127738dcb4255d8967c7aa8c [3/8] power: supply: ab8500_fg: convert to IIO ADC
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2cd6e3713a7a4230127738dcb4255d8967c7aa8c
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/power/supply/ab8500_charger.o: In function `ab8500_charger_usb_get_property':
ab8500_charger.c:(.text+0x2fc4): undefined reference to `iio_read_channel_processed'
ab8500_charger.c:(.text+0x30c4): undefined reference to `iio_read_channel_processed'
drivers/power/supply/ab8500_charger.o: In function `ab8500_charger_ac_get_property':
ab8500_charger.c:(.text+0x331c): undefined reference to `iio_read_channel_processed'
ab8500_charger.c:(.text+0x341c): undefined reference to `iio_read_channel_processed'
drivers/power/supply/ab8500_charger.o: In function `ab8500_charger_probe':
ab8500_charger.c:(.text+0x46cc): undefined reference to `devm_iio_channel_get'
ab8500_charger.c:(.text+0x471c): undefined reference to `devm_iio_channel_get'
ab8500_charger.c:(.text+0x4764): undefined reference to `devm_iio_channel_get'
ab8500_charger.c:(.text+0x47ac): undefined reference to `devm_iio_channel_get'
drivers/power/supply/ab8500_fg.o: In function `ab8500_fg_bat_voltage':
>> ab8500_fg.c:(.text+0x18ec): undefined reference to `iio_read_channel_processed'
drivers/power/supply/ab8500_fg.o: In function `ab8500_fg_probe':
>> ab8500_fg.c:(.text+0x257c): undefined reference to `devm_iio_channel_get'
drivers/power/supply/ab8500_btemp.o: In function `ab8500_btemp_get_batctrl_res':
ab8500_btemp.c:(.text+0xbf4): undefined reference to `iio_read_channel_processed'
drivers/power/supply/ab8500_btemp.o: In function `ab8500_btemp_probe':
ab8500_btemp.c:(.text+0xf0c): undefined reference to `devm_iio_channel_get'
ab8500_btemp.c:(.text+0xf5c): undefined reference to `devm_iio_channel_get'
drivers/power/supply/ab8500_btemp.o: In function `ab8500_btemp_periodic_work':
ab8500_btemp.c:(.text+0x1684): undefined reference to `iio_read_channel_processed'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 71382 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Frank Wunderlich @ 2019-08-23 15:53 UTC (permalink / raw)
To: linux-mediatek, Matthias Brugger, Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Mark Brown, Sean Wang,
Liam Girdwood, linux-kernel, Richard Fontana, Rob Herring,
Kate Stewart, René van Dorst, Thomas Gleixner, Eddie Huang,
Lee Jones, linux-arm-kernel, linux-rtc
In-Reply-To: <e8a918ab-3e7a-b487-db77-df28d56518ce@gmail.com>
Seems chip-id in 5.3 is read here
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/mt6397-core.c?h=v5.3-rc5#n282
It is before platform_get_irq which may call irq-init changed in the problematic commit.
I will add a dev_info here in next-code to see value of id
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCHv4 1/1] drivers/amba: add reset control to amba bus probe
From: Dinh Nguyen @ 2019-08-23 15:42 UTC (permalink / raw)
To: Linus Walleij, Philipp Zabel
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Daniel Thompson, Tony Luck, Manivannan Sadhasivam, Kees Cook,
Rob Herring, Anton Vorontsov, Russell King,
linux-kernel@vger.kernel.org, Colin Cross, Frank Rowand,
Linux ARM
In-Reply-To: <CACRpkdasbXuqUkO3NjMGBU_ePEBT23BS1eP-bigB0_g494LgvQ@mail.gmail.com>
On 8/23/19 4:19 AM, Linus Walleij wrote:
> On Tue, Aug 20, 2019 at 4:58 PM Dinh Nguyen <dinguyen@kernel.org> wrote:
>
>> @@ -401,6 +402,26 @@ static int amba_device_try_add(struct amba_device *dev, struct resource *parent)
>> ret = amba_get_enable_pclk(dev);
>> if (ret == 0) {
>> u32 pid, cid;
>> + int count;
>> + struct reset_control *rstc;
>> +
>> + /*
>> + * Find reset control(s) of the amba bus and de-assert them.
>> + */
>> + count = reset_control_get_count(&dev->dev);
>> + while (count > 0) {
>> + rstc = of_reset_control_get_shared_by_index(dev->dev.of_node, count - 1);
>> + if (IS_ERR(rstc)) {
>> + if (PTR_ERR(rstc) == -EPROBE_DEFER)
>> + ret = -EPROBE_DEFER;
>> + else
>> + dev_err(&dev->dev, "Can't get amba reset!\n");
>> + break;
>> + }
>> + reset_control_deassert(rstc);
>> + reset_control_put(rstc);
>> + count--;
>> + }
>
> I'm not normally a footprint person, but the looks of the stubs in
> <linux/reset.h> makes me suspicious whether this will have zero impact
> in size on platforms without reset controllers.
>
> Can you just ls -al on the kernel without CONFIG_RESET_CONTROLLER
> before and after this patch and ascertain that it has zero footprint effect?
Thanks for the review. I checked it, and indeed, it does have a zero
footprint effect.
>
> If it doesn't I'd sure like to break this into its own function and
> stick a if (!IS_ENABLED(CONFIG_RESET_CONTROLLER)) return 0;
> in there to make sure the compiler drops it.
>
> Also it'd be nice to get Philipp's ACK on the semantics, though they
> look correct to me.
>
Dinh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 2/3] fdt: add support for rng-seed
From: Will Deacon @ 2019-08-23 15:41 UTC (permalink / raw)
To: Hsin-Yi Wang, tytso
Cc: Kate Stewart, Peter Zijlstra, Catalin Marinas, Mukesh Ojha,
Grzegorz Halat, H . Peter Anvin, Guenter Roeck, Marek Szyprowski,
Rob Herring, Daniel Thompson, Anders Roxell, Yury Norov,
Marc Zyngier, Russell King, Aaro Koskinen, Ingo Molnar,
Viresh Kumar, Waiman Long, Paul E . McKenney, Wei Li,
Alexey Dobriyan, Julien Thierry, Len Brown, Kees Cook,
Arnd Bergmann, Rik van Riel, Stephen Boyd, Shaokun Zhang,
Mike Rapoport, Borislav Petkov, Josh Poimboeuf, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, Marcelo Tosatti,
linux-kernel, Armijn Hemel, Jiri Kosina, Mathieu Desnoyers,
Andrew Morton, Tim Chen, David S . Miller
In-Reply-To: <20190823062452.127528-3-hsinyi@chromium.org>
On Fri, Aug 23, 2019 at 02:24:51PM +0800, Hsin-Yi Wang wrote:
> Introducing a chosen node, rng-seed, which is an entropy that can be
> passed to kernel called very early to increase initial device
> randomness. Bootloader should provide this entropy and the value is
> read from /chosen/rng-seed in DT.
>
> Obtain of_fdt_crc32 for CRC check after early_init_dt_scan_nodes(),
> since early_init_dt_scan_chosen() would modify fdt to erase rng-seed.
>
> Add a new interface add_bootloader_randomness() for rng-seed use case.
> Depends on whether the seed is trustworthy, rng seed would be passed to
> add_hwgenerator_randomness(). Otherwise it would be passed to
> add_device_randomness(). Decision is controlled by kernel config
> RANDOM_TRUST_BOOTLOADER.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> Change from v9:
> * reword kconfig
> * use IS_ENABLED for config
Given that these aren't functional changes, I've kept Ted's ack from v9
and I'll queue these via arm64 assuming they pass testing.
Ted -- please shout if you're not happy about that, and I'll drop the
series.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Matthias Brugger @ 2019-08-23 15:42 UTC (permalink / raw)
To: frank-w, linux-mediatek, Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Mark Brown, Sean Wang,
Liam Girdwood, linux-kernel, Richard Fontana, Rob Herring,
Kate Stewart, René van Dorst, Thomas Gleixner, Eddie Huang,
Lee Jones, linux-arm-kernel, linux-rtc
In-Reply-To: <0A87F427-2D81-412A-9549-09A51A021799@public-files.de>
On 23/08/2019 17:26, Frank Wunderlich wrote:
>
>
> Am 23. August 2019 16:56:13 MESZ schrieb Matthias Brugger <matthias.bgg@gmail.com>:
>> are you sure that you provide the correct chip_id here? I saw 0x2023
>> (if I
>> remember correctly), while this switch checks for 0x23, 0x91 and 0x97,
>> so I'm
>> not sure if the problem really lies here. I didn't dig into the code to
>> find out
>> how the chip_id is created.
>
> The chip-id 0x2023 is reported with 5.3-rc5, next-code says 0x0. So i guess the chipid is read out/calculated the wrong way. If calculation is not changed the read is changed compared to 5.3
>
I suppose that's because 3/10 has code that should be in 2/10 and for some
reason 3/10 was not pushed for linux-next inclusion. Although it has the same
Acked-for-mfd-by tag.
@Frank, can you test if adding 3/10 to your code base fixes the issue?
Regards,
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Frank Wunderlich @ 2019-08-23 15:35 UTC (permalink / raw)
To: linux-mediatek, Matthias Brugger, Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Mark Brown, Sean Wang,
Liam Girdwood, linux-kernel, Richard Fontana, Rob Herring,
Kate Stewart, René van Dorst, Thomas Gleixner, Eddie Huang,
Lee Jones, linux-arm-kernel, linux-rtc
In-Reply-To: <e8a918ab-3e7a-b487-db77-df28d56518ce@gmail.com>
As far as i understand does old init-function not rely on the chip-id, so it seems that with this commit a prior bug is shown.
maybe the chip-id (should be 0x23 like constant) is set later after irq-request or completely missing for mt6323
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 09/10] rtc: mt6397: fix alarm register overwrite
From: Matthias Brugger @ 2019-08-23 15:35 UTC (permalink / raw)
To: Hsin-Hsiung Wang, Lee Jones, Rob Herring, Mark Brown,
Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, srv_heupstream, devicetree,
Greg Kroah-Hartman, Ran Bi, Sean Wang, Liam Girdwood,
linux-kernel, Richard Fontana, linux-mediatek, linux-arm-kernel,
Thomas Gleixner, Eddie Huang, Kate Stewart, linux-rtc
In-Reply-To: <1566531931-9772-10-git-send-email-hsin-hsiung.wang@mediatek.com>
On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> From: Ran Bi <ran.bi@mediatek.com>
>
> Alarm registers high byte was reserved for other functions.
> This add mask in alarm registers operation functions.
> This also fix error condition in interrupt handler.
>
> Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
>
> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Ran Bi <ran.bi@mediatek.com>
Misses your Signed-off-by.
Regards,
Matthias
> ---
> drivers/rtc/rtc-mt6397.c | 47 +++++++++++++++++++++++++++++++++--------------
> 1 file changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index b46ed4d..828def7 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -47,6 +47,14 @@
>
> #define RTC_AL_SEC 0x0018
>
> +#define RTC_AL_SEC_MASK 0x003f
> +#define RTC_AL_MIN_MASK 0x003f
> +#define RTC_AL_HOU_MASK 0x001f
> +#define RTC_AL_DOM_MASK 0x001f
> +#define RTC_AL_DOW_MASK 0x0007
> +#define RTC_AL_MTH_MASK 0x000f
> +#define RTC_AL_YEA_MASK 0x007f
> +
> #define RTC_PDN2 0x002e
> #define RTC_PDN2_PWRON_ALARM BIT(4)
>
> @@ -103,7 +111,7 @@ static irqreturn_t mtk_rtc_irq_handler_thread(int irq, void *data)
> irqen = irqsta & ~RTC_IRQ_EN_AL;
> mutex_lock(&rtc->lock);
> if (regmap_write(rtc->regmap, rtc->addr_base + RTC_IRQ_EN,
> - irqen) < 0)
> + irqen) == 0)
> mtk_rtc_write_trigger(rtc);
> mutex_unlock(&rtc->lock);
>
> @@ -225,12 +233,12 @@ static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
> alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> mutex_unlock(&rtc->lock);
>
> - tm->tm_sec = data[RTC_OFFSET_SEC];
> - tm->tm_min = data[RTC_OFFSET_MIN];
> - tm->tm_hour = data[RTC_OFFSET_HOUR];
> - tm->tm_mday = data[RTC_OFFSET_DOM];
> - tm->tm_mon = data[RTC_OFFSET_MTH];
> - tm->tm_year = data[RTC_OFFSET_YEAR];
> + tm->tm_sec = data[RTC_OFFSET_SEC] & RTC_AL_SEC_MASK;
> + tm->tm_min = data[RTC_OFFSET_MIN] & RTC_AL_MIN_MASK;
> + tm->tm_hour = data[RTC_OFFSET_HOUR] & RTC_AL_HOU_MASK;
> + tm->tm_mday = data[RTC_OFFSET_DOM] & RTC_AL_DOM_MASK;
> + tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_AL_MTH_MASK;
> + tm->tm_year = data[RTC_OFFSET_YEAR] & RTC_AL_YEA_MASK;
>
> tm->tm_year += RTC_MIN_YEAR_OFFSET;
> tm->tm_mon--;
> @@ -251,14 +259,25 @@ static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> tm->tm_mon++;
>
> - data[RTC_OFFSET_SEC] = tm->tm_sec;
> - data[RTC_OFFSET_MIN] = tm->tm_min;
> - data[RTC_OFFSET_HOUR] = tm->tm_hour;
> - data[RTC_OFFSET_DOM] = tm->tm_mday;
> - data[RTC_OFFSET_MTH] = tm->tm_mon;
> - data[RTC_OFFSET_YEAR] = tm->tm_year;
> -
> mutex_lock(&rtc->lock);
> + ret = regmap_bulk_read(rtc->regmap, rtc->addr_base + RTC_AL_SEC,
> + data, RTC_OFFSET_COUNT);
> + if (ret < 0)
> + goto exit;
> +
> + data[RTC_OFFSET_SEC] = ((data[RTC_OFFSET_SEC] & ~(RTC_AL_SEC_MASK)) |
> + (tm->tm_sec & RTC_AL_SEC_MASK));
> + data[RTC_OFFSET_MIN] = ((data[RTC_OFFSET_MIN] & ~(RTC_AL_MIN_MASK)) |
> + (tm->tm_min & RTC_AL_MIN_MASK));
> + data[RTC_OFFSET_HOUR] = ((data[RTC_OFFSET_HOUR] & ~(RTC_AL_HOU_MASK)) |
> + (tm->tm_hour & RTC_AL_HOU_MASK));
> + data[RTC_OFFSET_DOM] = ((data[RTC_OFFSET_DOM] & ~(RTC_AL_DOM_MASK)) |
> + (tm->tm_mday & RTC_AL_DOM_MASK));
> + data[RTC_OFFSET_MTH] = ((data[RTC_OFFSET_MTH] & ~(RTC_AL_MTH_MASK)) |
> + (tm->tm_mon & RTC_AL_MTH_MASK));
> + data[RTC_OFFSET_YEAR] = ((data[RTC_OFFSET_YEAR] & ~(RTC_AL_YEA_MASK)) |
> + (tm->tm_year & RTC_AL_YEA_MASK));
> +
> if (alm->enabled) {
> ret = regmap_bulk_write(rtc->regmap,
> rtc->addr_base + RTC_AL_SEC,
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Frank Wunderlich @ 2019-08-23 15:26 UTC (permalink / raw)
To: linux-mediatek, Matthias Brugger, Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Mark Brown, Sean Wang,
Liam Girdwood, linux-kernel, Richard Fontana, Rob Herring,
Kate Stewart, René van Dorst, Thomas Gleixner, Eddie Huang,
Lee Jones, linux-arm-kernel, linux-rtc
In-Reply-To: <e8a918ab-3e7a-b487-db77-df28d56518ce@gmail.com>
Am 23. August 2019 16:56:13 MESZ schrieb Matthias Brugger <matthias.bgg@gmail.com>:
>are you sure that you provide the correct chip_id here? I saw 0x2023
>(if I
>remember correctly), while this switch checks for 0x23, 0x91 and 0x97,
>so I'm
>not sure if the problem really lies here. I didn't dig into the code to
>find out
>how the chip_id is created.
The chip-id 0x2023 is reported with 5.3-rc5, next-code says 0x0. So i guess the chipid is read out/calculated the wrong way. If calculation is not changed the read is changed compared to 5.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 03/10] mfd: mt6397: modify suspend/resume behavior
From: Matthias Brugger @ 2019-08-23 15:12 UTC (permalink / raw)
To: Hsin-Hsiung Wang, Lee Jones, Rob Herring, Mark Brown,
Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, srv_heupstream, devicetree,
Greg Kroah-Hartman, Sean Wang, Liam Girdwood, linux-kernel,
Richard Fontana, linux-mediatek, linux-arm-kernel,
Thomas Gleixner, Eddie Huang, Kate Stewart, linux-rtc
In-Reply-To: <1566531931-9772-4-git-send-email-hsin-hsiung.wang@mediatek.com>
On 23/08/2019 05:45, Hsin-Hsiung Wang wrote:
> Some pmics don't need backup interrupt settings, so we change to use
> pm notifier for the pmics which are necessary to store settings.
>
> Acked-for-mfd-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> ---
> drivers/mfd/mt6397-core.c | 89 +++++++++++++++++------------------------
> drivers/mfd/mt6397-irq.c | 33 +++++++++++++++
> include/linux/mfd/mt6397/core.h | 3 ++
> 3 files changed, 73 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 93c8881..8f94187 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -4,7 +4,6 @@
> * Author: Flora Fu, MediaTek
> */
>
> -#include <linux/interrupt.h>
> #include <linux/module.h>
> #include <linux/of_device.h>
> #include <linux/of_irq.h>
> @@ -82,40 +81,27 @@
> }
> };
>
> -#ifdef CONFIG_PM_SLEEP
> -static int mt6397_irq_suspend(struct device *dev)
> -{
> - struct mt6397_chip *chip = dev_get_drvdata(dev);
> -
> - regmap_write(chip->regmap, chip->int_con[0], chip->wake_mask[0]);
> - regmap_write(chip->regmap, chip->int_con[1], chip->wake_mask[1]);
> -
> - enable_irq_wake(chip->irq);
> -
> - return 0;
> -}
> -
> -static int mt6397_irq_resume(struct device *dev)
> -{
> - struct mt6397_chip *chip = dev_get_drvdata(dev);
> -
> - regmap_write(chip->regmap, chip->int_con[0], chip->irq_masks_cur[0]);
> - regmap_write(chip->regmap, chip->int_con[1], chip->irq_masks_cur[1]);
> -
> - disable_irq_wake(chip->irq);
> +struct chip_data {
> + u32 cid_addr;
> + u32 cid_shift;
> +};
>
> - return 0;
> -}
> -#endif
> +static const struct chip_data mt6323_core = {
> + .cid_addr = MT6323_CID,
> + .cid_shift = 0,
> +};
>
> -static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_irq_suspend,
> - mt6397_irq_resume);
> +static const struct chip_data mt6397_core = {
> + .cid_addr = MT6397_CID,
> + .cid_shift = 0,
> +};
>
> static int mt6397_probe(struct platform_device *pdev)
> {
> int ret;
> unsigned int id;
> struct mt6397_chip *pmic;
> + const struct chip_data *pmic_core;
>
> pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
> if (!pmic)
> @@ -131,28 +117,30 @@ static int mt6397_probe(struct platform_device *pdev)
> if (!pmic->regmap)
> return -ENODEV;
>
> - platform_set_drvdata(pdev, pmic);
> + pmic_core = of_device_get_match_data(&pdev->dev);
> + if (!pmic_core)
> + return -ENODEV;
>
> - ret = regmap_read(pmic->regmap, MT6397_CID, &id);
> + ret = regmap_read(pmic->regmap, pmic_core->cid_addr, &id);
> if (ret) {
> - dev_err(pmic->dev, "Failed to read chip id: %d\n", ret);
> + dev_err(&pdev->dev, "Failed to read chip id: %d\n", ret);
> return ret;
> }
>
> + pmic->chip_id = (id >> pmic_core->cid_shift) & 0xff;
> +
> + platform_set_drvdata(pdev, pmic);
> +
What do this changes have to do with the commit message/subject?
> pmic->irq = platform_get_irq(pdev, 0);
> if (pmic->irq <= 0)
> return pmic->irq;
>
> - switch (id & 0xff) {
> - case MT6323_CHIP_ID:
> - pmic->int_con[0] = MT6323_INT_CON0;
> - pmic->int_con[1] = MT6323_INT_CON1;
> - pmic->int_status[0] = MT6323_INT_STATUS0;
> - pmic->int_status[1] = MT6323_INT_STATUS1;
> - ret = mt6397_irq_init(pmic);
> - if (ret)
> - return ret;
This looks to me as if it should be part of 02/10.
> + ret = mt6397_irq_init(pmic);
> + if (ret)
> + return ret;
>
> + switch (pmic->chip_id) {
> + case MT6323_CHIP_ID:
> ret = devm_mfd_add_devices(&pdev->dev, -1, mt6323_devs,
> ARRAY_SIZE(mt6323_devs), NULL,
> 0, pmic->irq_domain);
> @@ -160,21 +148,13 @@ static int mt6397_probe(struct platform_device *pdev)
>
> case MT6391_CHIP_ID:
> case MT6397_CHIP_ID:
> - pmic->int_con[0] = MT6397_INT_CON0;
> - pmic->int_con[1] = MT6397_INT_CON1;
> - pmic->int_status[0] = MT6397_INT_STATUS0;
> - pmic->int_status[1] = MT6397_INT_STATUS1;
> - ret = mt6397_irq_init(pmic);
> - if (ret)
> - return ret;
> -
Same here.
Regards,
Matthias
> ret = devm_mfd_add_devices(&pdev->dev, -1, mt6397_devs,
> ARRAY_SIZE(mt6397_devs), NULL,
> 0, pmic->irq_domain);
> break;
>
> default:
> - dev_err(&pdev->dev, "unsupported chip: %d\n", id);
> + dev_err(&pdev->dev, "unsupported chip: %d\n", pmic->chip_id);
> return -ENODEV;
> }
>
> @@ -187,9 +167,15 @@ static int mt6397_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id mt6397_of_match[] = {
> - { .compatible = "mediatek,mt6397" },
> - { .compatible = "mediatek,mt6323" },
> - { }
> + {
> + .compatible = "mediatek,mt6323",
> + .data = &mt6323_core,
> + }, {
> + .compatible = "mediatek,mt6397",
> + .data = &mt6397_core,
> + }, {
> + /* sentinel */
> + }
> };
> MODULE_DEVICE_TABLE(of, mt6397_of_match);
>
> @@ -204,7 +190,6 @@ static int mt6397_probe(struct platform_device *pdev)
> .driver = {
> .name = "mt6397",
> .of_match_table = of_match_ptr(mt6397_of_match),
> - .pm = &mt6397_pm_ops,
> },
> .id_table = mt6397_id,
> };
> diff --git a/drivers/mfd/mt6397-irq.c b/drivers/mfd/mt6397-irq.c
> index b2d3ce1..669e93d 100644
> --- a/drivers/mfd/mt6397-irq.c
> +++ b/drivers/mfd/mt6397-irq.c
> @@ -9,6 +9,7 @@
> #include <linux/of_irq.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> +#include <linux/suspend.h>
> #include <linux/mfd/mt6323/core.h>
> #include <linux/mfd/mt6323/registers.h>
> #include <linux/mfd/mt6397/core.h>
> @@ -128,6 +129,36 @@ static int mt6397_irq_domain_map(struct irq_domain *d, unsigned int irq,
> .map = mt6397_irq_domain_map,
> };
>
> +static int mt6397_irq_pm_notifier(struct notifier_block *notifier,
> + unsigned long pm_event, void *unused)
> +{
> + struct mt6397_chip *chip =
> + container_of(notifier, struct mt6397_chip, pm_nb);
> +
> + switch (pm_event) {
> + case PM_SUSPEND_PREPARE:
> + regmap_write(chip->regmap,
> + chip->int_con[0], chip->wake_mask[0]);
> + regmap_write(chip->regmap,
> + chip->int_con[1], chip->wake_mask[1]);
> + enable_irq_wake(chip->irq);
> + break;
> +
> + case PM_POST_SUSPEND:
> + regmap_write(chip->regmap,
> + chip->int_con[0], chip->irq_masks_cur[0]);
> + regmap_write(chip->regmap,
> + chip->int_con[1], chip->irq_masks_cur[1]);
> + disable_irq_wake(chip->irq);
> + break;
> +
> + default:
> + break;
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> int mt6397_irq_init(struct mt6397_chip *chip)
> {
> int ret;
> @@ -159,6 +190,7 @@ int mt6397_irq_init(struct mt6397_chip *chip)
> regmap_write(chip->regmap, chip->int_con[0], 0x0);
> regmap_write(chip->regmap, chip->int_con[1], 0x0);
>
> + chip->pm_nb.notifier_call = mt6397_irq_pm_notifier;
> chip->irq_domain = irq_domain_add_linear(chip->dev->of_node,
> MT6397_IRQ_NR,
> &mt6397_irq_domain_ops,
> @@ -177,5 +209,6 @@ int mt6397_irq_init(struct mt6397_chip *chip)
> return ret;
> }
>
> + register_pm_notifier(&chip->pm_nb);
> return 0;
> }
> diff --git a/include/linux/mfd/mt6397/core.h b/include/linux/mfd/mt6397/core.h
> index 9320c2a..23e21da 100644
> --- a/include/linux/mfd/mt6397/core.h
> +++ b/include/linux/mfd/mt6397/core.h
> @@ -7,6 +7,8 @@
> #ifndef __MFD_MT6397_CORE_H__
> #define __MFD_MT6397_CORE_H__
>
> +#include <linux/notifier.h>
> +
> enum chip_id {
> MT6323_CHIP_ID = 0x23,
> MT6391_CHIP_ID = 0x91,
> @@ -52,6 +54,7 @@ enum mt6397_irq_numbers {
> struct mt6397_chip {
> struct device *dev;
> struct regmap *regmap;
> + struct notifier_block pm_nb;
> int irq;
> struct irq_domain *irq_domain;
> struct mutex irqlock;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] ASoC: atmel: enable SSC_PCM_DMA in Kconfig
From: Alexandre Belloni @ 2019-08-23 15:09 UTC (permalink / raw)
To: mirq-linux
Cc: alsa-devel, lgirdwood, tiwai, perex, Ludovic.Desroches, broonie,
Codrin.Ciubotariu, linux-arm-kernel
In-Reply-To: <20190723232505.GA21811@qmqm.qmqm.pl>
On 24/07/2019 01:25:05+0200, mirq-linux@rere.qmqm.pl wrote:
> On Tue, Jul 23, 2019 at 08:39:15PM +0200, Alexandre Belloni wrote:
> > On 23/07/2019 18:43:12+0200, mirq-linux@rere.qmqm.pl wrote:
> > > On Tue, Jul 23, 2019 at 01:36:37PM +0000, Codrin.Ciubotariu@microchip.com wrote:
> > > > On 22.07.2019 21:27, Michał Mirosław wrote:
> > > > > Allow SSC to be used on platforms described using audio-graph-card
> > > > > in Device Tree.
> > > > >
> > > > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > > > ---
> > > > > sound/soc/atmel/Kconfig | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
> > > > > index 06c1d5ce642c..9ef9d25bb517 100644
> > > > > --- a/sound/soc/atmel/Kconfig
> > > > > +++ b/sound/soc/atmel/Kconfig
> > > > > @@ -25,7 +25,7 @@ config SND_ATMEL_SOC_DMA
> > > > > default y if SND_ATMEL_SOC_SSC_DMA=y || (SND_ATMEL_SOC_SSC_DMA=m && SND_ATMEL_SOC_SSC=y)
> > > > >
> > > > > config SND_ATMEL_SOC_SSC_DMA
> > > > > - tristate
> > > > > + tristate "SoC PCM DAI support for AT91 SSC controller using DMA"
> > > >
> > > > Could you please make something similar for SND_ATMEL_SOC_SSC_PDC? Also,
> > > > I think that it should select ATMEL_SSC, to be able to use
> > > > simple/graph-card with SSC.
> > >
> > > Hmm. The Kconfig dependencies seems overly complicated, do you mind if I
> > > get rid of most of the entries in the process?
> > >
> >
> > Unfortunately, it is just complicated enough. This is done to support
> > all the possible configurations. Removing them will lead to linking
> > errors.
> >
> > After having that discussion back in March, I had a very quick look and
> > didn't send a patch because I still had linking issues. It is not
> > impossible but it required more time than I had.
>
> Can you try patch below if it covers the configurations you mention?
> This uses Kconfig's m/y resolution instead of open-coded defaults.
>
Seems good to me, thanks.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/5] soc: amlogic: Add support for Everything-Else power domains controller
From: Kevin Hilman @ 2019-08-23 15:06 UTC (permalink / raw)
To: Neil Armstrong, ulf.hansson
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <0ac1cf30-1796-a549-e195-0f94c4a85993@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
[...]
>>> It's for legacy when VPU is initialized from vendor U-Boot, look at commit :
>>> 339cd0ea082287ea8e2b7e7159a5a33665a2cbe3 "soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader"
>>>
>>> In the case the VPU power domain has been powered on by the bootloader
>>> and no driver are attached to this power domain, the genpd will power it
>>> off after a certain amount of time, but the clocks hasn't been enabled
>>> by the kernel itself and the power-off will trigger some faults.
>>> This patch enable the clocks to have a coherent state for an eventual
>>> poweroff and switches to the pm_domain_always_on_gov governor.
>>
>> The key phrase there being "and no driver is attached". Now that we
>> have a driver, it claims this domain so I don't think it will be
>> powered off:
>>
>> # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
>> domain status slaves
>> /device runtime status
>> ----------------------------------------------------------------------
>> ETH on
>> /devices/platform/soc/ff3f0000.ethernet unsupported
>> AUDIO off-0
>> GE2D off-0
>> PCI off-0
>> USB on
>> /devices/platform/soc/ffe09000.usb active
>> NNA off-0
>> VPU on
>> /devices/platform/soc/ff900000.vpu unsupported
>>
>> In my tests with a framebuffer console (over HDMI), I don't see the
>> display being powered off.
>
> It's in the case where the driver is a module loaded by the post-initramfs
> system after the genpd timeout, or if the display driver is disabled.
>
> In the later I had some system failures when vendor u-boot enabled the
> display and genpd disabled the power domain later on.
OK, thanks for the explanation. I get it now.
>>
>>> I could set always-on governor only if the domain was already enabled,
>>> what do you think ?
>>
>> I don't think that's necessary now that we have a driver. We really
>> want to be able to power-down this domain when the display is not in
>> use, and if you use always_on, that will never happen.
>>
>>> And seems I'm also missing the "This patch enable the clocks".
>>
>> I'm not sure what patch you're referring to.
>
> It's also added in 339cd0ea082287ea8e2b7e7159a5a33665a2cbe3 "soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader"
>
> I would like to keep the same behavior as meson-gx-pwrc-vpu, since it works fine
> and we debugged all the issues we got.
OK, that's fine with me.
We'll have to revist when we start using runtime PM enabled drviers and
want to power down the display IPs on idle, but that's fine to do later.
Thanks,
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 1/5] mm: untag user pointers in mmap/munmap/mremap/brk
From: Will Deacon @ 2019-08-23 15:01 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-doc, Szabolcs Nagy, Catalin Marinas,
Kevin Brodsky, Will Deacon, Dave P Martin, linux-mm,
Andrey Konovalov, Vincenzo Frascino, Dave Hansen,
linux-arm-kernel
In-Reply-To: <20190822164125.acfb97de912996b2b9127c61@linux-foundation.org>
On Thu, Aug 22, 2019 at 04:41:25PM -0700, Andrew Morton wrote:
> On Mon, 19 Aug 2019 17:28:51 +0100 Will Deacon <will@kernel.org> wrote:
>
> > On Thu, Aug 15, 2019 at 04:43:59PM +0100, Catalin Marinas wrote:
> > > There isn't a good reason to differentiate between the user address
> > > space layout modification syscalls and the other memory
> > > permission/attributes ones (e.g. mprotect, madvise) w.r.t. the tagged
> > > address ABI. Untag the user addresses on entry to these functions.
> > >
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > ---
> > > mm/mmap.c | 5 +++++
> > > mm/mremap.c | 6 +-----
> > > 2 files changed, 6 insertions(+), 5 deletions(-)
> >
> > Acked-by: Will Deacon <will@kernel.org>
> >
> > Andrew -- please can you pick this patch up? I'll take the rest of the
> > series via arm64 once we've finished discussing the wording details.
> >
>
> Sure, I grabbed the patch from the v9 series.
Thanks, Andrew.
> But please feel free to include this in the arm64 tree - I'll autodrop
> my copy if this turns up in linux-next.
I'd prefer for this one to go via you so that it can sit with the rest of
the core changes relating to tagged addresses. Obviously please yell if
you run into any issues with it!
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 3/3] watchdog/aspeed: add support for dual boot
From: Ivan Mikhaylov @ 2019-08-23 14:58 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-watchdog, linux-aspeed, Andrew Jeffery, openbmc,
Alexander Amelkin, linux-kernel, Joel Stanley, Wim Van Sebroeck,
linux-arm-kernel
In-Reply-To: <20190823141930.GA11610@roeck-us.net>
On Fri, 2019-08-23 at 07:19 -0700, Guenter Roeck wrote:
> >
> > +/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
> > +static ssize_t access_cs0_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> > +
>
> Unnecessary empty line.
>
Ok, will cut.
> > +static ssize_t access_cs0_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + struct aspeed_wdt *wdt = dev_get_drvdata(dev);
> > + unsigned long val = 0;
>
> Unnecessary initialization.
So, you're saying 'unsigned long val;' is enough? Will do then.
>
> So the attribute would only exist if the boot was from the secondary
> flash, and it would exist even if it wasn't needed (ie on ast2500 /
> ast2600)?
Yes, only at secondary flash it will be available.
Also, found out that is for 2600 aspeed completely changed the process of
switch. For 2500 it just swaps chipselects back to make it accordingly as at
first side, on idea it may be helpful.
May be some approach like this will suffice?
if ((of_device_is_compatible(np, "aspeed,ast2400-wdt") or
(of_device_is_compatible(np, "aspeed,ast2500-wdt"))
wdt->wdd.groups = bswitch_groups;
> Well, if that is what you want, who am I to argue, but
> you'll have to document it accordingly. When you do so, please also
> document what happens on ast2500 / ast2600 when the attribute exists
> and is written.
>
Ok, I'll put it in Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
for next patch set.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5] arm64: implement KPROBES_ON_FTRACE
From: Masami Hiramatsu @ 2019-08-23 14:57 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Mark Rutland, Jonathan Corbet, Peter Zijlstra, Catalin Marinas,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Steven Rostedt, Naveen N. Rao, Will Deacon, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190822191351.3796aca8@xhacker.debian>
Hi Jisheng,
On Thu, 22 Aug 2019 11:25:00 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
>
> Tested on berlin arm64 platform.
>
> ~ # mount -t debugfs debugfs /sys/kernel/debug/
> ~ # cd /sys/kernel/debug/
> /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
>
> before the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009fe28 k _do_fork+0x0 [DISABLED]
>
> after the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009ff54 k _do_fork+0x4 [DISABLED][FTRACE]
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Looks good to me.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you,
> ---
>
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
>
> Applied after arm64 FTRACE_WITH_REGS:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/674404.html
>
> Changes since v4:
> - correct reg->pc: probed on foo, then pre_handler see foo+0x4, while
> post_handler see foo+0x8
>
> Changes since v3:
> - move kprobe_lookup_name() and arch_kprobe_on_func_entry to ftrace.c since
> we only want to choose the ftrace entry for KPROBES_ON_FTRACE.
> - only choose ftrace entry if (addr && !offset)
>
> Changes since v2:
> - remove patch1, make it a single cleanup patch
> - remove "This patch" in the change log
> - implement arm64's kprobe_lookup_name() and arch_kprobe_on_func_entry instead
> of patching the common kprobes code
>
> Changes since v1:
> - make the kprobes/x86: use instruction_pointer and instruction_pointer_set
> as patch1
> - add Masami's ACK to patch1
> - add some description about KPROBES_ON_FTRACE and why we need it on
> arm64
> - correct the log before the patch
> - remove the consolidation patch, make it as TODO
> - only adjust kprobe's addr when KPROBE_FLAG_FTRACE is set
> - if KPROBES_ON_FTRACE, ftrace_call_adjust() the kprobe's addr before
> calling ftrace_location()
> - update the kprobes-on-ftrace/arch-support.txt in doc
>
> .../debug/kprobes-on-ftrace/arch-support.txt | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/probes/Makefile | 1 +
> arch/arm64/kernel/probes/ftrace.c | 83 +++++++++++++++++++
> 4 files changed, 86 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/kernel/probes/ftrace.c
>
> diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> index 68f266944d5f..e8358a38981c 100644
> --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> @@ -9,7 +9,7 @@
> | alpha: | TODO |
> | arc: | TODO |
> | arm: | TODO |
> - | arm64: | TODO |
> + | arm64: | ok |
> | c6x: | TODO |
> | csky: | TODO |
> | h8300: | TODO |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 663392d1eae2..928700f15e23 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -167,6 +167,7 @@ config ARM64
> select HAVE_STACKPROTECTOR
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_KPROBES
> + select HAVE_KPROBES_ON_FTRACE
> select HAVE_KRETPROBES
> select HAVE_GENERIC_VDSO
> select IOMMU_DMA if IOMMU_SUPPORT
> diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
> index 8e4be92e25b1..4020cfc66564 100644
> --- a/arch/arm64/kernel/probes/Makefile
> +++ b/arch/arm64/kernel/probes/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
> simulate-insn.o
> obj-$(CONFIG_UPROBES) += uprobes.o decode-insn.o \
> simulate-insn.o
> +obj-$(CONFIG_KPROBES_ON_FTRACE) += ftrace.o
> diff --git a/arch/arm64/kernel/probes/ftrace.c b/arch/arm64/kernel/probes/ftrace.c
> new file mode 100644
> index 000000000000..9f80905f02fa
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/ftrace.c
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Dynamic Ftrace based Kprobes Optimization
> + *
> + * Copyright (C) Hitachi Ltd., 2012
> + * Copyright (C) 2019 Jisheng Zhang <jszhang@kernel.org>
> + * Synaptics Incorporated
> + */
> +
> +#include <linux/kprobes.h>
> +
> +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> +void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> + struct ftrace_ops *ops, struct pt_regs *regs)
> +{
> + struct kprobe *p;
> + struct kprobe_ctlblk *kcb;
> +
> + /* Preempt is disabled by ftrace */
> + p = get_kprobe((kprobe_opcode_t *)ip);
> + if (unlikely(!p) || kprobe_disabled(p))
> + return;
> +
> + kcb = get_kprobe_ctlblk();
> + if (kprobe_running()) {
> + kprobes_inc_nmissed_count(p);
> + } else {
> + unsigned long orig_ip = instruction_pointer(regs);
> +
> + instruction_pointer_set(regs, ip);
> + __this_cpu_write(current_kprobe, p);
> + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> + if (!p->pre_handler || !p->pre_handler(p, regs)) {
> + /*
> + * Emulate singlestep (and also recover regs->pc)
> + * as if there is a nop
> + */
> + instruction_pointer_set(regs,
> + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> + if (unlikely(p->post_handler)) {
> + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> + p->post_handler(p, regs, 0);
> + }
> + instruction_pointer_set(regs, orig_ip);
> + }
> + /*
> + * If pre_handler returns !0, it changes regs->pc. We have to
> + * skip emulating post_handler.
> + */
> + __this_cpu_write(current_kprobe, NULL);
> + }
> +}
> +NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> +
> +kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
> +{
> + unsigned long addr = kallsyms_lookup_name(name);
> +
> + if (addr && !offset) {
> + unsigned long faddr;
> + /*
> + * with -fpatchable-function-entry=2, the first 4 bytes is the
> + * LR saver, then the actual call insn. So ftrace location is
> + * always on the first 4 bytes offset.
> + */
> + faddr = ftrace_location_range(addr,
> + addr + AARCH64_INSN_SIZE);
> + if (faddr)
> + return (kprobe_opcode_t *)faddr;
> + }
> + return (kprobe_opcode_t *)addr;
> +}
> +
> +bool arch_kprobe_on_func_entry(unsigned long offset)
> +{
> + return offset <= AARCH64_INSN_SIZE;
> +}
> +
> +int arch_prepare_kprobe_ftrace(struct kprobe *p)
> +{
> + p->ainsn.api.insn = NULL;
> + return 0;
> +}
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node
From: Maxime Ripard @ 2019-08-23 14:56 UTC (permalink / raw)
To: Samuel Holland
Cc: Mark Rutland, devicetree, linux-sunxi, Stephen Boyd,
Michael Turquette, Jassi Brar, linux-kernel, Chen-Yu Tsai,
Rob Herring, Corentin Labbe, linux-clk, linux-arm-kernel
In-Reply-To: <f3e3420e-450a-7d41-edf8-776c0cd5a320@sholland.org>
[-- Attachment #1.1: Type: text/plain, Size: 1008 bytes --]
Hi,
On Tue, Aug 20, 2019 at 08:17:49AM -0500, Samuel Holland wrote:
> On 8/20/19 3:15 AM, Maxime Ripard wrote:
> > On Mon, Aug 19, 2019 at 10:23:06PM -0500, Samuel Holland wrote:
> >> The A80 SoC contains a message box that can be used to send messages and
> >> interrupts back and forth between the ARM application CPUs and the ARISC
> >> coprocessor. Add a device tree node for it.
> >>
> >> Signed-off-by: Samuel Holland <samuel@sholland.org>
> >
> > I think you mentionned that crust has been tested only on the A64 and
> > the H3/H5, did you test the mailbox on those other SoCs as well?
>
> No, I only have A64/H3/H5, and recently H6, hardware to test. I've looked
> through the manuals to verify that the registers are all the same, but I haven't
> run the driver on earlier SoCs.
I'd rather not merge them until they've been properly tested. We've
had some surprises with the documentation in the past :/
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [BUG] [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
From: Matthias Brugger @ 2019-08-23 14:56 UTC (permalink / raw)
To: Frank Wunderlich, Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Greg Kroah-Hartman, Sean Wang, Liam Girdwood,
Rob Herring, linux-kernel, Richard Fontana, Mark Brown,
linux-mediatek, linux-arm-kernel, René van Dorst,
Thomas Gleixner, Eddie Huang, Lee Jones, Kate Stewart, linux-rtc
In-Reply-To: <trinity-1f82bff1-535e-47cd-9a2f-8faccb56e356-1566562433314@3c-app-gmx-bs11>
On 23/08/2019 14:13, Frank Wunderlich wrote:
> Hi,
>
> this commit breaks mt6323 pmic on BananaPi-R2
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4872e80ce7d2a1844328176dbf279d0a2b89bdb
>
> resulting in this message in dmesg:
>
> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0
> and multiple
> mtk-cpufreq mtk-cpufreq: failed to initialize dvfs info for cpu0
>
> see discussion here:
> http://lists.infradead.org/pipermail/linux-mediatek/2019-August/022505.html
>
> after reverting this one the errors are gone, please provide a fix
are you sure that you provide the correct chip_id here? I saw 0x2023 (if I
remember correctly), while this switch checks for 0x23, 0x91 and 0x97, so I'm
not sure if the problem really lies here. I didn't dig into the code to find out
how the chip_id is created.
Regards,
Matthias
>
> regards Frank
>
>
>> Gesendet: Freitag, 23. August 2019 um 05:45 Uhr
>> Von: "Hsin-Hsiung Wang" <hsin-hsiung.wang@mediatek.com>
>> Betreff: [PATCH v5 02/10] mfd: mt6397: extract irq related code from core driver
>>
>> In order to support different types of irq design, we decide to add
>> separate irq drivers for different design and keep mt6397 mfd core
>> simple and reusable to all generations of PMICs so far.
>>
>> Acked-for-mfd-by: Lee Jones <lee.jones@linaro.org>
>> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
>> ---
>> drivers/mfd/Makefile | 3 +-
>> drivers/mfd/mt6397-core.c | 146 --------------------------------
>> drivers/mfd/mt6397-irq.c | 181 ++++++++++++++++++++++++++++++++++++++++
>> include/linux/mfd/mt6397/core.h | 9 ++
>> 4 files changed, 192 insertions(+), 147 deletions(-)
>> create mode 100644 drivers/mfd/mt6397-irq.c
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox