* Re: [PATCH 07/12] of/device: Add input id to of_dma_configure()
From: Lorenzo Pieralisi @ 2020-06-04 14:49 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Catalin Marinas, Will Deacon, Diana Craciun, PCI,
Joerg Roedel, Sudeep Holla, Rafael J. Wysocki, Makarand Pawagi,
linux-acpi, Linux IOMMU, Marc Zyngier, Hanjun Guo, Bjorn Helgaas,
Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Laurentiu Tudor
In-Reply-To: <CAL_JsqJw3wyiUrbd1AekwDc5+uqhHi9BwoB-rYpypUEGNgzCtw@mail.gmail.com>
On Thu, May 21, 2020 at 05:02:20PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> >
> > Devices sitting on proprietary busses have a device ID space that
> > is owned by the respective bus and related firmware bindings. In order
> > to let the generic OF layer handle the input translations to
> > an IOMMU id, for such busses the current of_dma_configure() interface
> > should be extended in order to allow the bus layer to provide the
> > device input id parameter - that is retrieved/assigned in bus
> > specific code and firmware.
> >
> > Augment of_dma_configure() to add an optional input_id parameter,
> > leaving current functionality unchanged.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Joerg Roedel <joro@8bytes.org>
> > Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > ---
> > drivers/bus/fsl-mc/fsl-mc-bus.c | 4 ++-
> > drivers/iommu/of_iommu.c | 53 +++++++++++++++++++++------------
> > drivers/of/device.c | 8 +++--
> > include/linux/of_device.h | 16 ++++++++--
> > include/linux/of_iommu.h | 6 ++--
> > 5 files changed, 60 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > index 40526da5c6a6..8ead3f0238f2 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > @@ -118,11 +118,13 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> > static int fsl_mc_dma_configure(struct device *dev)
> > {
> > struct device *dma_dev = dev;
> > + struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> > + u32 input_id = mc_dev->icid;
> >
> > while (dev_is_fsl_mc(dma_dev))
> > dma_dev = dma_dev->parent;
> >
> > - return of_dma_configure(dev, dma_dev->of_node, 0);
> > + return of_dma_configure_id(dev, dma_dev->of_node, 0, &input_id);
> > }
> >
> > static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > index ad96b87137d6..4516d5bf6cc9 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -139,25 +139,53 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
> > return err;
> > }
> >
> > -static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
> > - struct device_node *master_np)
> > +static int of_iommu_configure_dev_id(struct device_node *master_np,
> > + struct device *dev,
> > + const u32 *id)
>
> Should have read this patch before #6. I guess you could still make
> of_pci_iommu_init() call
> of_iommu_configure_dev_id.
Yes that makes sense, I will update it.
Thanks,
Lorenzo
_______________________________________________
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] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
From: Will Deacon @ 2020-06-04 15:01 UTC (permalink / raw)
To: Marc Zyngier
Cc: mark.rutland, suzuki.poulose, catalin.marinas, james.morse,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200604154141.4983aeaa@why>
On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote:
> Hi all,
>
> On Tue, 28 Apr 2020 15:49:35 +0100
> Will Deacon <will@kernel.org> wrote:
>
> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote:
> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of
> > > the arm64 port where the boot protocol was basically 'copy this image
> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space
> > > to put the swapper page tables. When the arm64 port was merged for
> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET,
> > > to allow the bootloader to discover it dynamically rather than hardcode
> > > it to 512 KB.
> > >
> > > [...]
> >
> > Applied to arm64 (for-next/misc), thanks!
> >
> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
> > https://git.kernel.org/arm64/c/cfa7ede20f13
>
> This breaks a guest kernel booted with kvmtool (tested on my d05).
> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet
> investigated what is happening here though.
Weird, that's a combination I test, just not on d05. Are you using
defconfig? Can you share your full kvmtool invication please?
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 1/3] KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
From: Mark Rutland @ 2020-06-04 15:04 UTC (permalink / raw)
To: Marc Zyngier
Cc: kernel-team, kvm, Suzuki K Poulose, Catalin Marinas, stable,
James Morse, Julien Thierry, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20200604133354.1279412-2-maz@kernel.org>
On Thu, Jun 04, 2020 at 02:33:52PM +0100, Marc Zyngier wrote:
> When using the PtrAuth feature in a guest, we need to save the host's
> keys before allowing the guest to program them. For that, we dump
> them in a per-CPU data structure (the so called host context).
>
> But both call sites that do this are in preemptible context,
> which may end up in disaster should the vcpu thread get preempted
> before reentering the guest.
Yuck!
> Instead, save the keys eagerly on each vcpu_load(). This has an
> increased overhead, but is at least safe.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Marc Zyngier <maz@kernel.org>
This looks sound to me given kvm_arch_vcpu_load() is surrounded with
get_cpu() .. put_cpu() and gets called when the thread is preempted.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/include/asm/kvm_emulate.h | 6 ------
> arch/arm64/kvm/arm.c | 18 +++++++++++++++++-
> arch/arm64/kvm/handle_exit.c | 19 ++-----------------
> 3 files changed, 19 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index a30b4eec7cb4..977843e4d5fb 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -112,12 +112,6 @@ static inline void vcpu_ptrauth_disable(struct kvm_vcpu *vcpu)
> vcpu->arch.hcr_el2 &= ~(HCR_API | HCR_APK);
> }
>
> -static inline void vcpu_ptrauth_setup_lazy(struct kvm_vcpu *vcpu)
> -{
> - if (vcpu_has_ptrauth(vcpu))
> - vcpu_ptrauth_disable(vcpu);
> -}
> -
> static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
> {
> return vcpu->arch.vsesr_el2;
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index d6988401c22a..152049c5055d 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -337,6 +337,12 @@ void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu)
> preempt_enable();
> }
>
> +#define __ptrauth_save_key(regs, key) \
> +({ \
> + regs[key ## KEYLO_EL1] = read_sysreg_s(SYS_ ## key ## KEYLO_EL1); \
> + regs[key ## KEYHI_EL1] = read_sysreg_s(SYS_ ## key ## KEYHI_EL1); \
> +})
> +
> void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> int *last_ran;
> @@ -370,7 +376,17 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> else
> vcpu_set_wfx_traps(vcpu);
>
> - vcpu_ptrauth_setup_lazy(vcpu);
> + if (vcpu_has_ptrauth(vcpu)) {
> + struct kvm_cpu_context *ctxt = vcpu->arch.host_cpu_context;
> +
> + __ptrauth_save_key(ctxt->sys_regs, APIA);
> + __ptrauth_save_key(ctxt->sys_regs, APIB);
> + __ptrauth_save_key(ctxt->sys_regs, APDA);
> + __ptrauth_save_key(ctxt->sys_regs, APDB);
> + __ptrauth_save_key(ctxt->sys_regs, APGA);
> +
> + vcpu_ptrauth_disable(vcpu);
> + }
> }
>
> void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index eb194696ef62..065251efa2e6 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -162,31 +162,16 @@ static int handle_sve(struct kvm_vcpu *vcpu, struct kvm_run *run)
> return 1;
> }
>
> -#define __ptrauth_save_key(regs, key) \
> -({ \
> - regs[key ## KEYLO_EL1] = read_sysreg_s(SYS_ ## key ## KEYLO_EL1); \
> - regs[key ## KEYHI_EL1] = read_sysreg_s(SYS_ ## key ## KEYHI_EL1); \
> -})
> -
> /*
> * Handle the guest trying to use a ptrauth instruction, or trying to access a
> * ptrauth register.
> */
> void kvm_arm_vcpu_ptrauth_trap(struct kvm_vcpu *vcpu)
> {
> - struct kvm_cpu_context *ctxt;
> -
> - if (vcpu_has_ptrauth(vcpu)) {
> + if (vcpu_has_ptrauth(vcpu))
> vcpu_ptrauth_enable(vcpu);
> - ctxt = vcpu->arch.host_cpu_context;
> - __ptrauth_save_key(ctxt->sys_regs, APIA);
> - __ptrauth_save_key(ctxt->sys_regs, APIB);
> - __ptrauth_save_key(ctxt->sys_regs, APDA);
> - __ptrauth_save_key(ctxt->sys_regs, APDB);
> - __ptrauth_save_key(ctxt->sys_regs, APGA);
> - } else {
> + else
> kvm_inject_undefined(vcpu);
> - }
> }
>
> /*
> --
> 2.26.2
>
_______________________________________________
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] gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving
From: Miguel Ojeda @ 2020-06-04 15:05 UTC (permalink / raw)
To: Alexander Popov
Cc: Kernel Hardening, Catalin Marinas, Masahiro Yamada,
Vincenzo Frascino, Will Deacon, Naohiro Aota, Sven Schnelle,
Masahiro Yamada, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Emese Revfy, Iurii Zaikin, PaX Team, Laura Abbott, Mathias Krause,
Kees Cook, Linux Kbuild mailing list, Alexander Monakov,
Michal Marek, Thomas Gleixner, Peter Collingbourne, Linux ARM,
notify, Florian Weimer, gcc, Brad Spengler, linux-kernel,
Luis Chamberlain, Jessica Yu, Andrew Morton,
Thiago Jung Bauermann
In-Reply-To: <20200604134957.505389-3-alex.popov@linux.com>
Hi Alexander,
On Thu, Jun 4, 2020 at 3:50 PM Alexander Popov <alex.popov@linux.com> wrote:
>
> diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
> index cdf016596659..522d57ae8532 100644
> --- a/include/linux/compiler_attributes.h
> +++ b/include/linux/compiler_attributes.h
> @@ -41,6 +41,7 @@
> # define __GCC4_has_attribute___nonstring__ 0
> # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
> # define __GCC4_has_attribute___fallthrough__ 0
> +# define __GCC4_has_attribute___no_caller_saved_registers__ 0
> #endif
Nit: if you do another version, please move it before `noclone` to
keep the order (`fallthrough` was added in the wrong place).
Otherwise don't worry, I will sort it together with `fallthrough` when
I send a patch.
> +/*
> + * Optional: only supported since gcc >= 7
> + *
> + * gcc: https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#index-no_005fcaller_005fsaved_005fregisters-function-attribute_002c-x86
> + * clang: https://clang.llvm.org/docs/AttributeReference.html#no-caller-saved-registers
> + */
> +#if __has_attribute(__no_caller_saved_registers__)
> +# define __no_caller_saved_registers __attribute__((__no_caller_saved_registers__))
> +#else
> +# define __no_caller_saved_registers
> +#endif
Ditto.
Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cheers,
Miguel
_______________________________________________
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] regulator: mt6360: Add support for MT6360 regulator
From: Randy Dunlap @ 2020-06-04 15:06 UTC (permalink / raw)
To: Gene Chen, matthias.bgg
Cc: gene_chen, lgirdwood, linux-kernel, cy_huang, benjamin.chao,
broonie, linux-mediatek, Wilma.Wu, linux-arm-kernel, shufan_lee
In-Reply-To: <1591254387-10304-1-git-send-email-gene.chen.richtek@gmail.com>
On 6/4/20 12:06 AM, Gene Chen wrote:
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index f4b72cb..05a3b14 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -680,6 +680,16 @@ config REGULATOR_MT6358
> This driver supports the control of different power rails of device
> through regulator interface.
>
> +config REGULATOR_MT6360
> + tristate "MT6360 SubPMIC Regulator"
> + depends on MFD_MT6360
> + select CRC8
> + help
> + Say Y here to enable MT6360 regulator support.
> + This is support MT6360 PMIC/LDO part include
This supports the MT6300 PMIC/LDO part, which includes
> + 2-channel buck with Thermal Shutdown and Overlord Protection
is that Overload ?
Yes, it could be Overlord.
> + 6-channel High PSRR and Low Dropout LDO.
> +
> config REGULATOR_MT6380
> tristate "MediaTek MT6380 PMIC"
> depends on MTK_PMIC_WRAP
--
~Randy
_______________________________________________
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] iommu/mediatek: Use totalram_pages to setup enable_4GB
From: Christoph Hellwig @ 2020-06-04 15:06 UTC (permalink / raw)
To: David Hildenbrand
Cc: wsd_upstream, Joerg Roedel, iommu, linux-kernel, Chao Hao,
Miles Chen, linux-mediatek, linux-arm-kernel, Matthias Brugger,
yingjoe.chen, Yong Wu
In-Reply-To: <f02c8c9d-ed75-6513-f8a9-a2fdbb11b750@redhat.com>
On Thu, Jun 04, 2020 at 01:32:40PM +0200, David Hildenbrand wrote:
> Just a thought: If memory hotplug is applicable as well, you might
> either want to always assume data->enable_4GB, or handle memory hotplug
> events from the memory notifier, when new memory gets onlined (not sure
> how tricky that is).
We probably want a highest_pfn_possible() or similar API instead of
having drivers poking into random VM internals.
_______________________________________________
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 10/12] of/irq: Make of_msi_map_rid() PCI bus agnostic
From: Lorenzo Pieralisi @ 2020-06-04 15:08 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Catalin Marinas, Rafael J. Wysocki, PCI, Marc Zyngier,
Joerg Roedel, Sudeep Holla, Hanjun Guo, Linux IOMMU, linux-acpi,
Makarand Pawagi, Diana Craciun, Bjorn Helgaas, Laurentiu Tudor,
Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Robin Murphy
In-Reply-To: <CAL_JsqLTBxX_3KjiEqMfw0qMaTmj_DdPD3j-yMUvrvONPBSvjg@mail.gmail.com>
On Thu, May 21, 2020 at 05:17:27PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> >
> > There is nothing PCI bus specific in the of_msi_map_rid()
> > implementation other than the requester ID tag for the input
> > ID space. Rename requester ID to a more generic ID so that
> > the translation code can be used by all busses that require
> > input/output ID translations.
> >
> > Leave a wrapper function of_msi_map_rid() in place to keep
> > existing PCI code mapping requester ID syntactically unchanged.
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Marc Zyngier <maz@kernel.org>
> > ---
> > drivers/of/irq.c | 28 ++++++++++++++--------------
> > include/linux/of_irq.h | 14 ++++++++++++--
> > 2 files changed, 26 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > index 48a40326984f..25d17b8a1a1a 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -576,43 +576,43 @@ void __init of_irq_init(const struct of_device_id *matches)
> > }
> > }
> >
> > -static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
> > - u32 rid_in)
> > +static u32 __of_msi_map_id(struct device *dev, struct device_node **np,
> > + u32 id_in)
> > {
> > struct device *parent_dev;
> > - u32 rid_out = rid_in;
> > + u32 id_out = id_in;
> >
> > /*
> > * Walk up the device parent links looking for one with a
> > * "msi-map" property.
> > */
> > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> > - if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > - "msi-map-mask", np, &rid_out))
> > + if (!of_map_id(parent_dev->of_node, id_in, "msi-map",
> > + "msi-map-mask", np, &id_out))
> > break;
> > - return rid_out;
> > + return id_out;
> > }
> >
> > /**
> > - * of_msi_map_rid - Map a MSI requester ID for a device.
> > + * of_msi_map_id - Map a MSI ID for a device.
> > * @dev: device for which the mapping is to be done.
> > * @msi_np: device node of the expected msi controller.
> > - * @rid_in: unmapped MSI requester ID for the device.
> > + * @id_in: unmapped MSI ID for the device.
> > *
> > * Walk up the device hierarchy looking for devices with a "msi-map"
> > - * property. If found, apply the mapping to @rid_in.
> > + * property. If found, apply the mapping to @id_in.
> > *
> > - * Returns the mapped MSI requester ID.
> > + * Returns the mapped MSI ID.
> > */
> > -u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in)
> > +u32 of_msi_map_id(struct device *dev, struct device_node *msi_np, u32 id_in)
> > {
> > - return __of_msi_map_rid(dev, &msi_np, rid_in);
> > + return __of_msi_map_id(dev, &msi_np, id_in);
> > }
> >
> > /**
> > * of_msi_map_get_device_domain - Use msi-map to find the relevant MSI domain
> > * @dev: device for which the mapping is to be done.
> > - * @rid: Requester ID for the device.
> > + * @id: Device ID.
> > * @bus_token: Bus token
> > *
> > * Walk up the device hierarchy looking for devices with a "msi-map"
> > @@ -625,7 +625,7 @@ struct irq_domain *of_msi_map_get_device_domain(struct device *dev, u32 id,
> > {
> > struct device_node *np = NULL;
> >
> > - __of_msi_map_rid(dev, &np, id);
> > + __of_msi_map_id(dev, &np, id);
> > return irq_find_matching_host(np, bus_token);
> > }
> >
> > diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> > index 7142a3722758..cf9cb1e545ce 100644
> > --- a/include/linux/of_irq.h
> > +++ b/include/linux/of_irq.h
> > @@ -55,7 +55,12 @@ extern struct irq_domain *of_msi_map_get_device_domain(struct device *dev,
> > u32 id,
> > u32 bus_token);
> > extern void of_msi_configure(struct device *dev, struct device_node *np);
> > -u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in);
> > +u32 of_msi_map_id(struct device *dev, struct device_node *msi_np, u32 id_in);
> > +static inline u32 of_msi_map_rid(struct device *dev,
> > + struct device_node *msi_np, u32 rid_in)
> > +{
> > + return of_msi_map_id(dev, msi_np, rid_in);
> > +}
> > #else
> > static inline int of_irq_count(struct device_node *dev)
> > {
> > @@ -93,10 +98,15 @@ static inline struct irq_domain *of_msi_map_get_device_domain(struct device *dev
> > static inline void of_msi_configure(struct device *dev, struct device_node *np)
> > {
> > }
> > +static inline u32 of_msi_map_id(struct device *dev,
> > + struct device_node *msi_np, u32 id_in)
> > +{
> > + return id_in;
> > +}
> > static inline u32 of_msi_map_rid(struct device *dev,
> > struct device_node *msi_np, u32 rid_in)
>
> Move this out of the ifdef and you only need it declared once.
>
> But again, I think I'd just kill of_msi_map_rid.
Yes I don't think there is a clear benefit in keeping the _rid
interface.
Thanks,
Lorenzo
_______________________________________________
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] scs: Report SCS usage in bytes rather than number of entries
From: Will Deacon @ 2020-06-04 15:15 UTC (permalink / raw)
To: Kees Cook; +Cc: Sami Tolvanen, linux-kernel, linux-arm-kernel
In-Reply-To: <202006031006.2E6B4367@keescook>
On Wed, Jun 03, 2020 at 10:06:13AM -0700, Kees Cook wrote:
> On Wed, Jun 03, 2020 at 04:12:17PM +0100, Will Deacon wrote:
> > Fix the SCS debug usage check so that we report the number of bytes
> > usedm, rather than the number of entries.
>
> typo: used
>
> >
> > Fixes: 5bbaf9d1fcb9 ("scs: Add support for stack usage debugging")
> > Reported-by: Sami Tolvanen <samitolvanen@google.com>
> > Signed-off-by: Will Deacon <will@kernel.org>
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Cheers, Kees!
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: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-06-04 15:15 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rob Herring, Arnd Bergmann, Devicetree List, Viresh Kumar,
Linux Kernel Mailing List, Bjorn Andersson, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20200604092052.GD8814@bogus>
On Thu, Jun 4, 2020 at 4:20 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Jun 03, 2020 at 01:32:42PM -0500, Jassi Brar wrote:
> > On Wed, Jun 3, 2020 at 1:04 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > On Fri, May 29, 2020 at 09:37:58AM +0530, Viresh Kumar wrote:
> > > > On 28-05-20, 13:20, Rob Herring wrote:
> > > > > Whether Linux
> > > > > requires serializing mailbox accesses is a separate issue. On that side,
> > > > > it seems silly to not allow driving the h/w in the most efficient way
> > > > > possible.
> > > >
> > > > That's exactly what we are trying to say. The hardware allows us to
> > > > write all 32 bits in parallel, without any hardware issues, why
> > > > shouldn't we do that ? The delay (which Sudeep will find out, he is
> > > > facing issues with hardware access because of lockdown right now)
> > >
> > > OK, I was able to access the setup today. I couldn't reach a point
> > > where I can do measurements as the system just became unusable with
> > > one physical channel instead of 2 virtual channels as in my patches.
> > >
> > > My test was simple. Switch to schedutil and read sensors periodically
> > > via sysfs.
> > >
> > > arm-scmi firmware:scmi: message for 1 is not expected!
> > >
> > This sounds like you are not serialising requests on a shared channel.
> > Can you please also share the patch?
>
> OK, I did try with a small patch initially and then realised we must hit
> issue with mainline as is. Tried and the behaviour is exact same. All
> I did is removed my patches and use bit[0] as the signal. It doesn't
> matter as writes to the register are now serialised. Oh, the above
> message comes when OS times out in advance while firmware continues to
> process the old request and respond.
>
> The trace I sent gives much better view of what's going on.
>
BTW, you didn't even share 'good' vs 'bad' log for me to actually see
if the api lacks.
Let us look closely ...
>> bash-1019 [005] 1149.452340: scmi_xfer_begin:
transfer_id=1537 msg_id=7 protocol_id=19 seq=0 poll=1
>> bash-1019 [005] 1149.452407: scmi_xfer_end:
transfer_id=1537 msg_id=7 protocol_id=19 seq=0 status=0
>
This round trip took 67usecs. (log shows some at even 3usecs)
That includes mailbox api overhead, memcpy and the time taken by
remote to respond.
So the api is definitely capable of much faster transfers than you require.
>> bash-1526 [000] 1149.472553: scmi_xfer_begin: transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0
>> <idle>-0 [001] 1149.472733: scmi_xfer_begin: transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1
>
Here another request is started before the first is finished.
If you want this to work you have to serialise access to the single
physical channel and/or run the remote firmware in asynchronous mode -
that is, the firmware ack the bit as soon as it sees and starts
working in the background, so that we return in ~3usec always, while
the data returns whenever it is ready. Again, I don't have the code
or the 'good' run log to compare.
PS: I feel it is probably less effort for me to simply let the patch
through, than use my reiki powers to imagine how your test code and
firmware looks like.
_______________________________________________
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] iommu/arm-smmu: Mark qcom_smmu_client_of_match as possibly unused
From: Will Deacon @ 2020-06-04 15:20 UTC (permalink / raw)
To: Jordan Crouse
Cc: Sai Prakash Ranjan, linux-arm-msm, Joerg Roedel, linux-kernel,
iommu, Robin Murphy, linux-arm-kernel
In-Reply-To: <20200603211507.27756-1-jcrouse@codeaurora.org>
On Wed, Jun 03, 2020 at 03:15:07PM -0600, Jordan Crouse wrote:
> When CONFIG_OF=n of_match_device() gets pre-processed out of existence
> leaving qcom-smmu_client_of_match unused. Mark it as possibly unused to
> keep the compiler from warning in that case.
>
> Fixes: 0e764a01015d ("iommu/arm-smmu: Allow client devices to select direct mapping")
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
>
> drivers/iommu/arm-smmu-qcom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
> index cf01d0215a39..063b4388b0ff 100644
> --- a/drivers/iommu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm-smmu-qcom.c
> @@ -12,7 +12,7 @@ struct qcom_smmu {
> struct arm_smmu_device smmu;
> };
>
> -static const struct of_device_id qcom_smmu_client_of_match[] = {
> +static const struct __maybe_unused of_device_id qcom_smmu_client_of_match[] = {
Yikes, I've never seen that between the 'struct' and the struct name before!
I'd be inclined to stick it at the end, right before the '='.
With that:
Acked-by: Will Deacon <will@kernel.org>
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 2/3] KVM: arm64: Handle PtrAuth traps early
From: Mark Rutland @ 2020-06-04 15:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: kernel-team, kvm, Suzuki K Poulose, Catalin Marinas, James Morse,
Julien Thierry, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20200604133354.1279412-3-maz@kernel.org>
On Thu, Jun 04, 2020 at 02:33:53PM +0100, Marc Zyngier wrote:
> The current way we deal with PtrAuth is a bit heavy handed:
>
> - We forcefully save the host's keys on each vcpu_load()
> - Handling the PtrAuth trap forces us to go all the way back
> to the exit handling code to just set the HCR bits
>
> Overall, this is pretty heavy handed. A better approach would be
> to handle it the same way we deal with the FPSIMD registers:
>
> - On vcpu_load() disable PtrAuth for the guest
> - On first use, save the host's keys, enable PtrAuth in the
> guest
>
> Crutially, this can happen as a fixup, which is done very early
> on exit. We can then reenter the guest immediately without
> leaving the hypervisor role.
>
> Another thing is that it simplify the rest of the host handling:
> exiting all the way to the host means that the only possible
> outcome for this trap is to inject an UNDEF.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/arm.c | 17 +----------
> arch/arm64/kvm/handle_exit.c | 17 ++---------
> arch/arm64/kvm/hyp/switch.c | 59 ++++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/sys_regs.c | 13 +++-----
> 4 files changed, 68 insertions(+), 38 deletions(-)
[...]
> +static bool __hyp_text __hyp_handle_ptrauth(struct kvm_vcpu *vcpu)
> +{
> + u32 sysreg = esr_sys64_to_sysreg(kvm_vcpu_get_hsr(vcpu));
> + u32 ec = kvm_vcpu_trap_get_class(vcpu);
> + struct kvm_cpu_context *ctxt;
> + u64 val;
> +
> + if (!vcpu_has_ptrauth(vcpu))
> + return false;
> +
> + switch (ec) {
> + case ESR_ELx_EC_PAC:
> + break;
> + case ESR_ELx_EC_SYS64:
> + switch (sysreg) {
> + case SYS_APIAKEYLO_EL1:
> + case SYS_APIAKEYHI_EL1:
> + case SYS_APIBKEYLO_EL1:
> + case SYS_APIBKEYHI_EL1:
> + case SYS_APDAKEYLO_EL1:
> + case SYS_APDAKEYHI_EL1:
> + case SYS_APDBKEYLO_EL1:
> + case SYS_APDBKEYHI_EL1:
> + case SYS_APGAKEYLO_EL1:
> + case SYS_APGAKEYHI_EL1:
> + break;
> + default:
> + return false;
> + }
> + break;
> + default:
> + return false;
> + }
The ESR triage looks correct, but I think it might be clearer split out
into a helper, since you can avoid the default cases with direct
returns, and you could avoid the nested switch, e.g.
static inline bool __hyp_text esr_is_ptrauth_trap(u32 esr)
{
u32 ec = ESR_ELx_EC(esr);
if (ec == ESR_ELx_EC_PAC)
return true;
if (ec != ESR_ELx_EC_SYS64)
return false;
switch (esr_sys64_to_sysreg(esr)) {
case SYS_APIAKEYLO_EL1:
case SYS_APIAKEYHI_EL1:
case SYS_APIBKEYLO_EL1:
case SYS_APIBKEYHI_EL1:
case SYS_APDAKEYLO_EL1:
case SYS_APDAKEYHI_EL1:
case SYS_APDBKEYLO_EL1:
case SYS_APDBKEYHI_EL1:
case SYS_APGAKEYLO_EL1:
case SYS_APGAKEYHI_EL1:
return true;
}
return false;
}
> +
> + ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> + __ptrauth_save_key(ctxt->sys_regs, APIA);
> + __ptrauth_save_key(ctxt->sys_regs, APIB);
> + __ptrauth_save_key(ctxt->sys_regs, APDA);
> + __ptrauth_save_key(ctxt->sys_regs, APDB);
> + __ptrauth_save_key(ctxt->sys_regs, APGA);
> +
> + vcpu_ptrauth_enable(vcpu);
> +
> + val = read_sysreg(hcr_el2);
> + val |= (HCR_API | HCR_APK);
> + write_sysreg(val, hcr_el2);
> +
> + return true;
> +}
> +
> /*
> * Return true when we were able to fixup the guest exit and should return to
> * the guest, false when we should restore the host state and return to the
> @@ -524,6 +580,9 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> if (__hyp_handle_fpsimd(vcpu))
> return true;
>
> + if (__hyp_handle_ptrauth(vcpu))
> + return true;
> +
> if (!__populate_fault_info(vcpu))
> return true;
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index ad1d57501d6d..564995084cf8 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1034,16 +1034,13 @@ static bool trap_ptrauth(struct kvm_vcpu *vcpu,
> struct sys_reg_params *p,
> const struct sys_reg_desc *rd)
> {
> - kvm_arm_vcpu_ptrauth_trap(vcpu);
> -
> /*
> - * Return false for both cases as we never skip the trapped
> - * instruction:
> - *
> - * - Either we re-execute the same key register access instruction
> - * after enabling ptrauth.
> - * - Or an UNDEF is injected as ptrauth is not supported/enabled.
> + * If we land here, that is because we didn't fixup the access on exit
> + * by allowing the PtrAuth sysregs. The only way this happens is when
> + * the guest does not have PtrAuth support enabled.
> */
> + kvm_inject_undefined(vcpu);
> +
> return false;
> }
>
> --
> 2.26.2
>
Regardless of the suggestion above, this looks sound to me. I agree that
it's much nicer to handle this in hyp, and AFAICT the context switch
should do the right thing, so:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
_______________________________________________
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] gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic
From: Alexander Popov @ 2020-06-04 15:23 UTC (permalink / raw)
To: Jann Horn, Kees Cook, Elena Reshetova
Cc: Kernel Hardening, Catalin Marinas, Masahiro Yamada,
Vincenzo Frascino, Will Deacon, Naohiro Aota, Sven Schnelle,
Masahiro Yamada, the arch/x86 maintainers, Emese Revfy,
Iurii Zaikin, PaX Team, Laura Abbott, Mathias Krause,
linux-kbuild, Alexander Monakov, Michal Marek, Thomas Gleixner,
Peter Collingbourne, Linux ARM, notify, Florian Weimer, gcc,
Brad Spengler, kernel list, Miguel Ojeda, Luis Chamberlain,
Jessica Yu, Andrew Morton, Thiago Jung Bauermann
In-Reply-To: <CAG48ez05JOvqzYGr3PvyQGwFURspFWvNvf-b8Y613PX0biug8w@mail.gmail.com>
On 04.06.2020 17:01, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov <alex.popov@linux.com> wrote:
>> Some time ago Variable Length Arrays (VLA) were removed from the kernel.
>> The kernel is built with '-Wvla'. Let's exclude alloca() from the
>> instrumentation logic and make it simpler. The build-time assertion
>> against alloca() is added instead.
> [...]
>> + /* Variable Length Arrays are forbidden in the kernel */
>> + gcc_assert(!is_alloca(stmt));
>
> There is a patch series from Elena and Kees on the kernel-hardening
> list that deliberately uses __builtin_alloca() in the syscall entry
> path to randomize the stack pointer per-syscall - see
> <https://lore.kernel.org/kernel-hardening/20200406231606.37619-4-keescook@chromium.org/>.
Thanks, Jann.
At first glance, leaving alloca() handling in stackleak instrumentation logic
would allow to integrate stackleak and this version of random_kstack_offset.
Kees, Elena, did you try random_kstack_offset with upstream stackleak?
It looks to me that without stackleak erasing random_kstack_offset can be
weaker. I mean, if next syscall has a bigger stack randomization gap, the data
on thread stack from the previous syscall is not overwritten and can be used. Am
I right?
Another aspect: CONFIG_STACKLEAK_METRICS can be used for guessing kernel stack
offset, which is bad. It should be disabled if random_kstack_offset is on.
Best regards,
Alexander
_______________________________________________
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] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
From: Marc Zyngier @ 2020-06-04 15:25 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, suzuki.poulose, catalin.marinas, james.morse,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200604150122.GA3650@willie-the-truck>
On 2020-06-04 16:01, Will Deacon wrote:
> On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote:
>> Hi all,
>>
>> On Tue, 28 Apr 2020 15:49:35 +0100
>> Will Deacon <will@kernel.org> wrote:
>>
>> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote:
>> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of
>> > > the arm64 port where the boot protocol was basically 'copy this image
>> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space
>> > > to put the swapper page tables. When the arm64 port was merged for
>> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET,
>> > > to allow the bootloader to discover it dynamically rather than hardcode
>> > > it to 512 KB.
>> > >
>> > > [...]
>> >
>> > Applied to arm64 (for-next/misc), thanks!
>> >
>> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
>> > https://git.kernel.org/arm64/c/cfa7ede20f13
>>
>> This breaks a guest kernel booted with kvmtool (tested on my d05).
>> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet
>> investigated what is happening here though.
>
> Weird, that's a combination I test, just not on d05. Are you using
> defconfig? Can you share your full kvmtool invication please?
Ah, good point. Not defconfig, but one that allows me to run the same
kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty
basic:
lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image
Thanks,
M.
[1] http://www.loen.fr/tmp/Config-arm64-full
--
Jazz is not dead. It just smells funny...
_______________________________________________
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] iommu/mediatek: Use totalram_pages to setup enable_4GB
From: David Hildenbrand @ 2020-06-04 15:27 UTC (permalink / raw)
To: Christoph Hellwig
Cc: wsd_upstream, Joerg Roedel, iommu, linux-kernel, Chao Hao,
Miles Chen, linux-mediatek, linux-arm-kernel, Matthias Brugger,
yingjoe.chen, Yong Wu
In-Reply-To: <20200604150643.GA29193@infradead.org>
On 04.06.20 17:06, Christoph Hellwig wrote:
> On Thu, Jun 04, 2020 at 01:32:40PM +0200, David Hildenbrand wrote:
>> Just a thought: If memory hotplug is applicable as well, you might
>> either want to always assume data->enable_4GB, or handle memory hotplug
>> events from the memory notifier, when new memory gets onlined (not sure
>> how tricky that is).
>
> We probably want a highest_pfn_possible() or similar API instead of
> having drivers poking into random VM internals.
Well, memory notifiers are a reasonable api used accross the kernel to
get notified when new memory is onlined to the buddy that could be used
for allocations.
highest_pfn_possible() would have to default to something linked to
MAX_PHYSMEM_BITS whenever memory hotplug is configured, I am not sure
how helpful that is (IOW, you can just default to enable_4GB=true in
that case instead in most cases).
--
Thanks,
David / dhildenb
_______________________________________________
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 v3 2/7] documentation for stats_fs
From: Emanuele Giuseppe Esposito @ 2020-06-04 15:34 UTC (permalink / raw)
To: Randy Dunlap, Emanuele Giuseppe Esposito, kvm
Cc: linux-s390, linux-doc, netdev, linux-kernel, kvm-ppc,
Jonathan Adams, Christian Borntraeger, Alexander Viro,
David Rientjes, linux-fsdevel, Paolo Bonzini, linux-mips,
linuxppc-dev, linux-arm-kernel, Jim Mattson
In-Reply-To: <c9ddaed1-0efc-650b-6a51-ad5fc431af69@infradead.org>
Hi,
>> +
>> +The STATS_FS_HIDDEN attribute won't affect the aggregation, it will only
>> +block the creation of the files.
>
> Why does HIDDEN block the creation of files? instead of their visibility?
The file itself is used to allow the user to view the content of a
value. In order to make it hidden, the framework just doesn't create the
file.
The structure is still present and considered in statsfs, however.
Hidden in this case means not visible at all thus not created, not the
hidden file concept of dotted files (".filename")
>
>> +
>> +Add values to parent and child (also here order doesn't matter)::
>> +
>> + struct kvm *base_ptr = kmalloc(..., sizeof(struct kvm));
>> + ...
>> + stats_fs_source_add_values(child_source, kvm_stats, base_ptr, 0);
>> + stats_fs_source_add_values(parent_source, kvm_stats, NULL, STATS_FS_HIDDEN);
>> +
>> +``child_source`` will be a simple value, since it has a non-NULL base
>> +pointer, while ``parent_source`` will be an aggregate. During the adding
>> +phase, also values can optionally be marked as hidden, so that the folder
>> +and other values can be still shown.
>> +
>> +Of course the same ``struct stats_fs_value`` array can be also passed with a
>> +different base pointer, to represent the same value but in another instance
>> +of the kvm struct.
>> +
>> +Search:
>> +
>> +Fetch a value from the child source, returning the value
>> +pointed by ``(uint64_t *) base_ptr + kvm_stats[0].offset``::
>> +
>> + uint64_t ret_child, ret_parent;
>> +
>> + stats_fs_source_get_value(child_source, &kvm_stats[0], &ret_child);
>> +
>> +Fetch an aggregate value, searching all subsources of ``parent_source`` for
>> +the specified ``struct stats_fs_value``::
>> +
>> + stats_fs_source_get_value(parent_source, &kvm_stats[0], &ret_parent);
>> +
>> + assert(ret_child == ret_parent); // check expected result
>> +
>> +To make it more interesting, add another child::
>> +
>> + struct stats_fs_source child_source2 = stats_fs_source_create(0, "child2");
>> +
>> + stats_fs_source_add_subordinate(parent_source, child_source2);
>> + // now the structure is parent -> child1
>> + // -> child2
>
> Is that the same as parent -> child1 -> child2
> ? It could almost be read as
> parent -> child1
> parent -> child2
No the example in the documentation shows the relationship
parent -> child1 and
parent -> child2.
It's not the same as
parent -> child1 -> child2.
In order to do the latter, one would need to do:
stats_fs_source_add_subordinate(parent_source, child_source1);
stats_fs_source_add_subordinate(child_source1, child_source2);
Hope that this clarifies it.
>
> Whichever it is, can you make it more explicit, please?
>
>
>> +
>> + struct kvm *other_base_ptr = kmalloc(..., sizeof(struct kvm));
>> + ...
>> + stats_fs_source_add_values(child_source2, kvm_stats, other_base_ptr, 0);
>> +
>> +Note that other_base_ptr points to another instance of kvm, so the struct
>> +stats_fs_value is the same but the address at which they point is not.
>> +
>> +Now get the aggregate value::
>> +
>> + uint64_t ret_child, ret_child2, ret_parent;
>> +
>> + stats_fs_source_get_value(child_source, &kvm_stats[0], &ret_child);
>> + stats_fs_source_get_value(parent_source, &kvm_stats[0], &ret_parent);
>> + stats_fs_source_get_value(child_source2, &kvm_stats[0], &ret_child2);
>> +
>> + assert((ret_child + ret_child2) == ret_parent);
>> +
>> +Cleanup::
>> +
>> + stats_fs_source_remove_subordinate(parent_source, child_source);
>> + stats_fs_source_revoke(child_source);
>> + stats_fs_source_put(child_source);
>> +
>> + stats_fs_source_remove_subordinate(parent_source, child_source2);
>> + stats_fs_source_revoke(child_source2);
>> + stats_fs_source_put(child_source2);
>> +
>> + stats_fs_source_put(parent_source);
>> + kfree(other_base_ptr);
>> + kfree(base_ptr);
>> +
>> +Calling stats_fs_source_revoke is very important, because it will ensure
>
> stats_fs_source_revoke()
>
>> +that stats_fs will not access the data that were passed to
>> +stats_fs_source_add_value for this source.
>> +
>> +Because open files increase the reference count for a stats_fs_source, the
>> +source can end up living longer than the data that provides the values for
>> +the source. Calling stats_fs_source_revoke just before the backing data
>
> stats_fs_source_revoke()
>
>> +is freed avoids accesses to freed data structures. The sources will return
>> +0.
>> +
>> +This is not needed for the parent_source, since it just contains
>> +aggregates that would be 0 anyways if no matching child value exist.
>> +
>> +API Documentation
>> +=================
>> +
>> +.. kernel-doc:: include/linux/stats_fs.h
>> + :export: fs/stats_fs/*.c
>> \ No newline at end of file
>
> Please fix that. ^^^^^
>
>
> Thanks for the documentation.
>
Thank you for the feedback,
Emanuele
_______________________________________________
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 3/3] KVM: arm64: Enforce PtrAuth being disabled if not advertized
From: Mark Rutland @ 2020-06-04 15:39 UTC (permalink / raw)
To: Marc Zyngier
Cc: kernel-team, kvm, Suzuki K Poulose, Catalin Marinas, James Morse,
Julien Thierry, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20200604133354.1279412-4-maz@kernel.org>
Hi Marc,
On Thu, Jun 04, 2020 at 02:33:54PM +0100, Marc Zyngier wrote:
> Even if we don't expose PtrAuth to a guest, the guest can still
> write to its SCTIRLE_1 register and set the En{I,D}{A,B} bits
> and execute PtrAuth instructions from the NOP space. This has
> the effect of trapping to EL2, and we currently inject an UNDEF.
I think it's worth noting that this is an ill-behaved guest, as those
bits are RES0 when pointer authentication isn't implemented.
The rationale for RES0/RES1 bits is that new HW can rely on old SW
programming them with the 0/1 as appropriate, and that old SW that does
not do so may encounter behaviour which from its PoV is UNPREDICTABLE.
The SW side of the contract is that you must program them as 0/1 unless
you know they're allocated with a specific meaning.
With that in mind I think the current behaviour is legitimate: from the
guest's PoV it's the same as there being a distinct extension which it
is not aware of where the En{I,D}{A,B} bits means "trap some HINTs to
EL1".
I don't think that we should attempt to work around broken software here
unless we absolutely have to, as it only adds complexity for no real
gain.
Thanks,
Mark.
> This is definitely the wrong thing to do, as the architecture says
> that these instructions should behave as NOPs.
>
> Instead, we can simply reset the offending SCTLR_EL1 bits to
> zero, and resume the guest. It can still observe the SCTLR bits
> being set and then being cleared by magic, but that's much better
> than delivering an unexpected extension.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/handle_exit.c | 12 ------------
> arch/arm64/kvm/hyp/switch.c | 18 ++++++++++++++++--
> 2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 5a02d4c90559..98d8adf6f865 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -162,17 +162,6 @@ static int handle_sve(struct kvm_vcpu *vcpu, struct kvm_run *run)
> return 1;
> }
>
> -/*
> - * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into
> - * a NOP). If we get here, it is that we didn't fixup ptrauth on exit, and all
> - * that we can do is give the guest an UNDEF.
> - */
> -static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu, struct kvm_run *run)
> -{
> - kvm_inject_undefined(vcpu);
> - return 1;
> -}
> -
> static exit_handle_fn arm_exit_handlers[] = {
> [0 ... ESR_ELx_EC_MAX] = kvm_handle_unknown_ec,
> [ESR_ELx_EC_WFx] = kvm_handle_wfx,
> @@ -195,7 +184,6 @@ static exit_handle_fn arm_exit_handlers[] = {
> [ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug,
> [ESR_ELx_EC_BRK64] = kvm_handle_guest_debug,
> [ESR_ELx_EC_FP_ASIMD] = handle_no_fpsimd,
> - [ESR_ELx_EC_PAC] = kvm_handle_ptrauth,
> };
>
> static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 2a50b3771c3b..fc09c3dfa466 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -503,8 +503,22 @@ static bool __hyp_text __hyp_handle_ptrauth(struct kvm_vcpu *vcpu)
> struct kvm_cpu_context *ctxt;
> u64 val;
>
> - if (!vcpu_has_ptrauth(vcpu))
> - return false;
> + if (!vcpu_has_ptrauth(vcpu)) {
> + if (ec != ESR_ELx_EC_PAC)
> + return false;
> +
> + /*
> + * Interesting situation: the guest has enabled PtrAuth,
> + * despite KVM not advertising it. Fix SCTLR_El1 on behalf
> + * of the guest (the bits should behave as RES0 anyway).
> + */
> + val = read_sysreg_el1(SYS_SCTLR);
> + val &= ~(SCTLR_ELx_ENIA | SCTLR_ELx_ENIB |
> + SCTLR_ELx_ENDA | SCTLR_ELx_ENDB);
> + write_sysreg_el1(val, SYS_SCTLR);
> +
> + return true;
> + }
>
> switch (ec) {
> case ESR_ELx_EC_PAC:
> --
> 2.26.2
>
_______________________________________________
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] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
From: Ard Biesheuvel @ 2020-06-04 15:41 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, suzuki.poulose, Catalin Marinas, James Morse,
Will Deacon, Linux ARM
In-Reply-To: <fab4fb9e66fe48d82c9856a7d5839335@kernel.org>
On Thu, 4 Jun 2020 at 17:25, Marc Zyngier <maz@kernel.org> wrote:
>
> On 2020-06-04 16:01, Will Deacon wrote:
> > On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote:
> >> Hi all,
> >>
> >> On Tue, 28 Apr 2020 15:49:35 +0100
> >> Will Deacon <will@kernel.org> wrote:
> >>
> >> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote:
> >> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of
> >> > > the arm64 port where the boot protocol was basically 'copy this image
> >> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space
> >> > > to put the swapper page tables. When the arm64 port was merged for
> >> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET,
> >> > > to allow the bootloader to discover it dynamically rather than hardcode
> >> > > it to 512 KB.
> >> > >
> >> > > [...]
> >> >
> >> > Applied to arm64 (for-next/misc), thanks!
> >> >
> >> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
> >> > https://git.kernel.org/arm64/c/cfa7ede20f13
> >>
> >> This breaks a guest kernel booted with kvmtool (tested on my d05).
> >> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet
> >> investigated what is happening here though.
> >
> > Weird, that's a combination I test, just not on d05. Are you using
> > defconfig? Can you share your full kvmtool invication please?
>
> Ah, good point. Not defconfig, but one that allows me to run the same
> kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty
> basic:
>
> lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image
>
OK, so my suspicions is that your config does not enable
CONFIG_RANDOMIZE_BASE, and that kvmtool ignores the text offset value
in the header altogether.
_______________________________________________
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] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
From: Ard Biesheuvel @ 2020-06-04 15:48 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, suzuki.poulose, Catalin Marinas, James Morse,
Will Deacon, Linux ARM
In-Reply-To: <CAMj1kXFS8Vvjfpb8HYzRvsaB0j7bs+2V4rXE8DzfNMJxsV3r0g@mail.gmail.com>
On Thu, 4 Jun 2020 at 17:41, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 4 Jun 2020 at 17:25, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On 2020-06-04 16:01, Will Deacon wrote:
> > > On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote:
> > >> Hi all,
> > >>
> > >> On Tue, 28 Apr 2020 15:49:35 +0100
> > >> Will Deacon <will@kernel.org> wrote:
> > >>
> > >> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote:
> > >> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of
> > >> > > the arm64 port where the boot protocol was basically 'copy this image
> > >> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space
> > >> > > to put the swapper page tables. When the arm64 port was merged for
> > >> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET,
> > >> > > to allow the bootloader to discover it dynamically rather than hardcode
> > >> > > it to 512 KB.
> > >> > >
> > >> > > [...]
> > >> >
> > >> > Applied to arm64 (for-next/misc), thanks!
> > >> >
> > >> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
> > >> > https://git.kernel.org/arm64/c/cfa7ede20f13
> > >>
> > >> This breaks a guest kernel booted with kvmtool (tested on my d05).
> > >> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet
> > >> investigated what is happening here though.
> > >
> > > Weird, that's a combination I test, just not on d05. Are you using
> > > defconfig? Can you share your full kvmtool invication please?
> >
> > Ah, good point. Not defconfig, but one that allows me to run the same
> > kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty
> > basic:
> >
> > lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image
> >
>
> OK, so my suspicions is that your config does not enable
> CONFIG_RANDOMIZE_BASE, and that kvmtool ignores the text offset value
> in the header altogether.
arm/aarch64/include/kvm/kvm-arch.h:#define ARM_KERN_OFFSET(kvm)
((kvm)->cfg.arch.aarch32_guest ? \
arm/aarch64/include/kvm/kvm-arch.h- 0x8000
: \
arm/aarch64/include/kvm/kvm-arch.h- 0x80000)
_______________________________________________
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 v2 1/2] arm64: dts: Add a device tree for the Librem 5 phone
From: Mark Brown @ 2020-06-04 15:48 UTC (permalink / raw)
To: Martin Kepplinger
Cc: Daniel Baluta, robh, kernel, Anson.Huang, devicetree, shawnguo,
s.hauer, angus, linux-kernel, linux-imx, kernel, mchehab,
festevam, agx, linux-arm-kernel
In-Reply-To: <20200604084756.586-1-martin.kepplinger@puri.sm>
[-- Attachment #1.1: Type: text/plain, Size: 1162 bytes --]
On Thu, Jun 04, 2020 at 10:47:55AM +0200, Martin Kepplinger wrote:
> + reg_audio_pwr_en: regulator-audio-pwr-en {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_audiopwr>;
> + regulator-name = "AUDIO_PWR_EN";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + reg_aud_1v8: regulator-audio-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "AUD_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <®_audio_pwr_en>;
> + };
This looks broken - a combination of the structure, lack of any
references to reg_audio_pwr_en and the naming suggests that you have one
regulator here for a supply called AUD_1V8 which has a GPIO controlling
the enable. I can't figure out any reason for reg_audio_pwr_en.
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "wm8962";
You might want to put a more user friendly display name here (eg, one
mentioning Librem 5) - some UIs will show this string to users.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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: [PATCH 3/3] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-06-04 16:05 UTC (permalink / raw)
To: Mark Brown, Florian Fainelli
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Scott Branden, lukas, Ray Jui, linux-kernel,
open list:SPI SUBSYSTEM, Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl, Nicolas Saenz Julienne
In-Reply-To: <20200604123220.GD6644@sirena.org.uk>
On 6/4/2020 5:32 AM, Mark Brown wrote:
> On Wed, Jun 03, 2020 at 08:46:55PM -0700, Florian Fainelli wrote:
>> The SPI controller found in the BCM2711 and BCM7211 SoCs is instantiated
>> 5 times, with all instances sharing the same interrupt line. We
>> specifically match the two compatible strings here to determine whether
>> it is necessary to request the interrupt with the IRQF_SHARED flag and
>> to use an appropriate interrupt handler capable of returning IRQ_NONE.
>
>> For the BCM2835 case which is deemed performance critical, there is no
>> overhead since a dedicated handler that does not assume sharing is used.
>
> This feels hacky - it's essentially using the compatible string to set a
> boolean flag which isn't really about the IP but rather the platform
> integration. It might cause problems if we do end up having to quirk
> this version of the IP for some other reason.
I am not sure why it would be a problem, when you describe a piece of
hardware with Device Tree, even with the IP block being strictly the
same, its very integration into a new SoC (with details like shared
interrupt lines) do warrant a different compatible string. Maybe this is
more of a philosophical question.
> I'm also looking at the
> code and wondering if the overhead of checking to see if the interrupt
> is flagged is really that severe, it's just a check to see if a bit is
> set in a register which we already read so should be a couple of
> instructions (which disassembly seems to confirm). It *is* overhead so
> there's some value in it, I'm just surprised that it's such a hot path
> especially with a reasonably deep FIFO like this device has.
If it was up to me, we would just add the check on BCM2835_SPI_CS_INTR
not being set and return IRQ_NONE and be done with it. I appreciate that
Lukas has spent some tremendous amount of time working on this
controller driver and he has a sensitivity for performance.
>
> I guess ideally genirq would provide a way to figure out if an interrupt
> is actually shared in the present system, and better yet we'd have a way
> for drivers to say they aren't using the interrupt ATM, but that might
> be more effort than it's really worth. If this is needed and there's no
> better way of figuring out if the interrupt is really shared then I'd
> suggest a boolean flag rather than a compatible string, it's still a
> hack but it's less likely to store up trouble for the future.
Instead of counting the number of SPI devices we culd request the
interrupt first with flags = IRQF_PROBE_SHARED, if this works, good we
have a single SPI master enabled, if it returns -EBUSY, try again with
flags = IRQF_SHARED and set-up the bcm2835_spi_sh_interrupt interrupt
handler to manage the sharing.
This would not require DT changes, which is probably better anyway.
--
Florian
_______________________________________________
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] leds: mt6360: Add LED driver for MT6360
From: Dan Murphy @ 2020-06-04 16:07 UTC (permalink / raw)
To: Gene Chen, jacek.anaszewski, pavel, matthias.bgg
Cc: gene_chen, linux-kernel, cy_huang, benjamin.chao, linux-mediatek,
linux-leds, Wilma.Wu, linux-arm-kernel, shufan_lee
In-Reply-To: <1591252004-12681-1-git-send-email-gene.chen.richtek@gmail.com>
Gene
On 6/4/20 1:26 AM, Gene Chen wrote:
> From: Gene Chen <gene_chen@richtek.com>
>
> Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
> and 3-channel RGB LED support Register/Flash/Breath Mode
>
> Signed-off-by: Gene Chen <gene_chen@richtek.com>
> base-commit: 098c4adf249c198519a4abebe482b1e6b8c50e47
> ---
> drivers/leds/Kconfig | 11 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-mt6360.c | 1061 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/mt6360.h | 6 +-
> 4 files changed, 1078 insertions(+), 1 deletion(-)
> create mode 100644 drivers/leds/leds-mt6360.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index c664d84..c47be91 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -229,6 +229,17 @@ config LEDS_MT6323
> This option enables support for on-chip LED drivers found on
> Mediatek MT6323 PMIC.
>
> +config LEDS_MT6360
> + tristate "LED Support for Mediatek MT6360 PMIC"
> + depends on LEDS_CLASS_FLASH && OF
> + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
> + depends on MFD_MT6360
> + help
> + This option enables support for dual Flash LED drivers found on
> + Mediatek MT6360 PMIC.
> + Support Torch and Strobe mode independently current source.
> + Include Low-VF and short protection.
> +
> config LEDS_S3C24XX
> tristate "LED Support for Samsung S3C24XX GPIO LEDs"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 45235d5..2883b4d 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_LEDS_MIKROTIK_RB532) += leds-rb532.o
> obj-$(CONFIG_LEDS_MLXCPLD) += leds-mlxcpld.o
> obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
> obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
> +obj-$(CONFIG_LEDS_MT6360) += leds-mt6360.o
> obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
> obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
> obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
> diff --git a/drivers/leds/leds-mt6360.c b/drivers/leds/leds-mt6360.c
> new file mode 100644
> index 0000000..3e62547
> --- /dev/null
> +++ b/drivers/leds/leds-mt6360.c
> @@ -0,0 +1,1061 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + *
> + * Author: Gene Chen <gene_chen@richtek.com>
> + */
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/regmap.h>
> +#include <linux/platform_device.h>
> +#include <linux/interrupt.h>
> +#include <linux/of.h>
> +#include <linux/led-class-flash.h>
> +#include <media/v4l2-flash-led-class.h>
> +
> +#include <linux/mfd/mt6360.h>
> +
> +enum {
> + MT6360_LED_ISINK1 = 0,
> + MT6360_LED_ISINK2,
> + MT6360_LED_ISINK3,
> + MT6360_LED_ISINK4,
> + MT6360_LED_MAX,
> +};
> +
> +enum {
> + MT6360_LEDMODE_PWM = 0,
> + MT6360_LEDMODE_BREATH,
> + MT6360_LEDMODE_CC,
> + MT6360_LEDMODE_MAX,
> +};
> +
> +enum {
> + MT6360_FLED_CH1 = 0,
> + MT6360_FLED_CH2,
> + MT6360_FLED_MAX,
> +};
> +
> +/* ILED setting/reg */
> +#define MT6360_SINKCUR_MAX1 (0x0d)
> +#define MT6360_SINKCUR_MAX2 (0x0d)
> +#define MT6360_SINKCUR_MAX3 (0x0d)
> +#define MT6360_SINKCUR_MAX4 (0x1f)
> +#define MT6360_CURRSEL_REG1 (MT6360_PMU_RGB1_ISNK)
> +#define MT6360_CURRSEL_REG2 (MT6360_PMU_RGB2_ISNK)
> +#define MT6360_CURRSEL_REG3 (MT6360_PMU_RGB3_ISNK)
> +#define MT6360_CURRSEL_REG4 (MT6360_PMU_RGB_ML_ISNK)
> +#define MT6360_CURRSEL_MASK1 (0x0f)
> +#define MT6360_CURRSEL_MASK2 (0x0f)
> +#define MT6360_CURRSEL_MASK3 (0x0f)
> +#define MT6360_CURRSEL_MASK4 (0x1f)
> +#define MT6360_LEDMODE_REG1 (MT6360_PMU_RGB1_ISNK)
> +#define MT6360_LEDMODE_REG2 (MT6360_PMU_RGB2_ISNK)
> +#define MT6360_LEDMODE_REG3 (MT6360_PMU_RGB3_ISNK)
> +#define MT6360_LEDMODE_REG4 (0)
> +#define MT6360_LEDMODE_MASK1 (0xc0)
> +#define MT6360_LEDMODE_MASK2 (0xc0)
> +#define MT6360_LEDMODE_MASK3 (0xc0)
> +#define MT6360_LEDMODE_MASK4 (0)
> +#define MT6360_PWMDUTY_REG1 (MT6360_PMU_RGB1_DIM)
> +#define MT6360_PWMDUTY_REG2 (MT6360_PMU_RGB2_DIM)
> +#define MT6360_PWMDUTY_REG3 (MT6360_PMU_RGB3_DIM)
> +#define MT6360_PWMDUTY_REG4 (0)
> +#define MT6360_PWMDUTY_MASK1 (0xff)
> +#define MT6360_PWMDUTY_MASK2 (0xff)
> +#define MT6360_PWMDUTY_MASK3 (0xff)
> +#define MT6360_PWMDUTY_MASK4 (0)
> +#define MT6360_PWMFREQ_REG1 (MT6360_PMU_RGB12_Freq)
> +#define MT6360_PWMFREQ_REG2 (MT6360_PMU_RGB12_Freq)
> +#define MT6360_PWMFREQ_REG3 (MT6360_PMU_RGB34_Freq)
> +#define MT6360_PWMFREQ_REG4 (0)
> +#define MT6360_PWMFREQ_MASK1 (0xe0)
> +#define MT6360_PWMFREQ_MASK2 (0x1c)
> +#define MT6360_PWMFREQ_MASK3 (0xe0)
> +#define MT6360_PWMFREQ_MASK4 (0)
> +#define MT6360_BREATH_REGBASE1 (MT6360_PMU_RGB1_Tr)
> +#define MT6360_BREATH_REGBASE2 (MT6360_PMU_RGB2_Tr)
> +#define MT6360_BREATH_REGBASE3 (MT6360_PMU_RGB3_Tr)
> +#define MT6360_BREATH_REGBASE4 (0)
> +#define MT6360_LEDEN_MASK1 (0x80)
> +#define MT6360_LEDEN_MASK2 (0x40)
> +#define MT6360_LEDEN_MASK3 (0x20)
> +#define MT6360_LEDEN_MASK4 (0x10)
> +#define MT6360_LEDEN_REG (MT6360_PMU_RGB_EN)
> +#define MT6360_LEDALLEN_MASK (0xf0)
> +
> +#define MT6360_CHRIND_MASK (0x08)
> +
> +/* pattern order -> toff, tr1, tr2, ton, tf1, tf2 */
> +#define MT6360_BRPATTERN_NUM (6)
> +#define MT6360_BREATHREG_NUM (3)
> +
> +/* FLED setting */
> +#define MT6360_CSENABLE_REG1 (MT6360_PMU_FLED_EN)
> +#define MT6360_CSENABLE_MASK1 (0x02)
> +#define MT6360_CSENABLE_REG2 (MT6360_PMU_FLED_EN)
> +#define MT6360_CSENABLE_MASK2 (0x01)
> +#define MT6360_TORBRIGHT_MAX1 (0x1f)
> +#define MT6360_TORBRIGHT_MAX2 (0x1f)
> +#define MT6360_TORBRIGHT_REG1 (MT6360_PMU_FLED1_TOR_CTRL)
> +#define MT6360_TORBRIGHT_MASK1 (0x1f)
> +#define MT6360_STRBRIGHT_REG1 (MT6360_PMU_FLED1_STRB_CTRL2)
> +#define MT6360_STRBRIGHT_MASK1 (0x7f)
> +#define MT6360_TORBRIGHT_REG2 (MT6360_PMU_FLED2_TOR_CTRL)
> +#define MT6360_TORBRIGHT_MASK2 (0x1f)
> +#define MT6360_STRBRIGHT_REG2 (MT6360_PMU_FLED2_STRB_CTRL2)
> +#define MT6360_STRBRIGHT_MASK2 (0x7f)
> +#define MT6360_TORENABLE_REG1 (MT6360_PMU_FLED_EN)
> +#define MT6360_TORENABLE_MASK1 (0x08)
> +#define MT6360_TORENABLE_REG2 (MT6360_PMU_FLED_EN)
> +#define MT6360_TORENABLE_MASK2 (0x08)
> +#define MT6360_STRBENABLE_REG1 (MT6360_PMU_FLED_EN)
> +#define MT6360_STRBENABLE_MASK1 (0x06)
> +#define MT6360_STRBENABLE_REG2 (MT6360_PMU_FLED_EN)
> +#define MT6360_STRBENABLE_MASK2 (0x04)
> +#define MT6360_STRBTIMEOUT_REG (MT6360_PMU_FLED_STRB_CTRL)
> +#define MT6360_STRBTIMEOUT_MASK (0x7f)
> +#define MT6360_TORCHCUR_MIN (25000)
> +#define MT6360_TORCHCUR_STEP (12500)
> +#define MT6360_TORCHCUR_MAX (400000)
> +#define MT6360_STROBECUR_MIN (50000)
> +#define MT6360_STROBECUR_STEP (12500)
> +#define MT6360_STROBECUR_MAX (1500000)
> +#define MT6360_STRBTIMEOUT_MIN (64000)
> +#define MT6360_STRBTIMEOUT_STEP (32000)
> +#define MT6360_STRBTIMEOUT_MAX (2432000)
> +
> +#define MT6360_MASK_ULTRA_STROBE (0x80)
> +#define MT6360_SHIFT_ULTRA_STROBE (7)
> +
> +#define MT6360_FLEDSUPPORT_FAULTS (LED_FAULT_UNDER_VOLTAGE |\
> + LED_FAULT_SHORT_CIRCUIT |\
> + LED_FAULT_INPUT_VOLTAGE |\
> + LED_FAULT_TIMEOUT)
> +
> +struct mt6360_led_platform_data {
> + u32 rgbon_sync;
> + u32 fled1_ultraistrb;
> + u32 fled2_ultraistrb;
> +};
> +
> +struct breath_element_cfg {
> + /* base, step in ms */
> + unsigned int base;
> + unsigned int step;
> + unsigned int maxval;
> + unsigned int reg_offset;
> + unsigned int reg_mask;
> +};
> +
> +struct mt6360_led_classdev {
> + struct led_classdev cdev;
> + int index;
> + struct device_node *np;
> + unsigned int currsel_reg;
> + unsigned int currsel_mask;
> + unsigned int enable_mask;
> + unsigned int mode_reg;
> + unsigned int mode_mask;
> + unsigned int pwmduty_reg;
> + unsigned int pwmduty_mask;
> + unsigned int pwmfreq_reg;
> + unsigned int pwmfreq_mask;
> + unsigned int breath_regbase;
> +};
> +
> +struct mt6360_fled_classdev {
> + struct led_classdev_flash fl_cdev;
> + int index;
> + struct v4l2_flash *v4l2_flash;
> + struct device_node *np;
> + unsigned int cs_enable_reg;
> + unsigned int cs_enable_mask;
> + unsigned int torch_bright_reg;
> + unsigned int torch_bright_mask;
> + unsigned int torch_enable_reg;
> + unsigned int torch_enable_mask;
> + unsigned int strobe_bright_reg;
> + unsigned int strobe_bright_mask;
> + unsigned int strobe_enable_reg;
> + unsigned int strobe_enable_mask;
> + unsigned int strobe_external_reg;
> + unsigned int strobe_external_mask;
> + u32 faults;
> +};
> +
> +struct mt6360_led_data {
> + struct device *dev;
> + struct mt6360_led_platform_data *pdata;
> + struct regmap *regmap;
> + struct mt6360_led_classdev mtled_cdev[MT6360_LED_MAX];
> + struct mt6360_fled_classdev mtfled_cdev[MT6360_FLED_MAX];
> + unsigned long fl_torch_flags;
> + unsigned long fl_strobe_flags;
> +};
> +
> +static const struct mt6360_led_platform_data def_platform_data = {
> + .rgbon_sync = 0,
> + .fled1_ultraistrb = 1,
> + .fled2_ultraistrb = 1,
> +};
> +
> +static int mt6360_led_brightness_set(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + struct mt6360_led_classdev *mtled_cdev =
> + (struct mt6360_led_classdev *)cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(cdev->dev->parent);
> + int shift, sync_regval = 0, ret;
> +
> + /* if isink1 user control, set chrind function to sw mode */
> + if (mtled_cdev->index == MT6360_LED_ISINK1) {
> + ret = regmap_update_bits(mld->regmap,
> + MT6360_PMU_RGB_EN, MT6360_CHRIND_MASK, 0xff);
> + if (ret < 0)
> + dev_err(cdev->dev, "disable chrind func fail\n");
> + }
> + if (brightness == LED_OFF) {
> + ret = regmap_update_bits(mld->regmap,
> + MT6360_LEDEN_REG, mtled_cdev->enable_mask, 0);
> + if (ret < 0)
> + return ret;
> + if (mtled_cdev->mode_reg == 0)
> + goto out_bright_set;
> + /* if off, force config to cc_mode */
> + shift = ffs(mtled_cdev->mode_mask) - 1;
> + ret = regmap_update_bits(mld->regmap, mtled_cdev->mode_reg,
> + mtled_cdev->mode_mask, MT6360_LEDMODE_CC << shift);
> + if (ret < 0)
> + dev_err(cdev->dev, "config cc mode fail\n");
> + goto out_bright_set;
> + }
> + shift = ffs(mtled_cdev->currsel_mask) - 1;
> + brightness -= 1;
> + ret = regmap_update_bits(mld->regmap, mtled_cdev->currsel_reg,
> + mtled_cdev->currsel_mask, brightness << shift);
> + if (ret < 0)
> + return ret;
> + if (mld->pdata->rgbon_sync) {
> + ret = regmap_read(mld->regmap, MT6360_LEDEN_REG, &sync_regval);
> + if (ret < 0)
> + goto out_bright_set;
> + ret = regmap_update_bits(mld->regmap,
> + MT6360_LEDEN_REG, MT6360_LEDALLEN_MASK, 0);
> + if (ret < 0)
> + goto out_bright_set;
> + sync_regval |= mtled_cdev->enable_mask;
> + ret = regmap_update_bits(mld->regmap, MT6360_LEDEN_REG,
> + MT6360_LEDALLEN_MASK, sync_regval);
> + } else {
> + ret = regmap_update_bits(mld->regmap, MT6360_LEDEN_REG,
> + mtled_cdev->enable_mask, 0xff);
> + }
> +out_bright_set:
> + return ret;
> +}
> +
> +static enum led_brightness mt6360_led_brightness_get(struct led_classdev *cdev)
> +{
> + struct mt6360_led_classdev *mtled_cdev =
> + (struct mt6360_led_classdev *)cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(cdev->dev->parent);
> + unsigned int regval = 0;
> + int shift = ffs(mtled_cdev->currsel_mask) - 1, ret;
> +
> + ret = regmap_read(mld->regmap, MT6360_LEDEN_REG, ®val);
> + if (ret < 0) {
> + dev_err(cdev->dev, "%s: get enable fail\n", __func__);
> + return LED_OFF;
> + }
> + if (!(regval & mtled_cdev->enable_mask))
> + return LED_OFF;
> + ret = regmap_read(mld->regmap, mtled_cdev->currsel_reg, ®val);
> + if (ret < 0) {
> + dev_err(cdev->dev, "%s: get isink fail\n", __func__);
> + return LED_OFF;
> + }
> + regval &= mtled_cdev->currsel_mask;
> + regval >>= shift;
> + return (regval + 1);
> +}
> +
> +static const unsigned int dim_freqs[] = {
> + 4, 8, 250, 500, 1000, 2000, 4000, 8000,
> +};
> +
> +static int mt6360_led_blink_set(struct led_classdev *cdev,
> + unsigned long *delay_on, unsigned long *delay_off)
> +{
> + struct mt6360_led_classdev *mtled_cdev =
> + (struct mt6360_led_classdev *)cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(cdev->dev->parent);
> + int freq, duty, shift, sum, ret;
> +
> + if (mtled_cdev->mode_reg == 0)
> + return -ENOTSUPP;
> + if (*delay_on == 0 && *delay_off == 0)
> + *delay_on = *delay_off = 500;
> + sum = *delay_on + *delay_off;
> + for (freq = 0; freq < ARRAY_SIZE(dim_freqs); freq++) {
> + if (sum <= dim_freqs[freq])
> + break;
> + }
> + if (freq == ARRAY_SIZE(dim_freqs)) {
> + dev_err(cdev->dev, "exceed pwm frequency max\n");
> + return -EINVAL;
> + }
> + /* invert */
> + freq = ARRAY_SIZE(dim_freqs) - 1 - freq;
> + shift = ffs(mtled_cdev->pwmfreq_mask) - 1;
> + ret = regmap_update_bits(mld->regmap, mtled_cdev->pwmfreq_reg,
> + mtled_cdev->pwmfreq_mask, freq << shift);
> + if (ret < 0) {
> + dev_err(cdev->dev, "Failed to set pwmfreq\n");
> + return ret;
> + }
> + duty = 255 * (*delay_on) / sum;
> + shift = ffs(mtled_cdev->pwmduty_mask) - 1;
> + ret = regmap_update_bits(mld->regmap, mtled_cdev->pwmduty_reg,
> + mtled_cdev->pwmduty_mask, duty << shift);
> + if (ret < 0) {
> + dev_err(cdev->dev, "Failed to set pwmduty\n");
> + return ret;
> + }
> + shift = ffs(mtled_cdev->mode_mask) - 1;
> + ret = regmap_update_bits(mld->regmap, mtled_cdev->mode_reg,
> + mtled_cdev->mode_mask, MT6360_LEDMODE_PWM << shift);
> + return ret;
> +}
> +
> +#define MT6360_LED_DESC(_id) { \
> + .cdev = { \
> + .name = "mt6360_isink" #_id, \
> + .max_brightness = MT6360_SINKCUR_MAX##_id, \
> + .brightness_set_blocking = mt6360_led_brightness_set, \
> + .brightness_get = mt6360_led_brightness_get, \
> + .blink_set = mt6360_led_blink_set, \
> + }, \
> + .index = MT6360_LED_ISINK##_id, \
> + .currsel_reg = MT6360_CURRSEL_REG##_id, \
> + .currsel_mask = MT6360_CURRSEL_MASK##_id, \
> + .enable_mask = MT6360_LEDEN_MASK##_id, \
> + .mode_reg = MT6360_LEDMODE_REG##_id, \
> + .mode_mask = MT6360_LEDMODE_MASK##_id, \
> + .pwmduty_reg = MT6360_PWMDUTY_REG##_id, \
> + .pwmduty_mask = MT6360_PWMDUTY_MASK##_id, \
> + .pwmfreq_reg = MT6360_PWMFREQ_REG##_id, \
> + .pwmfreq_mask = MT6360_PWMFREQ_MASK##_id, \
> + .breath_regbase = MT6360_BREATH_REGBASE##_id, \
> +}
> +
> +/* ISINK 1/2/3 for RGBLED, ISINK4 for MoonLight */
> +static const struct mt6360_led_classdev def_led_classdev[MT6360_LED_MAX] = {
> + MT6360_LED_DESC(1),
> + MT6360_LED_DESC(2),
> + MT6360_LED_DESC(3),
> + MT6360_LED_DESC(4),
> +};
> +
> +static inline bool mt6360_fled_check_flags_if_any(unsigned long *flags)
> +{
> + return (*flags) ? true : false;
> +}
> +
> +static int mt6360_fled_strobe_brightness_set(
> + struct led_classdev_flash *fled_cdev, u32 brightness)
> +{
> + struct led_classdev *led_cdev = &fled_cdev->led_cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct led_flash_setting *fs = &fled_cdev->brightness;
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)fled_cdev;
> + int shift;
> + u32 val;
> +
> + val = brightness;
> + val = (val - fs->min) / fs->step;
> + shift = ffs(mtfled_cdev->strobe_bright_mask) - 1;
> + return regmap_update_bits(mld->regmap, mtfled_cdev->strobe_bright_reg,
> + mtfled_cdev->strobe_bright_mask, val << shift);
> +}
> +
> +static int mt6360_fled_strobe_brightness_get(
> + struct led_classdev_flash *fled_cdev, u32 *brightness)
> +{
> + struct led_classdev *led_cdev = &fled_cdev->led_cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct led_flash_setting *fs = &fled_cdev->brightness;
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)fled_cdev;
> + int shift, ret;
> + u32 regval = 0;
> +
> + ret = regmap_read(mld->regmap, mtfled_cdev->strobe_bright_reg, ®val);
> + if (ret < 0)
> + return ret;
> + regval &= mtfled_cdev->strobe_bright_mask;
> + shift = ffs(mtfled_cdev->strobe_bright_mask) - 1;
> + regval >>= shift;
> + /* convert to microamp value */
> + *brightness = regval * fs->step + fs->min;
> + return 0;
> +}
> +
> +static int mt6360_fled_strobe_set(
> + struct led_classdev_flash *fled_cdev, bool state)
> +{
> + struct led_classdev *led_cdev = &fled_cdev->led_cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)fled_cdev;
> + int id = mtfled_cdev->index, ret;
> +
> + if (!(state ^ test_bit(id, &mld->fl_strobe_flags)))
> + return 0;
> + if (mt6360_fled_check_flags_if_any(&mld->fl_torch_flags)) {
> + dev_err(led_cdev->dev,
> + "Disable all leds torch [%lu]\n", mld->fl_torch_flags);
> + return -EINVAL;
> + }
> + ret = regmap_update_bits(mld->regmap, mtfled_cdev->cs_enable_reg,
> + mtfled_cdev->cs_enable_mask, state ? 0xff : 0);
> + if (ret < 0) {
> + dev_err(led_cdev->dev, "Fail to set cs enable [%d]\n", state);
> + goto out_strobe_set;
> + }
> + ret = regmap_update_bits(mld->regmap, mtfled_cdev->strobe_enable_reg,
> + mtfled_cdev->strobe_enable_mask, state ? 0xff : 0);
> + if (ret < 0) {
> + dev_err(led_cdev->dev, "Fail to set strb enable [%d]\n", state);
> + goto out_strobe_set;
> + }
> + if (state) {
> + if (!mt6360_fled_check_flags_if_any(&mld->fl_strobe_flags))
> + usleep_range(5000, 6000);
> + set_bit(id, &mld->fl_strobe_flags);
> + mtfled_cdev->faults = 0;
> + } else {
> + clear_bit(id, &mld->fl_strobe_flags);
> + if (!mt6360_fled_check_flags_if_any(&mld->fl_strobe_flags))
> + usleep_range(400, 500);
> + }
> +out_strobe_set:
> + return ret;
> +}
> +
> +static int mt6360_fled_strobe_get(
> + struct led_classdev_flash *fled_cdev, bool *state)
> +{
> + struct led_classdev *led_cdev = &fled_cdev->led_cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)fled_cdev;
> + int id = mtfled_cdev->index;
> +
> + *state = test_bit(id, &mld->fl_strobe_flags) ? true : false;
> + return 0;
> +}
> +
> +static int mt6360_fled_strobe_timeout_set(
> + struct led_classdev_flash *fled_cdev, u32 timeout)
> +{
> + struct led_classdev *led_cdev = &fled_cdev->led_cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct led_flash_setting *ts = &fled_cdev->timeout;
> + int shift, ret;
> + u32 regval;
> +
> + regval = (timeout - ts->min) / ts->step;
> + shift = ffs(MT6360_STRBTIMEOUT_MASK) - 1;
> + ret = regmap_update_bits(mld->regmap, MT6360_STRBTIMEOUT_REG,
> + MT6360_STRBTIMEOUT_MASK, regval << shift);
> + return ret;
> +}
> +
> +static int mt6360_fled_strobe_fault_get(
> + struct led_classdev_flash *fled_cdev, u32 *fault)
> +{
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)fled_cdev;
> +
> + *fault = mtfled_cdev->faults;
> + return 0;
> +}
> +
> +static const struct led_flash_ops mt6360_fled_ops = {
> + .flash_brightness_set = mt6360_fled_strobe_brightness_set,
> + .flash_brightness_get = mt6360_fled_strobe_brightness_get,
> + .strobe_set = mt6360_fled_strobe_set,
> + .strobe_get = mt6360_fled_strobe_get,
> + .timeout_set = mt6360_fled_strobe_timeout_set,
> + .fault_get = mt6360_fled_strobe_fault_get,
> +};
> +
> +static int mt6360_fled_brightness_set(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + struct led_classdev_flash *lcf = lcdev_to_flcdev(led_cdev);
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)lcf;
> + int id = mtfled_cdev->index, shift, keep, ret;
> +
> + if (mt6360_fled_check_flags_if_any(&mld->fl_strobe_flags)) {
> + dev_err(led_cdev->dev,
> + "Disable all leds strobe [%lu]\n", mld->fl_strobe_flags);
> + return -EINVAL;
> + }
> + if (brightness == LED_OFF) {
> + clear_bit(id, &mld->fl_torch_flags);
> + keep = mt6360_fled_check_flags_if_any(&mld->fl_torch_flags);
> + ret = regmap_update_bits(mld->regmap,
> + mtfled_cdev->torch_enable_reg,
> + mtfled_cdev->torch_enable_mask,
> + keep ? 0xff : 0);
> + if (ret < 0) {
> + dev_err(led_cdev->dev, "Fail to set torch disable\n");
> + goto out_bright_set;
> + }
> + ret = regmap_update_bits(mld->regmap,
> + mtfled_cdev->cs_enable_reg,
> + mtfled_cdev->cs_enable_mask, 0);
> + if (ret < 0)
> + dev_err(led_cdev->dev, "Fail to set torch disable\n");
> + goto out_bright_set;
> + }
> + shift = ffs(mtfled_cdev->torch_bright_mask) - 1;
> + brightness -= 1;
> + ret = regmap_update_bits(mld->regmap, mtfled_cdev->torch_bright_reg,
> + mtfled_cdev->torch_bright_mask, brightness << shift);
> + if (ret < 0) {
> + dev_err(led_cdev->dev,
> + "Fail to set torch bright [%d]\n", brightness);
> + goto out_bright_set;
> + }
> + ret = regmap_update_bits(mld->regmap, mtfled_cdev->cs_enable_reg,
> + mtfled_cdev->cs_enable_mask, 0xff);
> + if (ret < 0) {
> + dev_err(led_cdev->dev, "Fail to set cs enable\n");
> + goto out_bright_set;
> + }
> + ret = regmap_update_bits(mld->regmap, mtfled_cdev->torch_enable_reg,
> + mtfled_cdev->torch_enable_mask, 0xff);
> + set_bit(id, &mld->fl_torch_flags);
> +out_bright_set:
> + return ret;
> +}
> +
> +static enum led_brightness mt6360_fled_brightness_get(
> + struct led_classdev *led_cdev)
> +{
> + struct led_classdev_flash *lcf = lcdev_to_flcdev(led_cdev);
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)lcf;
> + int id = mtfled_cdev->index, shift, ret;
> + u32 regval = 0;
> +
> + if (!test_bit(id, &mld->fl_torch_flags))
> + return LED_OFF;
> + ret = regmap_read(mld->regmap, mtfled_cdev->torch_bright_reg, ®val);
> + if (ret < 0) {
> + dev_err(led_cdev->dev, "%s: Fail to get torb reg\n", __func__);
> + return LED_OFF;
> + }
> + shift = ffs(mtfled_cdev->torch_bright_mask) - 1;
> + regval &= mtfled_cdev->torch_bright_mask;
> + regval >>= shift;
> + return (regval + 1);
> +}
> +
> +#define MT6360_FLED_DESC(_id) { \
> + .fl_cdev = { \
> + .led_cdev = { \
> + .name = "mt6360_fled_ch" #_id, \
> + .max_brightness = MT6360_TORBRIGHT_MAX##_id, \
> + .brightness_set_blocking = mt6360_fled_brightness_set, \
> + .brightness_get = mt6360_fled_brightness_get, \
> + .flags = LED_DEV_CAP_FLASH, \
> + }, \
> + .brightness = { \
> + .min = MT6360_STROBECUR_MIN, \
> + .step = MT6360_STROBECUR_STEP, \
> + .max = MT6360_STROBECUR_MAX, \
> + .val = MT6360_STROBECUR_MIN, \
> + }, \
> + .timeout = { \
> + .min = MT6360_STRBTIMEOUT_MIN, \
> + .step = MT6360_STRBTIMEOUT_STEP, \
> + .max = MT6360_STRBTIMEOUT_MAX, \
> + .val = MT6360_STRBTIMEOUT_MIN, \
> + }, \
> + .ops = &mt6360_fled_ops, \
> + }, \
> + .index = MT6360_FLED_CH##_id, \
> + .cs_enable_reg = MT6360_CSENABLE_REG##_id, \
> + .cs_enable_mask = MT6360_CSENABLE_MASK##_id, \
> + .torch_bright_reg = MT6360_TORBRIGHT_REG##_id, \
> + .torch_bright_mask = MT6360_TORBRIGHT_MASK##_id, \
> + .torch_enable_reg = MT6360_TORENABLE_REG##_id, \
> + .torch_enable_mask = MT6360_TORENABLE_MASK##_id, \
> + .strobe_bright_reg = MT6360_STRBRIGHT_REG##_id, \
> + .strobe_bright_mask = MT6360_STRBRIGHT_MASK##_id, \
> + .strobe_enable_reg = MT6360_STRBENABLE_REG##_id, \
> + .strobe_enable_mask = MT6360_STRBENABLE_MASK##_id, \
> +}
> +
> +static const struct mt6360_fled_classdev def_fled_classdev[MT6360_FLED_MAX] = {
> + MT6360_FLED_DESC(1),
> + MT6360_FLED_DESC(2),
> +};
> +
> +#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
> +static int mt6360_fled_external_strobe_set(
> + struct v4l2_flash *v4l2_flash, bool enable)
> +{
> + struct led_classdev_flash *lcf = v4l2_flash->fled_cdev;
> + struct led_classdev *led_cdev = &lcf->led_cdev;
> + struct mt6360_led_data *mld = dev_get_drvdata(led_cdev->dev->parent);
> + struct mt6360_fled_classdev *mtfled_cdev = (void *)lcf;
> + int id = mtfled_cdev->index, ret;
> +
> + if (!(enable ^ test_bit(id, &mld->fl_strobe_flags)))
> + return 0;
> + if (mt6360_fled_check_flags_if_any(&mld->fl_torch_flags)) {
> + dev_err(led_cdev->dev,
> + "Disable all leds torch [%lu]\n", mld->fl_torch_flags);
> + return -EINVAL;
> + }
> + ret = regmap_update_bits(mld->regmap, mtfled_cdev->cs_enable_reg,
> + mtfled_cdev->cs_enable_mask, enable ? 0xff : 0);
> + if (enable) {
> + set_bit(id, &mld->fl_strobe_flags);
> + mtfled_cdev->faults = 0;
> + } else
> + clear_bit(id, &mld->fl_strobe_flags);
> + return ret;
> +}
> +
> +static const struct v4l2_flash_ops v4l2_flash_ops = {
> + .external_strobe_set = mt6360_fled_external_strobe_set,
> +};
> +
> +static void mt6360_init_v4l2_flash_config(
> + struct mt6360_fled_classdev *mtfled_cdev,
> + struct v4l2_flash_config *config)
> +{
> + struct led_flash_setting *torch_intensity = &config->intensity;
> + struct led_classdev *led_cdev = &(mtfled_cdev->fl_cdev.led_cdev);
> + s32 val;
> +
> + snprintf(config->dev_name, sizeof(config->dev_name),
> + "%s", mtfled_cdev->fl_cdev.led_cdev.name);
> + torch_intensity->min = MT6360_TORCHCUR_MIN;
> + torch_intensity->step = MT6360_TORCHCUR_STEP;
> + val = MT6360_TORCHCUR_MIN;
> + val += ((led_cdev->max_brightness - 1) * MT6360_TORCHCUR_STEP);
> + torch_intensity->val = torch_intensity->max = val;
> + config->flash_faults |= MT6360_FLEDSUPPORT_FAULTS;
> + config->has_external_strobe = 1;
> +}
> +#else
> +static const struct v4l2_flash_ops v4l2_flash_ops;
> +
> +static void mt6360_init_v4l2_flash_config(
> + struct mt6360_fled_classdev *mtfled_cdev,
> + struct v4l2_flash_config *config)
> +{
> +}
> +#endif /* IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS) */
> +
> +static irqreturn_t mt6360_pmu_fled_lvf_evt_handler(int irq, void *data)
> +{
> + struct mt6360_led_data *mld = data;
> +
> + dev_err(mld->dev, "%s\n", __func__);
> + mld->mtfled_cdev[MT6360_FLED_CH1].faults |= LED_FAULT_UNDER_VOLTAGE;
> + mld->mtfled_cdev[MT6360_FLED_CH2].faults |= LED_FAULT_UNDER_VOLTAGE;
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mt6360_pmu_fled2_short_evt_handler(int irq, void *data)
> +{
> + struct mt6360_led_data *mld = data;
> +
> + dev_err(mld->dev, "%s\n", __func__);
> + mld->mtfled_cdev[MT6360_FLED_CH2].faults |= LED_FAULT_SHORT_CIRCUIT;
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mt6360_pmu_fled1_short_evt_handler(int irq, void *data)
> +{
> + struct mt6360_led_data *mld = data;
> +
> + dev_err(mld->dev, "%s\n", __func__);
> + mld->mtfled_cdev[MT6360_FLED_CH1].faults |= LED_FAULT_SHORT_CIRCUIT;
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mt6360_pmu_fled2_strb_to_evt_handler(int irq, void *data)
> +{
> + struct mt6360_led_data *mld = data;
> +
> + mld->mtfled_cdev[MT6360_FLED_CH2].faults |= LED_FAULT_TIMEOUT;
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mt6360_pmu_fled1_strb_to_evt_handler(int irq, void *data)
> +{
> + struct mt6360_led_data *mld = data;
> +
> + mld->mtfled_cdev[MT6360_FLED_CH1].faults |= LED_FAULT_TIMEOUT;
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mt6360_pmu_fled_chg_vinovp_evt_handler(int irq, void *data)
> +{
> + struct mt6360_led_data *mld = data;
> +
> + dev_warn(mld->dev, "%s\n", __func__);
> + mld->mtfled_cdev[MT6360_FLED_CH1].faults |= LED_FAULT_INPUT_VOLTAGE;
> + mld->mtfled_cdev[MT6360_FLED_CH2].faults |= LED_FAULT_INPUT_VOLTAGE;
> + return IRQ_HANDLED;
> +}
> +
> +static struct mt6360_pmu_irq_desc mt6360_pmu_fled_irq_desc[] = {
> + { "fled_chg_vinovp_evt", mt6360_pmu_fled_chg_vinovp_evt_handler },
> + { "fled_lvf_evt", mt6360_pmu_fled_lvf_evt_handler },
> + { "fled2_short_evt", mt6360_pmu_fled2_short_evt_handler },
> + { "fled1_short_evt", mt6360_pmu_fled1_short_evt_handler },
> + { "fled2_strb_to_evt", mt6360_pmu_fled2_strb_to_evt_handler },
> + { "fled1_strb_to_evt", mt6360_pmu_fled1_strb_to_evt_handler },
> +};
> +
> +static int mt6360_fled_irq_register(struct platform_device *pdev)
> +{
> + struct mt6360_pmu_irq_desc *irq_desc;
> + int i, irq, ret;
> +
> + for (i = 0; i < ARRAY_SIZE(mt6360_pmu_fled_irq_desc); i++) {
> + irq_desc = mt6360_pmu_fled_irq_desc + i;
> + if (unlikely(!irq_desc->name))
> + continue;
> + irq = platform_get_irq_byname(pdev, irq_desc->name);
> + if (irq < 0)
> + continue;
> + ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
> + irq_desc->irq_handler,
> + IRQF_TRIGGER_FALLING,
> + irq_desc->name,
> + platform_get_drvdata(pdev));
> + if (ret < 0) {
> + dev_err(&pdev->dev,
> + "request %s irq fail\n", irq_desc->name);
> + return ret;
> + }
> + }
> + return 0;
> +}
> +
> +static int mt6360_iled_parse_dt(struct device *dev,
> + struct mt6360_led_data *mld)
> +{
> + struct device_node *iled_np, *child;
> + struct mt6360_led_classdev *mtled_cdev;
> + u32 val;
> + int ret;
> +
> + if (!dev->of_node)
> + return 0;
> + iled_np = of_find_node_by_name(dev->of_node, "iled");
This should really follow the LED node naming convention
> + if (!iled_np)
> + return 0;
> + for_each_available_child_of_node(iled_np, child) {
Please use fwnode APIs
> + ret = of_property_read_u32(child, "reg", &val);
> + if (ret) {
> + dev_err(dev, "Fail to read reg property\n");
> + continue;
> + }
> + if (val >= MT6360_LED_MAX) {
> + dev_err(dev, "Invalid iled reg [%u]\n", val);
> + ret = -EINVAL;
> + goto out_iled_dt;
> + }
> + mtled_cdev = mld->mtled_cdev + val;
> +
> + of_property_read_string(child,
> + "label", &(mtled_cdev->cdev.name));
> + of_property_read_string(child, "linux,default-trigger",
> + &(mtled_cdev->cdev.default_trigger));
Same here
> + mtled_cdev->np = child;
> + }
> + return 0;
> +out_iled_dt:
> + of_node_put(child);
> + return ret;
> +}
> +
> +static int mt6360_fled_parse_dt(struct device *dev,
> + struct mt6360_led_data *mld)
> +{
> + struct device_node *fled_np, *child;
> + struct mt6360_fled_classdev *mtfled_cdev;
> + struct led_classdev *led_cdev;
> + struct led_flash_setting *fs;
> + u32 val;
> + int ret;
> +
> + if (!dev->of_node)
> + return 0;
Is this really necessary can this be done once by the caller before
calling each parse_dt function?
> + fled_np = of_find_node_by_name(dev->of_node, "fled");
> + if (!fled_np)
> + return 0;
> + for_each_available_child_of_node(fled_np, child) {
> + ret = of_property_read_u32(child, "reg", &val);
> + if (ret) {
> + dev_err(dev, "Fail to read reg property\n");
> + continue;
> + }
> + if (val >= MT6360_FLED_MAX) {
> + dev_err(dev, "Invalid fled reg [%u]\n", val);
> + ret = -EINVAL;
> + goto out_fled_dt;
> + }
> + mtfled_cdev = mld->mtfled_cdev + val;
> +
> + of_property_read_string(child, "label",
> + &(mtfled_cdev->fl_cdev.led_cdev.name));
> + ret = of_property_read_u32(child, "led-max-microamp", &val);
> + if (ret) {
> + dev_warn(dev, "led-max-microamp property missing\n");
> + val = MT6360_TORCHCUR_MIN;
> + }
> + if (val < MT6360_TORCHCUR_MIN)
> + val = MT6360_TORCHCUR_MIN;
> + val = (val - MT6360_TORCHCUR_MIN) / MT6360_TORCHCUR_STEP + 1;
> + led_cdev = &(mtfled_cdev->fl_cdev.led_cdev);
> + led_cdev->max_brightness = min(led_cdev->max_brightness, val);
> + ret = of_property_read_u32(child, "flash-max-microamp", &val);
> + if (ret) {
> + dev_warn(dev, "flash-max-microamp property missing\n");
> + val = MT6360_STROBECUR_MIN;
> + }
> + if (val < MT6360_STROBECUR_MIN)
> + val = MT6360_STROBECUR_MIN;
> + fs = &(mtfled_cdev->fl_cdev.brightness);
> + fs->val = fs->max = min(fs->max, val);
> + ret = of_property_read_u32(child, "flash-max-timeout", &val);
> + if (ret) {
> + dev_warn(dev, "flash-max-timeout property missing\n");
> + val = MT6360_STRBTIMEOUT_MIN;
> + }
> + if (val < MT6360_STRBTIMEOUT_MIN)
> + val = MT6360_STRBTIMEOUT_MIN;
> + fs = &(mtfled_cdev->fl_cdev.timeout);
> + fs->val = fs->max = min(fs->max, val);
> + mtfled_cdev->np = child;
> + }
> + return 0;
> +out_fled_dt:
> + of_node_put(child);
> + return ret;
> +}
> +
> +static void mt6360_led_parse_dt_data(struct device *dev,
> + struct mt6360_led_platform_data *pdata)
> +{
> + struct device_node *np = dev->of_node;
> + int i, ret;
> + const struct {
> + const char *name;
> + u32 *val_ptr;
> + } u32_opts[] = {
> + { "rgbon_sync", &pdata->rgbon_sync },
> + { "fled1_ultraistrb", &pdata->fled1_ultraistrb },
> + { "fled2_ultraistrb", &pdata->fled2_ultraistrb },
> + };
> +
> + memcpy(pdata, &def_platform_data, sizeof(*pdata));
> + for (i = 0; i < ARRAY_SIZE(u32_opts); i++) {
> + ret = of_property_read_u32(np, u32_opts[i].name,
> + u32_opts[i].val_ptr);
> + if (ret)
> + dev_err(dev, "error reading '%s'\n", u32_opts[i].name);
> + }
> +}
> +
> +static int mt6360_led_apply_pdata(struct mt6360_led_data *mld,
> + struct mt6360_led_platform_data *pdata)
> +{
> + int i, ret;
> + const struct {
> + u32 *val_ptr;
> + u8 reg;
> + u8 mask;
> + u8 shift;
> + } sel_props[] = {
> + {
> + &pdata->fled1_ultraistrb, MT6360_PMU_FLED1_STRB_CTRL2,
> + MT6360_MASK_ULTRA_STROBE, MT6360_SHIFT_ULTRA_STROBE,
> + },
> + {
> + &pdata->fled2_ultraistrb, MT6360_PMU_FLED2_STRB_CTRL2,
> + MT6360_MASK_ULTRA_STROBE, MT6360_SHIFT_ULTRA_STROBE,
> + },
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(sel_props); i++) {
> + ret = regmap_update_bits(mld->regmap,
> + sel_props[i].reg,
> + sel_props[i].mask,
> + *sel_props[i].val_ptr <<
> + sel_props[i].shift);
> + if (ret < 0)
> + return ret;
> + }
> + return 0;
> +}
> +
> +static int mt6360_led_probe(struct platform_device *pdev)
> +{
> + struct mt6360_led_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + struct mt6360_led_data *mld;
> + struct mt6360_led_classdev *mtled_cdev;
> + struct mt6360_fled_classdev *mtfled_cdev;
> + struct v4l2_flash_config v4l2_config;
> + int i, ret;
> +
> + mld = devm_kzalloc(&pdev->dev, sizeof(*mld), GFP_KERNEL);
> + if (!mld)
> + return -ENOMEM;
> +
> + if (pdev->dev.of_node) {
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> + mt6360_led_parse_dt_data(&pdev->dev, pdata);
> + }
> +
> + if (!pdata) {
> + dev_err(&pdev->dev, "no platform data specified\n");
> + return -EINVAL;
> + }
> +
> + mld->dev = &pdev->dev;
> + mld->pdata = pdata;
> + platform_set_drvdata(pdev, mld);
> +
> + mld->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + if (!mld->regmap) {
> + dev_err(&pdev->dev, "Failed to get parent regmap\n");
> + return -ENODEV;
> + }
> +
> + ret = mt6360_led_apply_pdata(mld, pdata);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "apply pdata fail\n");
> + return ret;
> + }
> +
> + memcpy(mld->mtled_cdev, def_led_classdev, sizeof(def_led_classdev));
> + ret = mt6360_iled_parse_dt(&pdev->dev, mld);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to parse iled dt\n");
> + return ret;
> + }
> +
> + for (i = 0; i < MT6360_LED_MAX; i++) {
> + mtled_cdev = mld->mtled_cdev + i;
> + ret = devm_led_classdev_register(&pdev->dev,
> + &(mtled_cdev->cdev));
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to register led[%d]\n", i);
> + return ret;
> + }
> + mtled_cdev->cdev.dev->of_node = mtled_cdev->np;
> + }
> +
> + memcpy(mld->mtfled_cdev, def_fled_classdev, sizeof(def_fled_classdev));
> + ret = mt6360_fled_parse_dt(&pdev->dev, mld);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Fail to parse fled dt\n");
> + return ret;
> + }
> +
> + for (i = 0; i < MT6360_FLED_MAX; i++) {
> + mtfled_cdev = mld->mtfled_cdev + i;
> + ret = led_classdev_flash_register(&pdev->dev,
> + &mtfled_cdev->fl_cdev);
use devm_* function
Dan
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to register fled[%d]\n", i);
> + goto out_fled_cdev;
> + }
> + }
> +
> + for (i = 0; i < MT6360_FLED_MAX; i++) {
> + mtfled_cdev = mld->mtfled_cdev + i;
> + memset(&v4l2_config, 0, sizeof(v4l2_config));
> + mt6360_init_v4l2_flash_config(mtfled_cdev, &v4l2_config);
> + mtfled_cdev->v4l2_flash = v4l2_flash_init(&pdev->dev,
> + of_fwnode_handle(mtfled_cdev->np),
> + &mtfled_cdev->fl_cdev,
> + &v4l2_flash_ops, &v4l2_config);
> + if (IS_ERR(mtfled_cdev->v4l2_flash)) {
> + dev_err(&pdev->dev, "Failed to register v4l2_sd\n");
> + ret = PTR_ERR(mtfled_cdev->v4l2_flash);
> + goto out_v4l2_sd;
> + }
> + }
> +
> + ret = mt6360_fled_irq_register(pdev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "Failed to register irqs\n");
> + goto out_v4l2_sd;
> + }
> +
> + return 0;
> +out_v4l2_sd:
> + while (--i >= 0) {
> + mtfled_cdev = mld->mtfled_cdev + i;
> + v4l2_flash_release(mtfled_cdev->v4l2_flash);
> + }
> + i = MT6360_FLED_MAX;
> +out_fled_cdev:
> + while (--i >= 0) {
> + mtfled_cdev = mld->mtfled_cdev + i;
> + led_classdev_flash_unregister(&mtfled_cdev->fl_cdev);
> + }
> + return ret;
> +}
> +
> +static int mt6360_led_remove(struct platform_device *pdev)
> +{
> + struct mt6360_led_data *mld = platform_get_drvdata(pdev);
> + struct mt6360_fled_classdev *mtfled_cdev;
> + int i;
> +
> + for (i = 0; i < MT6360_FLED_MAX; i++) {
> + mtfled_cdev = mld->mtfled_cdev + i;
> + v4l2_flash_release(mtfled_cdev->v4l2_flash);
> + led_classdev_flash_unregister(&mtfled_cdev->fl_cdev);
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id __maybe_unused mt6360_led_of_id[] = {
> + { .compatible = "mediatek,mt6360_led", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mt6360_led_of_id);
> +
> +static struct platform_driver mt6360_led_driver = {
> + .driver = {
> + .name = "mt6360_led",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(mt6360_led_of_id),
> + },
> + .probe = mt6360_led_probe,
> + .remove = mt6360_led_remove,
> +};
> +module_platform_driver(mt6360_led_driver);
> +
> +MODULE_AUTHOR("Gene Chen <gene_chen@richtek.com>");
> +MODULE_DESCRIPTION("MT6360 Led Driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
> index ea13040..2b81ab5 100644
> --- a/include/linux/mfd/mt6360.h
> +++ b/include/linux/mfd/mt6360.h
> @@ -29,6 +29,11 @@ struct mt6360_pmu_data {
> unsigned int chip_rev;
> };
>
> +struct mt6360_pmu_irq_desc {
> + const char *name;
> + irq_handler_t irq_handler;
> +};
> +
> /* PMU register defininition */
> #define MT6360_PMU_DEV_INFO (0x00)
> #define MT6360_PMU_CORE_CTRL1 (0x01)
> @@ -236,5 +241,4 @@ struct mt6360_pmu_data {
> #define CHIP_VEN_MASK (0xF0)
> #define CHIP_VEN_MT6360 (0x50)
> #define CHIP_REV_MASK (0x0F)
> -
> #endif /* __MT6360_H__ */
_______________________________________________
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] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
From: Marc Zyngier @ 2020-06-04 16:07 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Mark Rutland, suzuki.poulose, Catalin Marinas, James Morse,
Will Deacon, Linux ARM
In-Reply-To: <CAMj1kXEnJOUSWZTMGCn6cS3OiM9_DpJUj-MekENySf1x6Y1W5g@mail.gmail.com>
On 2020-06-04 16:48, Ard Biesheuvel wrote:
> On Thu, 4 Jun 2020 at 17:41, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> On Thu, 4 Jun 2020 at 17:25, Marc Zyngier <maz@kernel.org> wrote:
>> >
>> > On 2020-06-04 16:01, Will Deacon wrote:
>> > > On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote:
>> > >> Hi all,
>> > >>
>> > >> On Tue, 28 Apr 2020 15:49:35 +0100
>> > >> Will Deacon <will@kernel.org> wrote:
>> > >>
>> > >> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote:
>> > >> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of
>> > >> > > the arm64 port where the boot protocol was basically 'copy this image
>> > >> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space
>> > >> > > to put the swapper page tables. When the arm64 port was merged for
>> > >> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET,
>> > >> > > to allow the bootloader to discover it dynamically rather than hardcode
>> > >> > > it to 512 KB.
>> > >> > >
>> > >> > > [...]
>> > >> >
>> > >> > Applied to arm64 (for-next/misc), thanks!
>> > >> >
>> > >> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
>> > >> > https://git.kernel.org/arm64/c/cfa7ede20f13
>> > >>
>> > >> This breaks a guest kernel booted with kvmtool (tested on my d05).
>> > >> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet
>> > >> investigated what is happening here though.
>> > >
>> > > Weird, that's a combination I test, just not on d05. Are you using
>> > > defconfig? Can you share your full kvmtool invication please?
>> >
>> > Ah, good point. Not defconfig, but one that allows me to run the same
>> > kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty
>> > basic:
>> >
>> > lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image
>> >
>>
>> OK, so my suspicions is that your config does not enable
>> CONFIG_RANDOMIZE_BASE, and that kvmtool ignores the text offset value
>> in the header altogether.
>
> arm/aarch64/include/kvm/kvm-arch.h:#define ARM_KERN_OFFSET(kvm)
> ((kvm)->cfg.arch.aarch32_guest ? \
> arm/aarch64/include/kvm/kvm-arch.h- 0x8000
> : \
> arm/aarch64/include/kvm/kvm-arch.h-
> 0x80000)
Yeah, nice catch. I'll try and fix the sucker.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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] pinctrl: pxa: pxa2xx: Remove 'pxa2xx_pinctrl_exit()' which is unused and broken
From: Joe Perches @ 2020-06-04 16:08 UTC (permalink / raw)
To: Dan Carpenter, Julia Lawall
Cc: Linus Walleij, kernel-janitors, linux-kernel@vger.kernel.org,
Haojian Zhuang, open list:GPIO SUBSYSTEM, Christophe JAILLET,
Daniel Mack, Robert Jarzmik, Linux ARM
In-Reply-To: <20200604123038.GG22511@kadam>
On Thu, 2020-06-04 at 15:30 +0300, Dan Carpenter wrote:
> On Thu, Jun 04, 2020 at 01:42:12PM +0200, Julia Lawall wrote:
> > OK, I recall a discussion with Dan where he suggested that some things
> > that were not actually bug fixes could also merit a Fixes tag. But it's
> > probably better if he weighs in directly.
>
> I generally think Fixes should only be used for "real bug" fixes.
>
> The one exception is when I'm reviewing a patch that fixes an "unused
> assignment" static checker warning is that I know which commit
> introduced the warning. I don't have strong feelings if it's in the
> Fixes tag or if it's just mentioned in the commit message.
My view is that changes that silence compiler warnings are
not fixing bugs and that these changes should generally not
be backported.
Compiler silencing changes marked as fixes can introduce other
defects in working code.
Backporting patches to stable trees should be conservatively
rather than liberally applied.
It seems that the actual backport maintainers disagree though.
_______________________________________________
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 0/2] Small devm helper for devm implementations
From: Marc Gonzalez @ 2020-06-04 16:13 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette, Kuninori Morimoto, Russell King,
Sudip Mukherjee, Dmitry Torokhov, Guenter Roeck, Bjorn Andersson,
Robin Murphy, Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel,
Greg Kroah-Hartman, Rafael Wysocki, Suzuki Poulose, Mark Rutland
Cc: linux-clk, Linux ARM, LKML
In-Reply-To: <e8221bff-3e2a-7607-c5c8-abcf9cebb1b5@free.fr>
Looks like this series has fallen through the cracks :(
Greg, you would be taking the drivers/base/devres.c changes?
As mentioned in patch 2, "This patch needs testing on a platform with many clocks."
(I've only tested using a trivial kernel module)
On 10/03/2020 11:11, Marc Gonzalez wrote:
> Differences from v4 to v5
> x Fix the grammar in devm_add comments [Geert]
> x Undo an unrelated change in devm_clk_put [Geert]
>
> Differences from v3 to v4
> x Add a bunch of kerneldoc above devm_add() [Greg KH]
> x Split patch in two [Greg KH]
>
> Differences from v2 to v3
> x Make devm_add() return an error-code rather than the raw data pointer
> (in case devres_alloc ever returns an ERR_PTR) as suggested by Geert
> x Provide a variadic version devm_vadd() to work with structs as suggested
> by Geert
> x Don't use nested ifs in clk_devm* implementations (hopefully simpler
> code logic to follow) as suggested by Geert
>
> Marc Gonzalez (2):
> devres: Provide new helper for devm functions
> clk: Use devm_add in managed functions
>
> drivers/base/devres.c | 28 ++++++++++++
> drivers/clk/clk-devres.c | 97 +++++++++++++++-------------------------
> include/linux/device.h | 3 ++
> 3 files changed, 67 insertions(+), 61 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] pinctrl: pxa: pxa2xx: Remove 'pxa2xx_pinctrl_exit()' which is unused and broken
From: Julia Lawall @ 2020-06-04 16:29 UTC (permalink / raw)
To: Joe Perches
Cc: Linux ARM, Linus Walleij, kernel-janitors,
linux-kernel@vger.kernel.org, Haojian Zhuang, Julia Lawall,
open list:GPIO SUBSYSTEM, Christophe JAILLET, Dan Carpenter,
Robert Jarzmik, Daniel Mack
In-Reply-To: <0749ac5e3868c6ba50728ced8366bfd86b0b8500.camel@perches.com>
On Thu, 4 Jun 2020, Joe Perches wrote:
> On Thu, 2020-06-04 at 15:30 +0300, Dan Carpenter wrote:
> > On Thu, Jun 04, 2020 at 01:42:12PM +0200, Julia Lawall wrote:
> > > OK, I recall a discussion with Dan where he suggested that some things
> > > that were not actually bug fixes could also merit a Fixes tag. But it's
> > > probably better if he weighs in directly.
> >
> > I generally think Fixes should only be used for "real bug" fixes.
> >
> > The one exception is when I'm reviewing a patch that fixes an "unused
> > assignment" static checker warning is that I know which commit
> > introduced the warning. I don't have strong feelings if it's in the
> > Fixes tag or if it's just mentioned in the commit message.
>
> My view is that changes that silence compiler warnings are
> not fixing bugs and that these changes should generally not
> be backported.
>
> Compiler silencing changes marked as fixes can introduce other
> defects in working code.
>
> Backporting patches to stable trees should be conservatively
> rather than liberally applied.
>
> It seems that the actual backport maintainers disagree though.
But the rule seemed to be "bug fixing patches must contain a Fixes", and
not "backportable patches must contain a Fixes".
Overall, the relationship between backporting and Fixes is not so clear.
Patches that remove something unnecessary might benefit from having a
Fixes, but might not be worth backporting.
julia
_______________________________________________
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