* RE: [External] Re: [PATCH 3/5] s390, dcssblk: Allow a NULL-kaddr to ->direct_access()
From: Huaisheng HS1 Ye @ 2018-07-24 9:46 UTC (permalink / raw)
To: Christian Borntraeger, linux-nvdimm@lists.01.org,
dan.j.williams@intel.com
Cc: ross.zwisler@linux.intel.com, willy@infradead.org,
vishal.l.verma@intel.com, dave.jiang@intel.com,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
viro@zeniv.linux.org.uk, martin.petersen@oracle.com,
axboe@kernel.dk, gregkh@linuxfoundation.org,
bart.vanassche@wdc.com, jack@suse.cz,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
linux-fsdevel@vger.kernel.org, NingTing Cheng, Huaisheng Ye
In-Reply-To: <192a9dac-921f-e222-3a7d-32d43679cd12@de.ibm.com>
From: Christian Borntraeger <borntraeger@de.ibm.com>
Sent: Tuesday, July 24, 2018 4:54 PM
> On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
> > From: Huaisheng Ye <yehs1@lenovo.com>
> >
> > dcssblk_direct_access() needs to check the validity of second rank
> > pointer kaddr for NULL assignment. If kaddr equals to NULL, it
> > doesn't need to calculate the value.
> >
> > Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
> > ---
> > drivers/s390/block/dcssblk.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
> > index 0a312e4..9c13dc5 100644
> > --- a/drivers/s390/block/dcssblk.c
> > +++ b/drivers/s390/block/dcssblk.c
> > @@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
> > unsigned long dev_sz;
> >
> > dev_sz = dev_info->end - dev_info->start + 1;
> > - *kaddr = (void *) dev_info->start + offset;
> > + if (kaddr)
> > + *kaddr = (void *) dev_info->start + offset;
>
> So you are trading of a load + add (dev_info->start should be cache hot) against a
> compare+branch . Not sure that this is always a win.
Hmm...the calculation process of pfn is more complicated than kaddr. I think you agree to check pfn but not sure kaddr, right?
From the logical consistency of code, I think it shall be better to give pfn and kaddr similar treatment.
Cheers,
Huaisheng Ye
^ permalink raw reply
* Re: [PATCH v3 1/1] KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space
From: Cédric Le Goater @ 2018-07-24 9:07 UTC (permalink / raw)
To: Sam Bobroff, linuxppc-dev; +Cc: kvm, kvm-ppc, paulus, david
In-Reply-To: <1fb3aea5f44f1029866ee10db40abde7e18b24ad.1531967105.git.sbobroff@linux.ibm.com>
On 07/19/2018 04:25 AM, Sam Bobroff wrote:
> From: Sam Bobroff <sam.bobroff@au1.ibm.com>
>
> It is not currently possible to create the full number of possible
> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
> threads per core than it's core stride (or "VSMT mode"). This is
> because the VCORE ID and XIVE offsets to grow beyond KVM_MAX_VCPUS
> even though the VCPU ID is less than KVM_MAX_VCPU_ID.
>
> To address this, "pack" the VCORE ID and XIVE offsets by using
> knowledge of the way the VCPU IDs will be used when there are less
> guest threads per core than the core stride. The primary thread of
> each core will always be used first. Then, if the guest uses more than
> one thread per core, these secondary threads will sequentially follow
> the primary in each core.
>
> So, the only way an ID above KVM_MAX_VCPUS can be seen, is if the
> VCPUs are being spaced apart, so at least half of each core is empty
> and IDs between KVM_MAX_VCPUS and (KVM_MAX_VCPUS * 2) can be mapped
> into the second half of each core (4..7, in an 8-thread core).
>
> Similarly, if IDs above KVM_MAX_VCPUS * 2 are seen, at least 3/4 of
> each core is being left empty, and we can map down into the second and
> third quarters of each core (2, 3 and 5, 6 in an 8-thread core).
>
> Lastly, if IDs above KVM_MAX_VCPUS * 4 are seen, only the primary
> threads are being used and 7/8 of the core is empty, allowing use of
> the 1, 3, 5 and 7 thread slots.
>
> (Strides less than 8 are handled similarly.)
>
> This allows the VCORE ID or offset to be calculated quickly from the
> VCPU ID or XIVE server numbers, without access to the VCPU structure.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
On the XIVE part,
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Thanks,
C.
> ---
> Hello everyone,
>
> I've completed a trial merge with the guest native-XIVE code and found no
> problems; it's no more difficult than the host side and only requires a few
> calls to xive_vp().
>
> On that basis, here is v3 (unchanged from v2) as non-RFC and it seems to be
> ready to go.
>
> Patch set v3:
> Patch 1/1: KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space
>
> Patch set v2:
> Patch 1/1: KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space
> * Corrected places in kvm/book3s_xive.c where IDs weren't packed.
> * Because kvmppc_pack_vcpu_id() is only called on P9, there is no need to test "emul_smt_mode > 1", so remove it.
> * Re-ordered block_offsets[] to be more ascending.
> * Added more detailed description of the packing algorithm.
>
> Patch set v1:
> Patch 1/1: KVM: PPC: Book3S HV: pack VCORE IDs to access full VCPU ID space
>
> arch/powerpc/include/asm/kvm_book3s.h | 44 +++++++++++++++++++++++++++++++++++
> arch/powerpc/kvm/book3s_hv.c | 14 +++++++----
> arch/powerpc/kvm/book3s_xive.c | 19 +++++++++------
> 3 files changed, 66 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
> index 1f345a0b6ba2..ba4b6e00fca7 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -390,4 +390,48 @@ extern int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu);
> #define SPLIT_HACK_MASK 0xff000000
> #define SPLIT_HACK_OFFS 0xfb000000
>
> +/* Pack a VCPU ID from the [0..KVM_MAX_VCPU_ID) space down to the
> + * [0..KVM_MAX_VCPUS) space, while using knowledge of the guest's core stride
> + * (but not it's actual threading mode, which is not available) to avoid
> + * collisions.
> + *
> + * The implementation leaves VCPU IDs from the range [0..KVM_MAX_VCPUS) (block
> + * 0) unchanged: if the guest is filling each VCORE completely then it will be
> + * using consecutive IDs and it will fill the space without any packing.
> + *
> + * For higher VCPU IDs, the packed ID is based on the VCPU ID modulo
> + * KVM_MAX_VCPUS (effectively masking off the top bits) and then an offset is
> + * added to avoid collisions.
> + *
> + * VCPU IDs in the range [KVM_MAX_VCPUS..(KVM_MAX_VCPUS*2)) (block 1) are only
> + * possible if the guest is leaving at least 1/2 of each VCORE empty, so IDs
> + * can be safely packed into the second half of each VCORE by adding an offset
> + * of (stride / 2).
> + *
> + * Similarly, if VCPU IDs in the range [(KVM_MAX_VCPUS*2)..(KVM_MAX_VCPUS*4))
> + * (blocks 2 and 3) are seen, the guest must be leaving at least 3/4 of each
> + * VCORE empty so packed IDs can be offset by (stride / 4) and (stride * 3 / 4).
> + *
> + * Finally, VCPU IDs from blocks 5..7 will only be seen if the guest is using a
> + * stride of 8 and 1 thread per core so the remaining offsets of 1, 3, 5 and 7
> + * must be free to use.
> + *
> + * (The offsets for each block are stored in block_offsets[], indexed by the
> + * block number if the stride is 8. For cases where the guest's stride is less
> + * than 8, we can re-use the block_offsets array by multiplying the block
> + * number by (MAX_SMT_THREADS / stride) to reach the correct entry.)
> + */
> +static inline u32 kvmppc_pack_vcpu_id(struct kvm *kvm, u32 id)
> +{
> + const int block_offsets[MAX_SMT_THREADS] = {0, 4, 2, 6, 1, 3, 5, 7};
> + int stride = kvm->arch.emul_smt_mode;
> + int block = (id / KVM_MAX_VCPUS) * (MAX_SMT_THREADS / stride);
> + u32 packed_id;
> +
> + BUG_ON(block >= MAX_SMT_THREADS);
> + packed_id = (id % KVM_MAX_VCPUS) + block_offsets[block];
> + BUG_ON(packed_id >= KVM_MAX_VCPUS);
> + return packed_id;
> +}
> +
> #endif /* __ASM_KVM_BOOK3S_H__ */
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index de686b340f4a..363c2fb0d89e 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1816,7 +1816,7 @@ static int threads_per_vcore(struct kvm *kvm)
> return threads_per_subcore;
> }
>
> -static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int core)
> +static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int id)
> {
> struct kvmppc_vcore *vcore;
>
> @@ -1830,7 +1830,7 @@ static struct kvmppc_vcore *kvmppc_vcore_create(struct kvm *kvm, int core)
> init_swait_queue_head(&vcore->wq);
> vcore->preempt_tb = TB_NIL;
> vcore->lpcr = kvm->arch.lpcr;
> - vcore->first_vcpuid = core * kvm->arch.smt_mode;
> + vcore->first_vcpuid = id;
> vcore->kvm = kvm;
> INIT_LIST_HEAD(&vcore->preempt_list);
>
> @@ -2048,12 +2048,18 @@ static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
> mutex_lock(&kvm->lock);
> vcore = NULL;
> err = -EINVAL;
> - core = id / kvm->arch.smt_mode;
> + if (cpu_has_feature(CPU_FTR_ARCH_300)) {
> + BUG_ON(kvm->arch.smt_mode != 1);
> + core = kvmppc_pack_vcpu_id(kvm, id);
> + } else {
> + core = id / kvm->arch.smt_mode;
> + }
> if (core < KVM_MAX_VCORES) {
> vcore = kvm->arch.vcores[core];
> + BUG_ON(cpu_has_feature(CPU_FTR_ARCH_300) && vcore);
> if (!vcore) {
> err = -ENOMEM;
> - vcore = kvmppc_vcore_create(kvm, core);
> + vcore = kvmppc_vcore_create(kvm, id & ~(kvm->arch.smt_mode - 1));
> kvm->arch.vcores[core] = vcore;
> kvm->arch.online_vcores++;
> }
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index f9818d7d3381..dbd5887daf4a 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -317,6 +317,11 @@ static int xive_select_target(struct kvm *kvm, u32 *server, u8 prio)
> return -EBUSY;
> }
>
> +static u32 xive_vp(struct kvmppc_xive *xive, u32 server)
> +{
> + return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server);
> +}
> +
> static u8 xive_lock_and_mask(struct kvmppc_xive *xive,
> struct kvmppc_xive_src_block *sb,
> struct kvmppc_xive_irq_state *state)
> @@ -362,7 +367,7 @@ static u8 xive_lock_and_mask(struct kvmppc_xive *xive,
> */
> if (xd->flags & OPAL_XIVE_IRQ_MASK_VIA_FW) {
> xive_native_configure_irq(hw_num,
> - xive->vp_base + state->act_server,
> + xive_vp(xive, state->act_server),
> MASKED, state->number);
> /* set old_p so we can track if an H_EOI was done */
> state->old_p = true;
> @@ -418,7 +423,7 @@ static void xive_finish_unmask(struct kvmppc_xive *xive,
> */
> if (xd->flags & OPAL_XIVE_IRQ_MASK_VIA_FW) {
> xive_native_configure_irq(hw_num,
> - xive->vp_base + state->act_server,
> + xive_vp(xive, state->act_server),
> state->act_priority, state->number);
> /* If an EOI is needed, do it here */
> if (!state->old_p)
> @@ -495,7 +500,7 @@ static int xive_target_interrupt(struct kvm *kvm,
> kvmppc_xive_select_irq(state, &hw_num, NULL);
>
> return xive_native_configure_irq(hw_num,
> - xive->vp_base + server,
> + xive_vp(xive, server),
> prio, state->number);
> }
>
> @@ -883,7 +888,7 @@ int kvmppc_xive_set_mapped(struct kvm *kvm, unsigned long guest_irq,
> * which is fine for a never started interrupt.
> */
> xive_native_configure_irq(hw_irq,
> - xive->vp_base + state->act_server,
> + xive_vp(xive, state->act_server),
> state->act_priority, state->number);
>
> /*
> @@ -959,7 +964,7 @@ int kvmppc_xive_clr_mapped(struct kvm *kvm, unsigned long guest_irq,
>
> /* Reconfigure the IPI */
> xive_native_configure_irq(state->ipi_number,
> - xive->vp_base + state->act_server,
> + xive_vp(xive, state->act_server),
> state->act_priority, state->number);
>
> /*
> @@ -1084,7 +1089,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev,
> pr_devel("Duplicate !\n");
> return -EEXIST;
> }
> - if (cpu >= KVM_MAX_VCPUS) {
> + if (cpu >= KVM_MAX_VCPU_ID) {
> pr_devel("Out of bounds !\n");
> return -EINVAL;
> }
> @@ -1098,7 +1103,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev,
> xc->xive = xive;
> xc->vcpu = vcpu;
> xc->server_num = cpu;
> - xc->vp_id = xive->vp_base + cpu;
> + xc->vp_id = xive_vp(xive, cpu);
> xc->mfrr = 0xff;
> xc->valid = true;
>
>
^ permalink raw reply
* [PATCH] arm64: fix ACPI dependencies
From: Arnd Bergmann @ 2018-07-24 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724094406.GF19324@arm.com>
On Tue, Jul 24, 2018 at 11:44 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jul 24, 2018 at 11:37:10AM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> How about something along the lines of what Ard suggested? Untested diff
> below.
>
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 303809c6..ec78d4d 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -56,6 +56,7 @@ config ARM64
> select ARCH_USE_CMPXCHG_LOCKREF
> select ARCH_USE_QUEUED_RWLOCKS
> select ARCH_USE_QUEUED_SPINLOCKS
> + select ARCH_SUPPORTS_ACPI
> select ARCH_SUPPORTS_MEMORY_FAILURE
> select ARCH_SUPPORTS_ATOMIC_RMW
> select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 50000 || CC_IS_CLANG
I'd prefer Rafael's suggestion of just leaving out the architecture names from
the dependency, and making all three 'select ARCH_SUPPORTS_ACPI'.
I'll send a v2.
Arnd
^ permalink raw reply
* Re: [PATCH] arm64: fix ACPI dependencies
From: Arnd Bergmann @ 2018-07-24 9:46 UTC (permalink / raw)
To: Will Deacon
Cc: Rafael J. Wysocki, Catalin Marinas, Rafael J. Wysocki, Len Brown,
AKASHI Takahiro, Ard Biesheuvel, Mark Rutland, Marc Zyngier,
Linux ARM, Linux Kernel Mailing List, ACPI Devel Maling List
In-Reply-To: <20180724094406.GF19324@arm.com>
On Tue, Jul 24, 2018 at 11:44 AM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jul 24, 2018 at 11:37:10AM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> How about something along the lines of what Ard suggested? Untested diff
> below.
>
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 303809c6..ec78d4d 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -56,6 +56,7 @@ config ARM64
> select ARCH_USE_CMPXCHG_LOCKREF
> select ARCH_USE_QUEUED_RWLOCKS
> select ARCH_USE_QUEUED_SPINLOCKS
> + select ARCH_SUPPORTS_ACPI
> select ARCH_SUPPORTS_MEMORY_FAILURE
> select ARCH_SUPPORTS_ATOMIC_RMW
> select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 50000 || CC_IS_CLANG
I'd prefer Rafael's suggestion of just leaving out the architecture names from
the dependency, and making all three 'select ARCH_SUPPORTS_ACPI'.
I'll send a v2.
Arnd
^ permalink raw reply
* [PATCH v3 3/3] soc: imx: gpc: use GPC_PGC_DOMAIN_* indexes
From: Sven Schmitt @ 2018-07-24 9:46 UTC (permalink / raw)
To: linux-arm-kernel
Use GPC_PGC_DOMAIN_* indexes consistent.
Signed-off-by: Sven Schmitt <sven.schmitt@mixed-mode.de>
---
drivers/soc/imx/gpc.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 35cc1d2dc4d5..6618ff1eaebd 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -247,6 +247,7 @@ builtin_platform_driver(imx_pgc_power_domain_driver)
#define GPC_PGC_DOMAIN_ARM 0
#define GPC_PGC_DOMAIN_PU 1
#define GPC_PGC_DOMAIN_DISPLAY 2
+#define GPC_PGC_DOMAIN_PCI 3
static struct genpd_power_state imx6_pm_domain_pu_state = {
.power_off_latency_ns = 25000,
@@ -254,12 +255,13 @@ static struct genpd_power_state imx6_pm_domain_pu_state = {
};
static struct imx_pm_domain imx_gpc_domains[] = {
- {
+ [GPC_PGC_DOMAIN_ARM] {
.base = {
.name = "ARM",
.flags = GENPD_FLAG_ALWAYS_ON,
},
- }, {
+ },
+ [GPC_PGC_DOMAIN_PU] {
.base = {
.name = "PU",
.power_off = imx6_pm_domain_power_off,
@@ -269,7 +271,8 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x260,
.cntr_pdn_bit = 0,
- }, {
+ },
+ [GPC_PGC_DOMAIN_DISPLAY] {
.base = {
.name = "DISPLAY",
.power_off = imx6_pm_domain_power_off,
@@ -277,7 +280,8 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x240,
.cntr_pdn_bit = 4,
- }, {
+ },
+ [GPC_PGC_DOMAIN_PCI] {
.base = {
.name = "PCI",
.power_off = imx6_pm_domain_power_off,
@@ -343,8 +347,8 @@ static const struct regmap_config imx_gpc_regmap_config = {
};
static struct generic_pm_domain *imx_gpc_onecell_domains[] = {
- &imx_gpc_domains[0].base,
- &imx_gpc_domains[1].base,
+ &imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base,
+ &imx_gpc_domains[GPC_PGC_DOMAIN_PU].base,
};
static struct genpd_onecell_data imx_gpc_onecell_data = {
--
2.17.1
^ permalink raw reply related
* [PATCH v3 2/3] soc: imx: gpc: clean up
From: Sven Schmitt @ 2018-07-24 9:46 UTC (permalink / raw)
To: linux-arm-kernel
Remove unused #defines.
Signed-off-by: Sven Schmitt <sven.schmitt@mixed-mode.de>
---
drivers/soc/imx/gpc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 5126185e68c6..35cc1d2dc4d5 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -24,15 +24,11 @@
#define GPC_PGC_CTRL_OFFS 0x0
#define GPC_PGC_PUPSCR_OFFS 0x4
#define GPC_PGC_PDNSCR_OFFS 0x8
-#define GPC_PGC_SW2ISO_SHIFT 0x8
-#define GPC_PGC_SW_SHIFT 0x0
#define GPC_PGC_PCI_PDN 0x200
#define GPC_PGC_PCI_SR 0x20c
#define GPC_PGC_GPU_PDN 0x260
-#define GPC_PGC_GPU_PUPSCR 0x264
-#define GPC_PGC_GPU_PDNSCR 0x268
#define GPC_PGC_GPU_SR 0x26c
#define GPC_PGC_DISP_PDN 0x240
--
2.17.1
^ permalink raw reply related
* [PATCH v3 1/3] soc: imx: gpc: fix PDN delay
From: Sven Schmitt @ 2018-07-24 9:46 UTC (permalink / raw)
To: linux-arm-kernel
imx6_pm_domain_power_off() reads iso and iso2sw from GPC_PGC_PUPSCR_OFFS
which stores the power up delays.
So use GPC_PGC_PDNSCR_OFFS for the correct delays.
Signed-off-by: Sven Schmitt <sven.schmitt@mixed-mode.de>
---
drivers/soc/imx/gpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 0097a939487f..5126185e68c6 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -73,7 +73,7 @@ static int imx6_pm_domain_power_off(struct generic_pm_domain *genpd)
return -EBUSY;
/* Read ISO and ISO2SW power down delays */
- regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
+ regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PDNSCR_OFFS, &val);
iso = val & 0x3f;
iso2sw = (val >> 8) & 0x3f;
--
2.17.1
^ permalink raw reply related
* [PATCH v3 0/3] soc: imx: gpc: cleanups
From: Sven Schmitt @ 2018-07-24 9:46 UTC (permalink / raw)
To: linux-arm-kernel
This patch series fixes the power down delay in gpc.c
and improves readability.
Changes in v3:
* rebased to 4.18
* split up patch into 3 parts
Changes in v2:
* dropped cntr_pup_bit
Sven Schmitt (3):
soc: imx: gpc: fix PDN delay
soc: imx: gpc: clean up
soc: imx: gpc: use GPC_PGC_DOMAIN_* indexes
drivers/soc/imx/gpc.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
--
2.17.1
^ permalink raw reply
* [U-Boot] ext4: massive corruption with ext4write
From: Marek Vasut @ 2018-07-24 9:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <2864381.rCmOtbzTCc@awilliams-suse>
On 07/24/2018 08:25 AM, Aaron Williams wrote:
> On Monday, July 23, 2018 11:15:59 PM PDT Aaron Williams wrote:
>> External Email
>>
>> Hi all,
>>
>> It looks like after a certain amount of data has been written that all hell
>> breaks loose with the ext4 filesystem.
>>
>> In my case, I have the following files on a 64G USB thumb drive with two
>> partitions, a small FAT partition with the rest of the space dedicated to
>> ext4
> created using mkfs.ext4 /dev/sdg2
>>
>> total 477632
>> -rwxr-xr-x 1 root root 152777216 Jul 23 18:11 Image
>> drwx------ 2 root root 16384 Jul 23 18:10 lost+found
>> -rwxr-xr-x 1 root root 90706976 Dec 31 1969 test.64
>> -rwxr-xr-x 1 root root 152777216 Dec 31 1969 test.img
>> -rwxr-xr-x 1 root root 50 Dec 31 1969 test.txt
>> -rwxr-xr-x 1 root root 1841408 Jul 23 18:12 u-boot-octeon_ebb7304.bin
>> -rwxr-xr-x 1 root root 90706976 Jul 23 18:11 vmlinux.64
>>
>> Everything is fine until I wrote the file test.64, which is basically a
>> copy
> of vmlinux.64.
>>
>> The first few files were written using my host Linux system, namely Image,
>> u-
> boot-octeon_ebb7304.bin and vmlinux.64.
>>
>> From within U-Boot I performed the following commands:
>>
>> # ext4load usb 0:2 $loadaddr Image
>> # ext4write usb 0:2 $fileaddr /test.img $filesize
>> # tftpboot $loadaddr test.txt
>> # ext4write usb 0:2 $fileaddr /test.txt $filesize
>> # ext4load usb 0:2 $loadaddr vmlinux.64
>> # ext4write usb 0:2 $fileaddr /test.64 $filesize
>>
>> Everything is fine on the drive until I write test.64. At this point, I get
>> a
> huge list of errors:
>>
>> # fsck.ext4 -v -n /dev/sdg2
>> e2fsck 1.42.11 (09-Jul-2014)
>> Group descriptor 0 has invalid unused inodes count 57374. Fix? no
>>
>> /dev/sdg2 contains a file system with errors, check forced.
>> Pass 1: Checking inodes, blocks, and sizes
>> Deleted inode 130913 has zero dtime. Fix? no
>>
>> Inode 130915 is in use, but has dtime set. Fix? no
>>
>> Inode 130915 has imagic flag set. Clear? no
>>
>> Inode 130915 has a extra size (8223) which is invalid
>> Fix? no
>>
>> Inode 130916 is in use, but has dtime set. Fix? no
>>
>> Inode 130916 has imagic flag set. Clear? no
>>
>> Inode 130916 has a extra size (8223) which is invalid
>> Fix? no
>>
>> ...
>> Illegal block #11 (2435760161) in inode 131070. IGNORED.
>> Illegal indirect block (4026556192) in inode 131070. IGNORED.
>> Illegal double indirect block (2433138721) in inode 131070. IGNORED.
>> Illegal triple indirect block (2434195456) in inode 131070. IGNORED.
>> Error while iterating over blocks in inode 131070: Illegal triply indirect
>> block found
>>
>>
>> and many many more errors.
>>
>> Note that I am using the very latest ext4 code from the master branch.
>> This
> is not a USB problem because I can reproduce this problem with an SD
>> card. This problem also occurs on two different platforms, one being
>> aarch64 little endian and the other being MIPS64 big endian. The
>> filesystem code is identical since the latest code has been backported to
>> our older MIPS bootloader.
>>
>> My guess is that all hell is breaking loose when a file spans multiple
>> block
> groups.
>>
>> -Aaron Williams
>>
>> On Thursday, July 19, 2018 7:35:46 PM PDT Aaron Williams wrote:
>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I am sometimes seeing issues when using ext4write where fsck later
>>> complains
>>
>> that the group descriptor has an invalid number of unused
>>
>>> inodes. Is this a known problem?
>>>
>>>
>>>
>>> Also, I think the assert(offset == sizeof(*desc)); in
>>> ext4fs_checksum_update()
>>
>> is invalid since with ext4 the descriptor is
>>
>>> larger than the offset. When debugging was enabled I'd always hit this
>>> assert.
>>>
>>>
>>>
>>> Also, in ext4fs_write, the debug statement should say blocks and not
>>> bytes.
>>
>>>
>>>
>>> -Aaron
>>>
>>>
>>>
>>> --
>>> Aaron Williams
>>> Senior Software Engineer
>>> Cavium, Inc.
>>> (408) 943-7198 (510) 789-8988 (cell)
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>
>>
>> --
>> Aaron Williams
>> Senior Software Engineer
>> Cavium, Inc.
>> (408) 943-7198 (510) 789-8988 (cell)
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>
> Here is the output after the write operation from fsck.ext4 -v /dev/sdg2
>
> fsck.ext4 -v /dev/sdg2
> e2fsck 1.42.11 (09-Jul-2014)
> Group descriptor 0 has invalid unused inodes count 57374. Fix<y>? yes
> Pass 1: Checking inodes, blocks, and sizes
>
> Running additional passes to resolve blocks claimed by more than one inode...
> Pass 1B: Rescanning for multiply-claimed blocks
> Multiply-claimed block(s) in inode 7: 98307 98308 98309 98310 98311 98312
> 98313 98314 98315 98316 98317 98318 98319 98320 98321 98322 98323 98324 98325
> 98326 98327 98328 98329 98330 98331 98332 98333 98334 98335 98336 98337 98338
> 98339 98340 98341 98342 98343 98344 98345 98346 98347 98348 98349 98350 98351
> 98352 98353 98354 98355 98356 98357 98358 98359 98360 98361 98362 98363 98364
> 98365 98366 98367 98368 98369 98370 98371 98372 98373 98374 98375 98376 98377
> 98378 98379 98380 98381 98382 98383 98384 98385 98386 98387 98388 98389 98390
> 98391 98392 98393 98394 98395 98396 98397 98398 98399 98400 98401 98402 98403
> 98404 98405 98406 98407 98408 98409 98410 98411 98412 98413 98414 98415 98416
> 98417 98418 98419 98420 98421 98422 98423 98424 98425 98426 98427 98428 98429
> 98430 98431 98432 98433 98434 98435 98436 98437 98438 98439 98440 98441 98442
> 98443 98444 98445 98446 98447 98448 98449 98450 98451 98452 98453 98454 98455
> 98456 98457 98458 98459 98460 98461 98462 98463 98464 98465 98466 98467 98468
> 98469 98470 98471 98472 98473 98474 98475 98476 98477 98478 98479 98480 98481
> 98482 98483 98484 98485 98486 98487 98488 98489 98490 98491 98492 98493 98494
> 98495 98496 98497 98498 98499 98500 98501 98502 98503 98504 98505 98506 98507
> 98508 98509 98510 98511 98512 98513 98514 98515 98516 98517 98518 98519 98520
> 98521 98522 98523 98524 98525 98526 98527 98528 98529 98530 98531 98532 98533
> 98534 98535 98536 98537 98538 98539 98540 98541 98542 98543 98544 98545 98546
> 98547 98548 98549 98550 98551 98552 98553 98554 98555 98556 98557 98558 98559
> 98560 98561 98562 98563 98564 98565 98566 98567 98568 98569 98570 98571 98572
> 98573 98574 98575 98576 98577 98578 98579 98580 98581 98582 98583 98584 98585
> 98586 98587 98588 98589 98590 98591 98592 98593 98594 98595 98596 98597 98598
> 98599 98600 98601 98602 98603 98604 98605 98606 98607 98608 98609 98610 98611
> 98612 98613 98614 98615 98616 98617 98618 98619 98620 98621 98622 98623 98624
> 98625 98626 98627 98628 98629 98630 98631 98632 98633 98634 98635 98636 98637
> 98638 98639 98640 98641 98642 98643 98644 98645 98646 98647 98648 98649 98650
> 98651 98652 98653 98654 98655 98656 98657 98658 98659 98660 98661 98662 98663
> 98664 98665 98666 98667 98668 98669 98670 98671 98672 98673 98674 98675 98676
> 98677 98678 98679 98680 98681 98682 98683 98684 98685 98686 98687 98688 98689
> 98690 98691 98692 98693 98694 98695 98696 98697 98698 98699 98700 98701 98702
> 98703 98704 98705 98706 98707 98708 98709 98710 98711 98712 98713 98714 98715
> 98716 98717 98718 98719 98720 98721 98722 98723 98724 98725 98726 98727 98728
> 98729 98730 98731 98732 98733 98734 98735 98736 98737 98738 98739 98740 98741
> 98742 98743 98744 98745 98746 98747 98748 98749 98750 98751 98752 98753 98754
> 98755 98756 98757 98758 98759 98760 98761 98762 98763 98764 98765 98766 98767
> 98768 98769 98770 98771 98772 98773 98774 98775 98776 98777 98778 98779 98780
> 98781 98782 98783 98784 98785 98786 98787 98788 98789 98790 98791 98792 98793
> 98794 98795 98796 98797 98798 98799 98800 98801 98802 98803 98804 98805 98806
> 98807 98808 98809 98810 98811 98812 98813 98814 98815 98816 98817 98818 98819
> 98820 98821 98822 98823 98824 98825 98826 98827 98828 98829 98830 98831 98832
> 98833 98834 98835 98836 98837 98838 98839 98840 98841 98842 98843 98844 98845
> 98846 98847 98848 98849 98850 98851 98852 98853 98854 98855 98856 98857 98858
> 98859 98860 98861 98862 98863 98864 98865 98866 98867 98868 98869 98870 98871
> 98872 98873 98874 98875 98876 98877 98878 98879 98880 98881 98882 98883 98884
> 98885 98886 98887 98888 98889 98890 98891 98892 98893 98894 98895 98896 98897
> 98898 98899 98900 98901 98902 98903 98904 98905 98906 98907 98908 98909 98910
> 98911 98912 98913 98914 98915 98916 98917 98918 98919 98920 98921 98922 98923
> 98924 98925 98926 98927 98928 98929 98930 98931 98932 98933 98934 98935 98936
> 98937 98938 98939 98940 98941 98942 98943 98944 98945 98946 98947 98948 98949
> 98950 98951 98952 98953 98954 98955 98956 98957 98958 98959 98960 98961 98962
> 98963 98964 98965 98966 98967 98968 98969 98970 98971 98972 98973 98974 98975
> 98976 98977 98978 98979 98980 98981 98982 98983 98984 98985 98986 98987 98988
> 98989 98990 98991 98992 98993 98994 98995 98996 98997 98998 98999 99000 99001
> 99002 99003 99004 99005 99006 99007 99008 99009 99010 99011 99012 99013 99014
> 99015 99016 99017 99018 99019 99020 99021 99022 99023 99024 99025 99026 99027
> 99028 99029 99030 99031 99032 99033 99034 99035 99036 99037 99038 99039 99040
> 99041 99042 99043 99044 99045 99046 99047 99048 99049 99050 99051 99052 99053
> 99054 99055 99056 99057 99058 99059 99060 99061 99062 99063 99064 99065 99066
> 99067 99068 99069 99070 99071 99072 99073 99074 99075 99076 99077 99078 99079
> 99080 99081 99082 99083 99084 99085 99086 99087 99088 99089 99090 99091 99092
> 99093 99094 99095 99096 99097 99098 99099 99100 99101 99102 99103 99104 99105
> 99106 99107 99108 99109 99110 99111 99112 99113 99114 99115 99116 99117 99118
> 99119 99120 99121 99122 99123 99124 99125 99126 99127 99128 99129 99130 99131
> 99132 99133 99134 99135 99136 99137 99138 99139 99140 99141 99142 99143 99144
> 99145 99146 99147 99148 99149 99150 99151 99152 99153 99154 99155 99156 99157
> 99158 99159 99160 99161 99162 99163 99164 99165 99166 99167 99168 99169 99170
> 99171 99172 99173 99174 99175 99176 99177 99178 99179 99180 99181 99182 99183
> 99184 99185 99186 99187 99188 99189 99190 99191 99192 99193 99194 99195 99196
> 99197 99198 99199 99200 99201 99202 99203 99204 99205 99206 99207 99208 99209
> 99210 99211 99212 99213 99214 99215 99216 99217 99218 99219 99220 99221 99222
> 99223 99224 99225 99226 99227 99228 99229 99230 99231 99232 99233 99234 99235
> 99236 99237 99238 99239 99240 99241 99242 99243 99244 99245 99246 99247 99248
> 99249 99250 99251 99252 99253 99254 99255 99256 99257 99258 99259 99260 99261
> 99262 99263 99264 99265 99266 99267 99268 99269 99270 99271 99272 99273 99274
> 99275 99276 99277 99278 99279 99280 99281 99282 99283 99284 99285 99286 99287
> 99288 99289 99290 99291 99292 99293 99294 99295 99296 99297 99298 99299 99300
> 99301 99302 99303 99304 99305 99306 99307 99308 99309 99310 99311 99312 99313
> 99314 99315 99316 99317 99318 99319 99320 99321 99322 99323 99324 99325 99326
> 99327 99328
> Multiply-claimed block(s) in inode 15: 98304 98305 98306 98307 98308 98309
> 98310 98311 98312 98313 98314 98315 98316 98317 98318 98319 98320 98321 98322
> 98323 98324 98325 98326 98327 98328 98329 98330 98331 98332 98333 98334 98335
> 98336 98337 98338 98339 98340 98341 98342 98343 98344 98345 98346 98347 98348
> 98349 98350 98351 98352 98353 98354 98355 98356 98357 98358 98359 98360 98361
> 98362 98363 98364 98365 98366 98367 98368 98369 98370 98371 98372 98373 98374
> 98375 98376 98377 98378 98379 98380 98381 98382 98383 98384 98385 98386 98387
> 98388 98389 98390 98391 98392 98393 98394 98395 98396 98397 98398 98399 98400
> 98401 98402 98403 98404 98405 98406 98407 98408 98409 98410 98411 98412 98413
> 98414 98415 98416 98417 98418 98419 98420 98421 98422 98423 98424 98425 98426
> 98427 98428 98429 98430 98431 98432 98433 98434 98435 98436 98437 98438 98439
> 98440 98441 98442 98443 98444 98445 98446 98447 98448 98449 98450 98451 98452
> 98453 98454 98455 98456 98457 98458 98459 98460 98461 98462 98463 98464 98465
> 98466 98467 98468 98469 98470 98471 98472 98473 98474 98475 98476 98477 98478
> 98479 98480 98481 98482 98483 98484 98485 98486 98487 98488 98489 98490 98491
> 98492 98493 98494 98495 98496 98497 98498 98499 98500 98501 98502 98503 98504
> 98505 98506 98507 98508 98509 98510 98511 98512 98513 98514 98515 98516 98517
> 98518 98519 98520 98521 98522 98523 98524 98525 98526 98527 98528 98529 98530
> 98531 98532 98533 98534 98535 98536 98537 98538 98539 98540 98541 98542 98543
> 98544 98545 98546 98547 98548 98549 98550 98551 98552 98553 98554 98555 98556
> 98557 98558 98559 98560 98561 98562 98563 98564 98565 98566 98567 98568 98569
> 98570 98571 98572 98573 98574 98575 98576 98577 98578 98579 98580 98581 98582
> 98583 98584 98585 98586 98587 98588 98589 98590 98591 98592 98593 98594 98595
> 98596 98597 98598 98599 98600 98601 98602 98603 98604 98605 98606 98607 98608
> 98609 98610 98611 98612 98613 98614 98615 98616 98617 98618 98619 98620 98621
> 98622 98623 98624 98625 98626 98627 98628 98629 98630 98631 98632 98633 98634
> 98635 98636 98637 98638 98639 98640 98641 98642 98643 98644 98645 98646 98647
> 98648 98649 98650 98651 98652 98653 98654 98655 98656 98657 98658 98659 98660
> 98661 98662 98663 98664 98665 98666 98667 98668 98669 98670 98671 98672 98673
> 98674 98675 98676 98677 98678 98679 98680 98681 98682 98683 98684 98685 98686
> 98687 98688 98689 98690 98691 98692 98693 98694 98695 98696 98697 98698 98699
> 98700 98701 98702 98703 98704 98705 98706 98707 98708 98709 98710 98711 98712
> 98713 98714 98715 98716 98717 98718 98719 98720 98721 98722 98723 98724 98725
> 98726 98727 98728 98729 98730 98731 98732 98733 98734 98735 98736 98737 98738
> 98739 98740 98741 98742 98743 98744 98745 98746 98747 98748 98749 98750 98751
> 98752 98753 98754 98755 98756 98757 98758 98759 98760 98761 98762 98763 98764
> 98765 98766 98767 98768 98769 98770 98771 98772 98773 98774 98775 98776 98777
> 98778 98779 98780 98781 98782 98783 98784 98785 98786 98787 98788 98789 98790
> 98791 98792 98793 98794 98795 98796 98797 98798 98799 98800 98801 98802 98803
> 98804 98805 98806 98807 98808 98809 98810 98811 98812 98813 98814 98815 98816
> 98817 98818 98819 98820 98821 98822 98823 98824 98825 98826 98827 98828 98829
> 98830 98831 98832 98833 98834 98835 98836 98837 98838 98839 98840 98841 98842
> 98843 98844 98845 98846 98847 98848 98849 98850 98851 98852 98853 98854 98855
> 98856 98857 98858 98859 98860 98861 98862 98863 98864 98865 98866 98867 98868
> 98869 98870 98871 98872 98873 98874 98875 98876 98877 98878 98879 98880 98881
> 98882 98883 98884 98885 98886 98887 98888 98889 98890 98891 98892 98893 98894
> 98895 98896 98897 98898 98899 98900 98901 98902 98903 98904 98905 98906 98907
> 98908 98909 98910 98911 98912 98913 98914 98915 98916 98917 98918 98919 98920
> 98921 98922 98923 98924 98925 98926 98927 98928 98929 98930 98931 98932 98933
> 98934 98935 98936 98937 98938 98939 98940 98941 98942 98943 98944 98945 98946
> 98947 98948 98949 98950 98951 98952 98953 98954 98955 98956 98957 98958 98959
> 98960 98961 98962 98963 98964 98965 98966 98967 98968 98969 98970 98971 98972
> 98973 98974 98975 98976 98977 98978 98979 98980 98981 98982 98983 98984 98985
> 98986 98987 98988 98989 98990 98991 98992 98993 98994 98995 98996 98997 98998
> 98999 99000 99001 99002 99003 99004 99005 99006 99007 99008 99009 99010 99011
> 99012 99013 99014 99015 99016 99017 99018 99019 99020 99021 99022 99023 99024
> 99025 99026 99027 99028 99029 99030 99031 99032 99033 99034 99035 99036 99037
> 99038 99039 99040 99041 99042 99043 99044 99045 99046 99047 99048 99049 99050
> 99051 99052 99053 99054 99055 99056 99057 99058 99059 99060 99061 99062 99063
> 99064 99065 99066 99067 99068 99069 99070 99071 99072 99073 99074 99075 99076
> 99077 99078 99079 99080 99081 99082 99083 99084 99085 99086 99087 99088 99089
> 99090 99091 99092 99093 99094 99095 99096 99097 99098 99099 99100 99101 99102
> 99103 99104 99105 99106 99107 99108 99109 99110 99111 99112 99113 99114 99115
> 99116 99117 99118 99119 99120 99121 99122 99123 99124 99125 99126 99127 99128
> 99129 99130 99131 99132 99133 99134 99135 99136 99137 99138 99139 99140 99141
> 99142 99143 99144 99145 99146 99147 99148 99149 99150 99151 99152 99153 99154
> 99155 99156 99157 99158 99159 99160 99161 99162 99163 99164 99165 99166 99167
> 99168 99169 99170 99171 99172 99173 99174 99175 99176 99177 99178 99179 99180
> 99181 99182 99183 99184 99185 99186 99187 99188 99189 99190 99191 99192 99193
> 99194 99195 99196 99197 99198 99199 99200 99201 99202 99203 99204 99205 99206
> 99207 99208 99209 99210 99211 99212 99213 99214 99215 99216 99217 99218 99219
> 99220 99221 99222 99223 99224 99225 99226 99227 99228 99229 99230 99231 99232
> 99233 99234 99235 99236 99237 99238 99239 99240 99241 99242 99243 99244 99245
> 99246 99247 99248 99249 99250 99251 99252 99253 99254 99255 99256 99257 99258
> 99259 99260 99261 99262 99263 99264 99265 99266 99267 99268 99269 99270 99271
> 99272 99273 99274 99275 99276 99277 99278 99279 99280 99281 99282 99283 99284
> 99285 99286 99287 99288 99289 99290 99291 99292 99293 99294 99295 99296 99297
> 99298 99299 99300 99301 99302 99303 99304 99305 99306 99307 99308 99309 99310
> 99311 99312 99313 99314 99315 99316 99317 99318 99319 99320 99321 99322 99323
> 99324 99325 99326 99327 99328
> Pass 1C: Scanning directories for inodes with multiply-claimed blocks
> Pass 1D: Reconciling multiply-claimed blocks
> (There are 1 inodes containing multiply-claimed blocks.)
>
> File /test.img (inode #15, mod time Wed Dec 31 16:00:00 1969)
> has 1025 multiply-claimed block(s), shared with 2 file(s):
> <filesystem metadata>
> <The group descriptor inode> (inode #7, mod time Mon Jul 23 18:10:08
> 2018)
> Clone multiply-claimed blocks<y>?
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
>
> /dev/sdg2: ***** FILE SYSTEM WAS MODIFIED *****
>
> 17 inodes used (0.00%, out of 1913184)
> 0 non-contiguous files (0.0%)
> 0 non-contiguous directories (0.0%)
> # of inodes with ind/dind/tind blocks: 2/2/0
> Extent depth histogram: 6
> 283495 blocks used (3.71%, out of 7640576)
> 0 bad blocks
> 1 large file
>
> 6 regular files
> 2 directories
> 0 character device files
> 0 block device files
> 0 fifos
> 0 links
> 0 symbolic links (0 fast symbolic links)
> 0 sockets
> ------------
> 8 files
I don't think mainline U-Boot supports octeon, but I might be wrong.
Which U-Boot version is this ? Can you replicate this on ie. sandbox?
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: refs/notes/amlog problems, was Re: [PATCH v3 01/20] linear-assignment: a function to solve least-cost assignment problems
From: Jeff King @ 2018-07-24 9:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Schindelin via GitGitGadget, git
In-Reply-To: <xmqqlga11jwp.fsf@gitster-ct.c.googlers.com>
On Mon, Jul 23, 2018 at 06:50:46PM -0700, Junio C Hamano wrote:
> Side Note: there are a few workflow elements I do want to
> keep using but they currently *lose* the mapping info. An
> obvious one is
>
> $ git checkout -b to/pic master &&
> ... review in MUA and then ...
> $ git am -s mbox &&
> ... review in tree, attempt to build, tweak, etc.
> $ git format-patch --stdout master..to/pic >P &&
> $ edit P &&
> $ git reset --hard master &&
> $ git am P
>
> which is far more versatile and efficient when doing certain
> transformations on the series than running "rebase -i" and
> reopening and editing the target files of the patches one by
> one in each step. But because format-patch does not
> generate Message-Id header of the original one out of the
> commit, the post-applypatch hook run by "am" at the end of
> the steps would not have a chance to record that for the
> newly created commit.
>
> For this one, I think I can use "format-patch --notes=amlog"
> to produce the patch file and then teach post-applypatch
> script to pay attention to the Notes annotation without
> changing anything else to record the message id of the
> original.
Yes. I wonder if it would make sense to teach format-patch/am a
micro-format to automatically handle this case. I.e., some
machine-readable way of passing the notes in the email message.
Of course it's easy to design a format that covers the relatively
restricted form of these amlog notes, and much harder to cover the
general case.
> Other workflow elements that lose the notes need
> to be identified and either a fix implemented or a
> workaround found for each of them. For example, I suspect
> there is no workaround for "cherry-pick" and it would take a
> real fix.
I think the existing notes.rewriteRef is probably a good match here. I
can definitely think of notes you wouldn't want to cherry-pick, but I'm
having trouble coming up with an example that should survive a rebase
but not a cherry-pick.
> And these (incomplete) reverse mapping entries get in the way to
> maintain and correct the forward mapping. When a commit that got
> unreachable gets expired, I want "git notes prune" to remove notes
> on them, and I do not want to even think about what should happen to
> the entries in the notes tree that abuse the mechanism to map blobs
> that are otherwise *not* even reachable from the main history.
Right, I think the notes tree is a poor distribution method for that
reason.
> > Though personally, I do not know if there is much point in pushing it
> > out, given that receivers can reverse the mapping themselves.
>
> Before this thread, I was planning to construct and publish the
> reverse mapping at the end of the day, but do so on a separate notes
> ref (see above---the hacky abuse gets in the way of maintaining and
> debugging the forward mapping, but a separate notes-ref that only
> contains hacks is less worrysome). But I have changed my mind and
> decided not to generate or publish one. It is sort of similar to
> the way the pack .idx is constructed only by the receiver [*1*].
Yes, the pack .idx was the same mental model I had when writing my
earlier message.
> > Or is there some argument that there is information in the reverse map
> > that _cannot_ be generated from the forward map?
>
> I know there is no information loss (after all I was the only one
> who ran that experimental hack), but there is one objection that is
> still possible, even though I admit that is a weak argument.
I wondered if you might have a case like this (building as we go):
- message-id M becomes commit X
- we write the forward map X->M
- we write the reverse map M->X
- during a rewrite (e.g., --amend), commit X becomes commit Y
- we write the forward map Y->M
- we write the reverse map M->Y
The difference between that result and an inverted map created at the
end is that we know that M->Y is the final result. Whereas by looking at
the inverted map, we do not know which of M->X and M->Y is correct. In
fact they are _both_ correct. But only one of X and Y would eventually
get merged (both may make it into the repo's of people fetching from you
if we imagine that X is on "pu" and you push between the two steps).
So I think the inverted mapping is not actually one-to-one, and in
either case you'd want to retain all possible matches (pruning only when
a commit is eventually dropped from the forward mapping, which rewritten
things from "pu" would eventually do). And in that case it does not
matter if you generate it incrementally or all at once.
> If a plumbing "diff-{files,tree,index}" family had a sibling
> "diff-notes" to compare two notes-shaped trees while pretending that
> the object-name fan-out did not exist (i.e. instead, the trees being
> compared is without a subtree and full of 40-hex filenames), then it
> would be less cumbersome to incrementally update the reverse mapping
> by reading forward mapping with something like:
>
> git diff-notes --raw amlog@{1} amlog
>
> to learn the commits whose notes have changed. But without such a
> plumbing, it is cumbersome to do so correctly. "git diff-tree -r"
> could serve as a rough substitute, until the note tree grows and get
> rebalanced by reorganizing the fan-out, and on the day it happens
> the reverse mapper needs to read and discard ghost changes that are
> only due to tree reorganizing [*2*].
Yeah. My "log" hackery was trying to do that incremental comparison, but
it did not handle the multiple-commit case (nor did it handle
deletions). I agree an end-point diff is sufficient (and more
efficient).
-Peff
^ permalink raw reply
* Re: [PATCH] mmc: renesas_sdhi: Add r8a77990 support
From: Wolfram Sang @ 2018-07-24 8:39 UTC (permalink / raw)
To: Simon Horman
Cc: Wolfram Sang, linux-mmc, linux-renesas-soc, Niklas Söderlund
In-Reply-To: <20180723161719.zlalebcsp6uph3dp@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
> 8 tap support is included in the following patch which was accepted
> for inclusion in upstream (search for 4TAP):
>
> 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
Wow, sorry, I missed that :( I thought there were only 8 TAP preparations
in there. Cool, will have a look...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] arm64: fix ACPI dependencies
From: Will Deacon @ 2018-07-24 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0jTowUW6myVf0B2Gyq0ZA2ATqPNnaeOgFS01ce8A=FBpA@mail.gmail.com>
On Tue, Jul 24, 2018 at 11:37:10AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Kconfig reports a warning on x86 builds after the ARM64 dependency
> > was added.
> >
> > drivers/acpi/Kconfig:6:error: recursive dependency detected!
> > drivers/acpi/Kconfig:6: symbol ACPI depends on EFI
> >
> > This rephrases the dependency to keep the ARM64 details out of the
> > shared Kconfig file, so Kconfig no longer gets confused by it.
> >
> > Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/Kconfig | 1 +
> > drivers/acpi/Kconfig | 5 ++++-
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index cdcaa6a798b2..2f987a938405 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1267,6 +1267,7 @@ config EFI
> > bool "UEFI runtime support"
> > depends on OF && !CPU_BIG_ENDIAN
> > depends on KERNEL_MODE_NEON
> > + select ARCH_SUPPORTS_ACPI
> > select LIBFDT
> > select UCS2_STRING
> > select EFI_PARAMS_FROM_FDT
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index a8da730fabc6..0cda51c5d433 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -6,7 +6,7 @@
> > menuconfig ACPI
> > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > depends on !IA64_HP_SIM
> > - depends on IA64 || X86 || (ARM64 && EFI)
> > + depends on IA64 || X86 || ARCH_SUPPORTS_ACPI
>
> That doesn't look particularly consistent to me.
>
> It should be either "depends on ARCH_SUPPORTS_ACPI" alone or mention
> ARM64 somehow IMO
How about something along the lines of what Ard suggested? Untested diff
below.
Will
--->8
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 303809c6..ec78d4d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -56,6 +56,7 @@ config ARM64
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_SUPPORTS_ACPI
select ARCH_SUPPORTS_MEMORY_FAILURE
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 50000 || CC_IS_CLANG
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 15ab1da..198db2d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -3,10 +3,12 @@
# ACPI Configuration
#
+config ARCH_SUPPORTS_ACPI
+ def_bool (IA64 && !IA64_HP_SIM) || X86
+
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
- depends on !IA64_HP_SIM
- depends on IA64 || X86 || (ARM64 && EFI)
+ depends on ARCH_SUPPORTS_ACPI
depends on PCI
select PNP
default y if (IA64 || X86)
^ permalink raw reply related
* Re: [PATCH] arm64: fix ACPI dependencies
From: Will Deacon @ 2018-07-24 9:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Arnd Bergmann, Catalin Marinas, Rafael J. Wysocki, Len Brown,
AKASHI Takahiro, Ard Biesheuvel, Mark Rutland, Marc Zyngier,
Linux ARM, Linux Kernel Mailing List, ACPI Devel Maling List
In-Reply-To: <CAJZ5v0jTowUW6myVf0B2Gyq0ZA2ATqPNnaeOgFS01ce8A=FBpA@mail.gmail.com>
On Tue, Jul 24, 2018 at 11:37:10AM +0200, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 11:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Kconfig reports a warning on x86 builds after the ARM64 dependency
> > was added.
> >
> > drivers/acpi/Kconfig:6:error: recursive dependency detected!
> > drivers/acpi/Kconfig:6: symbol ACPI depends on EFI
> >
> > This rephrases the dependency to keep the ARM64 details out of the
> > shared Kconfig file, so Kconfig no longer gets confused by it.
> >
> > Fixes: 5bcd44083a08 ("drivers: acpi: add dependency of EFI for arm64")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm64/Kconfig | 1 +
> > drivers/acpi/Kconfig | 5 ++++-
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index cdcaa6a798b2..2f987a938405 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1267,6 +1267,7 @@ config EFI
> > bool "UEFI runtime support"
> > depends on OF && !CPU_BIG_ENDIAN
> > depends on KERNEL_MODE_NEON
> > + select ARCH_SUPPORTS_ACPI
> > select LIBFDT
> > select UCS2_STRING
> > select EFI_PARAMS_FROM_FDT
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index a8da730fabc6..0cda51c5d433 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -6,7 +6,7 @@
> > menuconfig ACPI
> > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > depends on !IA64_HP_SIM
> > - depends on IA64 || X86 || (ARM64 && EFI)
> > + depends on IA64 || X86 || ARCH_SUPPORTS_ACPI
>
> That doesn't look particularly consistent to me.
>
> It should be either "depends on ARCH_SUPPORTS_ACPI" alone or mention
> ARM64 somehow IMO
How about something along the lines of what Ard suggested? Untested diff
below.
Will
--->8
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 303809c6..ec78d4d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -56,6 +56,7 @@ config ARM64
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_SUPPORTS_ACPI
select ARCH_SUPPORTS_MEMORY_FAILURE
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 50000 || CC_IS_CLANG
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 15ab1da..198db2d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -3,10 +3,12 @@
# ACPI Configuration
#
+config ARCH_SUPPORTS_ACPI
+ def_bool (IA64 && !IA64_HP_SIM) || X86
+
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
- depends on !IA64_HP_SIM
- depends on IA64 || X86 || (ARM64 && EFI)
+ depends on ARCH_SUPPORTS_ACPI
depends on PCI
select PNP
default y if (IA64 || X86)
^ permalink raw reply related
* Re: automation: Creating a patchwork instance to improve pre-commit build testing
From: Wei Liu @ 2018-07-24 9:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Lars Kurth, Iurii Artemenko, Wei Liu, Doug Goldstein,
Minios-devel, committers, xen-devel, Matt Spencer
In-Reply-To: <5B56F2BB02000078001D7130@prv1-mh.provo.novell.com>
On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote:
> >>> On 24.07.18 at 11:24, <wei.liu2@citrix.com> wrote:
> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >> >>> On 23.07.18 at 18:40, <lars.kurth@citrix.com> wrote:
> >> > # How does this impact me?
> >> > The contribution workflow is *not* impacted by this change, but once up and
> >
> >> > running the following will happen once you post a patch or patch series to
> >> > xen-devel:
> >> > * Patchwork will take patch series from the mailing list and applies it
> >> > * CI/DC testing is triggered
> >> > * A test report will be sent as a mail to the patch or the series (aka the 00 patch of the series)
> >> >
> >> > This does mean though that series which do not build or show other issues,
> >> > will likely not be reviewed until the tests pass. This would lessen the
> >> > burden on reviewers, as they will know whether the code submitted builds on a
> >> > wide array of environments.
> >>
> >> So how are dependencies between series intended to be dealt with? It
> >> is not uncommon for someone to say "applies only on top of xyz". The
> >> implication of "will likely not be reviewed until the tests pass" seems
> >> unsuitable to me in such a case.
> >>
> >
> > We have been asking everyone to rebase to staging before posting a new
> > version for a long time. It is natural for the bot to assume that
> > everything should apply on top of staging. That would provide most value
> > to the community.
> >
> > For special cases like you just mention, we should aim to provide
> > mechanisms to manually appoint a branch to be tested.
>
> I'm afraid I disagree again: Tools used should not be dictated. I'm
> using quilt, not git for my work, and hence I don't maintain any
> branches anywhere.
Alright.
First, I don't think I said that only git would be supported.
Git is the most prevalent VCS nowadays, and most developers use it, so
it would make sense to support it first. If you want quilt, we can
certainly look into that. But I'm afraid if you don't say what you
specifically need, nothing can be done in that regard.
Second, it is up to individual whether they want to use a certain tool
or not. If you don't want to use this infrastructure for whatever
reason, that's OK. You're only missing out all the work in the community
has done, but you should be able to use your own workflow just fine.
Wei.
>
> Jan
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] firmware/shim : filter output files during Xen tree setup
From: Jan Beulich @ 2018-07-24 9:43 UTC (permalink / raw)
To: Christopher Clark; +Cc: Ian Jackson, Wei Liu, xen-devel
In-Reply-To: <1532121305-5253-1-git-send-email-christopher.w.clark@gmail.com>
>>> On 20.07.18 at 23:15, <christopher.w.clark@gmail.com> wrote:
> Exclude named output files from the Xen tree setup.
>
> The linkfarm.stamp content will differ between top level "make"
> and "make install" invocations, due to the introduction of these
> output files that are produced during the "make" build.
>
> Filter these out to prevent an unnecessary rebuild of the shim during
> "make install".
>
> Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
> ---
> tools/firmware/xen-dir/Makefile | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/firmware/xen-dir/Makefile
> b/tools/firmware/xen-dir/Makefile
> index 84648c3..e490dca 100644
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -11,6 +11,9 @@ D=xen-root
> LINK_DIRS=config xen
> LINK_FILES=Config.mk
>
> +# Files to exclude from the link farm
> +EXCLUDE_FILES=xen xen.gz xen-syms xen-syms.map efi.lds xen.lds mkelf32 mkreloc
What about xen.efi and all of its auxiliary files? What about other generated
files?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 1/1] iommu/arm-smmu: Add support to use Last level cache
From: Vivek Gautam @ 2018-07-24 9:43 UTC (permalink / raw)
To: Will Deacon
Cc: pdaly, linux-arm-msm, open list,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Linux ARM
In-Reply-To: <20180627163749.GA8729@arm.com>
Hi Will,
On Wed, Jun 27, 2018 at 10:07 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Vivek,
>
> On Tue, Jun 19, 2018 at 02:04:44PM +0530, Vivek Gautam wrote:
>> On Fri, Jun 15, 2018 at 10:22 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Jun 15, 2018 at 04:23:29PM +0530, Vivek Gautam wrote:
>> >> Qualcomm SoCs have an additional level of cache called as
>> >> System cache or Last level cache[1]. This cache sits right
>> >> before the DDR, and is tightly coupled with the memory
>> >> controller.
>> >> The cache is available to all the clients present in the
>> >> SoC system. The clients request their slices from this system
>> >> cache, make it active, and can then start using it. For these
>> >> clients with smmu, to start using the system cache for
>> >> dma buffers and related page tables [2], few of the memory
>> >> attributes need to be set accordingly.
>> >> This change makes the related memory Outer-Shareable, and
>> >> updates the MAIR with necessary protection.
>> >>
>> >> The MAIR attribute requirements are:
>> >> Inner Cacheablity = 0
>> >> Outer Cacheablity = 1, Write-Back Write Allocate
>> >> Outer Shareablity = 1
>> >
>> > Hmm, so is this cache coherent with the CPU or not?
>>
>> Thanks for reviewing.
>> Yes, this LLC is cache coherent with CPU, so we mark for Outer-cacheable.
>> The different masters such as GPU as able to allocated and activate a slice
>> in this Last Level Cache.
>
> What I mean is, for example, if the CPU writes some data using Normal, Inner
> Shareable, Inner/Outer Cacheable, Inner/Outer Write-back, Non-transient
> Read/Write-allocate and a device reads that data using your MAIR encoding
> above, is the device guaranteed to see the CPU writes after the CPU has
> executed a DSB instruction?
>
> I don't think so, because the ARM ARM would say that there's a mismatch on
> the Inner Cacheability attribute.
>
>> > Why don't normal
>> > non-cacheable mappings allocated in the LLC by default?
>>
>> Sorry, I couldn't fully understand your question here.
>> Few of the masters on qcom socs are not io-coherent, so for them
>> the IC has to be marked as 0.
>
> By IC you mean Inner Cacheability? In your MAIR encoding above, it is zero
> so I don't understand the problem. What goes wrong if non-coherent devices
> use your MAIR encoding for their DMA buffers?
>
>> But they are able to use the LLC with OC marked as 1.
>
> The issue here is that whatever attributes we put in the SMMU need to align
> with the attributes used by the CPU in order to avoid introducing mismatched
> aliases. Currently, we support three types of mapping in the SMMU:
>
> 1. DMA non-coherent (e.g. "dma-coherent" is not set on the device)
> Normal, Inner Shareable, Inner/Outer Non-Cacheable
>
> 2. DMA coherent (e.g. "dma-coherent" is set on the device) [IOMMU_CACHE]
> Normal, Inner Shareable, Inner/Outer Cacheable, Inner/Outer
> Write-back, Non-transient Read/Write-allocate
>
> 3. MMIO (e.g. MSI doorbell) [IOMMU_MMIO]
> Device-nGnRE (Outer Shareable)
>
> So either you override one of these types (I was suggesting (1)) or you need
> to create a new memory type, along with the infrastructure for it to be
> recognised on a per-device basis and used by the DMA API so that we don't
> get mismatched aliases on the CPU.
My apologies for delay in responding to this thread.
I have been digging and getting in touch with internal tech teams
to get more information on this. I will update as soon as I have enough
details.
Thanks.
Best regards
Vivek
>
> Will
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 1/1] iommu/arm-smmu: Add support to use Last level cache
From: Vivek Gautam @ 2018-07-24 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180627163749.GA8729@arm.com>
Hi Will,
On Wed, Jun 27, 2018 at 10:07 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Vivek,
>
> On Tue, Jun 19, 2018 at 02:04:44PM +0530, Vivek Gautam wrote:
>> On Fri, Jun 15, 2018 at 10:22 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Jun 15, 2018 at 04:23:29PM +0530, Vivek Gautam wrote:
>> >> Qualcomm SoCs have an additional level of cache called as
>> >> System cache or Last level cache[1]. This cache sits right
>> >> before the DDR, and is tightly coupled with the memory
>> >> controller.
>> >> The cache is available to all the clients present in the
>> >> SoC system. The clients request their slices from this system
>> >> cache, make it active, and can then start using it. For these
>> >> clients with smmu, to start using the system cache for
>> >> dma buffers and related page tables [2], few of the memory
>> >> attributes need to be set accordingly.
>> >> This change makes the related memory Outer-Shareable, and
>> >> updates the MAIR with necessary protection.
>> >>
>> >> The MAIR attribute requirements are:
>> >> Inner Cacheablity = 0
>> >> Outer Cacheablity = 1, Write-Back Write Allocate
>> >> Outer Shareablity = 1
>> >
>> > Hmm, so is this cache coherent with the CPU or not?
>>
>> Thanks for reviewing.
>> Yes, this LLC is cache coherent with CPU, so we mark for Outer-cacheable.
>> The different masters such as GPU as able to allocated and activate a slice
>> in this Last Level Cache.
>
> What I mean is, for example, if the CPU writes some data using Normal, Inner
> Shareable, Inner/Outer Cacheable, Inner/Outer Write-back, Non-transient
> Read/Write-allocate and a device reads that data using your MAIR encoding
> above, is the device guaranteed to see the CPU writes after the CPU has
> executed a DSB instruction?
>
> I don't think so, because the ARM ARM would say that there's a mismatch on
> the Inner Cacheability attribute.
>
>> > Why don't normal
>> > non-cacheable mappings allocated in the LLC by default?
>>
>> Sorry, I couldn't fully understand your question here.
>> Few of the masters on qcom socs are not io-coherent, so for them
>> the IC has to be marked as 0.
>
> By IC you mean Inner Cacheability? In your MAIR encoding above, it is zero
> so I don't understand the problem. What goes wrong if non-coherent devices
> use your MAIR encoding for their DMA buffers?
>
>> But they are able to use the LLC with OC marked as 1.
>
> The issue here is that whatever attributes we put in the SMMU need to align
> with the attributes used by the CPU in order to avoid introducing mismatched
> aliases. Currently, we support three types of mapping in the SMMU:
>
> 1. DMA non-coherent (e.g. "dma-coherent" is not set on the device)
> Normal, Inner Shareable, Inner/Outer Non-Cacheable
>
> 2. DMA coherent (e.g. "dma-coherent" is set on the device) [IOMMU_CACHE]
> Normal, Inner Shareable, Inner/Outer Cacheable, Inner/Outer
> Write-back, Non-transient Read/Write-allocate
>
> 3. MMIO (e.g. MSI doorbell) [IOMMU_MMIO]
> Device-nGnRE (Outer Shareable)
>
> So either you override one of these types (I was suggesting (1)) or you need
> to create a new memory type, along with the infrastructure for it to be
> recognised on a per-device basis and used by the DMA API so that we don't
> get mismatched aliases on the CPU.
My apologies for delay in responding to this thread.
I have been digging and getting in touch with internal tech teams
to get more information on this. I will update as soon as I have enough
details.
Thanks.
Best regards
Vivek
>
> Will
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 1/1] iommu/arm-smmu: Add support to use Last level cache
From: Vivek Gautam @ 2018-07-24 9:43 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-msm,
list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>, ,
open list, Linux ARM, pdaly-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <20180627163749.GA8729-5wv7dgnIgG8@public.gmane.org>
Hi Will,
On Wed, Jun 27, 2018 at 10:07 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi Vivek,
>
> On Tue, Jun 19, 2018 at 02:04:44PM +0530, Vivek Gautam wrote:
>> On Fri, Jun 15, 2018 at 10:22 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Fri, Jun 15, 2018 at 04:23:29PM +0530, Vivek Gautam wrote:
>> >> Qualcomm SoCs have an additional level of cache called as
>> >> System cache or Last level cache[1]. This cache sits right
>> >> before the DDR, and is tightly coupled with the memory
>> >> controller.
>> >> The cache is available to all the clients present in the
>> >> SoC system. The clients request their slices from this system
>> >> cache, make it active, and can then start using it. For these
>> >> clients with smmu, to start using the system cache for
>> >> dma buffers and related page tables [2], few of the memory
>> >> attributes need to be set accordingly.
>> >> This change makes the related memory Outer-Shareable, and
>> >> updates the MAIR with necessary protection.
>> >>
>> >> The MAIR attribute requirements are:
>> >> Inner Cacheablity = 0
>> >> Outer Cacheablity = 1, Write-Back Write Allocate
>> >> Outer Shareablity = 1
>> >
>> > Hmm, so is this cache coherent with the CPU or not?
>>
>> Thanks for reviewing.
>> Yes, this LLC is cache coherent with CPU, so we mark for Outer-cacheable.
>> The different masters such as GPU as able to allocated and activate a slice
>> in this Last Level Cache.
>
> What I mean is, for example, if the CPU writes some data using Normal, Inner
> Shareable, Inner/Outer Cacheable, Inner/Outer Write-back, Non-transient
> Read/Write-allocate and a device reads that data using your MAIR encoding
> above, is the device guaranteed to see the CPU writes after the CPU has
> executed a DSB instruction?
>
> I don't think so, because the ARM ARM would say that there's a mismatch on
> the Inner Cacheability attribute.
>
>> > Why don't normal
>> > non-cacheable mappings allocated in the LLC by default?
>>
>> Sorry, I couldn't fully understand your question here.
>> Few of the masters on qcom socs are not io-coherent, so for them
>> the IC has to be marked as 0.
>
> By IC you mean Inner Cacheability? In your MAIR encoding above, it is zero
> so I don't understand the problem. What goes wrong if non-coherent devices
> use your MAIR encoding for their DMA buffers?
>
>> But they are able to use the LLC with OC marked as 1.
>
> The issue here is that whatever attributes we put in the SMMU need to align
> with the attributes used by the CPU in order to avoid introducing mismatched
> aliases. Currently, we support three types of mapping in the SMMU:
>
> 1. DMA non-coherent (e.g. "dma-coherent" is not set on the device)
> Normal, Inner Shareable, Inner/Outer Non-Cacheable
>
> 2. DMA coherent (e.g. "dma-coherent" is set on the device) [IOMMU_CACHE]
> Normal, Inner Shareable, Inner/Outer Cacheable, Inner/Outer
> Write-back, Non-transient Read/Write-allocate
>
> 3. MMIO (e.g. MSI doorbell) [IOMMU_MMIO]
> Device-nGnRE (Outer Shareable)
>
> So either you override one of these types (I was suggesting (1)) or you need
> to create a new memory type, along with the infrastructure for it to be
> recognised on a per-device basis and used by the DMA API so that we don't
> get mismatched aliases on the CPU.
My apologies for delay in responding to this thread.
I have been digging and getting in touch with internal tech teams
to get more information on this. I will update as soon as I have enough
details.
Thanks.
Best regards
Vivek
>
> Will
> _______________________________________________
> iommu mailing list
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH net-next] net: remove redundant input checks in SIOCSIFTXQLEN case of dev_ifsioc
From: Tariq Toukan @ 2018-07-24 8:35 UTC (permalink / raw)
To: David Miller, xiyou.wangcong; +Cc: tariqt, netdev, eranbe
In-Reply-To: <20180723.140025.949946162106654052.davem@davemloft.net>
On 24/07/2018 12:00 AM, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Mon, 23 Jul 2018 13:37:22 -0700
>
>> On Sun, Jul 22, 2018 at 12:29 AM Tariq Toukan <tariqt@mellanox.com> wrote:
>>>
>>>
>>>
>>> On 19/07/2018 8:21 PM, Cong Wang wrote:
>>>> On Thu, Jul 19, 2018 at 7:50 AM Tariq Toukan <tariqt@mellanox.com> wrote:
>>>>> --- a/net/core/dev_ioctl.c
>>>>> +++ b/net/core/dev_ioctl.c
>>>>> @@ -282,14 +282,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
>>>>> return dev_mc_del_global(dev, ifr->ifr_hwaddr.sa_data);
>>>>>
>>>>> case SIOCSIFTXQLEN:
>>>>> - if (ifr->ifr_qlen < 0)
>>>>> - return -EINVAL;
>>>>
>>>> Are you sure we can remove this if check too?
>>>>
>>>> The other one is safe to remove.
>>>>
>>>
>>> Hmm, let's see:
>>> dev_change_tx_queue_len gets unsigned long new_len, any negative value
>>> passed is interpreted as a very large number, then we test:
>>> if (new_len != (unsigned int)new_len)
>>>
>>> This test returns true if range of unsigned long is larger than range of
>>> unsigned int. AFAIK these ranges are Arch dependent and there is no
>>> guarantee this holds.
>>
>> I am not sure either, you probably have to give it a test.
>> And at least, explain it in changelog if you still want to remove it.
>
> On 64-bit we will fail with -ERANGE. The 32-bit int ifr_qlen will be sign
> extended to 64-bits when it is passed into dev_change_tx_queue_len(). And
> then for negative values this test triggers:
>
> if (new_len != (unsigned int)new_len)
> return -ERANGE;
>
> because:
> if (0xffffffffWHATEVER != 0x00000000WHATEVER)
>
> On 32-bit the signed value will be accepted, changing behavior.
>
> I think, therefore, that the < 0 check should be retained.
Agree.
I am sending a re-spin.
>
> Thank you.
>
^ permalink raw reply
* Re: Wireguard fails on recent updates for OpenWRT on Turris Omnia, but same versions work on other (Linksys) routers with same CPU
From: Steven Honson @ 2018-07-24 9:49 UTC (permalink / raw)
To: Aaron Jones, mike, wireguard
In-Reply-To: <ac459db2-43e2-975e-decd-86a5066dde0d@gmail.com>
> On 22 Jul 2018, at 11:02 pm, Aaron Jones <aaronmdjones@gmail.com> =
wrote:
>=20
> # cat /sys/module/wireguard/version
On LEDE 17.01.5 at least, `/sys/module/wireguard/version` doesn=E2=80=99t =
exist, I=E2=80=99m not sure if this is the same for the release =
candidates of OpenWrt 18.06.
Unfortunately `modinfo wireguard` doesn=E2=80=99t give any indication of =
the version either for me with LEDE 17.01.5:
# modinfo wireguard
module: /lib/modules/4.4.140/wireguard.ko
alias: net-pf-16-proto-16-family-wireguard
alias: rtnl-link-wireguard
license: GPL v2
depends: udp_tunnel,ip6_udp_tunnel
If you have installed WireGuard from the LEDE/OpenWrt package =
repository, then `opkg info wireguard-tools` to check the tools, and =
`opkg info kmod-wireguard` to check the kernel module is one way to =
verify the version:
# opkg info wireguard-tools
Package: wireguard-tools
Version: 0.0.20180625-1
Depends: libc, libmnl, ip
Status: install ok installed
Section: net
...
# opkg info kmod-wireguard
Package: kmod-wireguard
Version: 4.4.140+0.0.20180519-1
Depends: kernel (=3D 4.4.140-1-78acdb0e5133ba67c91f7694e305d1e7), =
kmod-udptunnel6, kmod-udptunnel4
Status: install ok installed
...
Note that updates to the tools appear to be backported regularly to LEDE =
17.01, but the kernel module appears to be as of the version available =
at the time of the release (17.01.5 in my case), so it isn=E2=80=99t =
unusual for these versions to not match as is the case here with mine. =
I=E2=80=99m not sure if the next release of OpenWrt will do a similar =
thing. It=E2=80=99d be nice if the kernel module updates were backported =
too.
Cheers,
Steven=
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 05/99] s390-ccw: force diag 308 subcode to unsigned long
From: Cornelia Huck @ 2018-07-24 9:40 UTC (permalink / raw)
To: Michael Roth; +Cc: qemu-devel, qemu-stable, Thomas Huth
In-Reply-To: <153238409419.10934.1652388192245648682@sif>
On Mon, 23 Jul 2018 17:14:54 -0500
Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> Quoting Michael Roth (2018-07-23 15:16:14)
> > From: Cornelia Huck <cohuck@redhat.com>
> >
> > We currently pass an integer as the subcode parameter. However,
> > the upper bits of the register containing the subcode need to
> > be 0, which is not guaranteed unless we explicitly specify the
> > subcode to be an unsigned long value.
> >
> > Fixes: d046c51dad3 ("pc-bios/s390-ccw: Get device address via diag 308/6")
> > Cc: qemu-stable@nongnu.org
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
> > Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > Tested-by: Thomas Huth <thuth@redhat.com>
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > (cherry picked from commit 63d8b5ace31c1e1f3996fe4cd551d6d377594d5a)
> > Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
>
> Hi Cornelia,
>
> Would you be able to do an s390 BIOS build for this one as well?
Sure, will do a build for 2.12-stable.
^ permalink raw reply
* Re: [PATCH 3/3] iommu/arm-smmu: Error out only if not enough context interrupts
From: Vivek Gautam @ 2018-07-24 9:39 UTC (permalink / raw)
To: Will Deacon
Cc: joro, robh+dt, robin.murphy, andy.gross, mark.rutland, iommu,
devicetree, linux-kernel, tfiga, sricharan, linux-arm-msm,
david.brown, linux-soc, linux-arm-kernel
In-Reply-To: <20180724083633.GA19324@arm.com>
Hi Will,
On 7/24/2018 2:06 PM, Will Deacon wrote:
> On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
>> Currently we check if the number of context banks is not equal to
>> num_context_interrupts. However, there are booloaders such as, one
>> on sdm845 that reserves few context banks and thus kernel views
>> less than the total available context banks.
>> So, although the hardware definition in device tree would mention
>> the correct number of context interrupts, this number can be
>> greater than the number of context banks visible to smmu in kernel.
>> We should therefore error out only when the number of context banks
>> is greater than the available number of context interrupts.
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
>> Suggested-by: Tomasz Figa <tfiga@chromium.org>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> ---
>> drivers/iommu/arm-smmu.c | 19 +++++++++++++------
>> 1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 7c69736a30f8..4cb53bf4f423 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -2229,12 +2229,19 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>> if (err)
>> return err;
>>
>> - if (smmu->version == ARM_SMMU_V2 &&
>> - smmu->num_context_banks != smmu->num_context_irqs) {
>> - dev_err(dev,
>> - "found only %d context interrupt(s) but %d required\n",
>> - smmu->num_context_irqs, smmu->num_context_banks);
>> - return -ENODEV;
>> + if (smmu->version == ARM_SMMU_V2) {
>> + if (smmu->num_context_banks > smmu->num_context_irqs) {
>> + dev_err(dev,
>> + "found only %d context irq(s) but %d required\n",
>> + smmu->num_context_irqs, smmu->num_context_banks);
>> + return -ENODEV;
>> + } else if (smmu->num_context_banks < smmu->num_context_irqs) {
>> + /* loose extra context interrupts */
>> + dev_notice(dev,
>> + "found %d context irq(s) but only %d required\n",
>> + smmu->num_context_irqs, smmu->num_context_banks);
>> + smmu->num_context_irqs = smmu->num_context_banks;
>> + }
> I don't see the utility in the new message. Can you simplify with the patch
> below on top? It's a bit weird that we only decide to ignore the extra irqs
> after calling platform_get_irq() on them, but that seems to be harmless.
Thanks. I will modify as suggested below and respin.
Best regards
Vivek
>
> Will
>
> --->8
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index aa46c1ed5bf9..5349e22b5c78 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2109,13 +2109,10 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> "found only %d context irq(s) but %d required\n",
> smmu->num_context_irqs, smmu->num_context_banks);
> return -ENODEV;
> - } else if (smmu->num_context_banks < smmu->num_context_irqs) {
> - /* loose extra context interrupts */
> - dev_notice(dev,
> - "found %d context irq(s) but only %d required\n",
> - smmu->num_context_irqs, smmu->num_context_banks);
> - smmu->num_context_irqs = smmu->num_context_banks;
> }
> +
> + /* Ignore superfluous interrupts */
> + smmu->num_context_irqs = smmu->num_context_banks;
> }
>
> for (i = 0; i < smmu->num_global_irqs; ++i) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 1/2] mfd: rk808: Refactor shutdown functions
From: Wadim Egorov @ 2018-07-24 9:39 UTC (permalink / raw)
To: Lee Jones, Daniel Schultz,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: zyw-TNX95d0MmH7DzftRWevZcw, xsf-TNX95d0MmH7DzftRWevZcw,
zhangqing-TNX95d0MmH7DzftRWevZcw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
tony.xie-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <20180416093821.sqrcc6mmnc23njul@dell>
Hi,
Am 16.04.2018 um 11:38 schrieb Lee Jones:
> On Thu, 29 Mar 2018, Daniel Schultz wrote:
>
>> Since all three shutdown functions have almost the same code, all logic
>> from the shutdown functions can be refactored to a new function
>> "rk808_update_bits", which can update a register by a given address and
>> bitmask.
>>
>> Signed-off-by: Daniel Schultz <d.schultz-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
>> ---
>> Changes:
>> v2: Re-submit with recipients from Rockchip.
>> v3: - Added devicetree property to enable the PMIC reset seperate from
>> "rockchip,system-power-controller".
>> - Dropped the first patch of this serie.
>> v4: Splitted refactoring and the new reset feature.
>> v5: Removed null pointer from rk808_update_bits.
>>
>> drivers/mfd/rk808.c | 46 +++++++++++++---------------------------------
>> 1 file changed, 13 insertions(+), 33 deletions(-)
> I'd still like an Ack/Review from the Rockchip guys please.
>
can someone from Rockchip reply to this?
^ permalink raw reply
* Re: DPDK 18.05 only works with up to 4 NUMAs systems
From: Kumar, Ravi1 @ 2018-07-24 9:39 UTC (permalink / raw)
To: Burakov, Anatoly, dev@dpdk.org
In-Reply-To: <6170ad23-a317-cc4c-e42d-8ccadf41a8b0@intel.com>
>
>
>-----Original Message-----
>From: Burakov, Anatoly <anatoly.burakov@intel.com>
>Sent: Tuesday, July 24, 2018 2:33 PM
>To: Kumar, Ravi1 <Ravi1.Kumar@amd.com>; dev@dpdk.org
>Subject: Re: [dpdk-dev] DPDK 18.05 only works with up to 4 NUMAs systems
>
>On 24-Jul-18 9:09 AM, Kumar, Ravi1 wrote:
>>>
>>>
>>> -----Original Message-----
>>> From: Burakov, Anatoly <anatoly.burakov@intel.com>
>>> Sent: Monday, July 16, 2018 4:05 PM
>>> To: Kumar, Ravi1 <Ravi1.Kumar@amd.com>; dev@dpdk.org
>>> Subject: Re: [dpdk-dev] DPDK 18.05 only works with up to 4 NUMAs
>>> systems
>>>
>>> On 14-Jul-18 10:44 AM, Kumar, Ravi1 wrote:
>>>>
>>>> Memory setup with 2M pages works with the default configuration.
>>>> With the default configuration and 2M hugepages
>>>>
>>>> 1. Total amount of memory for each NUMA zone does not
>>>> exceed 128G (CONFIG_RTE_MAX_MEM_MB_PER_TYPE).
>>>>
>>>> 2. Total number of segment lists per NUMA is limited to
>>>> 32768 (CONFIG_RTE_MAX_MEMSEG_PER_TYPE). This constraint is met for
>>>> each numa zone. This is the limiting factor for memory per numa
>>>> with 2M hugepages and the default configuration.
>>>>
>>>> 3. The data structures are capable of supporting 64G of
>>>> memory for each numa zone (32768 segments * 2M hugepagesize).
>>>>
>>>> 4. 8 NUMA zones * 64G = 512G. Therefore the total for all
>>>> numa zones does not exceed 512G (CONFIG_RTE_MAX_MEM_MB).
>>>>
>>>> 5. Resources are capable of allocating up to 64G per NUMA
>>>> zone. Things will work as long as there are enough 2M hugepages to
>>>> cover the memory needs of the DPDK applications AND no memory zone
>>>> needs more than 64G.
>>>>
>>>> With the default configuration and 1G hugepages
>>>>
>>>> 1. Total amount of memory for each NUMA zone is limited to
>>>> 128G (CONFIG_RTE_MAX_MEM_MB_PER_TYPE). This constraint is hit for
>>>> each numa zone. This is the limiting factor for memory per numa.
>>>>
>>>> 2. Total number of segment lists (128) does not exceed
>>>> 32768 (CONFIG_RTE_MAX_MEMSEG_PER_TYPE). There are 128 segments per NUMA.
>>>>
>>>> 3. The data structures are capable of supporting 128G of
>>>> memory for each numa zone (128 segments * 1G hugepagesize).
>>>> However, only the first four NUMA zones get initialized before we
>>>> hit CONFIG_RTE_MAX_MEM_MB (512G).
>>>>
>>>> 4. The total for all numa zones is limited to 512G
>>>> (CONFIG_RTE_MAX_MEM_MB). This limit is hit after configuring the
>>>> first four NUMA zones (4 x 128G = 512G). The rest of the NUMA zones
>>>> cannot allocate memory.
>>>>
>>>> Apparently, it is intended to support max 8 NUMAs by default
>>>> (CONFIG_RTE_MAX_NUMA_NODES=8), but when 1G hugepages are use, it can
>>>> only support up to 4 NUMAs.
>>>>
>>>> Possible workarounds when using 1G hugepages:
>>>>
>>>> 1. Decrease CONFIG_RTE_MAX_MEM_MB_PER_TYPE to 65536 (limit
>>>> of 64G per NUMA zone). This is probably the best option unless you
>>>> need a lot of memory in any given NUMA.
>>>>
>>>> 2. Or, increase CONFIG_RTE_MAX_MEM_MB to 1048576.
>>>
>>> Hi Ravi,
>>>
>>> OK this makes it much clearer, thanks!
>>>
>>> I think the first one should be done. I think 64G per NUMA node is
>>> still a reasonable amount of memory and it makes the default work (i
>>> think we can go as far as reducing this limit to 32G per type!), and
>>> whoever has issues with it can change CONFIG_RTE_MAX_MEM_MB_PER_TYPE
>>> or CONFIG_RTE_MAX_MEM_MB for their use case. That's what these
>>> options are there for :)
>>>
>>> --
>>> Thanks,
>>> Anatoly
>>>
>>
>> Hi Anatoly,
>>
>> Thanks a lot. Will the next release include this change?
>>
>> Regards,
>> Ravi
>>
>
>No one has submitted a patch for this, so not at this moment. I will do so now, but i cannot guarantee it getting merged in 18.08 since it's almost RC2 time, and introducing such a change may be too big a risk.
>
>--
>Thanks,
>Anatoly
Thanks Anatoly. I understand.
Regards,
Ravi
^ permalink raw reply
* [PATCH 3/3] iommu/arm-smmu: Error out only if not enough context interrupts
From: Vivek Gautam @ 2018-07-24 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724083633.GA19324@arm.com>
Hi Will,
On 7/24/2018 2:06 PM, Will Deacon wrote:
> On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
>> Currently we check if the number of context banks is not equal to
>> num_context_interrupts. However, there are booloaders such as, one
>> on sdm845 that reserves few context banks and thus kernel views
>> less than the total available context banks.
>> So, although the hardware definition in device tree would mention
>> the correct number of context interrupts, this number can be
>> greater than the number of context banks visible to smmu in kernel.
>> We should therefore error out only when the number of context banks
>> is greater than the available number of context interrupts.
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
>> Suggested-by: Tomasz Figa <tfiga@chromium.org>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> ---
>> drivers/iommu/arm-smmu.c | 19 +++++++++++++------
>> 1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 7c69736a30f8..4cb53bf4f423 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -2229,12 +2229,19 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>> if (err)
>> return err;
>>
>> - if (smmu->version == ARM_SMMU_V2 &&
>> - smmu->num_context_banks != smmu->num_context_irqs) {
>> - dev_err(dev,
>> - "found only %d context interrupt(s) but %d required\n",
>> - smmu->num_context_irqs, smmu->num_context_banks);
>> - return -ENODEV;
>> + if (smmu->version == ARM_SMMU_V2) {
>> + if (smmu->num_context_banks > smmu->num_context_irqs) {
>> + dev_err(dev,
>> + "found only %d context irq(s) but %d required\n",
>> + smmu->num_context_irqs, smmu->num_context_banks);
>> + return -ENODEV;
>> + } else if (smmu->num_context_banks < smmu->num_context_irqs) {
>> + /* loose extra context interrupts */
>> + dev_notice(dev,
>> + "found %d context irq(s) but only %d required\n",
>> + smmu->num_context_irqs, smmu->num_context_banks);
>> + smmu->num_context_irqs = smmu->num_context_banks;
>> + }
> I don't see the utility in the new message. Can you simplify with the patch
> below on top? It's a bit weird that we only decide to ignore the extra irqs
> after calling platform_get_irq() on them, but that seems to be harmless.
Thanks. I will modify as suggested below and respin.
Best regards
Vivek
>
> Will
>
> --->8
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index aa46c1ed5bf9..5349e22b5c78 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2109,13 +2109,10 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> "found only %d context irq(s) but %d required\n",
> smmu->num_context_irqs, smmu->num_context_banks);
> return -ENODEV;
> - } else if (smmu->num_context_banks < smmu->num_context_irqs) {
> - /* loose extra context interrupts */
> - dev_notice(dev,
> - "found %d context irq(s) but only %d required\n",
> - smmu->num_context_irqs, smmu->num_context_banks);
> - smmu->num_context_irqs = smmu->num_context_banks;
> }
> +
> + /* Ignore superfluous interrupts */
> + smmu->num_context_irqs = smmu->num_context_banks;
> }
>
> for (i = 0; i < smmu->num_global_irqs; ++i) {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.