* [PATCH v13 05/12] mailbox: mediatek: cmdq: support mt8183 gce function
From: Bibby Hsieh @ 2019-08-20 8:36 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, Bibby Hsieh, linux-arm-kernel,
ginny.chen
In-Reply-To: <20190820083635.5404-1-bibby.hsieh@mediatek.com>
add mt8183 compatible name for supporting gce function
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/mailbox/mtk-cmdq-mailbox.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 8fddd26288e8..69daaadc3a5f 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -539,6 +539,7 @@ static const struct dev_pm_ops cmdq_pm_ops = {
static const struct of_device_id cmdq_of_ids[] = {
{.compatible = "mediatek,mt8173-gce", .data = (void *)16},
+ {.compatible = "mediatek,mt8183-gce", .data = (void *)24},
{}
};
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v13 08/12] soc: mediatek: cmdq: change the type of input parameter
From: Bibby Hsieh @ 2019-08-20 8:36 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, Philipp Zabel, srv_heupstream,
Daoyuan Huang, Sascha Hauer, linux-kernel, Daniel Kurtz,
Dennis-YC Hsieh, linux-mediatek, Houlong Wei, Sascha Hauer,
YT Shen, Jiaguang Zhang, Bibby Hsieh, linux-arm-kernel,
ginny.chen
In-Reply-To: <20190820083635.5404-1-bibby.hsieh@mediatek.com>
According to the cmdq hardware design, the subsys is u8,
the offset is u16 and the event id is u16.
This patch changes the type of subsys, offset and event id
to the correct type.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 10 +++++-----
include/linux/soc/mediatek/mtk-cmdq.h | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 082b8978651e..7aa0517ff2f3 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
- u32 offset, u32 value, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
@@ -161,7 +161,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
u32 arg_b;
@@ -181,7 +181,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
-int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event)
+int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 39d813dde4b4..9618debb9ceb 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -66,7 +66,7 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
@@ -78,8 +78,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
- u32 offset, u32 value, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
@@ -88,7 +88,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
@@ -97,7 +97,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event);
+int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Csapat motiváció
From: Kapolcs Mátyás @ 2019-08-20 8:30 UTC (permalink / raw)
To: linux-arm-kernel
Üdvözlöm!
Ahogyan az üzleti gyakorlat mutatja, a nem anyagi juttatások sajnos nem a leghatékonyabb módjai annak, hogy növeljük az alkalmazottak motivációját vagy a munka iránti elköteleződésüket!
Az alkalmazottakkal szemben tanúsított lojalitás jelenleg a legnagyobb kihívás a vállalkozások számára országunkban.
Az foglalkoztatók rendelkezésre bocsájtanak, többek között, étkezési jegyeket, amelyek felhasználhatók bármilyen jellegű élelmiszer vásárlása esetén, valamint az internetes vásárlások alkalmával is.
El tudja érni nem csupán a jobban motviált dolgozói csapatot, de ugyanakkor adóbefizetését is csökkentheti!
Szeretne többet tudni a lehetőségről amely megoldásként szolgálhat Ön és kollégái számára?
Kapolcs Mátyás
Hungary Team Leader
_______________________________________________
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] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Andy Shevchenko @ 2019-08-20 8:29 UTC (permalink / raw)
To: Linus Walleij
Cc: Salil Mehta, jinying, Tangkunshan, Liguozhu (Kenneth), John Garry,
Rafael J. Wysocki, Linux Kernel Mailing List, Wei Xu, Linuxarm,
open list:GPIO SUBSYSTEM, Shiju Jose, Shameerali Kolothum Thodi,
huangdaode, Jonathan Cameron, Thierry Reding, Mika Westerberg,
Zhangyi ac, linux-arm Mailing List, Len Brown
In-Reply-To: <CACRpkdbRZ=88+ooW5jb5vu4Dwsaj7Ce+V5Ked2-bGn0JWpTHfQ@mail.gmail.com>
On Tue, Aug 20, 2019 at 10:12 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>
> > The proper fix is to revert the culprit since we call
> > acpi_gpiochip_request_interrupts() for all controllers.
> > Linus, please re-do the approach with IRQ handling,
>
> Exactly what do you refer to when you want me to
> "re-do the approach for IRQ handling"? Do you mean
> this driver or are you referring to:
>
> commit e0d89728981393b7d694bd3419b7794b9882c92d
> Author: Thierry Reding <treding@nvidia.com>
> Date: Tue Nov 7 19:15:54 2017 +0100
>
> gpio: Implement tighter IRQ chip integration
>
> Currently GPIO drivers are required to add the GPIO chip and its
> corresponding IRQ chip separately, which can result in a lot of
> boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
> struct gpio_chip, that drivers can fill in if they want the GPIO core
> to automatically register the IRQ chip associated with a GPIO chip.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> The new API introduced by this patch is what I am trying to switch
> everything over to, because the forked paths inside of gpiolib
> is causing me a maintenance headache and also increasing
> the footprint of the library.
>
> > it seems broadly
> > regress with ACPI enabled platforms.
>
> It only becomes a problem if the platform uses ACPI right?
> But it's a problem if I can't really tell if a driver is using
> ACPI or not, there is no sign in the pl061 driver that it would
> be used on ACPI systems until now, so how do I design
> for it?
>
> The problem comes from the problem/mess I am trying to
> clean up in the first place. So if the new way of registering GPIO
> irqchips is not working for ACPI, then we have to fix that instead
> of reverting all attempts to use the new API IMO.
>
> Yours,
> Linus Walleij
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver
From: Maxime Ripard @ 2019-08-20 8:27 UTC (permalink / raw)
To: Samuel Holland
Cc: Mark Rutland, devicetree, linux-sunxi, Stephen Boyd,
Michael Turquette, Jassi Brar, linux-kernel, Chen-Yu Tsai,
Rob Herring, Corentin Labbe, linux-clk, linux-arm-kernel
In-Reply-To: <20190820032311.6506-5-samuel@sholland.org>
[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]
Hi,
On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> used for communication between the ARM CPUs and the ARISC management
> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
>
> Add a driver for it, so it can be used for SCPI or other communication
> protocols.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/sunxi-msgbox.c | 323 +++++++++++++++++++++++++++++++++
> 3 files changed, 335 insertions(+)
> create mode 100644 drivers/mailbox/sunxi-msgbox.c
It's pretty much the same remark than for the name of the binding
file, but sunxi in itself is pretty confusing, it covers a range of
SoCs going from armv5 to armv8, some with a single CPU and some with
more, and some with an OpenRISC core and some without.
It would be less confusing (albeit not perfect) to use sun6i there,
the family that IP was first introduced in.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 00/17] Arm SMMU refactoring
From: Vivek Gautam @ 2019-08-20 8:20 UTC (permalink / raw)
To: Robin Murphy, will
Cc: robdclark, gregory.clement, bjorn.andersson, iommu, jcrouse, joro,
linux-arm-kernel
In-Reply-To: <cover.1565892337.git.robin.murphy@arm.com>
On 8/16/2019 12:07 AM, Robin Murphy wrote:
> Hi all,
>
> v1 for context: https://patchwork.kernel.org/cover/11087347/
>
> Here's a quick v2 attempting to address all the minor comments; I've
> tweaked a whole bunch of names, added some verbosity in macros and
> comments for clarity, and rejigged arm_smmu_impl_init() for a bit more
> structure. The (new) patches #1 and #2 are up front as conceptual fixes,
> although they're not actually critical - it turns out to be more of an
> embarrassment than a real problem in practice.
>
> For ease of reference, the overall diff against v1 is attached below.
>
> Robin.
Hi,
I have given this series a shot with 5.3-rc5 kernel on MTP sdm845
device, and smmu works as expected.
Tested-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Best regards
Vivek
>
>
> Robin Murphy (17):
> iommu/arm-smmu: Mask TLBI address correctly
> iommu/qcom: Mask TLBI addresses correctly
> iommu/arm-smmu: Convert GR0 registers to bitfields
> iommu/arm-smmu: Convert GR1 registers to bitfields
> iommu/arm-smmu: Convert context bank registers to bitfields
> iommu/arm-smmu: Rework cb_base handling
> iommu/arm-smmu: Split arm_smmu_tlb_inv_range_nosync()
> iommu/arm-smmu: Get rid of weird "atomic" write
> iommu/arm-smmu: Abstract GR1 accesses
> iommu/arm-smmu: Abstract context bank accesses
> iommu/arm-smmu: Abstract GR0 accesses
> iommu/arm-smmu: Rename arm-smmu-regs.h
> iommu/arm-smmu: Add implementation infrastructure
> iommu/arm-smmu: Move Secure access quirk to implementation
> iommu/arm-smmu: Add configuration implementation hook
> iommu/arm-smmu: Add reset implementation hook
> iommu/arm-smmu: Add context init implementation hook
>
> MAINTAINERS | 3 +-
> drivers/iommu/Makefile | 2 +-
> drivers/iommu/arm-smmu-impl.c | 174 +++++++++++
> drivers/iommu/arm-smmu-regs.h | 210 -------------
> drivers/iommu/arm-smmu.c | 573 +++++++++++-----------------------
> drivers/iommu/arm-smmu.h | 394 +++++++++++++++++++++++
> drivers/iommu/qcom_iommu.c | 17 +-
> 7 files changed, 764 insertions(+), 609 deletions(-)
> create mode 100644 drivers/iommu/arm-smmu-impl.c
> delete mode 100644 drivers/iommu/arm-smmu-regs.h
> create mode 100644 drivers/iommu/arm-smmu.h
>
> ----->8-----
> diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
> index 3c731e087854..e22e9004f449 100644
> --- a/drivers/iommu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm-smmu-impl.c
> @@ -28,7 +28,7 @@ static int arm_smmu_gr0_ns(int offset)
> static u32 arm_smmu_read_ns(struct arm_smmu_device *smmu, int page,
> int offset)
> {
> - if (page == 0)
> + if (page == ARM_SMMU_GR0)
> offset = arm_smmu_gr0_ns(offset);
> return readl_relaxed(arm_smmu_page(smmu, page) + offset);
> }
> @@ -36,7 +36,7 @@ static u32 arm_smmu_read_ns(struct arm_smmu_device *smmu, int page,
> static void arm_smmu_write_ns(struct arm_smmu_device *smmu, int page,
> int offset, u32 val)
> {
> - if (page == 0)
> + if (page == ARM_SMMU_GR0)
> offset = arm_smmu_gr0_ns(offset);
> writel_relaxed(val, arm_smmu_page(smmu, page) + offset);
> }
> @@ -52,18 +52,17 @@ struct cavium_smmu {
> struct arm_smmu_device smmu;
> u32 id_base;
> };
> -#define to_csmmu(s) container_of(s, struct cavium_smmu, smmu)
>
> static int cavium_cfg_probe(struct arm_smmu_device *smmu)
> {
> static atomic_t context_count = ATOMIC_INIT(0);
> + struct cavium_smmu *cs = container_of(smmu, struct cavium_smmu, smmu);
> /*
> * Cavium CN88xx erratum #27704.
> * Ensure ASID and VMID allocation is unique across all SMMUs in
> * the system.
> */
> - to_csmmu(smmu)->id_base = atomic_fetch_add(smmu->num_context_banks,
> - &context_count);
> + cs->id_base = atomic_fetch_add(smmu->num_context_banks, &context_count);
> dev_notice(smmu->dev, "\tenabling workaround for Cavium erratum 27704\n");
>
> return 0;
> @@ -71,12 +70,13 @@ static int cavium_cfg_probe(struct arm_smmu_device *smmu)
>
> int cavium_init_context(struct arm_smmu_domain *smmu_domain)
> {
> - u32 id_base = to_csmmu(smmu_domain->smmu)->id_base;
> + struct cavium_smmu *cs = container_of(smmu_domain->smmu,
> + struct cavium_smmu, smmu);
>
> if (smmu_domain->stage == ARM_SMMU_DOMAIN_S2)
> - smmu_domain->cfg.vmid += id_base;
> + smmu_domain->cfg.vmid += cs->id_base;
> else
> - smmu_domain->cfg.asid += id_base;
> + smmu_domain->cfg.asid += cs->id_base;
>
> return 0;
> }
> @@ -88,18 +88,18 @@ const struct arm_smmu_impl cavium_impl = {
>
> struct arm_smmu_device *cavium_smmu_impl_init(struct arm_smmu_device *smmu)
> {
> - struct cavium_smmu *csmmu;
> + struct cavium_smmu *cs;
>
> - csmmu = devm_kzalloc(smmu->dev, sizeof(*csmmu), GFP_KERNEL);
> - if (!csmmu)
> + cs = devm_kzalloc(smmu->dev, sizeof(*cs), GFP_KERNEL);
> + if (!cs)
> return ERR_PTR(-ENOMEM);
>
> - csmmu->smmu = *smmu;
> - csmmu->smmu.impl = &cavium_impl;
> + cs->smmu = *smmu;
> + cs->smmu.impl = &cavium_impl;
>
> devm_kfree(smmu->dev, smmu);
>
> - return &csmmu->smmu;
> + return &cs->smmu;
> }
>
>
> @@ -150,16 +150,25 @@ const struct arm_smmu_impl arm_mmu500_impl = {
>
> struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
> {
> - /* The current quirks happen to be mutually-exclusive */
> + /*
> + * We will inevitably have to combine model-specific implementation
> + * quirks with platform-specific integration quirks, but everything
> + * we currently support happens to work out as straightforward
> + * mutually-exclusive assignments.
> + */
> + switch (smmu->model) {
> + case ARM_MMU500:
> + smmu->impl = &arm_mmu500_impl;
> + break;
> + case CAVIUM_SMMUV2:
> + return cavium_smmu_impl_init(smmu);
> + default:
> + break;
> + }
> +
> if (of_property_read_bool(smmu->dev->of_node,
> "calxeda,smmu-secure-config-access"))
> smmu->impl = &calxeda_impl;
>
> - if (smmu->model == CAVIUM_SMMUV2)
> - return cavium_smmu_impl_init(smmu);
> -
> - if (smmu->model == ARM_MMU500)
> - smmu->impl = &arm_mmu500_impl;
> -
> return smmu;
> }
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 251089d6428d..b8628e2ab579 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -264,7 +264,7 @@ static void arm_smmu_tlb_sync_global(struct arm_smmu_device *smmu)
> unsigned long flags;
>
> spin_lock_irqsave(&smmu->global_sync_lock, flags);
> - __arm_smmu_tlb_sync(smmu, 0, ARM_SMMU_GR0_sTLBGSYNC,
> + __arm_smmu_tlb_sync(smmu, ARM_SMMU_GR0, ARM_SMMU_GR0_sTLBGSYNC,
> ARM_SMMU_GR0_sTLBGSTATUS);
> spin_unlock_irqrestore(&smmu->global_sync_lock, flags);
> }
> @@ -276,7 +276,7 @@ static void arm_smmu_tlb_sync_context(void *cookie)
> unsigned long flags;
>
> spin_lock_irqsave(&smmu_domain->cb_lock, flags);
> - __arm_smmu_tlb_sync(smmu, smmu->numpage + smmu_domain->cfg.cbndx,
> + __arm_smmu_tlb_sync(smmu, ARM_SMMU_CB(smmu, smmu_domain->cfg.cbndx),
> ARM_SMMU_CB_TLBSYNC, ARM_SMMU_CB_TLBSTATUS);
> spin_unlock_irqrestore(&smmu_domain->cb_lock, flags);
> }
> @@ -326,7 +326,7 @@ static void arm_smmu_tlb_inv_range_s1(unsigned long iova, size_t size,
> reg = leaf ? ARM_SMMU_CB_S1_TLBIVAL : ARM_SMMU_CB_S1_TLBIVA;
>
> if (cfg->fmt != ARM_SMMU_CTX_FMT_AARCH64) {
> - iova &= ~12UL;
> + iova = (iova >> 12) << 12;
> iova |= cfg->asid;
> do {
> arm_smmu_cb_write(smmu, idx, reg, iova);
> @@ -1197,7 +1197,7 @@ static phys_addr_t arm_smmu_iova_to_phys_hard(struct iommu_domain *domain,
> else
> arm_smmu_cb_write(smmu, idx, ARM_SMMU_CB_ATS1PR, va);
>
> - reg = arm_smmu_page(smmu, smmu->numpage + idx) + ARM_SMMU_CB_ATSR;
> + reg = arm_smmu_page(smmu, ARM_SMMU_CB(smmu, idx)) + ARM_SMMU_CB_ATSR;
> if (readl_poll_timeout_atomic(reg, tmp, !(tmp & ATSR_ACTIVE), 5, 50)) {
> spin_unlock_irqrestore(&smmu_domain->cb_lock, flags);
> dev_err(dev,
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index cf367c3b1bee..611ed742e56f 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -366,20 +366,28 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
> writeq_relaxed(val, arm_smmu_page(smmu, page) + offset);
> }
>
> -#define arm_smmu_gr0_read(s, r) arm_smmu_readl((s), 0, (r))
> -#define arm_smmu_gr0_write(s, r, v) arm_smmu_writel((s), 0, (r), (v))
> +#define ARM_SMMU_GR0 0
> +#define ARM_SMMU_GR1 1
> +#define ARM_SMMU_CB(s, n) ((s)->numpage + (n))
>
> -#define arm_smmu_gr1_read(s, r) arm_smmu_readl((s), 1, (r))
> -#define arm_smmu_gr1_write(s, r, v) arm_smmu_writel((s), 1, (r), (v))
> +#define arm_smmu_gr0_read(s, o) \
> + arm_smmu_readl((s), ARM_SMMU_GR0, (o))
> +#define arm_smmu_gr0_write(s, o, v) \
> + arm_smmu_writel((s), ARM_SMMU_GR0, (o), (v))
>
> -#define arm_smmu_cb_read(s, n, r) \
> - arm_smmu_readl((s), (s)->numpage + (n), (r))
> -#define arm_smmu_cb_write(s, n, r, v) \
> - arm_smmu_writel((s), (s)->numpage + (n), (r), (v))
> -#define arm_smmu_cb_readq(s, n, r) \
> - arm_smmu_readq((s), (s)->numpage + (n), (r))
> -#define arm_smmu_cb_writeq(s, n, r, v) \
> - arm_smmu_writeq((s), (s)->numpage + (n), (r), (v))
> +#define arm_smmu_gr1_read(s, o) \
> + arm_smmu_readl((s), ARM_SMMU_GR1, (o))
> +#define arm_smmu_gr1_write(s, o, v) \
> + arm_smmu_writel((s), ARM_SMMU_GR1, (o), (v))
> +
> +#define arm_smmu_cb_read(s, n, o) \
> + arm_smmu_readl((s), ARM_SMMU_CB((s), (n)), (o))
> +#define arm_smmu_cb_write(s, n, o, v) \
> + arm_smmu_writel((s), ARM_SMMU_CB((s), (n)), (o), (v))
> +#define arm_smmu_cb_readq(s, n, o) \
> + arm_smmu_readq((s), ARM_SMMU_CB((s), (n)), (o))
> +#define arm_smmu_cb_writeq(s, n, o, v) \
> + arm_smmu_writeq((s), ARM_SMMU_CB((s), (n)), (o), (v))
>
> struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
>
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> index dadc707573a2..a2062d13584f 100644
> --- a/drivers/iommu/qcom_iommu.c
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -156,7 +156,7 @@ static void qcom_iommu_tlb_inv_range_nosync(unsigned long iova, size_t size,
> struct qcom_iommu_ctx *ctx = to_ctx(fwspec, fwspec->ids[i]);
> size_t s = size;
>
> - iova &= ~12UL;
> + iova = (iova >> 12) << 12;
> iova |= ctx->asid;
> do {
> iommu_writel(ctx, reg, iova);
_______________________________________________
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] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Sean Young @ 2019-08-20 8:15 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Rob Herring, Maxime Ripard,
linux-kernel, Chen-Yu Tsai, Rob Herring, mchehab, Frank Rowand,
linux-arm-kernel, linux-media
In-Reply-To: <20190819182619.29065-1-mripard@kernel.org>
On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The RC controllers have a bunch of generic properties that are needed in a
> device tree. Add a YAML schemas for those.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
For the series (both 1/2 and 2.2):
Reviewed-by: Sean Young <sean@mess.org>
How's tree should this go through?
Thanks
Sean
>
> ---
>
> Changes from v1:
> - Update the list of valid RC map name
> ---
> .../devicetree/bindings/media/rc.txt | 118 +-------------
> .../devicetree/bindings/media/rc.yaml | 145 ++++++++++++++++++
> 2 files changed, 146 insertions(+), 117 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/rc.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt
> index d3e7a012bfda..be629f7fa77e 100644
> --- a/Documentation/devicetree/bindings/media/rc.txt
> +++ b/Documentation/devicetree/bindings/media/rc.txt
> @@ -1,117 +1 @@
> -The following properties are common to the infrared remote controllers:
> -
> -- linux,rc-map-name: string, specifies the scancode/key mapping table
> - defined in-kernel for the remote controller. Support values are:
> - * "rc-adstech-dvb-t-pci"
> - * "rc-alink-dtu-m"
> - * "rc-anysee"
> - * "rc-apac-viewcomp"
> - * "rc-asus-pc39"
> - * "rc-asus-ps3-100"
> - * "rc-ati-tv-wonder-hd-600"
> - * "rc-ati-x10"
> - * "rc-avermedia-a16d"
> - * "rc-avermedia-cardbus"
> - * "rc-avermedia-dvbt"
> - * "rc-avermedia-m135a"
> - * "rc-avermedia-m733a-rm-k6"
> - * "rc-avermedia-rm-ks"
> - * "rc-avermedia"
> - * "rc-avertv-303"
> - * "rc-azurewave-ad-tu700"
> - * "rc-behold-columbus"
> - * "rc-behold"
> - * "rc-budget-ci-old"
> - * "rc-cec"
> - * "rc-cinergy-1400"
> - * "rc-cinergy"
> - * "rc-delock-61959"
> - * "rc-dib0700-nec"
> - * "rc-dib0700-rc5"
> - * "rc-digitalnow-tinytwin"
> - * "rc-digittrade"
> - * "rc-dm1105-nec"
> - * "rc-dntv-live-dvbt-pro"
> - * "rc-dntv-live-dvb-t"
> - * "rc-dtt200u"
> - * "rc-dvbsky"
> - * "rc-empty"
> - * "rc-em-terratec"
> - * "rc-encore-enltv2"
> - * "rc-encore-enltv-fm53"
> - * "rc-encore-enltv"
> - * "rc-evga-indtube"
> - * "rc-eztv"
> - * "rc-flydvb"
> - * "rc-flyvideo"
> - * "rc-fusionhdtv-mce"
> - * "rc-gadmei-rm008z"
> - * "rc-geekbox"
> - * "rc-genius-tvgo-a11mce"
> - * "rc-gotview7135"
> - * "rc-hauppauge"
> - * "rc-imon-mce"
> - * "rc-imon-pad"
> - * "rc-iodata-bctv7e"
> - * "rc-it913x-v1"
> - * "rc-it913x-v2"
> - * "rc-kaiomy"
> - * "rc-kworld-315u"
> - * "rc-kworld-pc150u"
> - * "rc-kworld-plus-tv-analog"
> - * "rc-leadtek-y04g0051"
> - * "rc-lirc"
> - * "rc-lme2510"
> - * "rc-manli"
> - * "rc-medion-x10"
> - * "rc-medion-x10-digitainer"
> - * "rc-medion-x10-or2x"
> - * "rc-msi-digivox-ii"
> - * "rc-msi-digivox-iii"
> - * "rc-msi-tvanywhere-plus"
> - * "rc-msi-tvanywhere"
> - * "rc-nebula"
> - * "rc-nec-terratec-cinergy-xs"
> - * "rc-norwood"
> - * "rc-npgtech"
> - * "rc-pctv-sedna"
> - * "rc-pinnacle-color"
> - * "rc-pinnacle-grey"
> - * "rc-pinnacle-pctv-hd"
> - * "rc-pixelview-new"
> - * "rc-pixelview"
> - * "rc-pixelview-002t"
> - * "rc-pixelview-mk12"
> - * "rc-powercolor-real-angel"
> - * "rc-proteus-2309"
> - * "rc-purpletv"
> - * "rc-pv951"
> - * "rc-hauppauge"
> - * "rc-rc5-tv"
> - * "rc-rc6-mce"
> - * "rc-real-audio-220-32-keys"
> - * "rc-reddo"
> - * "rc-snapstream-firefly"
> - * "rc-streamzap"
> - * "rc-tbs-nec"
> - * "rc-technisat-ts35"
> - * "rc-technisat-usb2"
> - * "rc-terratec-cinergy-c-pci"
> - * "rc-terratec-cinergy-s2-hd"
> - * "rc-terratec-cinergy-xs"
> - * "rc-terratec-slim"
> - * "rc-terratec-slim-2"
> - * "rc-tevii-nec"
> - * "rc-tivo"
> - * "rc-total-media-in-hand"
> - * "rc-total-media-in-hand-02"
> - * "rc-trekstor"
> - * "rc-tt-1500"
> - * "rc-twinhan-dtv-cab-ci"
> - * "rc-twinhan1027"
> - * "rc-videomate-k100"
> - * "rc-videomate-s350"
> - * "rc-videomate-tv-pvr"
> - * "rc-winfast"
> - * "rc-winfast-usbii-deluxe"
> - * "rc-su3000"
> +This file has been moved to rc.yaml.
> diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml
> new file mode 100644
> index 000000000000..3d5c154fd230
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rc.yaml
> @@ -0,0 +1,145 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/rc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic Infrared Remote Controller Device Tree Bindings
> +
> +maintainers:
> + - Mauro Carvalho Chehab <mchehab@kernel.org>
> + - Sean Young <sean@mess.org>
> +
> +properties:
> + $nodename:
> + pattern: "^ir(@[a-f0-9]+)?$"
> +
> + linux,rc-map-name:
> + description:
> + Specifies the scancode/key mapping table defined in-kernel for
> + the remote controller.
> + allOf:
> + - $ref: '/schemas/types.yaml#/definitions/string'
> + - enum:
> + - rc-adstech-dvb-t-pci
> + - rc-alink-dtu-m
> + - rc-anysee
> + - rc-apac-viewcomp
> + - rc-astrometa-t2hybrid
> + - rc-asus-pc39
> + - rc-asus-ps3-100
> + - rc-ati-tv-wonder-hd-600
> + - rc-ati-x10
> + - rc-avermedia
> + - rc-avermedia-a16d
> + - rc-avermedia-cardbus
> + - rc-avermedia-dvbt
> + - rc-avermedia-m135a
> + - rc-avermedia-m733a-rm-k6
> + - rc-avermedia-rm-ks
> + - rc-avertv-303
> + - rc-azurewave-ad-tu700
> + - rc-behold
> + - rc-behold-columbus
> + - rc-budget-ci-old
> + - rc-cec
> + - rc-cinergy
> + - rc-cinergy-1400
> + - rc-d680-dmb
> + - rc-delock-61959
> + - rc-dib0700-nec
> + - rc-dib0700-rc5
> + - rc-digitalnow-tinytwin
> + - rc-digittrade
> + - rc-dm1105-nec
> + - rc-dntv-live-dvb-t
> + - rc-dntv-live-dvbt-pro
> + - rc-dtt200u
> + - rc-dvbsky
> + - rc-dvico-mce
> + - rc-dvico-portable
> + - rc-em-terratec
> + - rc-empty
> + - rc-encore-enltv
> + - rc-encore-enltv-fm53
> + - rc-encore-enltv2
> + - rc-evga-indtube
> + - rc-eztv
> + - rc-flydvb
> + - rc-flyvideo
> + - rc-fusionhdtv-mce
> + - rc-gadmei-rm008z
> + - rc-geekbox
> + - rc-genius-tvgo-a11mce
> + - rc-gotview7135
> + - rc-hauppauge
> + - rc-hauppauge
> + - rc-hisi-poplar
> + - rc-hisi-tv-demo
> + - rc-imon-mce
> + - rc-imon-pad
> + - rc-imon-rsc
> + - rc-iodata-bctv7e
> + - rc-it913x-v1
> + - rc-it913x-v2
> + - rc-kaiomy
> + - rc-kworld-315u
> + - rc-kworld-pc150u
> + - rc-kworld-plus-tv-analog
> + - rc-leadtek-y04g0051
> + - rc-lme2510
> + - rc-manli
> + - rc-medion-x10
> + - rc-medion-x10-digitainer
> + - rc-medion-x10-or2x
> + - rc-msi-digivox-ii
> + - rc-msi-digivox-iii
> + - rc-msi-tvanywhere
> + - rc-msi-tvanywhere-plus
> + - rc-nebula
> + - rc-nec-terratec-cinergy-xs
> + - rc-norwood
> + - rc-npgtech
> + - rc-pctv-sedna
> + - rc-pinnacle-color
> + - rc-pinnacle-grey
> + - rc-pinnacle-pctv-hd
> + - rc-pixelview
> + - rc-pixelview-002t
> + - rc-pixelview-mk12
> + - rc-pixelview-new
> + - rc-powercolor-real-angel
> + - rc-proteus-2309
> + - rc-purpletv
> + - rc-pv951
> + - rc-rc5-tv
> + - rc-rc6-mce
> + - rc-real-audio-220-32-keys
> + - rc-reddo
> + - rc-snapstream-firefly
> + - rc-streamzap
> + - rc-su3000
> + - rc-tango
> + - rc-tbs-nec
> + - rc-technisat-ts35
> + - rc-technisat-usb2
> + - rc-terratec-cinergy-c-pci
> + - rc-terratec-cinergy-s2-hd
> + - rc-terratec-cinergy-xs
> + - rc-terratec-slim
> + - rc-terratec-slim-2
> + - rc-tevii-nec
> + - rc-tivo
> + - rc-total-media-in-hand
> + - rc-total-media-in-hand-02
> + - rc-trekstor
> + - rc-tt-1500
> + - rc-twinhan-dtv-cab-ci
> + - rc-twinhan1027
> + - rc-videomate-k100
> + - rc-videomate-s350
> + - rc-videomate-tv-pvr
> + - rc-winfast
> + - rc-winfast-usbii-deluxe
> + - rc-xbox-dvd
> + - rc-zx-irdec
> --
> 2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node
From: Maxime Ripard @ 2019-08-20 8:15 UTC (permalink / raw)
To: Samuel Holland
Cc: Mark Rutland, devicetree, linux-sunxi, Stephen Boyd,
Michael Turquette, Jassi Brar, linux-kernel, Chen-Yu Tsai,
Rob Herring, Corentin Labbe, linux-clk, linux-arm-kernel
In-Reply-To: <20190820032311.6506-6-samuel@sholland.org>
[-- Attachment #1.1: Type: text/plain, Size: 558 bytes --]
Hi,
On Mon, Aug 19, 2019 at 10:23:06PM -0500, Samuel Holland wrote:
> The A80 SoC contains a message box that can be used to send messages and
> interrupts back and forth between the ARM application CPUs and the ARISC
> coprocessor. Add a device tree node for it.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
I think you mentionned that crust has been tested only on the A64 and
the H3/H5, did you test the mailbox on those other SoCs as well?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/4] DCMI bridge support
From: Hugues FRUCHET @ 2019-08-20 8:09 UTC (permalink / raw)
To: Hans Verkuil, Alexandre TORGUE, Mauro Carvalho Chehab,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel@vger.kernel.org, Philippe CORNU,
Yannick FERTRE, Benjamin Gaignard,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <5d36f437-0de5-1aa0-09bf-51d3a415ad2f@st.com>
Hi Sakari, Hans,
st-mipid02 changes are already merged, thanks Sakari and sorry for
disturbance.
Still remain the V4L2_CID_LINK_FREQ for OV5640.
On 8/19/19 11:13 AM, Hugues FRUCHET wrote:
> Hi Hans, Sakari,
>
> OK to push separately the 80 char fix.
>
> There was pending related changes on st-mipid02 and ov5640 (listed
> below), do you think it's possible to take them also ?
>
>
> media: st-mipid02: add support of V4L2_CID_LINK_FREQ
> https://patchwork.linuxtv.org/patch/56969/
> State Accepted
>
> [v2,1/3] media: st-mipid02: add support of RGB565
> https://patchwork.linuxtv.org/patch/56970/
> State Accepted
>
> [v2,2/3] media: st-mipid02: add support of YUYV8 and UYVY8
> https://patchwork.linuxtv.org/patch/56971/
> State Accepted
>
> [v2,3/3] media: st-mipid02: add support of JPEG
> https://patchwork.linuxtv.org/patch/56973/
> State Accepted
>
>
> [v2] media: ov5640: add support of V4L2_CID_LINK_FREQ
> https://patchwork.linuxtv.org/patch/57215/
> State Changes Requested
> => This change is needed to make it work the whole setup.
> => I don't know what to change here, even if this 384MHz fixed value
> seems strange, it works fine on my setup, on my opinion it's better than
> nothing. We could come back on this later on when other OV5640 CSI
> interfaces will require V4L2_CID_LINK_FREQ value.
>
> Sakari, what do you think about this ?
>
>
> BR,
> Hugues.
BR,
Hugues.
_______________________________________________
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] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Linus Walleij @ 2019-08-20 8:01 UTC (permalink / raw)
To: Wei Xu
Cc: Salil Mehta, jinying, Tangkunshan, Liguozhu (Kenneth), John Garry,
Rafael J. Wysocki, linux-kernel@vger.kernel.org,
Shameerali Kolothum Thodi, Linuxarm, open list:GPIO SUBSYSTEM,
Andy Shevchenko, huangdaode, Jonathan Cameron, Shiju Jose,
Mika Westerberg, Zhangyi ac, Linux ARM, Len Brown
In-Reply-To: <1566221225-5170-1-git-send-email-xuwei5@hisilicon.com>
On Mon, Aug 19, 2019 at 3:29 PM Wei Xu <xuwei5@hisilicon.com> wrote:
> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
> attached to the pl061 acpi node to register interruption.
>
> Otherwise it will be failed to register interruption for the ACPI case.
> Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
> after gpiochip_add_irqchip but at that time the acpi data has not been
> attached yet.
We need to fix this problem in gpiochip_add_data_with_key() instead.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next v4 2/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-20 7:57 UTC (permalink / raw)
To: davem, robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, linux-amlogic, Rob Herring, linux-arm-kernel
In-Reply-To: <20190820075742.14857-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 4377f511a51d..c78be15704b9 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v4 1/2] dt-bindings: net: snps, dwmac: update reg minItems maxItems
From: Neil Armstrong @ 2019-08-20 7:57 UTC (permalink / raw)
To: davem, robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, Maxime Ripard, linux-amlogic, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190820075742.14857-1-narmstrong@baylibre.com>
The Amlogic Meson DWMAC glue bindings needs a second reg cells for the
glue registers, thus update the reg minItems/maxItems to allow more
than a single reg cell.
Also update the allwinner,sun7i-a20-gmac.yaml derivative schema to specify
maxItems to 1.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml | 3 +++
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 06b1cc8bea14..ef446ae166f3 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
const: allwinner,sun7i-a20-gmac
+ reg:
+ maxItems: 1
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..4377f511a51d 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -61,7 +61,8 @@ properties:
- snps,dwxgmac-2.10
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
interrupts:
minItems: 1
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next v4 0/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-20 7:57 UTC (permalink / raw)
To: davem, robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, linux-amlogic, linux-arm-kernel
This patchsets converts the Amlogic Meson DWMAC glue bindings over to
YAML schemas using the already converted dwmac bindings.
The first patch is needed because the Amlogic glue needs a supplementary
reg cell to access the DWMAC glue registers.
Changes since v3:
- Specified net-next target tree
Changes since v2:
- Added review tags
- Updated allwinner,sun7i-a20-gmac.yaml reg maxItems
Neil Armstrong (2):
dt-bindings: net: snps,dwmac: update reg minItems maxItems
dt-bindings: net: meson-dwmac: convert to yaml
.../net/allwinner,sun7i-a20-gmac.yaml | 3 +
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 8 +-
4 files changed, 123 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/8] soc: ti: Add OMAP PRM driver
From: Tero Kristo @ 2019-08-20 7:54 UTC (permalink / raw)
To: Suman Anna, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <432a70fc-2683-42ca-3ac7-9775efa3ca41@ti.com>
On 20.8.2019 2.20, Suman Anna wrote:
> Hi Tero,
>
> On 8/7/19 2:48 AM, Tero Kristo wrote:
>> Hi,
>>
>> This series adds OMAP PRM driver which initially supports only reset
>> handling. Later on, power domain support can be added to this to get
>> rid of the current OMAP power domain handling code which resides
>> under the mach-omap2 platform directory. Initially, reset data is
>> added for AM3, OMAP4 and DRA7 SoCs.
>
> Wakeup M3 remoteproc driver is fully upstream, so we should be able to
> test that driver as well if you can add the AM4 data. That will also
> unblock my PRUSS.
>
> If you can add the data to others as well, it will help in easier
> migration of the individual drivers, otherwise the ti-sysc interconnect,
> hwmod, and hwmod reset data combinations will all have to be supported
> in code.
Ok, so you are saying you would need the PRM data for am4 in addition? I
can generate that one also.
-Tero
>
> regards
> Suman
>
>>
>> I've been testing the reset handling logic with OMAP remoteproc
>> driver which has been converted to use generic reset framework. This
>> part is a work in progress, so will be posting patches from that part
>> later on.
>>
>> -Tero
>>
>> --
>>
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 5/8] soc: ti: omap-prm: add omap4 PRM data
From: Tero Kristo @ 2019-08-20 7:52 UTC (permalink / raw)
To: Suman Anna, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <04bc6773-dbd4-e1ab-ce31-d93e99dafb33@ti.com>
On 20.8.2019 2.08, Suman Anna wrote:
> On 8/7/19 2:48 AM, Tero Kristo wrote:
>> Add PRM data for omap4 family of SoCs.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>> index 870515e3..9b8d5945 100644
>> --- a/drivers/soc/ti/omap_prm.c
>> +++ b/drivers/soc/ti/omap_prm.c
>> @@ -54,7 +54,27 @@ struct omap_reset_data {
>>
>> #define OMAP_PRM_NO_RSTST BIT(0)
>>
>> +struct omap_prm_data omap4_prm_data[] = {
>
> static const
Will fix this and rest of the similar comments.
-Tero
>
> regards
> Suman
>
>> + { .name = "mpu", .base = 0x4a306300, .pwstst = 0x4 },
>> + { .name = "tesla", .base = 0x4a306400, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
>> + { .name = "abe", .base = 0x4a306500, .pwstst = 0x4 },
>> + { .name = "always_on_core", .base = 0x4a306600, .pwstst = 0x4 },
>> + { .name = "core", .base = 0x4a306700, .pwstst = 0x4, .rstctl = 0x210, .rstst = 0x214 },
>> + { .name = "ivahd", .base = 0x4a306f00, .pwstst = 0x4, .rstctl = 0x10, .rstst = 0x14 },
>> + { .name = "cam", .base = 0x4a307000, .pwstst = 0x4 },
>> + { .name = "dss", .base = 0x4a307100, .pwstst = 0x4 },
>> + { .name = "gfx", .base = 0x4a307200, .pwstst = 0x4 },
>> + { .name = "l3init", .base = 0x4a307300, .pwstst = 0x4 },
>> + { .name = "l4per", .base = 0x4a307400, .pwstst = 0x4 },
>> + { .name = "cefuse", .base = 0x4a307600, .pwstst = 0x4 },
>> + { .name = "wkup", .base = 0x4a307700, .pwstst = 0x4 },
>> + { .name = "emu", .base = 0x4a307900, .pwstst = 0x4 },
>> + { .name = "device", .base = 0x4a307b00, .rstctl = 0x0, .rstst = 0x4 },
>> + { },
>> +};
>> +
>> static const struct of_device_id omap_prm_id_table[] = {
>> + { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
>> { },
>> };
>>
>>
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 4/8] soc: ti: omap-prm: add support for denying idle for reset clockdomain
From: Tero Kristo @ 2019-08-20 7:51 UTC (permalink / raw)
To: Suman Anna, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <81cda31a-b321-f9b4-2df7-2b6c084b2ec5@ti.com>
On 20.8.2019 2.16, Suman Anna wrote:
> Hi Tero,
>
> On 8/7/19 2:48 AM, Tero Kristo wrote:
>> TI SoCs hardware reset signals require the parent clockdomain to be
>> in force wakeup mode while de-asserting the reset, otherwise it may
>> never complete. To support this, add pdata hooks to control the
>> clockdomain directly.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/soc/ti/omap_prm.c | 32 ++++++++++++++++++++++++++++----
>> include/linux/platform_data/ti-prm.h | 21 +++++++++++++++++++++
>> 2 files changed, 49 insertions(+), 4 deletions(-)
>> create mode 100644 include/linux/platform_data/ti-prm.h
>>
>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>> index d412af3..870515e3 100644
>> --- a/drivers/soc/ti/omap_prm.c
>> +++ b/drivers/soc/ti/omap_prm.c
>> @@ -16,6 +16,8 @@
>> #include <linux/reset-controller.h>
>> #include <linux/delay.h>
>>
>> +#include <linux/platform_data/ti-prm.h>
>> +
>> struct omap_rst_map {
>> s8 rst;
>> s8 st;
>> @@ -24,6 +26,7 @@ struct omap_rst_map {
>> struct omap_prm_data {
>> u32 base;
>> const char *name;
>> + const char *clkdm_name;
>> u16 pwstctrl;
>> u16 pwstst;
>> u16 rstctl;
>> @@ -40,6 +43,8 @@ struct omap_prm {
>> struct omap_reset_data {
>> struct reset_controller_dev rcdev;
>> struct omap_prm *prm;
>> + struct clockdomain *clkdm;
>> + struct device *dev;
>> };
>>
>> #define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
>> @@ -108,6 +113,8 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>> int st_bit = id;
>> bool has_rstst;
>> int timeout = 0;
>> + struct ti_prm_platform_data *pdata = dev_get_platdata(reset->dev);
>> + int ret = 0;
>>
>> /* check the current status to avoid de-asserting the line twice */
>> v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>> @@ -125,13 +132,16 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>> writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
>> }
>>
>> + if (pdata->clkdm_deny_idle && reset->clkdm)
>> + pdata->clkdm_deny_idle(reset->clkdm);
>> +
>> /* de-assert the reset control line */
>> v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>> v &= ~(1 << id);
>> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>
>> if (!has_rstst)
>> - return 0;
>> + goto exit;
>>
>> /* wait for the status to be set */
>> while (1) {
>> @@ -140,13 +150,19 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>> if (v)
>> break;
>> timeout++;
>> - if (timeout > OMAP_RESET_MAX_WAIT)
>> - return -EBUSY;
>> + if (timeout > OMAP_RESET_MAX_WAIT) {
>> + ret = -EBUSY;
>> + goto exit;
>> + }
>>
>> udelay(1);
>> }
>>
>> - return 0;
>> +exit:
>> + if (pdata->clkdm_allow_idle && reset->clkdm)
>> + pdata->clkdm_allow_idle(reset->clkdm);
>> +
>> + return ret;
>> }
>>
>> static const struct reset_control_ops omap_reset_ops = {
>> @@ -159,6 +175,8 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
>> struct omap_prm *prm)
>> {
>> struct omap_reset_data *reset;
>> + struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
>
> Please add checks for NULL callbacks. I don't think these are optional
> right, so better to check in init rather than during runtime. Granted
> you will probably not run into this after patch 8, but would be good to
> check and print an error in case pdata quirks is missed out.
Hmm ok, this would get rid of the runtime checks which would be slightly
cleaner.
>
>> + char buf[32];
>>
>> /*
>> * Check if we have resets. If either rstctl or rstst is
>> @@ -177,9 +195,15 @@ static int omap_prm_reset_probe(struct platform_device *pdev,
>> reset->rcdev.ops = &omap_reset_ops;
>> reset->rcdev.of_node = pdev->dev.of_node;
>> reset->rcdev.nr_resets = OMAP_MAX_RESETS;
>> + reset->dev = &pdev->dev;
>>
>> reset->prm = prm;
>>
>> + sprintf(buf, "%s_clkdm", prm->data->clkdm_name ? prm->data->clkdm_name :
>> + prm->data->name);
>> +
>> + reset->clkdm = pdata->clkdm_lookup(buf);
>
> Not checking return status?
clkdm will just end up being NULL in failure, which is fine for rest of
the code. I don't think it can be ever NULL though, so I can add a check
here for sanity.
-Tero
>
> regards
> Suman
>
>> +
>> return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
>> }
>>
>> diff --git a/include/linux/platform_data/ti-prm.h b/include/linux/platform_data/ti-prm.h
>> new file mode 100644
>> index 0000000..28154c3
>> --- /dev/null
>> +++ b/include/linux/platform_data/ti-prm.h
>> @@ -0,0 +1,21 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * TI PRM (Power & Reset Manager) platform data
>> + *
>> + * Copyright (C) 2019 Texas Instruments, Inc.
>> + *
>> + * Tero Kristo <t-kristo@ti.com>
>> + */
>> +
>> +#ifndef _LINUX_PLATFORM_DATA_TI_PRM_H
>> +#define _LINUX_PLATFORM_DATA_TI_PRM_H
>> +
>> +struct clockdomain;
>> +
>> +struct ti_prm_platform_data {
>> + void (*clkdm_deny_idle)(struct clockdomain *clkdm);
>> + void (*clkdm_allow_idle)(struct clockdomain *clkdm);
>> + struct clockdomain * (*clkdm_lookup)(const char *name);
>> +};
>> +
>> +#endif /* _LINUX_PLATFORM_DATA_TI_PRM_H */
>>
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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] efi/arm: fix allocation failure when reserving the kernel base
From: Mike Rapoport @ 2019-08-20 7:49 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux@armlinux.org.uk,
linux-kernel@vger.kernel.org, Chester Lin, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu-sdhNbhfD24Fn93mj-h6=vGi82Ghjy7AzaRSqcpXCx-g@mail.gmail.com>
On Mon, Aug 19, 2019 at 05:56:51PM +0300, Ard Biesheuvel wrote:
> On Mon, 19 Aug 2019 at 11:01, Chester Lin <clin@suse.com> wrote:
> >
> > Hi Mike and Ard,
> >
> > On Thu, Aug 15, 2019 at 04:37:39PM +0300, Mike Rapoport wrote:
> > > On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> > > > (adding Mike)
> > > >
...
> > > > > In this case the kernel failed to reserve cma, which should hit the issue of
> > > > > memblock_limit=0x1000 as I had mentioned in my patch description. The first
> > > > > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> > > > > with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> > > > > was extremely low. That's why I expand the first reservation from 1 PAGESIZE to
> > > > > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> > > > > if any suggestion, thank you.
> > >
> > >
> > > > This looks like it is a separate issue. The memblock/cma code should
> > > > not choke on a reserved page of memory at 0x0.
> > > >
> > > > Perhaps Russell or Mike (cc'ed) have an idea how to address this?
> > >
> > > Presuming that the last memblock dump comes from the end of
> > > arm_memblock_init() with the this memory map
> > >
> > > memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> > > memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> > > memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> > > memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
> > >
> > > adjust_lowmem_bounds() will set the memblock_limit (and respectively global
> > > memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
> > > happily fail.
> > >
> > > I believe that the assumption for memblock_limit calculations was that the
> > > first bank has several megs at least.
> > >
> > > I wonder if this hack would help:
> > >
> > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > index d9a0038..948e5b9 100644
> > > --- a/arch/arm/mm/mmu.c
> > > +++ b/arch/arm/mm/mmu.c
> > > @@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
> > > * allocated when mapping the start of bank 0, which
> > > * occurs before any free memory is mapped.
> > > */
> > > - if (!memblock_limit) {
> > > + if (memblock_limit < PMD_SIZE) {
> > > if (!IS_ALIGNED(block_start, PMD_SIZE))
> > > memblock_limit = block_start;
> > > else if (!IS_ALIGNED(block_end, PMD_SIZE))
> > >
> >
> > I applied this patch as well and it works well on rpi-2 model B.
> >
>
> Thanks, Chester, that is good to know.
>
> However, afaict, this only affects systems where physical memory
> starts at address 0x0, so I think we need a better fix.
This hack can be easily extended to handle systems with arbitrary start
address, but it's still a hack...
> I know Mike has been looking into the NOMAP stuff lately, and your
> original patch contains a hunk that makes this code (?) disregard
> nomap memblocks. That might be a better approach.
I was actually looking how to replace NOMAP with something else to make
memblock.memory consistent with actual physical memory banks. But this work
is stashed for now.
I'm not sure that skipping NOMAP regions would be good enough.
If I understand corrrectly, with Chester's original patch the reservation
of PMD aligned chunk of 32M for the kernel made the first conv-mem region
PMD aligned and then memblock_limit will be set to the end of this region.
Is there a reason for marking EFI_RESERVED_TYPE as NOMAP rather than simply
reserve them with memblock_reserve()?
--
Sincerely yours,
Mike.
_______________________________________________
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/8] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-08-20 7:45 UTC (permalink / raw)
To: Suman Anna, Keerthy, ssantosh, linux-arm-kernel, linux-omap,
robh+dt
Cc: tony, devicetree
In-Reply-To: <b6506850-f4fc-43be-b5b7-b83cd77b5d66@ti.com>
On 20.8.2019 0.28, Suman Anna wrote:
> Hi Tero,
>
> On 8/19/19 4:28 AM, Tero Kristo wrote:
>> On 08/08/2019 07:35, Keerthy wrote:
>>>
>>>
>>> On 07/08/19 1:18 PM, Tero Kristo wrote:
>>>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>>>> of these will act as a power domain controller and potentially as a
>>>> reset
>>>> provider.
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>> .../devicetree/bindings/arm/omap/prm-inst.txt | 24
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 24 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> new file mode 100644
>>>> index 0000000..e0ae87b
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>>> @@ -0,0 +1,24 @@
>>>> +OMAP PRM instance bindings
>>>> +
>>>> +Power and Reset Manager is an IP block on OMAP family of devices which
>>>> +handle the power domains and their current state, and provide reset
>>>> +handling for the domains and/or separate IP blocks under the power
>>>> domain
>>>> +hierarchy.
>
> So, I see that you are adding these as flat nodes directly under the prm
> nodes where we have the clocks and clock_domains. Are you anticipating a
> single DT node and/or driver managing both power-domains and resets?
Single DT node + driver for both power-domains / resets. You can
probably see from the driver code that the reset probing is called
separately from the main probe function; power domain support should be
added in similar manner under it.
>
>>>> +
>>>> +Required properties:
>>>> +- compatible: Must be one of:
>>>> + "ti,am3-prm-inst"
>>>> + "ti,am4-prm-inst"
>>>> + "ti,omap4-prm-inst"
>>>> + "ti,omap5-prm-inst"
>>>> + "ti,dra7-prm-inst"
>
> What about OMAP2, OMAP3, DM814x, DM816x?
OMAP2/3 architectures are slightly different beast to tackle, so
planning to work on those later on.
-Tero
>
> regards
> Suman
>
>>>> +- reg: Contains PRM instance register address range
>>>> + (base address and length)
>>>
>>> How about reset-cells property, Isn't that a mandatory property?
>>
>> It is optional, but you are right, should be added to this.
>>
>> -Tero
>>
>>>
>>>> +
>>>> +Example:
>>>> +
>>>> +prm_dsp2: prm@1b00 {
>>>> + compatible = "ti,dra7-prm-inst";
>>>> + reg = <0x1b00 0x40>;
>>>> + #reset-cells = <1>;
>>>> +};
>>>>
>>
>> --
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 2/3] fdt: add support for rng-seed
From: Hsin-Yi Wang @ 2019-08-20 7:42 UTC (permalink / raw)
To: Theodore Y. Ts'o, Hsin-Yi Wang,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Rob Herring, devicetree, lkml, Frank Rowand, Catalin Marinas,
Will Deacon, Andrew Morton, Mike Rapoport, Ard Biesheuvel,
Miles Chen, James Morse, Andrew Murray, Mark Rutland, Jun Yao,
Yu Zhao, Robin Murphy, Laura Abbott, Stephen Boyd, Kees Cook
In-Reply-To: <20190819181349.GE10349@mit.edu>
Hi Ted,
Thanks for raising this question.
For UEFI based system, they have a config table that carries rng seed
and can be passed to device randomness. However, they also use
add_device_randomness (not sure if it's the same reason that they
can't guarantee _all_ bootloader can be trusted)
This patch is to let DT based system also have similar features, which
can make initial random number stronger. (We only care initial
situation here, since more entropy would be added to kernel as time
goes on )
Conservatively, we can use add_device_randomness() as well, which
would pass buffer to crng_slow_load() instead of crng_fast_load().
But I think we should trust bootloader here. Whoever wants to use this
feature should make sure their bootloader can pass valid (random
enough) seeds. If they are not sure, they can just don't add the
property to DT.
_______________________________________________
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/8] soc: ti: add initial PRM driver with reset control support
From: Tero Kristo @ 2019-08-20 7:37 UTC (permalink / raw)
To: Suman Anna, Keerthy, ssantosh, linux-arm-kernel, linux-omap,
robh+dt
Cc: tony, devicetree
In-Reply-To: <9372957c-9ab9-b0dd-fe07-815eb2cb2f16@ti.com>
On 20.8.2019 2.01, Suman Anna wrote:
> Hi Tero,
>
> On 8/19/19 4:32 AM, Tero Kristo wrote:
>> On 08/08/2019 08:26, Keerthy wrote:
>>>
>>>
>>> On 07/08/19 1:18 PM, Tero Kristo wrote:
>>>> Add initial PRM (Power and Reset Management) driver for TI OMAP class
>>>> SoCs. Initially this driver only supports reset control, but can be
>>>> extended to support rest of the functionality, like powerdomain
>>>> control, PRCM irq support etc.
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>> ---
>>>> arch/arm/mach-omap2/Kconfig | 1 +
>>>> drivers/soc/ti/Makefile | 1 +
>>>> drivers/soc/ti/omap_prm.c | 216
>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 218 insertions(+)
>>>> create mode 100644 drivers/soc/ti/omap_prm.c
>>>>
>>>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>>>> index fdb6743..42ad063 100644
>>>> --- a/arch/arm/mach-omap2/Kconfig
>>>> +++ b/arch/arm/mach-omap2/Kconfig
>>>> @@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
>>>> select TI_SYSC
>>>> select OMAP_IRQCHIP
>>>> select CLKSRC_TI_32K
>>>> + select RESET_CONTROLLER
>
> Use ARCH_HAS_RESET_CONTROLLER instead.
Ok.
>
>>>> help
>>>> Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>>>> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
>>>> index b3868d3..788b5cd 100644
>>>> --- a/drivers/soc/ti/Makefile
>>>> +++ b/drivers/soc/ti/Makefile
>>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
>>>> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
>>>> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
>>>> obj-$(CONFIG_AMX3_PM) += pm33xx.o
>>>> +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
>>>> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
>>>> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
>>>> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
>>>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>>>> new file mode 100644
>>>> index 0000000..7c89eb8
>>>> --- /dev/null
>>>> +++ b/drivers/soc/ti/omap_prm.c
>>>> @@ -0,0 +1,216 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * OMAP2+ PRM driver
>>>> + *
>>>> + * Copyright (C) 2019 Texas Instruments Incorporated -
>>>> http://www.ti.com/
>>>> + * Tero Kristo <t-kristo@ti.com>
>>>> + */
>>>> +
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/device.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_device.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/reset-controller.h>
>>>> +#include <linux/delay.h>
>>>> +
>>>> +struct omap_rst_map {
>>>> + s8 rst;
>>>> + s8 st;
>>>> +};
>>>> +
>>>> +struct omap_prm_data {
>>>> + u32 base;
>>>> + const char *name;
>>>> + u16 pwstctrl;
>>>> + u16 pwstst;
>>>> + u16 rstctl;
>
> Minor nit, can you use rstctrl instead here so that it is in sync with
> the other variables and with the register names used in TRM.
Ok.
>
>>>> + u16 rstst;
>>>> + struct omap_rst_map *rstmap;
>>>> + u8 flags;
>>>> +};
>>>> +
>>>> +struct omap_prm {
>>>> + const struct omap_prm_data *data;
>>>> + void __iomem *base;
>>>> +};
>>>> +
>>>> +struct omap_reset_data {
>>>> + struct reset_controller_dev rcdev;
>>>> + struct omap_prm *prm;
>>>> +};
>>>> +
>>>> +#define to_omap_reset_data(p) container_of((p), struct
>>>> omap_reset_data, rcdev)
>>>> +
>>>> +#define OMAP_MAX_RESETS 8
>>>> +#define OMAP_RESET_MAX_WAIT 10000
>>>> +
>>>> +#define OMAP_PRM_NO_RSTST BIT(0)
>>>> +
>>>> +static const struct of_device_id omap_prm_id_table[] = {
>>>> + { },
>>>> +};
>>>
>>> This table is blank and we are doing of_match_device against it.
>>
>> Yes, it gets populated with other patches in series, one entry per soc.
>>
>>>
>>>> +
>>>> +static int omap_reset_status(struct reset_controller_dev *rcdev,
>>>> + unsigned long id)
>>>> +{
>>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>>> + u32 v;
>>>> +
>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>>>> + v &= 1 << id;
>>>> + v >>= id;
>>>> +
>>>> + return v;
>>>> +}
>>>> +
>>>> +static int omap_reset_assert(struct reset_controller_dev *rcdev,
>>>> + unsigned long id)
>>>> +{
>>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>>> + u32 v;
>>>> +
>>>> + /* assert the reset control line */
>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>>> + v |= 1 << id;
>>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int omap_reset_get_st_bit(struct omap_reset_data *reset,
>>>> + unsigned long id)
>>>> +{
>>>> + struct omap_rst_map *map = reset->prm->data->rstmap;
>>>> +
>>>> + while (map && map->rst >= 0) {
>>>> + if (map->rst == id)
>>>> + return map->st;
>>>> +
>>>> + map++;
>>>> + }
>>>> +
>>>> + return id;
>>>> +}
>>>> +
>>>> +/*
>>>> + * Note that status will not change until clocks are on, and clocks
>>>> cannot be
>>>> + * enabled until reset is deasserted. Consumer drivers must check
>>>> status
>>>> + * separately after enabling clocks.
>>>> + */
>>>> +static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>>>> + unsigned long id)
>>>> +{
>>>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>>>> + u32 v;
>>>> + int st_bit = id;
>
> No need to initialize this, will always get overwritten below.
Hmm right, must be a leftover from some earlier code.
>
>>>> + bool has_rstst;
>>>> +
>>>> + /* check the current status to avoid de-asserting the line twice */
>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>>> + if (!(v & BIT(id)))
>>>> + return -EEXIST;
>>>> +
>>>> + has_rstst = !(reset->prm->data->flags & OMAP_PRM_NO_RSTST);
>>>> +
>>>> + if (has_rstst) {
>>>> + st_bit = omap_reset_get_st_bit(reset, id);
>>>> +
>>>> + /* Clear the reset status by writing 1 to the status bit */
>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>>>> + v |= 1 << st_bit;
>>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
>>>> + }
>>>> +
>>>> + /* de-assert the reset control line */
>>>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>>>> + v &= ~(1 << id);
>>>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static const struct reset_control_ops omap_reset_ops = {
>>>> + .assert = omap_reset_assert,
>>>> + .deassert = omap_reset_deassert,
>>>> + .status = omap_reset_status,
>>>> +};
>>>> +
>>>> +static int omap_prm_reset_probe(struct platform_device *pdev,
>>>> + struct omap_prm *prm)
>
> Call this omap_prm_reset_init or something similar to avoid confusion.
Ok, can change this.
>
>>>> +{
>>>> + struct omap_reset_data *reset;
>>>> +
>>>> + /*
>>>> + * Check if we have resets. If either rstctl or rstst is
>>>> + * non-zero, we have reset registers in place. Additionally
>>>> + * the flag OMAP_PRM_NO_RSTST implies that we have resets.
>>>> + */
>>>> + if (!prm->data->rstctl && !prm->data->rstst &&
>>>> + !(prm->data->flags & OMAP_PRM_NO_RSTST))
>>>> + return 0;
>>>> +
>>>> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
>>>> + if (!reset)
>>>> + return -ENOMEM;
>>>> +
>>>> + reset->rcdev.owner = THIS_MODULE;
>>>> + reset->rcdev.ops = &omap_reset_ops;
>>>> + reset->rcdev.of_node = pdev->dev.of_node;
>>>> + reset->rcdev.nr_resets = OMAP_MAX_RESETS;
>
> Suggest adding a number of resets to prm->data, and using it so that we
> don't even entertain any resets beyond the actual number of resets.
Hmm why bother? Accessing a stale reset bit will just cause access to a
reserved bit in the reset register, doing basically nothing. Also, this
would not work for am3/am4 wkup, as there is a single reset bit at an
arbitrary position.
>
> You actually seem to be using the bit-position directly in client data
> instead of a reset number. I am not sure if this is accepted practice
> with reset controllers, do you incur any memory wastage?
Reset numbering almost always seems to start from 0, I think the only
exception to this is wkup_m3 on am3/am4. Introducing an additional
arbitrary mapping for this doesn't seem to make any sense.
Also, resets are allocated on-need-basis, so it only allocates one
instance for the reset control whatever the index is.
>
>>>> +
>>>> + reset->prm = prm;
>>>> +
>>>> + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
>>>> +}
>>>> +
>>>> +static int omap_prm_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct resource *res;
>>>> + const struct omap_prm_data *data;
>>>> + struct omap_prm *prm;
>>>> + const struct of_device_id *match;
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> + if (!res)
>>>> + return -ENODEV;
>>>> +
>>>> + match = of_match_device(omap_prm_id_table, &pdev->dev);
>>>> + if (!match)
>>>> + return -ENOTSUPP;
>
> Use of_device_get_match_data() instead to do both match and get the
> data. That can perhaps be the first block.
>
>>>> +
>>>> + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
>>>> + if (!prm)
>>>> + return -ENOMEM;
>
> Perhaps move the allocate after the match check to streamline.
Ok, will check these two out.
>
>>>> +
>>>> + data = match->data;
>>>> +
>>>> + while (data->base != res->start) {
>>>> + if (!data->base)
>>>> + return -EINVAL;
>>>> + data++;
>>>> + }
>>>> +
>>>> + prm->data = data;
>>>> +
>>>> + prm->base = devm_ioremap_resource(&pdev->dev, res);
>>>> + if (!prm->base)
>>>> + return -ENOMEM;
>>>> +
>>>> + return omap_prm_reset_probe(pdev, prm);
>>>> +}
>>>> +
>>>> +static struct platform_driver omap_prm_driver = {
>>>> + .probe = omap_prm_probe,
>>>> + .driver = {
>>>> + .name = KBUILD_MODNAME,
>>>> + .of_match_table = omap_prm_id_table,
>>>> + },
>>>> +};
>>>> +builtin_platform_driver(omap_prm_driver);
>>>> +
>>>> +MODULE_ALIAS("platform:prm");
>
> Drop this and use MODULE_DEVICE_TABLE instead on omap_prm_id_table if
> retaining, but I don't think these need to be defined.
Ok, will ditch them.
-Tero
>
> regards
> Suman
>
>>>> +MODULE_LICENSE("GPL v2");
>>>> +MODULE_DESCRIPTION("omap2+ prm driver");
>>>
>>> It is a builtin_platform_driver so do we need the MODULE*?
>>
>> Well, thats debatable, however some existing drivers do introduce this
>> even if they are builtin.
>>
>> -Tero
>> --
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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] efi/arm: fix allocation failure when reserving the kernel base
From: Chester Lin @ 2019-08-20 7:33 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, linux-kernel@vger.kernel.org,
linux@armlinux.org.uk, Mike Rapoport, Chester Lin,
geert@linux-m68k.org, ren_guo@c-sky.com, Gary Lin,
akpm@linux-foundation.org, mingo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu-sdhNbhfD24Fn93mj-h6=vGi82Ghjy7AzaRSqcpXCx-g@mail.gmail.com>
On Mon, Aug 19, 2019 at 05:56:51PM +0300, Ard Biesheuvel wrote:
> On Mon, 19 Aug 2019 at 11:01, Chester Lin <clin@suse.com> wrote:
> >
> > Hi Mike and Ard,
> >
> > On Thu, Aug 15, 2019 at 04:37:39PM +0300, Mike Rapoport wrote:
> > > On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> > > > (adding Mike)
> > > >
> > > > On Thu, 15 Aug 2019 at 14:28, Chester Lin <clin@suse.com> wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > > > > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > > > > > >
> > > > > > > Hello Chester,
> > > > > > >
> > > > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
> > > > > > > >
> > > > > > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > > > > > uncompressed kernel. For example, we got the following error message when
> > > > > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > > > > > >
> > > > > > > > EFI stub: Booting Linux Kernel...
> > > > > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > > > > > > > EFI stub: ERROR: Failed to relocate kernel
> > > > > > > >
> > > > > > > > After checking the EFI memory map we found that the first page [0 - 0xfff]
> > > > > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > > > > > > > set the dram base at 0, which was actually in a reserved region.
> > > > > > > >
> > > > > > >
> > > > > > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > > > > > ARM when using the decompressor. The decompressor rounds down its own
> > > > > > > base address to a multiple of 128 MB, and assumes the whole area is
> > > > > > > available for the decompressed kernel and related data structures.
> > > > > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > > > > > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > > > > > this is fragile). Note that the decompressor does not look at any DT
> > > > > > > or EFI provided memory maps *at all*.
> > > > > > >
> > > > > > > So unfortunately, this is not something we can fix in the kernel, but
> > > > > > > we should fix it in the bootloader or in GRUB, so it does not put any
> > > > > > > reserved regions in the first 128 MB of memory,
> > > > > > >
> > > > > >
> > > > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > > > > > ARM boot protocol docs are unclear about whether this memory should be
> > > > > > used or not, but it is no longer used for its original purpose (page
> > > > > > tables), and the RPi loader already keeps data there.
> > > > > >
> > > > > > Can you check whether the following patch works for you?
> > > > > >
> > > > > > diff --git a/drivers/firmware/efi/libstub/Makefile
> > > > > > b/drivers/firmware/efi/libstub/Makefile
> > > > > > index 0460c7581220..ee0661ddb25b 100644
> > > > > > --- a/drivers/firmware/efi/libstub/Makefile
> > > > > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > > > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > > > > > string.o random.o \
> > > > > >
> > > > > > lib-$(CONFIG_ARM) += arm32-stub.o
> > > > > > lib-$(CONFIG_ARM64) += arm64-stub.o
> > > > > > +CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > > > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > > >
> > > > > > #
> > > > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > index e8f7aefb6813..66ff0c8ec269 100644
> > > > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > @@ -204,7 +204,7 @@ efi_status_t
> > > > > > handle_kernel_image(efi_system_table_t *sys_table,
> > > > > > * loaded. These assumptions are made by the decompressor,
> > > > > > * before any memory map is available.
> > > > > > */
> > > > > > - dram_base = round_up(dram_base, SZ_128M);
> > > > > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;
> > > > > >
> > > > > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
> > > > > > reserve_size);
> > > > > >
> > > > >
> > > > > I tried your patch on rpi2 and got the following panic. Just a reminder that I
> > > > > have replaced some log messages with "......" since it might be too long to
> > > > > post all.
> > > > >
> > > >
> > > > OK. Good to know that this change helps you to get past the EFI stub boot issue.
> > > >
> > > > > In this case the kernel failed to reserve cma, which should hit the issue of
> > > > > memblock_limit=0x1000 as I had mentioned in my patch description. The first
> > > > > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> > > > > with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> > > > > was extremely low. That's why I expand the first reservation from 1 PAGESIZE to
> > > > > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> > > > > if any suggestion, thank you.
> > >
> > >
> > > > This looks like it is a separate issue. The memblock/cma code should
> > > > not choke on a reserved page of memory at 0x0.
> > > >
> > > > Perhaps Russell or Mike (cc'ed) have an idea how to address this?
> > >
> > > Presuming that the last memblock dump comes from the end of
> > > arm_memblock_init() with the this memory map
> > >
> > > memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> > > memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> > > memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> > > memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
> > >
> > > adjust_lowmem_bounds() will set the memblock_limit (and respectively global
> > > memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
> > > happily fail.
> > >
> > > I believe that the assumption for memblock_limit calculations was that the
> > > first bank has several megs at least.
> > >
> > > I wonder if this hack would help:
> > >
> > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > index d9a0038..948e5b9 100644
> > > --- a/arch/arm/mm/mmu.c
> > > +++ b/arch/arm/mm/mmu.c
> > > @@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
> > > * allocated when mapping the start of bank 0, which
> > > * occurs before any free memory is mapped.
> > > */
> > > - if (!memblock_limit) {
> > > + if (memblock_limit < PMD_SIZE) {
> > > if (!IS_ALIGNED(block_start, PMD_SIZE))
> > > memblock_limit = block_start;
> > > else if (!IS_ALIGNED(block_end, PMD_SIZE))
> > >
> >
> > I applied this patch as well and it works well on rpi-2 model B.
> >
>
> Thanks, Chester, that is good to know.
>
> However, afaict, this only affects systems where physical memory
> starts at address 0x0, so I think we need a better fix.
>
> I know Mike has been looking into the NOMAP stuff lately, and your
> original patch contains a hunk that makes this code (?) disregard
> nomap memblocks. That might be a better approach.
>
Hi Ard and Mike,
In my original patch, I studied map_lowmem() and found that some blocks might
not be mapped according to the current memory map. Thus I assumed maybe NOMAP
blocks could still be ignored in adjust_lowmem_bounds() since they would not
be allocated afterward. But that change in mmu.c still depends on a condition
that there should be a PMD_SIZE block or consecutive smaller NOMAP blocks which
exacly fit the PM_SIZE alignment at the beginning of memory map otherwise the
memblock_limit could still fall on a very low address. That's why I tried to
allocate pages again in arm32-stub.c in order to fill the gap between the
unaligned block_start and the PMD_SIZE aligned kernel base.
Please feel free to let me know if any idea and I am willing to help with
verification.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Enabling UBSAN breaks KCOV in clang (8.0.*) on arm64
From: Nathan Chancellor @ 2019-08-20 7:28 UTC (permalink / raw)
To: Mark Rutland
Cc: clang-built-linux, Nick Desaulniers, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190819165947.GA30292@lakrids.cambridge.arm.com>
On Mon, Aug 19, 2019 at 05:59:48PM +0100, Mark Rutland wrote:
> Hi,
>
> I found that when I enable both KCOV and UBSAN on arm64, clang fails to
> emit any __sanitizer_cov_trace_*() calls in the resulting binary,
> rendering KCOV useless.
>
> For example, when building v5.3-rc3's arch/arm64/kernel/setup.o:
>
> * With defconfig + CONFIG KCOV:
>
> clang -Wp,-MD,arch/arm64/kernel/.setup.o.d -nostdinc -isystem
> /mnt/data/opt/toolchain/llvm/8.0.0/clang+llvm-8.0.0-x86_64-linux-sles11.3/lib/clang/8.0.0/include
> -I./arch/arm64/include -I./arch/arm64/include/generated -I./include
> -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi
> -I./include/uapi -I./include/generated/uapi -include
> ./include/linux/kconfig.h -include ./include/linux/compiler_types.h
> -D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3
> -Qunused-arguments -Wall -Wundef -Werror=strict-prototypes
> -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wno-format-security -std=gnu89 --target=aarch64-linux
> --prefix=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux/bin/
> --gcc-toolchain=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux
> -no-integrated-as -Werror=unknown-warning-option -mgeneral-regs-only
> -DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables
> -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks
> -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048
> -fstack-protector-strong -Wno-format-invalid-specifier -Wno-gnu
> -Wno-tautological-compare -mno-global-merge -Wno-unused-const-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -g
> -Wdeclaration-after-statement -Wvla -Wno-pointer-sign
> -fno-strict-overflow -fno-merge-all-constants -fno-stack-check
> -Werror=date-time -Werror=incompatible-pointer-types
> -Wno-initializer-overrides -Wno-format -Wno-sign-compare
> -Wno-format-zero-length -fsanitize-coverage=trace-pc
> -DKBUILD_BASENAME='"setup"' -DKBUILD_MODNAME='"setup"' -c -o
> arch/arm64/kernel/setup.o arch/arm64/kernel/setup.c
>
> ... and there are 44 calls to __sanitizer_cov_trace_pc in the
> resulting setup.o
>
> * with defconfig + CONFIG_KCOV + CONFIG_UBSAN:
>
> clang -Wp,-MD,arch/arm64/kernel/.setup.o.d -nostdinc -isystem
> /mnt/data/opt/toolchain/llvm/8.0.0/clang+llvm-8.0.0-x86_64-linux-sles11.3/lib/clang/8.0.0/include
> -I./arch/arm64/include -I./arch/arm64/include/generated -I./include
> -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi
> -I./include/uapi -I./include/generated/uapi -include
> ./include/linux/kconfig.h -include ./include/linux/compiler_types.h
> -D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3
> -Qunused-arguments -Wall -Wundef -Werror=strict-prototypes
> -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wno-format-security -std=gnu89 --target=aarch64-linux
> --prefix=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux/bin/
> --gcc-toolchain=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux
> -no-integrated-as -Werror=unknown-warning-option -mgeneral-regs-only
> -DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables
> -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks
> -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048
> -fstack-protector-strong -Wno-format-invalid-specifier -Wno-gnu
> -Wno-tautological-compare -mno-global-merge -Wno-unused-const-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -g
> -Wdeclaration-after-statement -Wvla -Wno-pointer-sign
> -fno-strict-overflow -fno-merge-all-constants -fno-stack-check
> -Werror=date-time -Werror=incompatible-pointer-types
> -Wno-initializer-overrides -Wno-format -Wno-sign-compare
> -Wno-format-zero-length -fsanitize=shift
> -fsanitize=integer-divide-by-zero -fsanitize=unreachable
> -fsanitize=signed-integer-overflow -fsanitize=bounds
> -fsanitize=object-size -fsanitize=bool -fsanitize=enum
> -fsanitize-coverage=trace-pc -DKBUILD_BASENAME='"setup"'
> -DKBUILD_MODNAME='"setup"' -c -o arch/arm64/kernel/setup.o
> arch/arm64/kernel/setup.c
>
> ... and there are 0 calls to __sanitizer_cov_trace_pc in the resulting
> setup.o, even though -fsanitize-coverage=trace-pc was passed to clang.
>
> If I remove -fsanitize=bounds, there are 121 calls to
> __sanitizer_cov_trace_pc in setup.o. Removing the other options enabled
> by UBSAN didn't have any effect on setup.o.
>
> I'm using the llvm.org 8.0.{0,1} binaries [1,2], along with the
> kernel.org crosstool 8.1.0 binaries [3].
>
> Any ideas as to what's going on?
>
> Thanks,
> Mark.
>
> [1] http://releases.llvm.org/download.html#8.0.0
> [2] http://releases.llvm.org/download.html#8.0.1
> [3] https://mirrors.edge.kernel.org/pub/tools/crosstool/
Hi Mark,
I've narrowed it down further; it seems that the combination of
-fsanitize-coverage=trace-pc and -fsanitize=local-bounds prevents the
emission of __sanitizer_cov_trace_pc. -fsanitize=bounds is the same as
-fsanitize=local-bounds and -fsanitize=array-bounds, the latter of which
has no issues.
https://godbolt.org/z/YdF-he
This reproducer was taken from a somewhat related bug report in April.
https://bugs.llvm.org/show_bug.cgi?id=41387
What's also interesting is when you remove -Qunused-arguments from the
clang command, the following warning appears (also visible in the
godbolt link):
clang-10: warning: argument unused during compilation:
'-fsanitize-coverage=trace-pc' [-Wunused-command-line-argument]
I have no idea why this combination is special, I've been searching the
source trying to see what I can find and I am currently not coming up
with anything (I'm sure a good night's rest will give me a fresh set of
eyes).
This is still an issue on Clang trunk.
Cheers,
Nathan
_______________________________________________
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 3/3] arm64: implement KPROBES_ON_FTRACE
From: Jisheng Zhang @ 2019-08-20 7:17 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Will Deacon, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86@kernel.org,
Naveen N. Rao, Anil S Keshavamurthy, David S. Miller,
Masami Hiramatsu
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20190820114314.685a3239@xhacker.debian>
On Tue, 20 Aug 2019 03:54:20 +0000 Jisheng Zhang wrote:
>
>
> KPROBES_ON_FTRACE avoids much of the overhead with regular kprobes as it
> eliminates the need for a trap, as well as the need to emulate or
> single-step instructions.
>
> This patch implements KPROBES_ON_FTRACE for arm64.
>
> Tested on berlin arm64 platform.
some performance numbers may be interesting.
HW: Berlin arm64 platform, cpufreq is forced to 800MHZ
SW: getppid syscall micro-benchmark, source code is put at the end of this email.
A. Not probed.
B. Probed at __arm64_sys_getppid w/ non-operation probe functions, w/o KPROBES_ON_FTRACE
C. Probed at __arm64_sys_getppid w/ non-operation probe functions, w/ KPROBES_ON_FTRACE
A: 1905 ns/call
B: 5833 ns/call
C: 2169 ns/call
The overhead of kprobes is 5833 - 1905 = 3928 ns/call
The overhead of kprobes w/ KPROBES_ON_FTRACE is 2169 - 1905 = 264 ns/call
As can be seen, KPROBES_ON_FTRACE significantly reduce the overhead of kprobes.
Thanks
<---8---
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
int main (int argc, char *argv[])
{
struct timeval tv;
unsigned long count;
struct rusage usage;
for (count = 0; count < 10000000; count++)
getppid();
getrusage(RUSAGE_SELF, &usage);
tv = usage.ru_stime;
tv.tv_sec += usage.ru_utime.tv_sec;
tv.tv_usec += usage.ru_utime.tv_usec;
fprintf(stderr, "getppid was called %u times: %d nsec per call\n",
count, (tv.tv_sec*1000*1000 + tv.tv_usec)/(count/1000));
return 0;
}
>
> ~ # mount -t debugfs debugfs /sys/kernel/debug/
> ~ # cd /sys/kernel/debug/
> /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
>
> before the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009fe28 k _do_fork+0x0 [DISABLED]
>
> after the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009ff54 k _do_fork+0x4 [DISABLED][FTRACE]
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> .../debug/kprobes-on-ftrace/arch-support.txt | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/probes/Makefile | 1 +
> arch/arm64/kernel/probes/ftrace.c | 60 +++++++++++++++++++
> 4 files changed, 63 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/kernel/probes/ftrace.c
>
> diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> index 68f266944d5f..e8358a38981c 100644
> --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
> @@ -9,7 +9,7 @@
> | alpha: | TODO |
> | arc: | TODO |
> | arm: | TODO |
> - | arm64: | TODO |
> + | arm64: | ok |
> | c6x: | TODO |
> | csky: | TODO |
> | h8300: | TODO |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 663392d1eae2..928700f15e23 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -167,6 +167,7 @@ config ARM64
> select HAVE_STACKPROTECTOR
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_KPROBES
> + select HAVE_KPROBES_ON_FTRACE
> select HAVE_KRETPROBES
> select HAVE_GENERIC_VDSO
> select IOMMU_DMA if IOMMU_SUPPORT
> diff --git a/arch/arm64/kernel/probes/Makefile b/arch/arm64/kernel/probes/Makefile
> index 8e4be92e25b1..4020cfc66564 100644
> --- a/arch/arm64/kernel/probes/Makefile
> +++ b/arch/arm64/kernel/probes/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_KPROBES) += kprobes.o decode-insn.o \
> simulate-insn.o
> obj-$(CONFIG_UPROBES) += uprobes.o decode-insn.o \
> simulate-insn.o
> +obj-$(CONFIG_KPROBES_ON_FTRACE) += ftrace.o
> diff --git a/arch/arm64/kernel/probes/ftrace.c b/arch/arm64/kernel/probes/ftrace.c
> new file mode 100644
> index 000000000000..52901ffff570
> --- /dev/null
> +++ b/arch/arm64/kernel/probes/ftrace.c
> @@ -0,0 +1,60 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Dynamic Ftrace based Kprobes Optimization
> + *
> + * Copyright (C) Hitachi Ltd., 2012
> + * Copyright (C) 2019 Jisheng Zhang <jszhang@kernel.org>
> + * Synaptics Incorporated
> + */
> +
> +#include <linux/kprobes.h>
> +
> +/* Ftrace callback handler for kprobes -- called under preepmt disabed */
> +void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> + struct ftrace_ops *ops, struct pt_regs *regs)
> +{
> + struct kprobe *p;
> + struct kprobe_ctlblk *kcb;
> +
> + /* Preempt is disabled by ftrace */
> + p = get_kprobe((kprobe_opcode_t *)ip);
> + if (unlikely(!p) || kprobe_disabled(p))
> + return;
> +
> + kcb = get_kprobe_ctlblk();
> + if (kprobe_running()) {
> + kprobes_inc_nmissed_count(p);
> + } else {
> + unsigned long orig_ip = instruction_pointer(regs);
> + /* Kprobe handler expects regs->pc = pc + 1 as breakpoint hit */
> + instruction_pointer_set(regs, ip + sizeof(kprobe_opcode_t));
> +
> + __this_cpu_write(current_kprobe, p);
> + kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> + if (!p->pre_handler || !p->pre_handler(p, regs)) {
> + /*
> + * Emulate singlestep (and also recover regs->pc)
> + * as if there is a nop
> + */
> + instruction_pointer_set(regs,
> + (unsigned long)p->addr + MCOUNT_INSN_SIZE);
> + if (unlikely(p->post_handler)) {
> + kcb->kprobe_status = KPROBE_HIT_SSDONE;
> + p->post_handler(p, regs, 0);
> + }
> + instruction_pointer_set(regs, orig_ip);
> + }
> + /*
> + * If pre_handler returns !0, it changes regs->pc. We have to
> + * skip emulating post_handler.
> + */
> + __this_cpu_write(current_kprobe, NULL);
> + }
> +}
> +NOKPROBE_SYMBOL(kprobe_ftrace_handler);
> +
> +int arch_prepare_kprobe_ftrace(struct kprobe *p)
> +{
> + p->ainsn.api.insn = NULL;
> + return 0;
> +}
> --
> 2.23.0.rc1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 03/10] dt-bindings: mailbox: Add a sunxi message box binding
From: Maxime Ripard @ 2019-08-20 7:14 UTC (permalink / raw)
To: Samuel Holland
Cc: Mark Rutland, devicetree, linux-sunxi, Rob Herring, Stephen Boyd,
Michael Turquette, Jassi Brar, linux-kernel, Chen-Yu Tsai,
Rob Herring, Corentin Labbe, linux-clk, linux-arm-kernel
In-Reply-To: <20190820032311.6506-4-samuel@sholland.org>
[-- Attachment #1.1: Type: text/plain, Size: 776 bytes --]
Hi,
On Mon, Aug 19, 2019 at 10:23:04PM -0500, Samuel Holland wrote:
> This mailbox hardware is present in Allwinner sun8i, sun9i, and sun50i
> SoCs. Add a device tree binding for it.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> .../mailbox/allwinner,sunxi-msgbox.yaml | 79 +++++++++++++++++++
> 1 file changed, 79 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml
So we merged a bunch of schemas already, with the convention that the
name was the first compatible to use that binding.
That would be allwinner,sun6i-a31-msgbox.yaml in that case
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Linus Walleij @ 2019-08-20 7:12 UTC (permalink / raw)
To: Andy Shevchenko, Thierry Reding
Cc: Salil Mehta, jinying, Tangkunshan, Liguozhu (Kenneth), John Garry,
Rafael J. Wysocki, Linux Kernel Mailing List, Wei Xu, Linuxarm,
open list:GPIO SUBSYSTEM, Shameerali Kolothum Thodi, huangdaode,
Jonathan Cameron, Shiju Jose, Mika Westerberg, Zhangyi ac,
linux-arm Mailing List, Len Brown
In-Reply-To: <CAHp75Vct3qtR5bDF6iALmduKEEq+gNL-btmzQVuWq_hYsmxKhw@mail.gmail.com>
On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> The proper fix is to revert the culprit since we call
> acpi_gpiochip_request_interrupts() for all controllers.
> Linus, please re-do the approach with IRQ handling,
Exactly what do you refer to when you want me to
"re-do the approach for IRQ handling"? Do you mean
this driver or are you referring to:
commit e0d89728981393b7d694bd3419b7794b9882c92d
Author: Thierry Reding <treding@nvidia.com>
Date: Tue Nov 7 19:15:54 2017 +0100
gpio: Implement tighter IRQ chip integration
Currently GPIO drivers are required to add the GPIO chip and its
corresponding IRQ chip separately, which can result in a lot of
boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
struct gpio_chip, that drivers can fill in if they want the GPIO core
to automatically register the IRQ chip associated with a GPIO chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The new API introduced by this patch is what I am trying to switch
everything over to, because the forked paths inside of gpiolib
is causing me a maintenance headache and also increasing
the footprint of the library.
> it seems broadly
> regress with ACPI enabled platforms.
It only becomes a problem if the platform uses ACPI right?
But it's a problem if I can't really tell if a driver is using
ACPI or not, there is no sign in the pl061 driver that it would
be used on ACPI systems until now, so how do I design
for it?
The problem comes from the problem/mess I am trying to
clean up in the first place. So if the new way of registering GPIO
irqchips is not working for ACPI, then we have to fix that instead
of reverting all attempts to use the new API IMO.
Yours,
Linus Walleij
_______________________________________________
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