* [PATCH v4 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527097616-25214-3-git-send-email-Dave.Martin@arm.com>
On Wed, May 23, 2018 at 06:46:56PM +0100, Dave Martin wrote:
> Stateful CPU architecture extensions may require the signal frame
> to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
> However, changing this #define is an ABI break.
>
> To allow userspace the option of determining the signal frame size
> in a more forwards-compatible way, this patch adds a new auxv entry
> tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
> size that the process can observe during its lifetime.
>
> If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
> assume that the MINSIGSTKSZ #define is sufficient. This allows for
> a consistent interface with older kernels that do not provide
> AT_MINSIGSTKSZ.
>
> The idea is that libc could expose this via sysconf() or some
> similar mechanism.
>
> There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
> about userspace's own stack overheads and should not pretend to
> know.
[...]
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index fac1c4d..9c18f0e 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -121,6 +121,9 @@
>
> #ifndef __ASSEMBLY__
>
> +#include <linux/bug.h>
> +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> +
> typedef unsigned long elf_greg_t;
>
> #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
> @@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> do { \
> NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> (elf_addr_t)current->mm->context.vdso); \
> + \
> + /* \
> + * Should always be nonzero unless there's a kernel bug. If \
> + * the we haven't determined a sensible value to give to \
"If the we"?
> + * userspace, omit the entry: \
> + */ \
> + if (likely(signal_minsigstksz)) \
> + NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
> } while (0)
>
> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 7675989..65ab83e 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -35,6 +35,8 @@
> #ifdef __KERNEL__
>
> #include <linux/build_bug.h>
> +#include <linux/cache.h>
> +#include <linux/init.h>
> #include <linux/stddef.h>
> #include <linux/string.h>
>
> @@ -244,6 +246,9 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused);
> void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused);
> void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
>
> +extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
> +extern void __init minsigstksz_setup(void);
> +
> /* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
> #define SVE_SET_VL(arg) sve_set_current_vl(arg)
> #define SVE_GET_VL() sve_get_current_vl()
> diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
> index ec0a86d..743c0b8 100644
> --- a/arch/arm64/include/uapi/asm/auxvec.h
> +++ b/arch/arm64/include/uapi/asm/auxvec.h
> @@ -19,7 +19,8 @@
>
> /* vDSO location */
> #define AT_SYSINFO_EHDR 33
> +#define AT_MINSIGSTKSZ 51 /* stack needed for signal delivery */
Curious: but how do we avoid/detect conflicts at -rc1? I guess somebody just
needs to remember to run grep? (I know you have another series consolidating
the ID allocations).
> -#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
> +#define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
>
> #endif
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9d1b06d..0e0b53d 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1619,6 +1619,7 @@ void __init setup_cpu_features(void)
> pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
>
> sve_setup();
> + minsigstksz_setup();
>
> /* Advertise that we have computed the system capabilities */
> set_sys_caps_initialised();
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 154b7d3..00b9990 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -17,6 +17,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/cache.h>
> #include <linux/compat.h>
> #include <linux/errno.h>
> #include <linux/kernel.h>
> @@ -570,8 +571,15 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
> return 0;
> }
>
> -/* Determine the layout of optional records in the signal frame */
> -static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> +/*
> + * Determine the layout of optional records in the signal frame
> + *
> + * add_all: if true, lays out the biggest possible signal frame for
> + * this task; otherwise, generates a layout for the current state
> + * of the task.
> + */
> +static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
> + bool add_all)
> {
> int err;
>
> @@ -581,7 +589,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> return err;
>
> /* fault information, if valid */
> - if (current->thread.fault_code) {
> + if (add_all || current->thread.fault_code) {
> err = sigframe_alloc(user, &user->esr_offset,
> sizeof(struct esr_context));
> if (err)
> @@ -591,8 +599,14 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> if (system_supports_sve()) {
> unsigned int vq = 0;
>
> - if (test_thread_flag(TIF_SVE))
> - vq = sve_vq_from_vl(current->thread.sve_vl);
> + if (add_all || test_thread_flag(TIF_SVE)) {
> + int vl = sve_max_vl;
> +
> + if (!add_all)
> + vl = current->thread.sve_vl;
> +
> + vq = sve_vq_from_vl(vl);
> + }
>
> err = sigframe_alloc(user, &user->sve_offset,
> SVE_SIG_CONTEXT_SIZE(vq));
> @@ -603,7 +617,6 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> return sigframe_alloc_end(user);
> }
>
> -
> static int setup_sigframe(struct rt_sigframe_user_layout *user,
> struct pt_regs *regs, sigset_t *set)
> {
> @@ -701,7 +714,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
> int err;
>
> init_user_layout(user);
> - err = setup_sigframe_layout(user);
> + err = setup_sigframe_layout(user, false);
> if (err)
> return err;
>
> @@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
> thread_flags = READ_ONCE(current_thread_info()->flags);
> } while (thread_flags & _TIF_WORK_MASK);
> }
> +
> +unsigned long __ro_after_init signal_minsigstksz;
> +
> +/*
> + * Determine the stack space required for guaranteed signal devliery.
> + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> + * cpufeatures setup is assumed to be complete.
> + */
> +void __init minsigstksz_setup(void)
> +{
> + struct rt_sigframe_user_layout user;
> +
> + init_user_layout(&user);
> +
> + /*
> + * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
> + * be big enough, but it's our best guess:
> + */
> + if (WARN_ON(setup_sigframe_layout(&user, true)))
> + signal_minsigstksz = SIGFRAME_MAXSZ;
Can we not leave signal_minsigstksz as zero in this case?
Will
^ permalink raw reply
* [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening
From: Marc Zyngier @ 2018-05-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524123049.GY17671@n2100.armlinux.org.uk>
On 24/05/18 13:30, Russell King - ARM Linux wrote:
> On Thu, May 24, 2018 at 01:03:50PM +0100, Marc Zyngier wrote:
>> On 23/05/18 20:45, Russell King - ARM Linux wrote:
>>> On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:
>>>> On 21/05/18 12:45, Russell King wrote:
>>>>> +#ifdef CONFIG_ARM_PSCI
>>>>> + if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
>>>>> + struct arm_smccc_res res;
>>>>> +
>>>>> + switch (psci_ops.conduit) {
>>>>> + case PSCI_CONDUIT_HVC:
>>>>> + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>>>>> + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
>>>>> + if ((int)res.a0 < 0)
>>>>> + break;
>>>>
>>>> I just realised that there is a small, but significant difference
>>>> between this and the arm64 version: On arm64, we have a table of
>>>> vulnerable implementations, and we try the mitigation on a per-cpu
>>>> basis. Here, you entirely rely on the firmware to discover whether the
>>>> CPU needs mitigation or not. You then need to check for a return value
>>>> of 1, which indicates that although the mitigation is implemented, it is
>>>> not required on this particular CPU.
>>>
>>> Okay, so digging further into the documentation seems to suggest that we
>>> only need to check the firmware for A72 and A57 CPUs, and given this
>>> statement:
>>>
>>> "Arm recommends that the caller only call this on PEs for which a
>>> firmware based mitigation of CVE-2017-5715 is required, or where
>>> a local workaround is infeasible."
>>>
>>> it seems that the right answer is to ignore the PSCI based methods when
>>> we have anything but these CPUs. Do you agree?
>>
>> For CPUs that are produced by ARM, I agree. I don't know about CPUs
>> produced by ARM licensees though, so I'd rather use the opposite logic:
>> Use the firmware unless the CPU is one of those that can be easily
>> mitigated at EL1 (or isn't affected).
>
> The "or isn't affected" is the difficult bit - I guess we could match
> on the CPU vendor field though, and just reject all ARM CPUs that
> aren't explicitly listed as having a problem.
That seems sensible. ARM has published an exhaustive status for all its
cores, which we can trust. For architecture licensees, I'm not aware of
such a list, but I'd expect them to communicate one if they were affected.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening
From: Russell King - ARM Linux @ 2018-05-24 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dcd72fc1-4ec3-217e-30ed-00c6b6b2a122@arm.com>
On Thu, May 24, 2018 at 01:49:51PM +0100, Marc Zyngier wrote:
> On 24/05/18 13:30, Russell King - ARM Linux wrote:
> > On Thu, May 24, 2018 at 01:03:50PM +0100, Marc Zyngier wrote:
> >> On 23/05/18 20:45, Russell King - ARM Linux wrote:
> >>> On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:
> >>>> On 21/05/18 12:45, Russell King wrote:
> >>>>> +#ifdef CONFIG_ARM_PSCI
> >>>>> + if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
> >>>>> + struct arm_smccc_res res;
> >>>>> +
> >>>>> + switch (psci_ops.conduit) {
> >>>>> + case PSCI_CONDUIT_HVC:
> >>>>> + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> >>>>> + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> >>>>> + if ((int)res.a0 < 0)
> >>>>> + break;
> >>>>
> >>>> I just realised that there is a small, but significant difference
> >>>> between this and the arm64 version: On arm64, we have a table of
> >>>> vulnerable implementations, and we try the mitigation on a per-cpu
> >>>> basis. Here, you entirely rely on the firmware to discover whether the
> >>>> CPU needs mitigation or not. You then need to check for a return value
> >>>> of 1, which indicates that although the mitigation is implemented, it is
> >>>> not required on this particular CPU.
> >>>
> >>> Okay, so digging further into the documentation seems to suggest that we
> >>> only need to check the firmware for A72 and A57 CPUs, and given this
> >>> statement:
> >>>
> >>> "Arm recommends that the caller only call this on PEs for which a
> >>> firmware based mitigation of CVE-2017-5715 is required, or where
> >>> a local workaround is infeasible."
> >>>
> >>> it seems that the right answer is to ignore the PSCI based methods when
> >>> we have anything but these CPUs. Do you agree?
> >>
> >> For CPUs that are produced by ARM, I agree. I don't know about CPUs
> >> produced by ARM licensees though, so I'd rather use the opposite logic:
> >> Use the firmware unless the CPU is one of those that can be easily
> >> mitigated at EL1 (or isn't affected).
> >
> > The "or isn't affected" is the difficult bit - I guess we could match
> > on the CPU vendor field though, and just reject all ARM CPUs that
> > aren't explicitly listed as having a problem.
>
> That seems sensible. ARM has published an exhaustive status for all its
> cores, which we can trust. For architecture licensees, I'm not aware of
> such a list, but I'd expect them to communicate one if they were affected.
It's not that simple - there's an exhaustive list for those affected
cores, but it says that cores which aren't listed are unaffected.
If we want to explicitly list each core, we need a complete list of
both affected and unaffected cores to ensure that none are missed.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: Bjorn Helgaas @ 2018-05-24 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82656e20-e821-1944-3399-1667ceb27719@codeaurora.org>
On Thu, May 24, 2018 at 07:43:05AM -0400, Sinan Kaya wrote:
> On 5/23/2018 6:57 PM, Sinan Kaya wrote:
> >> The crash seems to indicate that the hpsa device attempted a DMA after
> >> we cleared the Root Port's PCI_COMMAND_MASTER, which means
> >> hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
> >> shutdown methods don't disable device DMA, so it's in good company).
> > All drivers are expected to shutdown DMA and interrupts in their shutdown()
> > routines. They can skip removing threads, data structures etc. but DMA and
> > interrupt disabling are required. This is the difference between shutdown()
> > and remove() callbacks.
>
> I found this note yesterday to see why we are not disabling the
> devices in the PCI core itself.
>
> pci_device_remove()
>
> /*
> * We would love to complain here if pci_dev->is_enabled is set, that
> * the driver should have called pci_disable_device(), but the
> * unfortunate fact is there are too many odd BIOS and bridge setups
> * that don't like drivers doing that all of the time.
> * Oh well, we can dream of sane hardware when we sleep, no matter how
> * horrible the crap we have to deal with is when we are awake...
> */
>
> Ryan, can you discard the previous patch and test this one instead?
> remove() path in hpsa driver seems to call pci_disable_device() via
>
> hpsa_remove_one()
> hpsa_free_pci_init()
>
> but nothing on the shutdown path.
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 4ed3d26..3823f04 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -8651,6 +8651,7 @@ static void hpsa_shutdown(struct pci_dev *pdev)
> h->access.set_intr_mask(h, HPSA_INTR_OFF);
> hpsa_free_irqs(h); /* init_one 4 */
> hpsa_disable_interrupt_mode(h); /* pci_init 2 */
> + pci_disable_device(h->pdev);
> }
I suspect this will make things "work" (if the device can't attempt
DMA, no Unsupported Request error will occur).
But I'm concerned that the reason for the DMA might that hpsa is
transferring buffers from system memory to the hpsa device, and if we
arbitrarily terminate those transfers with pci_disable_device(), we
may leave the hpsa device in an inconsistent state, e.g., with a dirty
filesystem.
But we really need guidance from an hpsa expert. I don't know the
filesystem/SCSI/hpsa details.
Bjorn
^ permalink raw reply
* [PATCH 6/9] asm-generic/bitops/atomic.h: Rewrite using atomic_fetch_*
From: Mark Rutland @ 2018-05-24 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524124734.GE8689@arm.com>
On Thu, May 24, 2018 at 01:47:39PM +0100, Will Deacon wrote:
> On Thu, May 24, 2018 at 02:44:10PM +0200, Peter Zijlstra wrote:
> > On Thu, May 24, 2018 at 11:59:43AM +0100, Will Deacon wrote:
> > > +static inline void set_bit(unsigned int nr, volatile unsigned long *p)
> > > {
> > > + p += BIT_WORD(nr);
> > > + atomic_long_fetch_or_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> > > }
> > >
> > > +static inline void clear_bit(unsigned int nr, volatile unsigned long *p)
> > > {
> > > + p += BIT_WORD(nr);
> > > + atomic_long_fetch_andnot_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> > > }
> > >
> > > +static inline void change_bit(unsigned int nr, volatile unsigned long *p)
> > > {
> > > + p += BIT_WORD(nr);
> > > + atomic_long_fetch_xor_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> > > }
> >
> > Why use the fetch variants here?
>
> I noticed the same thing just now; I'll drop that and just use the
> non-value-returning variants. It's shame that I can't do the same for
> the lock.h unlock code, but we don't have non-returning release variants.
As an aside, If I complete the autogeneration stuff, it'll be possible
to generate those. I split out the necessary barriers in [1], but I
still have a lot of other preparatory cleanup to do.
IIUC, the void-returning atomic ops are relaxed, so trying to unify that
with the usual rule that no suffix means fence will slow things down
unless we want to do a treewide substitition to fixup for that.
Thanks,
Mark.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=atomics/api-unification&id=c6b9ff2627d06776e427a7f1a7f83caeff3db536
^ permalink raw reply
* [PATCH 0/3] Dts nodes for Keystone2 hw_rng driver
From: Vitaly Andrianov @ 2018-05-24 13:12 UTC (permalink / raw)
To: linux-arm-kernel
This series adds dts nodes for Keystone2 hw_rng driver
Vitaly Andrianov (3):
ARM: dts: k2hk: add dts node for k2hk hw_rng driver
ARM: dts: k2l: add dts node for k2l hw_rng driver
ARM: dts: k2e: add dts node for k2e hw_rng driver
arch/arm/boot/dts/keystone-k2e-netcp.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2hk-netcp.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2l-netcp.dtsi | 20 ++++++++++++++++++++
3 files changed, 60 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] ARM: dts: k2hk: add dts node for k2hk hw_rng driver
From: Vitaly Andrianov @ 2018-05-24 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527167538-29837-1-git-send-email-vitalya@ti.com>
This patch adds dts node for k2hk hw_random generator driver
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
[t-kristo at ti.com: added missing addresses from node identifiers]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
arch/arm/boot/dts/keystone-k2hk-netcp.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk-netcp.dtsi b/arch/arm/boot/dts/keystone-k2hk-netcp.dtsi
index b88c068..e203145 100644
--- a/arch/arm/boot/dts/keystone-k2hk-netcp.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk-netcp.dtsi
@@ -228,3 +228,23 @@ netcp: netcp at 2000000 {
};
};
};
+
+sa_subsys: subsys at 20c0000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x20c0000 0x40000>;
+
+ sa_config: subsys at 0 {
+ compatible = "syscon";
+ reg = <0x0 0x100>;
+ };
+
+ rng at 24000 {
+ compatible = "ti,keystone-rng";
+ reg = <0x24000 0x1000>;
+ ti,syscon-sa-cfg = <&sa_config>;
+ clocks = <&clksa>;
+ clock-names = "fck";
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: k2l: add dts node for k2l hw_rng driver
From: Vitaly Andrianov @ 2018-05-24 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527167538-29837-1-git-send-email-vitalya@ti.com>
This patch adds dts node for k2l hw_random generator driver
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
[t-kristo at ti.com: added missing addresses from node identifiers]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
arch/arm/boot/dts/keystone-k2l-netcp.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l-netcp.dtsi b/arch/arm/boot/dts/keystone-k2l-netcp.dtsi
index 9ec8422..a2e47ba 100644
--- a/arch/arm/boot/dts/keystone-k2l-netcp.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l-netcp.dtsi
@@ -208,3 +208,23 @@ netcp: netcp at 26000000 {
};
};
};
+
+sa_subsys: subsys at 26080000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x26080000 0x40000>;
+
+ sa_config: subsys at 0 {
+ compatible = "syscon";
+ reg = <0x0 0x100>;
+ };
+
+ rng at 24000 {
+ compatible = "ti,keystone-rng";
+ reg = <0x24000 0x1000>;
+ ti,syscon-sa-cfg = <&sa_config>;
+ clocks = <&clksa>;
+ clock-names = "fck";
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: k2e: add dts node for k2e hw_rng driver
From: Vitaly Andrianov @ 2018-05-24 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527167538-29837-1-git-send-email-vitalya@ti.com>
This patch adds dts node for k2e hw_random generator driver
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
---
arch/arm/boot/dts/keystone-k2e-netcp.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2e-netcp.dtsi b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
index a17311c..1db17ec 100644
--- a/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
@@ -225,3 +225,23 @@ netcp: netcp at 24000000 {
};
};
};
+
+sa_subsys: subsys at 24080000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x24080000 0x40000>;
+
+ sa_config: subsys at 0 {
+ compatible = "syscon";
+ reg = <0x0 0x100>;
+ };
+
+ rng at 24000 {
+ compatible = "ti,keystone-rng";
+ reg = <0x24000 0x1000>;
+ ti,syscon-sa-cfg = <&sa_config>;
+ clocks = <&clksa>;
+ clock-names = "fck";
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-24 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdX-t8WfjRKpZ7UxXBbBNojsn-8z7_BM9grmLJcf=9Ks2Q@mail.gmail.com>
On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
>>> does not distinguish between the absence of the clock property, and an
>>> actual error in getting the clock, and never considers any error a failure
>>> (incl. -PROBE_DEFER).
>>>
>>> As of_clk_get() returns -ENOENT for both a missing clock property and a
>>> missing clock, you should use (devm_)clk_get() instead, and distinguish
>>> between NULL (no clock property) and IS_ERR() (actual failure -> abort).
>>
>> I was trying to do as you suggested but I didn't quite get what is the
>> dev_id (2nd) parameter to devm_clk_get parameter is supposed to be.
>
> It's the (optional) name of the clock, helpful in case there is more than one.
> In your case, NULL is fine.
>
I have assumed as much and tried it, it did not work and so I assumed
I am missing something and asked you.
It turns out I was missing the fact I was using the wrong device tree
file... :-(
So thanks, it works now :-)
Having said that, while using devm)clk_get() is a better approach, it
does not seems to distinguish
between no "clocks" and a failure to clock information - it returns
ENOENT in both cases as well.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [GIT PULL] Rockchip driver updates for 4.18 round 2
From: Heiko Stuebner @ 2018-05-24 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin Olof,
please find below a second pull request for Rockchip-specific drivers,
adding power-domain support for some more socs on top of the
previous git tag.
If it looks ok, please pull
Heiko
The following changes since commit 9e59c5f66c624b43c766a9fe3b2430e0e976bf0e:
soc: rockchip: power-domain: Fix wrong value when power up pd with writemask (2018-05-14 11:53:26 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-drivers-2
for you to fetch changes up to 9bdf401bf49eddba98ae36f7243b888d43496bd6:
soc: rockchip: power-domain: add power domain support for px30 (2018-05-23 20:47:57 +0200)
----------------------------------------------------------------
Power-domain support for Rockchip socs px30, rk3128, rk3228 and rk3036.
----------------------------------------------------------------
Caesar Wang (3):
dt-bindings: power: add RK3036 SoCs header for power-domain
dt-bindings: power: add binding for rk3036 power domains
soc: rockchip: power-domain: add power domain support for rk3036
Elaine Zhang (6):
dt-bindings: power: add RK3128 SoCs header for power-domain
dt-bindings: power: add binding for rk3128 power domains
soc: rockchip: power-domain: add power domain support for rk3128
dt-bindings: power: add RK3228 SoCs header for power-domain
dt-bindings: power: add binding for rk3228 power domains
soc: rockchip: power-domain: add power domain support for rk3228
Finley Xiao (3):
dt-bindings: power: add PX30 SoCs header for power-domain
dt-bindings: power: add binding for px30 power domains
soc: rockchip: power-domain: add power domain support for px30
.../bindings/soc/rockchip/power_domain.txt | 12 +++
drivers/soc/rockchip/pm_domains.c | 115 +++++++++++++++++++++
include/dt-bindings/power/px30-power.h | 27 +++++
include/dt-bindings/power/rk3036-power.h | 13 +++
include/dt-bindings/power/rk3128-power.h | 14 +++
include/dt-bindings/power/rk3228-power.h | 21 ++++
6 files changed, 202 insertions(+)
create mode 100644 include/dt-bindings/power/px30-power.h
create mode 100644 include/dt-bindings/power/rk3036-power.h
create mode 100644 include/dt-bindings/power/rk3128-power.h
create mode 100644 include/dt-bindings/power/rk3228-power.h
^ permalink raw reply
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Robin Murphy @ 2018-05-24 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523181058.GC27570@roeck-us.net>
On 23/05/18 19:10, Guenter Roeck wrote:
> On Wed, May 23, 2018 at 11:57:25AM +0100, Robin Murphy wrote:
>> On 22/05/18 19:47, Ray Jui wrote:
>>> Update the SP805 binding document to add optional 'timeout-sec'
>>> devicetree property
>>>
>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>>> Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>> index edc4f0e..f898a86 100644
>>> --- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>> +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>> @@ -19,6 +19,8 @@ Required properties:
>>> Optional properties:
>>> - interrupts : Should specify WDT interrupt number.
>>> +- timeout-sec : Should specify default WDT timeout in seconds. If unset, the
>>> + default timeout is 30 seconds
>>
>> According to the SP805 TRM, the default interval is dependent on the rate of
>> WDOGCLK, but would typically be a lot longer than that :/
>>
> Depends on the definition of "default". In the context of watchdog drivers,
> it is (or should be) a driver default, not a chip default.
DT describes hardware, not driver behaviour.
I appreciate that where a timeout *is* specified, that is effectively a
hardware aspect even if it's something an OS consuming the binding still
has to voluntarily program into the device. The notion of "this is the
longest period of time for which you can reasonably expect to see no
activity under normal operation" is indeed a property of the platform as
a whole - a system with user-accessible PCIe slots may need to reflect
the worst case of one CPU waiting for an ATS invalidation timeout with
interrupts disabled, whereas a much shorter period might be appropriate
for the same SoC in some closed-down embedded device.
The absence of the property, though, doesn't convey anything other than
"I don't know" and/or "it doesn't really matter", and in that situation
the default is always going to be "whatever the OS thinks is
appropriate". The binding itself can't possibly know, whereas an OS
might be configured for some pseudo-real-time application which it knows
warrants a maximum of 100ms regardless of what the DT does or doesn't
say. In the case of SP805, if the OS doesn't reconfigure it at all,
there happens to be an actual hardware default of (2^32 / WDOGCLK), but
since that's already implicit in the compatible it doesn't really need
saying either.
Optional properties don't need to explicitly state what their absence
might infer, especially when it's not directly meaningful (just imagine
trying to do that for bindings/regulator/regulator.txt...), so I would
suggest following the 93% of existing bindings which simply don't try to
claim some default value for this property.
I also think the fact that, within the context of this patch series, the
Linux driver doesn't even do what the binding claims only goes to help
make my point ;)
Robin.
^ permalink raw reply
* [PATCH 04/14] arm64: Add ARCH_WORKAROUND_2 probing
From: Suzuki K Poulose @ 2018-05-24 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524113933.GA8689@arm.com>
On 24/05/18 12:39, Will Deacon wrote:
> On Thu, May 24, 2018 at 10:58:43AM +0100, Suzuki K Poulose wrote:
>> On 22/05/18 16:06, Marc Zyngier wrote:
>>> As for Spectre variant-2, we rely on SMCCC 1.1 to provide the
>>> discovery mechanism for detecting the SSBD mitigation.
>>>
>>> A new capability is also allocated for that purpose, and a
>>> config option.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>>
>>> +static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
>>> + int scope)
>>> +{
>>> + struct arm_smccc_res res;
>>> + bool supported = true;
>>> +
>>> + WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
>>> +
>>> + if (psci_ops.smccc_version == SMCCC_VERSION_1_0)
>>> + return false;
>>> +
>>> + /*
>>> + * The probe function return value is either negative
>>> + * (unsupported or mitigated), positive (unaffected), or zero
>>> + * (requires mitigation). We only need to do anything in the
>>> + * last case.
>>> + */
>>> + switch (psci_ops.conduit) {
>>> + case PSCI_CONDUIT_HVC:
>>> + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>>> + ARM_SMCCC_ARCH_WORKAROUND_2, &res);
>>> + if ((int)res.a0 != 0)
>>> + supported = false;
>>> + break;
>>> +
>>> + case PSCI_CONDUIT_SMC:
>>> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>>> + ARM_SMCCC_ARCH_WORKAROUND_2, &res);
>>> + if ((int)res.a0 != 0)
>>> + supported = false;
>>> + break;
>>> +
>>> + default:
>>> + supported = false;
>>> + }
>>> +
>>> + if (supported) {
>>> + __this_cpu_write(arm64_ssbd_callback_required, 1);
>>> + do_ssbd(true);
>>> + }
>>
>>
>> Marc,
>>
>> As discussed, we have minor issue with the "corner case". If a CPU
>> is hotplugged in which requires the mitigation, after the system has
>> finalised the cap to "not available", the CPU could go ahead and
>> do the "work around" as above, while not effectively doing anything
>> about it at runtime for KVM guests (as thats the only place where
>> we rely on the CAP being set).
>>
>> But, yes this is real corner case. There is no easy way to solve it
>> other than
>>
>> 1) Allow late modifications to CPU hwcaps
>>
>> OR
>>
>> 2) Penalise the fastpath to always check per-cpu setting.
>
> Shouldn't we just avoid bring up CPUs that require the mitigation after
> we've finalised the capability to say that it's not required? Assuming this
> is just another issue with maxcpus=, then I don't much care for it.
Ah! Sorry, yes we do kill the CPU. But it is just that it will set the
ssbd_callback_required flag and issue the do_ssbd(), which is not an issue.
Yes this can only be triggered by maxcpus=.
Suzuki
^ permalink raw reply
* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: okaya at codeaurora.org @ 2018-05-24 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524130727.GA85822@bhelgaas-glaptop.roam.corp.google.com>
On 2018-05-24 09:07, Bjorn Helgaas wrote:
> On Thu, May 24, 2018 at 07:43:05AM -0400, Sinan Kaya wrote:
>> On 5/23/2018 6:57 PM, Sinan Kaya wrote:
>> >> The crash seems to indicate that the hpsa device attempted a DMA after
>> >> we cleared the Root Port's PCI_COMMAND_MASTER, which means
>> >> hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
>> >> shutdown methods don't disable device DMA, so it's in good company).
>> > All drivers are expected to shutdown DMA and interrupts in their shutdown()
>> > routines. They can skip removing threads, data structures etc. but DMA and
>> > interrupt disabling are required. This is the difference between shutdown()
>> > and remove() callbacks.
>>
>> I found this note yesterday to see why we are not disabling the
>> devices in the PCI core itself.
>>
>> pci_device_remove()
>>
>> /*
>> * We would love to complain here if pci_dev->is_enabled is set, that
>> * the driver should have called pci_disable_device(), but the
>> * unfortunate fact is there are too many odd BIOS and bridge setups
>> * that don't like drivers doing that all of the time.
>> * Oh well, we can dream of sane hardware when we sleep, no matter
>> how
>> * horrible the crap we have to deal with is when we are awake...
>> */
>>
>> Ryan, can you discard the previous patch and test this one instead?
>> remove() path in hpsa driver seems to call pci_disable_device() via
>>
>> hpsa_remove_one()
>> hpsa_free_pci_init()
>>
>> but nothing on the shutdown path.
>>
>> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
>> index 4ed3d26..3823f04 100644
>> --- a/drivers/scsi/hpsa.c
>> +++ b/drivers/scsi/hpsa.c
>> @@ -8651,6 +8651,7 @@ static void hpsa_shutdown(struct pci_dev *pdev)
>> h->access.set_intr_mask(h, HPSA_INTR_OFF);
>> hpsa_free_irqs(h); /* init_one 4 */
>> hpsa_disable_interrupt_mode(h); /* pci_init 2 */
>> + pci_disable_device(h->pdev);
>> }
>
> I suspect this will make things "work" (if the device can't attempt
> DMA, no Unsupported Request error will occur).
>
> But I'm concerned that the reason for the DMA might that hpsa is
> transferring buffers from system memory to the hpsa device, and if we
> arbitrarily terminate those transfers with pci_disable_device(), we
> may leave the hpsa device in an inconsistent state, e.g., with a dirty
> filesystem.
>
> But we really need guidance from an hpsa expert. I don't know the
> filesystem/SCSI/hpsa details.
Agreed,
We can drop shutdown and use the remove callback. Remove is supposed to
do a safe cleanup.
>
> Bjorn
^ permalink raw reply
* [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
From: Don Brace @ 2018-05-24 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524130727.GA85822@bhelgaas-glaptop.roam.corp.google.com>
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: Thursday, May 24, 2018 8:07 AM
> To: Sinan Kaya <okaya@codeaurora.org>
> Cc: linux-pci at vger.kernel.org; timur at codeaurora.org; ryan at finnie.org; linux-
> arm-msm at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> stable at vger.kernel.org; Bjorn Helgaas <bhelgaas@google.com>; Rafael J.
> Wysocki <rafael.j.wysocki@intel.com>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Thomas Gleixner <tglx@linutronix.de>; Kate
> Stewart <kstewart@linuxfoundation.org>; Frederick Lawler
> <fred@fredlawl.com>; Dongdong Liu <liudongdong3@huawei.com>; Mika
> Westerberg <mika.westerberg@linux.intel.com>; open list <linux-
> kernel at vger.kernel.org>; Don Brace <don.brace@microsemi.com>;
> esc.storagedev <esc.storagedev@microsemi.com>; linux-scsi at vger.kernel.org
> Subject: Re: [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown
>
> EXTERNAL EMAIL
>
>
> On Thu, May 24, 2018 at 07:43:05AM -0400, Sinan Kaya wrote:
> > On 5/23/2018 6:57 PM, Sinan Kaya wrote:
> > >> The crash seems to indicate that the hpsa device attempted a DMA after
> > >> we cleared the Root Port's PCI_COMMAND_MASTER, which means
> > >> hpsa_shutdown() didn't stop DMA from the device (it looks like *most*
> > >> shutdown methods don't disable device DMA, so it's in good company).
> > > All drivers are expected to shutdown DMA and interrupts in their shutdown()
> > > routines. They can skip removing threads, data structures etc. but DMA and
> > > interrupt disabling are required. This is the difference between shutdown()
> > > and remove() callbacks.
> >
> > I found this note yesterday to see why we are not disabling the
> > devices in the PCI core itself.
> >
> > pci_device_remove()
> >
> > /*
> > * We would love to complain here if pci_dev->is_enabled is set, that
> > * the driver should have called pci_disable_device(), but the
> > * unfortunate fact is there are too many odd BIOS and bridge setups
> > * that don't like drivers doing that all of the time.
> > * Oh well, we can dream of sane hardware when we sleep, no matter how
> > * horrible the crap we have to deal with is when we are awake...
> > */
> >
> > Ryan, can you discard the previous patch and test this one instead?
> > remove() path in hpsa driver seems to call pci_disable_device() via
> >
> > hpsa_remove_one()
> > hpsa_free_pci_init()
> >
> > but nothing on the shutdown path.
> >
> > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> > index 4ed3d26..3823f04 100644
> > --- a/drivers/scsi/hpsa.c
> > +++ b/drivers/scsi/hpsa.c
> > @@ -8651,6 +8651,7 @@ static void hpsa_shutdown(struct pci_dev *pdev)
> > h->access.set_intr_mask(h, HPSA_INTR_OFF);
> > hpsa_free_irqs(h); /* init_one 4 */
> > hpsa_disable_interrupt_mode(h); /* pci_init 2 */
> > + pci_disable_device(h->pdev);
> > }
>
> I suspect this will make things "work" (if the device can't attempt
> DMA, no Unsupported Request error will occur).
>
> But I'm concerned that the reason for the DMA might that hpsa is
> transferring buffers from system memory to the hpsa device, and if we
> arbitrarily terminate those transfers with pci_disable_device(), we
> may leave the hpsa device in an inconsistent state, e.g., with a dirty
> filesystem.
>
> But we really need guidance from an hpsa expert. I don't know the
> filesystem/SCSI/hpsa details.
>
> Bjorn
It's most likely OCSD traffic that will stop when bus mastering is turned off.
So, I'll run some tests on my end before ACKing your patch.
Thanks,
Don Brace
ESC - Smart Storage
Microsemi Corporation
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Rob Herring @ 2018-05-24 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3307687.qJF5Pr3uHG@phil>
On Thu, May 24, 2018 at 7:07 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> Hi Rob,
>
> Am Mittwoch, 23. Mai 2018, 21:53:53 CEST schrieb Rob Herring:
>> On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
>> > Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
>> >> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
>> >> > On 2018-05-23 2:02 AM, Rob Herring wrote:
>> >> >> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
>> >> >>> From: Levin Du <djw@t-chip.com.cn>
>> >> >>>
>> >> >>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>> >> >>> which do not belong to the general pinctrl.
>> >> >>>
>> >> >>> Adding gpio-syscon support makes controlling regulator or
>> >> >>> LED using these special pins very easy by reusing existing
>> >> >>> drivers, such as gpio-regulator and led-gpio.
>> >> >>>
>> >> >>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>> >> >>>
>> >> >>> ---
>> >> >>>
>> >> >>> Changes in v2:
>> >> >>> - Rename gpio_syscon10 to gpio_mute in doc
>> >> >>>
>> >> >>> Changes in v1:
>> >> >>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>> >> >>> - Add doc rockchip,gpio-syscon.txt
>> >> >>>
>> >> >>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>> >> >>>
>> >> >>> ++++++++++++++++++++++
>> >> >>>
>> >> >>> drivers/gpio/gpio-syscon.c | 30
>> >> >>>
>> >> >>> ++++++++++++++++
>> >> >>>
>> >> >>> 2 files changed, 71 insertions(+)
>> >> >>> create mode 100644
>> >> >>>
>> >> >>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >> >>>
>> >> >>> diff --git
>> >> >>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >> >>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >> >>> new file mode 100644
>> >> >>> index 0000000..b1b2a67
>> >> >>> --- /dev/null
>> >> >>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>> >> >>> @@ -0,0 +1,41 @@
>> >> >>> +* Rockchip GPIO support for GRF_SOC_CON registers
>> >> >>> +
>> >> >>> +Required properties:
>> >> >>> +- compatible: Should contain "rockchip,gpio-syscon".
>> >> >>> +- gpio-controller: Marks the device node as a gpio controller.
>> >> >>> +- #gpio-cells: Should be two. The first cell is the pin number and
>> >> >>> + the second cell is used to specify the gpio polarity:
>> >> >>> + 0 = Active high,
>> >> >>> + 1 = Active low.
>> >> >>
>> >> >> There's no need for this child node. Just make the parent node a gpio
>> >> >> controller.
>> >> >>
>> >> >> Rob
>> >> >
>> >> > Hi Rob, it is not clear to me. Do you suggest that the grf node should be
>> >> > a
>> >> > gpio controller,
>> >> > like below?
>> >> >
>> >> > + grf: syscon at ff100000 {
>> >> > + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
>> >> > "syscon", "simple-mfd";
>> >>
>> >> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
>> >
>> > I would disagree quite a bit here. The grf are the "general register files",
>> > a bunch of registers used for quite a lot of things, and so it seems
>> > among other users, also a gpio-controller for some more random pins
>> > not controlled through the regular gpio controllers.
>> >
>> > For a more fully stocked grf, please see
>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
>> >
>> > So the gpio controller should definitly also be a subnode.
>>
>> Sigh, yes, if there are a bunch of functions needing subnodes like the
>> above, then yes that makes sense. But that's not what has been
>> presented. Please make some attempt at defining *all* the functions.
>> An actual binding would be nice, but I'll settle for just a list of
>> things. The list should have functions that have DT dependencies (like
>> clocks for phys in the above) because until you do, you don't need
>> child nodes.
>
> That's the problem with the Rockchip-GRF, you only realize its content
> when implementing specific features.
>
> Like on the rk3399 the table of the register-list of the GRF alone is 11
> pages long with the register details tables taking up another 230 pages.
> And functional description is often somewhat thin.
But surely one can scan thru it and have some clue what functions
there are. For example, does this chip have phy registers in GRF?
> So I'm not sure I fully understand what you're asking, but in general
> we define the bindings for sub-devices when tackling these individual
> components, see for example
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=72580a49a837c2c7da83f698c00592eac41537d8
Yes, and in that case it makes sense. The individual functions
themselves have resources defined in DT like clocks. What I don't want
to see are child nodes defining *only* a compatible and any provider
properties (e.g. #gpio-cells). The only reason to do that is to make
Linux bind a driver, but DT is not a list of drivers to bind.
This is what I don't want to see:
syscon {
compatible = "foo,soc-sysctrl", "syscon", "simple-mfd";
reg = <...>;
clock-controller {
compatible = "foo,soc-sysctrl-clocks";
#clock-cells = <1>;
};
reset-controller {
compatible = "foo,soc-sysctrl-resets";
#reset-cells = <1>;
};
gpio {
compatible = "foo,soc-sysctrl-gpios";
#gpio-cells = <2>;
gpio-controller;
};
};
But rather:
syscon {
compatible = "foo,soc-sysctrl";
reg = <...>;
#clock-cells = <1>;
#reset-cells = <1>;
#gpio-cells = <2>;
gpio-controller;
};
> which also has a real phy-driver behind it and binding against that
> subnode of the GRF simple-mfd.
>
> These are real IP blocks somewhere on the socs, with regular supplies
> like resets, clocks etc in most cases. Only their controlling registers
> got dumped into the GRF for some reason.
I can tell that from your examples, but I can't tell that with this
binding. For this binding, it looks like you are adding a sub-node for
1 register bit. That wouldn't scale if you have 11 page register list.
> And in retrospect it really looks like we're doing something right,
> because it seems these bindings seem quite stable over time.
>
>
>> > The gpio in question is called "mute", so I'd think the gpio-syscon driver
>> > should just define a "rockchip,rk3328-gpio-mute" compatible and contain
>> > all the register voodoo in the driver itself and not define it in the dt.
>>
>> Is there really just one GPIO? If it has a defined function, then is
>> it really GP? Can you control direction? I know Linus W doesn't like
>> that kind of abuse of GPIO.
>
> looks like I convinced Linus that we're not abusing anything with this :-) .
Okay, but still my question remains: is it really only 1 GPIO?
Dropping "-mute" would be more future proof if not.
Rob
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Geert Uytterhoeven @ 2018-05-24 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOtvUMdCSoxYjpyb+fD36EE5+4sV4CjrxwK94RQ7bNKE5rajmQ@mail.gmail.com>
Hi Gilad,
On Thu, May 24, 2018 at 3:20 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
>>>> does not distinguish between the absence of the clock property, and an
>>>> actual error in getting the clock, and never considers any error a failure
>>>> (incl. -PROBE_DEFER).
>>>>
>>>> As of_clk_get() returns -ENOENT for both a missing clock property and a
>>>> missing clock, you should use (devm_)clk_get() instead, and distinguish
>>>> between NULL (no clock property) and IS_ERR() (actual failure -> abort).
>>>
>>> I was trying to do as you suggested but I didn't quite get what is the
>>> dev_id (2nd) parameter to devm_clk_get parameter is supposed to be.
>>
>> It's the (optional) name of the clock, helpful in case there is more than one.
>> In your case, NULL is fine.
>
> I have assumed as much and tried it, it did not work and so I assumed
> I am missing something and asked you.
> It turns out I was missing the fact I was using the wrong device tree
> file... :-(
>
> So thanks, it works now :-)
Glad to hear that!
> Having said that, while using devm)clk_get() is a better approach, it
> does not seems to distinguish
> between no "clocks" and a failure to clock information - it returns
> ENOENT in both cases as well.
Oh right, I guess I'm too used to not even getting that far due to the PM
Domain code failing to obtain the clock...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Robin Murphy @ 2018-05-24 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b0ec4ab-2d9e-1e4b-e294-c175805f4013@broadcom.com>
On 23/05/18 20:29, Ray Jui wrote:
>
>
> On 5/23/2018 11:59 AM, Rob Herring wrote:
>> On Wed, May 23, 2018 at 09:25:49AM -0700, Ray Jui wrote:
>>>
>>>
>>> On 5/23/2018 3:57 AM, Robin Murphy wrote:
>>>> On 22/05/18 19:47, Ray Jui wrote:
>>>>> Update the SP805 binding document to add optional 'timeout-sec'
>>>>> devicetree property
>>>>>
>>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>>>> ---
>>>>> ?? Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
>>>>> ?? 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>>> b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>>> index edc4f0e..f898a86 100644
>>>>> --- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>>> +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>>>> @@ -19,6 +19,8 @@ Required properties:
>>>>> ?? Optional properties:
>>>>> ?? - interrupts : Should specify WDT interrupt number.
>>>>> +- timeout-sec : Should specify default WDT timeout in seconds. If
>>>>> unset, the
>>>>> +??????????????? default timeout is 30 seconds
>>>>
>>>> According to the SP805 TRM, the default interval is dependent on the
>>>> rate of WDOGCLK, but would typically be a lot longer than that :/
>>>>
>>>> On a related note, anyone have any idea why we seem to have two subtly
>>>> different SP805 bindings defined?
>>
>> Sigh.
>>
>>> Interesting, I did not even know that until you pointed this out (and
>>> it's
>>> funny that I found that I actually reviewed arm,sp805.txt internally in
>>> Broadcom code review).
>>>
>>> It looks like one was done by Bhupesh Sharma (sp805-wdt.txt) and the
>>> other
>>> was done by Anup Patel (arm,sp805.txt). Both were merged at the same
>>> time
>>> around March 20, 2016: 915c56bc01d6. I'd assume both were sent out at
>>> around
>>> the same time.
>>>
>>> It sounds like we should definitely remove one of them. Given that
>>> sp805-wdt.txt appears to have more detailed descriptions on the use
>>> of the
>>> clocks, should we remove arm,sp805.txt?
>>
>> Take whichever text you like, but I prefer filenames using the
>> compatible string and the correct string is 'arm,sp805' because '-wdt'
>> is redundant. You can probably safely just update all the dts files with
>> 'arm,sp805' and just remove 'arm,sp805-wdt' because it is not actually
>> used (as the ID registers are).
>
> Okay. I'll consolidate everything into arm,sp805.txt. Will also fix all
> DTS files to use "arm,sp805". The fix for actual DTS files will be in a
> different patch series.
Looking at the current in-tree DTs, for extra fun try to figure out
which binding each instance was following for the clocks. The most
common answer seems to be "neither"... :(
Robin.
^ permalink raw reply
* [PATCH v10 0/4] Fix issues with huge mapping in ioremap for ARM64
From: Chintan Pandya @ 2018-05-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
This series of patches re-bring huge vmap back for arm64.
Patch 1/4 has been taken by Toshi in his series of patches
by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86"
to avoid merge conflict with this series.
Patch 4/4 may conflict with Laura's patch "[PATCHv2] arm64: Make
sure permission updates happen for pmd/pud". It looks to me that,
problem addressed by this patch will also get resolved by below
series of patches. There could be multiple ways to resolve this.
I would let maintainer suggest the best approach, and I will do
the needful.
This patches are tested on 4.16 kernel with Cortex-A75 based SoC.
The test used for verifying these patches is a stress test on
ioremap/unmap which tries to re-use same io-address but changes
size of mapping randomly i.e. 4K to 2M to 16K etc. The same test
used to reproduce 3rd level translation fault without these fixes
(and also of course with Revert "arm64: Enforce BBM for huge IO/VMAP
mappings" being part of the tree).
These patches can also go into '-stable' branch (if accepted)
for 4.6 onwards.
>From V9->V10:
- Updated commit log for patch 1/4 by Toshi
- Addressed review comments by Will on patch 3/4
>From V8->V9:
- Used __TLBI_VADDR macros in new TLB flush API
>From V7->V8:
- Properly fixed compilation issue in x86 file
>From V6->V7:
- Fixed compilation issue in x86 case
- V6 patches were not properly enumarated
>From V5->V6:
- Use __flush_tlb_kernel_pgtable() for both PUD and PMD. Remove
"bool tlb_inv" based variance as it is not need now
- Re-naming for consistency
>From V4->V5:
- Add new API __flush_tlb_kernel_pgtable(unsigned long addr)
for kernel addresses
>From V3->V4:
- Add header for 'addr' in x86 implementation
- Re-order pmd/pud clear and table free
- Avoid redundant TLB invalidatation in one perticular case
>From V2->V3:
- Use the exisiting page table free interface to do arm64
specific things
>From V1->V2:
- Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
- Honored BBM for ARM64
Chintan Pandya (4):
ioremap: Update pgtable free interfaces with addr
arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
arm64: Implement page table free interfaces
Revert "arm64: Enforce BBM for huge IO/VMAP mappings"
arch/arm64/include/asm/tlbflush.h | 7 +++++++
arch/arm64/mm/mmu.c | 42 ++++++++++++++++++++++++++++-----------
arch/x86/mm/pgtable.c | 8 +++++---
include/asm-generic/pgtable.h | 8 ++++----
lib/ioremap.c | 4 ++--
5 files changed, 48 insertions(+), 21 deletions(-)
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH v10 1/4] ioremap: Update pgtable free interfaces with addr
From: Chintan Pandya @ 2018-05-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527170250-5291-1-git-send-email-cpandya@codeaurora.org>
From: Chintan Pandya <cpandya@codeaurora.org>
The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.
1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4. CPU may hit an exception because the old pmd entry is still in TLB,
which leads to a kernel panic.
Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
table") has addressed this panic by falling to pte mappings in the above
case on ARM64.
To support pmd mappings in all cases, TLB purge needs to be performed
in this case on ARM64.
Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
so that TLB purge can be added later in seprate patches.
[toshi at hpe.com: merge changes, rewrite patch description]
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
arch/arm64/mm/mmu.c | 4 ++--
arch/x86/mm/pgtable.c | 8 +++++---
include/asm-generic/pgtable.h | 8 ++++----
lib/ioremap.c | 4 ++--
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..da98828 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -973,12 +973,12 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return pud_none(*pud);
}
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return pmd_none(*pmd);
}
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index ffc8c13..37e3cba 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -718,11 +718,12 @@ int pmd_clear_huge(pmd_t *pmd)
/**
* pud_free_pmd_page - Clear pud entry and free pmd page.
* @pud: Pointer to a PUD.
+ * @addr: Virtual address associated with pud.
*
* Context: The pud range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
pmd_t *pmd;
int i;
@@ -733,7 +734,7 @@ int pud_free_pmd_page(pud_t *pud)
pmd = (pmd_t *)pud_page_vaddr(*pud);
for (i = 0; i < PTRS_PER_PMD; i++)
- if (!pmd_free_pte_page(&pmd[i]))
+ if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
return 0;
pud_clear(pud);
@@ -745,11 +746,12 @@ int pud_free_pmd_page(pud_t *pud)
/**
* pmd_free_pte_page - Clear pmd entry and free pte page.
* @pmd: Pointer to a PMD.
+ * @addr: Virtual address associated with pmd.
*
* Context: The pmd range has been unmaped and TLB purged.
* Return: 1 if clearing the entry succeeded. 0 otherwise.
*/
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
pte_t *pte;
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index f59639a..b081794 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1019,8 +1019,8 @@ static inline int p4d_clear_huge(p4d_t *p4d)
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
-int pud_free_pmd_page(pud_t *pud);
-int pmd_free_pte_page(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud, unsigned long addr);
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
{
@@ -1046,11 +1046,11 @@ static inline int pmd_clear_huge(pmd_t *pmd)
{
return 0;
}
-static inline int pud_free_pmd_page(pud_t *pud)
+static inline int pud_free_pmd_page(pud_t *pud, unsigned long addr)
{
return 0;
}
-static inline int pmd_free_pte_page(pmd_t *pmd)
+static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
{
return 0;
}
diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bba..517f585 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -92,7 +92,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
- pmd_free_pte_page(pmd)) {
+ pmd_free_pte_page(pmd, addr)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -119,7 +119,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
- pud_free_pmd_page(pud)) {
+ pud_free_pmd_page(pud, addr)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply related
* [PATCH v10 2/4] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
From: Chintan Pandya @ 2018-05-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527170250-5291-1-git-send-email-cpandya@codeaurora.org>
Add an interface to invalidate intermediate page tables
from TLB for kernel.
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
---
arch/arm64/include/asm/tlbflush.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index dfc61d7..a4a1901 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -218,6 +218,13 @@ static inline void __flush_tlb_pgtable(struct mm_struct *mm,
dsb(ish);
}
+static inline void __flush_tlb_kernel_pgtable(unsigned long kaddr)
+{
+ unsigned long addr = __TLBI_VADDR(kaddr, 0);
+
+ __tlbi(vaae1is, addr);
+ dsb(ish);
+}
#endif
#endif
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply related
* [PATCH v10 3/4] arm64: Implement page table free interfaces
From: Chintan Pandya @ 2018-05-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527170250-5291-1-git-send-email-cpandya@codeaurora.org>
Implement pud_free_pmd_page() and pmd_free_pte_page().
Implementation requires,
1) Clearing off the current pud/pmd entry
2) Invalidate TLB which could have previously
valid but not stale entry
3) Freeing of the un-used next level page tables
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
---
arch/arm64/mm/mmu.c | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index da98828..17d9282 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -45,6 +45,7 @@
#include <asm/memblock.h>
#include <asm/mmu_context.h>
#include <asm/ptdump.h>
+#include <asm/tlbflush.h>
#define NO_BLOCK_MAPPINGS BIT(0)
#define NO_CONT_MAPPINGS BIT(1)
@@ -973,12 +974,37 @@ int pmd_clear_huge(pmd_t *pmdp)
return 1;
}
-int pud_free_pmd_page(pud_t *pud, unsigned long addr)
+int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
{
- return pud_none(*pud);
+ pmd_t *table;
+ pmd_t pmd;
+
+ pmd = READ_ONCE(*pmdp);
+ if (pmd_present(pmd)) {
+ table = __va(pmd_val(pmd));
+ pmd_clear(pmdp);
+ __flush_tlb_kernel_pgtable(addr);
+ pte_free_kernel(NULL, (pte_t *) table);
+ }
+ return 1;
}
-int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
+int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
{
- return pmd_none(*pmd);
+ pmd_t *table;
+ pud_t pud;
+ int i = 0;
+
+ pud = READ_ONCE(*pudp);
+ if (pud_present(pud)) {
+ table = __va(pud_val(pud));
+ do {
+ pmd_free_pte_page(&table[i], addr + (i * PMD_SIZE));
+ } while (i++, i < PTRS_PER_PMD);
+
+ pud_clear(pudp);
+ __flush_tlb_kernel_pgtable(addr);
+ pmd_free(NULL, table);
+ }
+ return 1;
}
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply related
* [PATCH v10 4/4] Revert "arm64: Enforce BBM for huge IO/VMAP mappings"
From: Chintan Pandya @ 2018-05-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527170250-5291-1-git-send-email-cpandya@codeaurora.org>
This commit 15122ee2c515a ("arm64: Enforce BBM for huge
IO/VMAP mappings") is a temporary work-around until the
issues with CONFIG_HAVE_ARCH_HUGE_VMAP gets fixed.
Revert this change as we have fixes for the issue.
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
---
arch/arm64/mm/mmu.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 17d9282..defb3bb 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -935,10 +935,6 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot)
pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
- /* ioremap_page_range doesn't honour BBM */
- if (pud_present(READ_ONCE(*pudp)))
- return 0;
-
BUG_ON(phys & ~PUD_MASK);
set_pud(pudp, pfn_pud(__phys_to_pfn(phys), sect_prot));
return 1;
@@ -949,10 +945,6 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t prot)
pgprot_t sect_prot = __pgprot(PMD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
- /* ioremap_page_range doesn't honour BBM */
- if (pmd_present(READ_ONCE(*pmdp)))
- return 0;
-
BUG_ON(phys & ~PMD_MASK);
set_pmd(pmdp, pfn_pmd(__phys_to_pfn(phys), sect_prot));
return 1;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply related
* [PATCH v2 08/13] ASoC: pxa: remove the dmaengine compat need
From: Mark Brown @ 2018-05-24 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-9-robert.jarzmik@free.fr>
On Thu, May 24, 2018 at 09:06:58AM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
Acked-by: Mark Brown <broonie@kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/f0c21ccd/attachment-0001.sig>
^ permalink raw reply
* linux-next: build failure after merge of the pm tree
From: Mark Brown @ 2018-05-24 14:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rafael,
After merging the pm tree, today's linux-next build (arm64 defconfig)
failed like this:
drivers/acpi/ec.o: In function `acpi_ec_dispatch_gpe':
/home/broonie/next/next/drivers/acpi/ec.c:1040: undefined reference to `acpi_dispatch_gpe'
/home/broonie/next/next/drivers/acpi/ec.c:1040:(.text+0x228c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `acpi_dispatch_gpe'
Probably caused by commit
8f81c457105b5d4 ("ACPI: EC: Dispatch the EC GPE directly on s2idle wake")
(though the symbol appears to be there and like it should be built and
the relocation warning looks funky...). I've used the PM tree from the
last -next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180524/fcc5a5bf/attachment.sig>
^ 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