Re: [PATCH] bpf: whitelist syscalls for error injection
On Fri, Mar 16, 2018 at 03:55:04PM -0700, Howard McLauchlan wrote: > On 03/13/2018 04:56 PM, Andy Lutomirski wrote: > > On Tue, Mar 13, 2018 at 11:16 PM, Howard McLauchlan > > wrote: > >> Error injection is a useful mechanism to fail arbitrary kernel > >> functions. However, it is often hard to guarantee an error propagates > >> appropriately to user space programs. By injecting into syscalls, we can > >> return arbitrary values to user space directly; this increases > >> flexibility and robustness in testing, allowing us to test user space > >> error paths effectively. > > > > Temporary NAK IMO. Specifically: > > > >> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > >> index a78186d826d7..e8c6d63ace78 100644 > >> --- a/include/linux/syscalls.h > >> +++ b/include/linux/syscalls.h > >> @@ -191,6 +191,8 @@ static inline int is_syscall_trace_event(struct > >> trace_event_call *tp_event) > >> > >> #define SYSCALL_DEFINE0(sname) \ > >> SYSCALL_METADATA(_##sname, 0); \ > >> + asmlinkage long sys_##sname(void); \ > >> + ALLOW_ERROR_INJECTION(sys_##sname, ERRNO); \ > > > > sys_xyz() is not just the syscall itself; it's also a helper that's > > used for entirely silly reasons by various bits of kernel code for > > quite a few syscalls. Fortunately, Dominik has patches to fix that, > > and Linus is even considering pulling them for 4.16. This patch will > > most likely conflict with the final result of Dominik's series. > > > > Can you and Dominik coordinate a bit to get this patch or its > > equivalent landed on top of Dominik's work? It might make sense for > > Dominik to just add this patch to his series so it can land with the > > rest of it. Dominik, Ingo, what do you think? > > > > --Andy > > > > Dominik, > > This patch applies cleanly on top of your patch series. Is there anything > you'd need from me to get this in on top of your work? Howard, would this form part of the kernel<->userspace interface and therefore needs to be kept stable? If so, this patch should wait until the arch-specific syscall calling convention is agreed upon. Moreover, the patches I sent out already do not cover all syscalls yet. Until all in-kernel users of sys_*() are gone (or at least outside arch/), I'd prefer to postpone this patch. Thanks, Dominik
[PATCH] vmbus: use put_device() if device_register fail
if device_register() returned an error. Always use put_device()
to give up the reference initialized.
Signed-off-by: Arvind Yadav
---
drivers/hv/vmbus_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bc65c4d..25da2f3 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1358,6 +1358,7 @@ int vmbus_device_register(struct hv_device
*child_device_obj)
ret = device_register(&child_device_obj->device);
if (ret) {
pr_err("Unable to register child device\n");
+ put_device(&child_device_obj->device);
return ret;
}
--
2.7.4
Re: [PATCH v10 3/5] arm/arm64: KVM: Introduce set and get per-vcpu event
Hi James,
Thanks for your review and good suggestion.
>
> Hi Dongjiu Geng,
>
> On 03/03/18 16:09, Dongjiu Geng wrote:
> > RAS Extension provides VSESR_EL2 register to specify virtual SError
> > syndrome value, this patch adds a new IOCTL to export user-invisible
> > states related to SError exceptions. User space can setup the
> > kvm_vcpu_events to inject specified SError, also it can support live
> > migration.
>
> > diff --git a/Documentation/virtual/kvm/api.txt
> > b/Documentation/virtual/kvm/api.txt
> > index 8a3d708..26ae151 100644
> > --- a/Documentation/virtual/kvm/api.txt
> > +++ b/Documentation/virtual/kvm/api.txt
> > @@ -819,11 +819,13 @@ struct kvm_clock_data {
> >
> > Capability: KVM_CAP_VCPU_EVENTS
> > Extended by: KVM_CAP_INTR_SHADOW
> > -Architectures: x86
> > +Architectures: x86, arm, arm64
> > Type: vm ioctl
> > Parameters: struct kvm_vcpu_event (out)
> > Returns: 0 on success, -1 on error
> >
> > +X86:
> > +
> > Gets currently pending exceptions, interrupts, and NMIs as well as
> > related states of the vcpu.
> >
> > @@ -865,15 +867,29 @@ Only two fields are defined in the flags field:
> > - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
> >smi contains a valid state.
> >
> > +ARM, ARM64:
> > +
> > +Gets currently pending SError exceptions as well as related states of the
> > vcpu.
> > +
> > +struct kvm_vcpu_events {
> > + struct {
> > + bool serror_pending;
> > + bool serror_has_esr;
> > + u64 serror_esr;
> > + } exception;
> > +};
>
> Don't put bool in an ABI struct. The encoding is up to the compiler.
> The compiler will insert padding in this struct to make serror_esr naturally
> aligned. Different compilers may do it differently. You'll see that
> the existing struct kvm_vcpu_events has 'pad' fields to ensure each element
> in the struct is naturally aligned.
I checked the exited x86 strut kvm_vcpu_events definition, it aligned to 32
bits, so how about using below kvm_vcpu_events struct definition for arm64?
struct kvm_vcpu_events {
struct {
__u8_8 serror_pending;
__u8 serror_has_esr;
__u8 pad[2];
__u64 serror_esr;
} exception;
};
>
> serror_pending and serror_has_esr need to be in a flags field.
How about this definition?
struct kvm_vcpu_events {
struct {
__u8_8 serror_pending;
__u8 serror_has_esr;
__u8 pad[2];
__u64 serror_esr;
} exception;
};
>
> I thought the logic for re-using the CAP was so user-space could re-use
> save/restore code to transfer whatever we put in here during
> migration. If the struct is a different size the code has to be different
> anyway.
> My understanding of Drew and Christoffer's comments was that we should re-use
> the existing struct. (but now that I look at it, its not so
> clear).
>
> (If we reuse the struct, we can put the esr in exception.error_code, if we
> can get away with it: It would be good to union exception up with
> a u64, then use that. This would let us transfer anything we need in those
> RES0 bits of the 64bit VSESR_EL2).
It seems Drew and Christoffer's comments suggested to use the
KVM_GET/SET_VCPU_EVENTS ABI, not suggested arm64 must use the same struct
kvm_vcpu_events definition with x86.
>
>
> > 4.32 KVM_SET_VCPU_EVENTS
> >
> > Capability: KVM_CAP_VCPU_EVENTS
> > Extended by: KVM_CAP_INTR_SHADOW
> > -Architectures: x86
> > +Architectures: x86, arm, arm64
> > Type: vm ioctl
> > Parameters: struct kvm_vcpu_event (in)
> > Returns: 0 on success, -1 on error
> >
> > +X86:
> > +
> > Set pending exceptions, interrupts, and NMIs as well as related
> > states of the vcpu.
> >
> > @@ -894,6 +910,12 @@ shall be written into the VCPU.
> >
> > KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
> >
> > +ARM, ARM64:
> > +
> > +Set pending SError exceptions as well as related states of the vcpu.
> > +
> > +See KVM_GET_VCPU_EVENTS for the data structure.
> > +
> >
> > 4.33 KVM_GET_DEBUGREGS
> >
>
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h
> > b/arch/arm64/include/uapi/asm/kvm.h
> > index 9abbf30..32c0eae 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -39,6 +39,7 @@
> > #define __KVM_HAVE_GUEST_DEBUG
> > #define __KVM_HAVE_IRQ_LINE
> > #define __KVM_HAVE_READONLY_MEM
> > +#define __KVM_HAVE_VCPU_EVENTS
> >
> > #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
> >
> > @@ -153,6 +154,15 @@ struct kvm_sync_regs { struct
> > kvm_arch_memory_slot { };
> >
> > +/* for KVM_GET/SET_VCPU_EVENTS */
> > +struct kvm_vcpu_events {
> > + struct {
> > + bool serror_pending;
> > + bool serror_has_esr;
> > + u64 serror_esr;
> > + } exception;
> > +};
> > +
>
> > /* If you need to interpret the index values, here is the key: */
> > #define KVM_REG_ARM_COPROC_MASK0x00
Re: [PATCH v6 07/15] fs, dax: use page->mapping to warn if truncate collides with a busy page
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All error/warnings (new ones prefixed by >>):
fs/dax.c: In function 'dax_entry_size':
>> fs/dax.c:308:10: error: 'HPAGE_SIZE' undeclared (first use in this
>> function); did you mean 'PAGE_SIZE'?
return HPAGE_SIZE;
^~
PAGE_SIZE
fs/dax.c:308:10: note: each undeclared identifier is reported only once for
each function it appears in
>> fs/dax.c:311:1: warning: control reaches end of non-void function
>> [-Wreturn-type]
}
^
vim +308 fs/dax.c
300
301 static unsigned long dax_entry_size(void *entry)
302 {
303 if (dax_is_zero_entry(entry))
304 return 0;
305 else if (dax_is_empty_entry(entry))
306 return 0;
307 else if (dax_is_pmd_entry(entry))
> 308 return HPAGE_SIZE;
309 else
310 return PAGE_SIZE;
> 311 }
312
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR
Hi Jonathan,
Here is the complete list of registers for the ADE7878 which I copied from the
data sheet. I added a column “IIO Attribute” which I hope follows your IIO ABI.
Please make any changes you feel are incorrect. BTW, there are several
registers that cannot be generalized and are used purely for chip
configuration. I think we should add a new naming convention, namely
{register}_{}. Also, I see in the sys_bus_iio doc
in_accel_x_peak_raw
so shouldn’t the phase be represented as follows:
in_current_A_scale
But for now, I followed your instructions from your reply.
After finalizing this one, I will work on the ADE9000, which as way more
registers ;-)
Once we can agree on the register naming, I will update the ADE7854 driver for
Rodrigo, which will go a long way to getting it out of staging.
Address RegisterIIO Attribute R/W Bit Length Bit Length
During CommunicationsTypeDefault Value Description
0x4380 AIGAIN in_currentA_scale R/W 24 32 ZPSE S
0x00Phase A current gain adjust.
0x4381 AVGAIN in_voltageA_scale R/W 24 32 ZPSE S
0x00Phase A voltage gain adjust.
0x4382 BIGAIN in_currentB_scale R/W 24 32 ZPSE S
0x00Phase B current gain adjust.
0x4383 BVGAIN in_voltageB_scale R/W 24 32 ZPSE S
0x00Phase B voltage gain adjust.
0x4384 CIGAIN in_currentC_scale R/W 24 32 ZPSE S
0x00Phase C current gain adjust.
0x4385 CVGAIN in_voltageC_scale R/W 24 32 ZPSE S
0x00Phase C voltage gain adjust.
0x4386 NIGAIN in_currentN_scale R/W 24 32 ZPSE S
0x00Neutral current gain adjust (ADE7868 and ADE7878 only).
0x4387 AIRMSOS in_currentA_rms_offset R/W 24 32 ZPSE S
0x00Phase A current rms offset.
0x4388 AVRMSOS in_voltageA_rms_offset R/W 24 32 ZPSE S
0x00Phase A voltage rms offset.
0x4389 BIRMSOS in_currentB_rms_offset R/W 24 32 ZPSE S
0x00Phase B current rms offset.
0x438A BVRMSOS in_voltageB_rms_offset R/W 24 32 ZPSE S
0x00Phase B voltage rms offset.
0x438B CIRMSOS in_currentC_rms_offset R/W 24 32 ZPSE S
0x00Phase C current rms offset.
0x438C CVRMSOS in_voltageC_rms_offset R/W 24 32 ZPSE S
0x00Phase C voltage rms offset.
0x438D NIRMSOS in_currentN_rms_offset R/W 24 32 ZPSE S
0x00Neutral current rms offset (ADE7868 and ADE7878 only).
0x438E AVAGAIN in_powerapparentA_scale R/W 24 32 ZPSE S
0x00Phase A apparent power gain adjust.
0x438F BVAGAIN in_powerapparentB_scale R/W 24 32 ZPSE S
0x00Phase B apparent power gain adjust.
0x4390 CVAGAIN in_powerapparentC_scale R/W 24 32 ZPSE S
0x00Phase C apparent power gain adjust.
0x4391 AWGAIN in_powerA_scale R/W 24 32 ZPSE S 0x00
Phase A total active power gain adjust.
0x4392 AWATTOS in_powerA_offsetR/W 24 32 ZPSE S
0x00Phase A total active power offset adjust.
0x4393 BWGAIN in_powerB_scale R/W 24 32 ZPSE S 0x00
Phase B total active power gain adjust.
0x4394 BWATTOS in_powerB_offsetR/W 24 32 ZPSE S
0x00Phase B total active power offset adjust.
0x4395 CWGAIN in_powerC_scale R/W 24 32 ZPSE S 0x00
Phase C total active power gain adjust.
0x4396 CWATTOS in_powerC_offsetR/W 24 32 ZPSE S
0x00Phase C total active power offset adjust.
0x4397 AVARGAINin_powerreactiveA_scale R/W 24 32 ZPSE S
0x00Phase A total reactive power gain adjust (ADE7858, ADE7868, and
ADE7878).
0x4398 AVAROS in_powerreactiveA_offsetR/W 24 32 ZPSE S
0x00Phase A total reactive power offset adjust (ADE7858, ADE7868,
and ADE7878).
0x4399 BVARGAINin_powerreactiveB_scale R/W 24 32 ZPSE S
0x00Phase B total reactive power gain adjust (ADE7858, ADE7868, and
ADE7878).
0x439A BVAROS in_powerreactiveB_offsetR/W 24 32 ZPSE S
0x00Phase B total reactive power offset adjust (ADE7858, ADE7868,
and ADE7878).
0x439B CVARGAINin_powerreactiveC_scale R/W 24 32 ZPSE S
0x00Phase C total reactive power gain adjust (ADE7858, ADE7868, and
ADE7878).
0x439C CVAROS in_powerreactiveC_offsetR/W 24 32 ZPSE S
0x00Phase C total reactive power offset adjust (ADE7858, ADE7868,
and ADE7878).
0x439D AFWGAIN in_powerA_fundamental_scale R/W 24 32 ZPSE S
0x00Phase A fundamental active power gain adjust. Location reserved
for ADE7
Re: [PATCH v3] ata: add Amiga Gayle PATA controller driver
On Fri, Mar 16, 2018 at 9:15 AM, Bartlomiej Zolnierkiewicz wrote: > Add Amiga Gayle PATA controller driver. It enables libata support > for the on-board IDE interfaces on some Amiga models (A600, A1200, > A4000 and A4000T) and also for IDE interfaces on the Zorro expansion > bus (M-Tech E-Matrix 530 expansion card). > > Thanks to John Paul Adrian Glaubitz and Michael Schmitz for help > with testing the driver. > > Tested-by: John Paul Adrian Glaubitz > Cc: Michael Schmitz > Cc: Geert Uytterhoeven > Cc: Philippe Ombredanne > Cc: Andy Shevchenko > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > v3: > - fix minor issues reported by Andy > > v2: > - clarify license version (it should be GPL 2.0) > - use SPDX header For the use of SPDX ids, you have my ack: (I am not qualified for the rest) Acked-by: Philippe Ombredanne -- Cordially Philippe Ombredanne
Re: [PATCH v10 1/5] arm64: KVM: Prepare set virtual SEI syndrome value
Hi James,
>
> Hi Dongjiu Geng,
>
> On 03/03/18 16:09, Dongjiu Geng wrote:
> > Export one API to specify virtual SEI syndrome value for guest, and
> > add a helper to get the VSESR_EL2 value.
>
> This patch adds two helpers that nothing calls... its not big, please merge
> it with the patch that uses these.
OK, thanks, I will merge them.
>
>
> > diff --git a/arch/arm64/include/asm/kvm_emulate.h
> > b/arch/arm64/include/asm/kvm_emulate.h
> > index 413dc82..3294885 100644
> > --- a/arch/arm64/include/asm/kvm_emulate.h
> > +++ b/arch/arm64/include/asm/kvm_emulate.h
> > @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu,
> > unsigned long hcr)
> > vcpu->arch.hcr_el2 = hcr;
> > }
> >
> > +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) {
> > + return vcpu->arch.vsesr_el2;
> > +}
> > +
> > static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
> > {
> > vcpu->arch.vsesr_el2 = vsesr;
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index a73f63a..3dc49b7 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -354,6 +354,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu,
> > struct kvm_run *run, int kvm_perf_init(void); int
> > kvm_perf_teardown(void);
> >
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
> > +
> > struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long
> > mpidr);
> >
> > static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff
> > --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> > index 60666a0..78ecb28 100644
> > --- a/arch/arm64/kvm/inject_fault.c
> > +++ b/arch/arm64/kvm/inject_fault.c
> > @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu) {
> > pend_guest_serror(vcpu, ESR_ELx_ISV); }
> > +
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) {
> > + pend_guest_serror(vcpu, syndrome & ESR_ELx_ISS_MASK);
>
> If you move the ISS_MASK into pend_guest_serror(), you wouldn't need this at
> all.
>
> It would be better if any validation were in the user-space helpers so we can
> check user-space hasn't put something funny in the top bits.
Yes, I agree your idea, thanks for the good suggestion.
>
> > +}
> >
>
>
> Thanks,
>
> James
Re: [PATCH] arm64: rename the function arm64_is_ras_serror() to avoid confusion
Hi James, > Hi gengdongjiu, > > On 26/02/18 16:13, gengdongjiu wrote: > > 2018-02-24 1:58 GMT+08:00 James Morse : > >> On 22/02/18 18:02, Dongjiu Geng wrote: > >>> The RAS SError Syndrome can be Implementation-Defined, > >>> arm64_is_ras_serror() is used to judge whether it is RAS SError, but > >>> arm64_is_ras_serror() does not include this judgement. In order to > >>> avoid function name confusion, we rename the arm64_is_ras_serror() > >>> to arm64_is_categorized_ras_serror(), this function is used to judge > >>> whether it is categorized RAS Serror. > >> > >> I don't see how 'categorized' is relevant. The most significant ISS > >> bit is used to determine if this is an IMP-DEF ESR, or one that uses the > >> architected layout. > > > > From the name arm64_is_ras_serror(), it used to judge whether this is > > RAS Serror, but arm64_is_ras_serror() think the IMP-DEF SError is not > > RAS SError, as shown the code note and code in[1]. > > > In fact the IMP-DEF SError is also RAS SError, so when I read the > > code, it looks like > > This is just you then. No-one else has your imp-def:RAS error ESR values. > > This would be like me adding some impdef branch instruction, then claiming > aarch64_insn_is_branch() doesn't take account of my private additions. > > I agree the name is assuming all architected ESR are RAS-errors, and that > impdef ESR are just that: impdef, that's all we know about them. > Unless this causes us to do the wrong thing, I don't think it matters. > Obviously we would need to change it if a new architected ESR is added. Ok, let us keep the current code and not change it until a new architected ESR is added
Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode
Hi Antoine,
On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote:
> This patch allow the CP100 comphy to configure some lanes in the
Should be 'CP110'.
> 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
> same code path.
>
> Signed-off-by: Antoine Tenart
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
[RFC PATCH] ext2, dax: ext2_dax_aops can be static
Fixes: 97affa6a9d1c ("ext2, dax: introduce ext2_dax_aops")
Signed-off-by: Fengguang Wu
---
inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 9590712..8ea394c8 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -989,7 +989,7 @@ const struct address_space_operations ext2_nobh_aops = {
.error_remove_page = generic_error_remove_page,
};
-const struct address_space_operations ext2_dax_aops = {
+static const struct address_space_operations ext2_dax_aops = {
.direct_IO = ext2_direct_IO,
.writepages = ext2_dax_writepages,
.set_page_dirty = noop_set_page_dirty,
Re: [PATCH v6 06/15] ext2, dax: introduce ext2_dax_aops
Hi Dan, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> fs/ext2/inode.c:992:39: sparse: symbol 'ext2_dax_aops' was not declared. >> Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall
On 18/03/2018, Jason Vas Dias wrote:
(should have CC'ed to list, sorry)
> On 17/03/2018, Andi Kleen wrote:
>>
>> That's quite a mischaracterization of the issue. gcc works as intended,
>> but the kernel did not correctly supply a indirect call retpoline thunk
>> to the vdso, and it just happened to work by accident with the old
>> vdso.
>>
>>>
>>> The automated test builds should now succeed with this patch.
>>
>> How about just adding the thunk function to the vdso object instead of
>> this cheap hack?
>>
>> The other option would be to build vdso with inline thunks.
>>
>> But just disabling is completely the wrong action.
>>
>> -Andi
>>
>
> Aha! Thanks for the clarification , Andi!
>
> I will do so and resend the 2nd patch.
>
> But is everyone agreed we should accept any slowdown for the timer
> functions ? I personally don't think it is a good idea, but I will
> regenerate the patch with the thunk function and without
> the Makefile change.
>
> Thanks & Best Regards,
> Jason
>
I am wondering if it is not better to avoid the thunk being generated
and remove the Makefile patch ?
I know that changing the switch in __vdso_clock_gettime() like
this avoids the thunk :
switch(clock) {
case CLOCK_MONOTONIC:
if (do_monotonic(ts) == VCLOCK_NONE)
goto fallback;
break;
default:
switch (clock) {
case CLOCK_REALTIME:
if (do_realtime(ts) == VCLOCK_NONE)
goto fallback;
break;
case CLOCK_MONOTONIC_RAW:
if (do_monotonic_raw(ts) == VCLOCK_NONE)
goto fallback;
break;
case CLOCK_REALTIME_COARSE:
do_realtime_coarse(ts);
break;
case CLOCK_MONOTONIC_COARSE:
do_monotonic_coarse(ts);
break;
default:
goto fallback;
}
return 0;
fallback: ...
}
So at the cost of an unnecessary extra test of the clock parameter,
the thunk is avoided .
I wonder if the whole switch should be changed to an if / else clause ?
Or, I know this might be unorthodox, but might work :
#define _CAT(V1,V2) V1##V2
#define GTOD_CLK_LABEL(CLK) _CAT(_VCG_L_,CLK)
#define MAX_CLK 16
//^^ ??
__vdso_clock_gettime( ... ) { ...
static const void *clklbl_tab[MAX_CLK]
={ [ CLOCK_MONOTONIC ]
= &>OD_CLK_LABEL(CLOCK_MONOTONIC) ,
[ CLOCK_MONOTONIC_RAW ]
= &>OD_CLK_LABEL(CLOCK_MONOTONIC_RAW) ,
// and similarly for all clocks handled ...
};
goto clklbl_tab[ clock & 0xf ] ;
GTOD_CLK_LABEL(CLOCK_MONOTONIC) :
if ( do_monotonic(ts) == VCLOCK_NONE )
goto fallback ;
GTOD_CLK_LABEL(CLOCK_MONOTONIC_RAW) :
if ( do_monotonic_raw(ts) == VCLOCK_NONE )
goto fallback ;
... // similarly for all clocks
fallback:
return vdso_fallback_gettime(clock,ts);
}
If a restructuring like that might be acceptable (with correct tab-based
formatting) , and the VDSO can have such a table in its .BSS , I think it
would avoid the thunk, and have the advantage of
precomputing the jump table at compile-time, and would not require any
indirect branches, I think.
Any thoughts ?
Thanks & Best regards,
Jason
;
G
[PATCH V2 2/2] regulator: pfuze100: update voltage setting for pfuze3000 sw1a
pfuze3000 datasheet(Rev.9.0) from:
https://www.nxp.com/docs/en/data-sheet/PF3000.pdf
updates sw1a's voltage range, the settings for 1.450V and 1.475V
are replaced with 1.8V and 3.3V:
5b'0 1.450 (SW1B), 1.8 (SW1A/SW1AB)
5b'1 1.475 (SW1B), 3.3 (SW1A/SW1AB)
the voltage calculation using steps is NOT available for sw1a now,
use voltage table instead.
Signed-off-by: Anson Huang
Signed-off-by: Robin Gong
---
changes since V1:
update the latest datasheet link and add version into commit message.
drivers/regulator/pfuze100-regulator.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/pfuze100-regulator.c
b/drivers/regulator/pfuze100-regulator.c
index 63922a2..680f076 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -86,6 +86,13 @@ static const int pfuze100_coin[] = {
250, 270, 280, 290, 300, 310, 320, 330,
};
+static const int pfuze3000_sw1a[] = {
+ 70, 725000, 75, 775000, 80, 825000, 85, 875000,
+ 90, 925000, 95, 975000, 100, 1025000, 105, 1075000,
+ 110, 1125000, 115, 1175000, 120, 1225000, 125, 1275000,
+ 130, 1325000, 135, 1375000, 140, 1425000, 180, 330,
+};
+
static const int pfuze3000_sw2lo[] = {
150, 155, 160, 165, 170, 175, 180, 185,
};
@@ -343,7 +350,7 @@ static struct pfuze_regulator pfuze200_regulators[] = {
};
static struct pfuze_regulator pfuze3000_regulators[] = {
- PFUZE100_SW_REG(PFUZE3000, SW1A, PFUZE100_SW1ABVOL, 70, 1475000,
25000),
+ PFUZE100_SWB_REG(PFUZE3000, SW1A, PFUZE100_SW1ABVOL, 0x1f,
pfuze3000_sw1a),
PFUZE100_SW_REG(PFUZE3000, SW1B, PFUZE100_SW1CVOL, 70, 1475000,
25000),
PFUZE100_SWB_REG(PFUZE3000, SW2, PFUZE100_SW2VOL, 0x7, pfuze3000_sw2lo),
PFUZE3000_SW3_REG(PFUZE3000, SW3, PFUZE100_SW3AVOL, 90, 165,
5),
--
2.7.4
[PATCH V2 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range
Update sw1a/vldo4's voltage range according to pfuze3000
datasheet(Rev.9.0) from:
https://www.nxp.com/docs/en/data-sheet/PF3000.pdf
Signed-off-by: Anson Huang
Signed-off-by: Robin Gong
---
no changes since V1.
arch/arm/boot/dts/imx6sx-udoo-neo.dtsi | 2 +-
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 4 ++--
arch/arm/boot/dts/imx7d-nitrogen7.dts | 2 +-
arch/arm/boot/dts/imx7d-sdb.dts | 6 +++---
arch/arm/boot/dts/imx7s-warp.dts| 2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
index 53b3eac..1de0a0f 100644
--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -142,7 +142,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
- regulator-max-microvolt = <1475000>;
+ regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index ae45af1..3781cb8 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -87,7 +87,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
- regulator-max-microvolt = <1475000>;
+ regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
@@ -284,4 +284,4 @@
MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG
PWREN */
>;
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/imx7d-nitrogen7.dts
b/arch/arm/boot/dts/imx7d-nitrogen7.dts
index 2b05898..2802bcf 100644
--- a/arch/arm/boot/dts/imx7d-nitrogen7.dts
+++ b/arch/arm/boot/dts/imx7d-nitrogen7.dts
@@ -188,7 +188,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
- regulator-max-microvolt = <1475000>;
+ regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index a7a5dc7..ba60457 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -248,7 +248,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
- regulator-max-microvolt = <1475000>;
+ regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
@@ -324,8 +324,8 @@
};
vgen6_reg: vldo4 {
- regulator-min-microvolt = <280>;
- regulator-max-microvolt = <280>;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
regulator-always-on;
};
};
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 9bdf121..0e0cbcf 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -129,7 +129,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
- regulator-max-microvolt = <1475000>;
+ regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
--
2.7.4
[PATCH 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source
On i.MX6SX SabreAuto board, there is external 24MHz clock
source for analog clock2, add this clock source to clock tree.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sx-sabreauto.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 72da5ac..83f7cac 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,14 @@
reg = <0x8000 0x8000>;
};
+ clocks {
+ codec_osc: anaclk2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24576000>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
--
2.7.4
[PATCH 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree
i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
And this lvds2, along with lvds1, can be used to provide
external clock source to the internal pll, such as pll4_audio
and pll5_video.
This patch mainly adds the lvds2 to the clock tree and fix its
relationship with pll accordingly.
Signed-off-by: Anson Huang
Signed-off-by: Shengjiu Wang
---
drivers/clk/imx/clk-imx6sx.c | 6 +-
include/dt-bindings/clock/imx6sx-clock.h | 6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index e6d389e..d180797 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -80,7 +80,7 @@ static const char *lvds_sels[]= {
"arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy",
"pll5_video_div",
"dummy", "dummy", "pcie_ref_125m", "dummy", "usbphy1", "usbphy2",
};
-static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", };
+static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", "lvds2_in",
"dummy", };
static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src", };
static const char *pll2_bypass_sels[] = { "pll2", "pll2_bypass_src", };
static const char *pll3_bypass_sels[] = { "pll3", "pll3_bypass_src", };
@@ -160,6 +160,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
/* Clock source from external clock via CLK1 PAD */
clks[IMX6SX_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
+ clks[IMX6SX_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sx-anatop");
base = of_iomap(np, 0);
@@ -228,7 +229,9 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_PCIE_REF_125M] = imx_clk_gate("pcie_ref_125m",
"pcie_ref", base + 0xe0, 19);
clks[IMX6SX_CLK_LVDS1_OUT] = imx_clk_gate_exclusive("lvds1_out",
"lvds1_sel", base + 0x160, 10, BIT(12));
+ clks[IMX6SX_CLK_LVDS2_OUT] = imx_clk_gate_exclusive("lvds2_out",
"lvds2_sel", base + 0x160, 11, BIT(13));
clks[IMX6SX_CLK_LVDS1_IN] = imx_clk_gate_exclusive("lvds1_in",
"anaclk1", base + 0x160, 12, BIT(10));
+ clks[IMX6SX_CLK_LVDS2_IN] = imx_clk_gate_exclusive("lvds2_in",
"anaclk2", base + 0x160, 13, BIT(11));
clks[IMX6SX_CLK_ENET_REF] = clk_register_divider_table(NULL,
"enet_ref", "pll6_enet", 0,
base + 0xe0, 0, 2, 0, clk_enet_ref_table,
@@ -270,6 +273,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
/*name
reg shift width parent_names num_parents */
clks[IMX6SX_CLK_LVDS1_SEL] = imx_clk_mux("lvds1_sel",
base + 0x160, 0, 5, lvds_sels, ARRAY_SIZE(lvds_sels));
+ clks[IMX6SX_CLK_LVDS2_SEL] = imx_clk_mux("lvds2_sel",
base + 0x160, 5, 5, lvds_sels, ARRAY_SIZE(lvds_sels));
np = ccm_node;
base = of_iomap(np, 0);
diff --git a/include/dt-bindings/clock/imx6sx-clock.h
b/include/dt-bindings/clock/imx6sx-clock.h
index 36f0324..cd2d6c5 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -275,6 +275,10 @@
#define IMX6SX_PLL6_BYPASS 262
#define IMX6SX_PLL7_BYPASS 263
#define IMX6SX_CLK_SPDIF_GCLK 264
-#define IMX6SX_CLK_CLK_END 265
+#define IMX6SX_CLK_LVDS2_SEL 265
+#define IMX6SX_CLK_LVDS2_OUT 266
+#define IMX6SX_CLK_LVDS2_IN267
+#define IMX6SX_CLK_ANACLK2 268
+#define IMX6SX_CLK_CLK_END 269
#endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
--
2.7.4
Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property
2018-02-08 4:32 GMT+09:00 Wolfram Sang : > On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote: >> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada : >> > This property is equivalent to "disable-wp" defined in >> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt >> >> This is mistake. >> >> "disable-wp" is defined in >> >> Documentation/devicetree/bindings/mmc/mmc.txt > > With that fixed: > > Reviewed-by: Wolfram Sang > BTW, the subject of the applied version is wrong. In my original post: https://patchwork.kernel.org/patch/10170007/ "toshiba,mmc-wrprotect-disable" No space after the vendor prefix. But, applied commit (788778b0d21a6d5cd5) I see a space, like "toshiba, mmc-wrprotect-disable" I think this is a bug of patchwork. I have seen various bugs that break the patch format. I filed some bug reports for patchwork, but not sure what happened. -- Best Regards Masahiro Yamada
RE: [PATCH 2/2] regulator: pfuze100: update voltage setting for pfuze3000 sw1a
Anson Huang Best Regards! > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Sunday, March 18, 2018 2:27 AM > To: Stefan Wahren > Cc: Rob Herring ; Fabio Estevam > ; Mark Rutland ; Robin > Gong ; Russell King - ARM Linux > ; Anson Huang ; Liam > Girdwood ; Shawn Guo ; > Sascha Hauer ; Mark Brown ; > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > ; dl-linux-imx ; moderated > list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE > ; linux-kernel > > Subject: Re: [PATCH 2/2] regulator: pfuze100: update voltage setting for > pfuze3000 sw1a > > Hi Stefan, > > On Sat, Mar 17, 2018 at 9:35 AM, Stefan Wahren > wrote: > > Hi Anson, > > > >> Anson Huang hat am 17. März 2018 um 07:57 > geschrieben: > >> > >> > >> Latest pfuze3000 datasheet from: > >> > >> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcache.fr > eescale.com%2Ffiles%2Fanalog%2Fdoc%2Fdata_sheet%2FPF3000.pdf%3Ffsrch > %3D1%26sr%3D1%26pageNum%3D1&data=02%7C01%7CAnson.Huang%40nxp > .com%7Cf6e1374a196741efe49b08d58c34bbab%7C686ea1d3bc2b4c6fa92cd99 > c5c301635%7C0%7C1%7C636569080479216580&sdata=DZQFb2hHbYqXjduHC0 > 1z%2FiAT4xvztN4Gy85S89mULwo%3D&reserved=0 > > > > this link goes to Rev. 7.0, 9/2016, which isn't the latest one. > > > > I guess Rev. 9.0, 8/2017 is the latest. > > You are right. This is the link to the latest datasheet: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.n > xp.com%2Fdocs%2Fen%2Fdata-sheet%2FPF3000.pdf&data=02%7C01%7CAnson > .Huang%40nxp.com%7Cf6e1374a196741efe49b08d58c34bbab%7C686ea1d3bc > 2b4c6fa92cd99c5c301635%7C0%7C1%7C636569080479216580&sdata=WIQYD > 7WDn0%2FTl4BzM7oJdSuwK31Z64TfekeBAkou9XQ%3D&reserved=0 Yes, thank you for the reminder, I will update the commit message and the link in V2. Anson.
RE: [PATCH 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range
Anson Huang
Best Regards!
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Saturday, March 17, 2018 10:53 PM
> To: Anson Huang
> Cc: Robin Gong ; Shawn Guo ;
> Sascha Hauer ; Fabio Estevam
> ; Rob Herring ; Mark Rutland
> ; Russell King - ARM Linux ;
> Liam Girdwood ; Mark Brown ;
> dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE ; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; linux-kernel
> Subject: Re: [PATCH 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range
>
> Hi Anson,
>
> On Sat, Mar 17, 2018 at 3:57 AM, Anson Huang
> wrote:
> > Update sw1a/vldo4's voltage range according to latest pfuze3000
> > datasheet from:
> >
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcach
> >
> e.freescale.com%2Ffiles%2Fanalog%2Fdoc%2Fdata_sheet%2FPF3000.pdf%3Ffsr
> >
> ch%3D1%26sr%3D1%26pageNum%3D1&data=02%7C01%7CAnson.Huang%40n
> xp.com%7Cc
> >
> 9614ae26f9443c2d0ae08d58c16cd8a%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0
> > %7C1%7C636568951923456037&sdata=OeM%2B3xPNlm9OETpZcrvG65LjH%
> 2Fp4CRZvyD
> > HT819kuPk%3D&reserved=0
> >
> > Signed-off-by: Anson Huang
> > Signed-off-by: Robin Gong
> > ---
> > arch/arm/boot/dts/imx6sx-udoo-neo.dtsi | 2 +-
> > arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 4 ++--
> > arch/arm/boot/dts/imx7d-nitrogen7.dts | 2 +-
> > arch/arm/boot/dts/imx7d-sdb.dts | 6 +++---
> > arch/arm/boot/dts/imx7s-warp.dts| 2 +-
> > 5 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > index 53b3eac..1de0a0f 100644
> > --- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > +++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > @@ -142,7 +142,7 @@
> > regulators {
> > sw1a_reg: sw1a {
> > regulator-min-microvolt = <70>;
> > - regulator-max-microvolt = <1475000>;
> > + regulator-max-microvolt =
> <330>;
>
> This change does not look like a safe thing to do without carefully checking
> each
> one of the board schematics.
>
> Even if the regulator itself is capable of driving a higher voltage, it does
> not
> mean that the circuitry that consumes such regulator is allowed to receive the
> higher voltages.
I thought the max value here means the capability of regulator itself, like the
internal
anatop LDO regulator VDD_CORE, the max value defined in dtsi is 1.45V, but out
i.MX6
SoCs can NOT receive to voltage higher than 1.3V.
The default setting of PMIC output is controlled by its OTP and the OTP value
should
consider the board design, the rest of voltage setting should be taken care by
device driver.
Here I think the max means PMIC's capability.
Anson.
[PATCH] iommu/mediatek: Fix protect memory setting
In MediaTek's IOMMU design, When a iommu translation fault occurs
(HW can NOT translate the destination address to a valid physical
address), the IOMMU HW output the dirty data into a special memory
to avoid corrupting the main memory, this is called "protect memory".
the register(0x114) for protect memory is a little different between
mt8173 and mt2712.
In the mt8173, bit[30:6] in the register represents [31:7] of the
physical address. In the 4GB mode, the register bit[31] should be 1.
While in the mt2712, the bits don't shift. bit[31:7] in the register
represents [31:7] in the physical address, and bit[1:0] in the
register represents bit[33:32] of the physical address if it has.
Fixes: e6dec9230862 ("iommu/mediatek: Add mt2712 IOMMU support")
Reported-by: Honghui Zhang
Signed-off-by: Yong Wu
---
After adding the setting above, the macro will be complex, like:
#define F_MMU_IVRP_PA_SET(data)({ \
const struct mtk_iommu_data *_data = data; \
phys_addr_t _pa = data->protect_base; \
((_data->m4u_plat == M4U_MT8173) ? \
((_pa >> 1) | (_data->enable_4GB << 31)) : \
(lower_32_bits(_pa) | (_pa >> 32)));\
})
And this macro is called twice(hw_init and resume).
To avoid adding this complex macro or a new function, I put
it in the code and backup its value in the suspend registers.
---
drivers/iommu/mtk_iommu.c | 15 ++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index f227d73..f2832a1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -60,7 +60,7 @@
(((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
#define REG_MMU_IVRP_PADDR 0x114
-#define F_MMU_IVRP_PA_SET(pa, ext) (((pa) >> 1) | ((!!(ext)) <<
31))
+
#define REG_MMU_VLD_PA_RNG 0x118
#define F_MMU_VLD_PA_RNG(EA, SA) (((EA) << 8) | (SA))
@@ -539,8 +539,13 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
- writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
- data->base + REG_MMU_IVRP_PADDR);
+ if (data->m4u_plat == M4U_MT8173)
+ regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
+ else
+ regval = lower_32_bits(data->protect_base) |
+upper_32_bits(data->protect_base);
+ writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
+
if (data->enable_4GB && data->m4u_plat != M4U_MT8173) {
/*
* If 4GB mode is enabled, the validate PA range is from
@@ -695,6 +700,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
*dev)
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
+ reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
clk_disable_unprepare(data->bclk);
return 0;
}
@@ -717,8 +723,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
*dev)
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
- writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
- base + REG_MMU_IVRP_PADDR);
+ writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
if (data->m4u_dom)
writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
base + REG_MMU_PT_BASE_ADDR);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b4451a1..778498b 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -32,6 +32,7 @@ struct mtk_iommu_suspend_reg {
u32 ctrl_reg;
u32 int_control0;
u32 int_main_control;
+ u32 ivrp_paddr;
};
enum mtk_iommu_plat {
--
1.8.1.1.dirty
Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0
On 03/17/2018 04:24 PM, Ram Pai wrote: > So the difference between the two proposals is just the freeing part i.e (b). > Did I get this right? Yeah, I think that's the only difference.
Re: [PATCH v2 net 1/2] vmxnet3: avoid xmit reset due to a race in vmxnet3
From: Ronak Doshi Date: Fri, 16 Mar 2018 14:47:54 -0700 > The field txNumDeferred is used by the driver to keep track of the number > of packets it has pushed to the emulation. The driver increments it on > pushing the packet to the emulation and the emulation resets it to 0 at > the end of the transmit. > > There is a possibility of a race either when (a) ESX is under heavy load or > (b) workload inside VM is of low packet rate. > > This race results in xmit hangs when network coalescing is disabled. This > change creates a local copy of txNumDeferred and uses it to perform ring > arithmetic. > > Reported-by: Noriho Tanaka > Signed-off-by: Ronak Doshi > Acked-by: Shrikrishna Khare Applied.
Re: [PATCH v2 net 2/2] vmxnet3: use correct flag to indicate LRO feature
From: Ronak Doshi
Date: Fri, 16 Mar 2018 14:49:19 -0700
> 'Commit 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2
> (fwd)")' introduced a flag "lro" in structure vmxnet3_adapter which is
> used to indicate whether LRO is enabled or not. However, the patch
> did not set the flag and hence it was never exercised.
>
> So, when LRO is enabled, it resulted in poor TCP performance due to
> delayed acks. This issue is seen with packets which are larger than
> the mss getting a delayed ack rather than an immediate ack, thus
> resulting in high latency.
>
> This patch removes the lro flag and directly uses device features
> against NETIF_F_LRO to check if lro is enabled.
>
> Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)")
> Reported-by: Rachel Lunnon
> Signed-off-by: Ronak Doshi
> Acked-by: Shrikrishna Khare
Applied.
Re: [PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware
On 03/17/2018 04:28 PM, Paul Cercueil wrote: > Add a documentation file about the Timer/Counter Unit (TCU) > present in the Ingenic JZ47xx SoCs. > > Signed-off-by: Paul Cercueil > --- > Documentation/mips/00-INDEX| 3 +++ > Documentation/mips/ingenic-tcu.txt | 50 > ++ > 2 files changed, 53 insertions(+) > create mode 100644 Documentation/mips/ingenic-tcu.txt > > v4: New patch in this series > diff --git a/Documentation/mips/ingenic-tcu.txt > b/Documentation/mips/ingenic-tcu.txt > new file mode 100644 > index ..2508e5793da8 > --- /dev/null > +++ b/Documentation/mips/ingenic-tcu.txt > @@ -0,0 +1,50 @@ > +Ingenic JZ47xx SoCs Timer/Counter Unit hardware > +--- > + > +The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function > +hardware block. It features eight channels, that can be used as counters, drop comma . ^ > +timers, or PWM. > + > +- JZ4770 introduced a separate channel, called Operating System Timer (OST). > + It is a 64-bit programmable timer. > + > +- Each one of the eight channels has its own clock, which can be reparented > + to three different clocks (pclk, ext, rtc), gated, and reclocked, through > + their TCSR register. > + * The watchdog and OST hardware blocks also feature a TCSR register with > + the same format in their register space. > + * The TCU registers used to gate/ungate can also gate/ungate the watchdog > + and OST clocks. > + > +- On SoCs >= JZ4770, there are two different modes: > + * Channels 0, 3-7 operate in TCU1 mode: they cannot work in sleep mode, > + but are easier to operate. > + * Channels 1-2 operate in TCU2 mode: they can work in sleep mode, but > + the operation is a bit more complicated than with TCU1 channels. > + > +- Each channel can generate an interrupt. Some channels share an interrupt > + line, some don't, and this changes between SoC versions: > + * on JZ4740, timer 0 and timer 1 have their own interrupt line; others > share > + one interrupt line. > + * on JZ4770 and JZ4780, timer 5 has its own interrupt; timers 0-4 and 6-7 > all > + use one interrupt line; the OST uses the last interrupt. "The OST uses the last interrupt." is not clear to someone who doesn't know about this hardware. (I can read it several ways.) Does it mean that the 4770 and 4780 have 3 interrupt lines used like so? - timer 5 uses one interrupt line - timers 0-4 and 6-7 use a second interrupt line - the OST uses a third interrupt line thanks, -- ~Randy
Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload
From: Grygorii Strashko Date: Thu, 15 Mar 2018 15:15:50 -0500 > In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host > port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in > CPSW_CONTROL register. VLAN header encapsulation word has following format: > > HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7) > HDR_PKT_CFIbits 28 - Header Packet VLAN CFI bit. > HDR_PKT_Vidbits 27-16 - Header Packet VLAN ID > PKT_Type bits 8-9 - Packet Type. Indicates whether the packet is > VLAN-tagged, priority-tagged, or non-tagged. > 00: VLAN-tagged packet > 01: Reserved > 10: Priority-tagged packet > 11: Non-tagged packet > > This feature can be used to implement TX VLAN offload in case of > VLAN-tagged packets and to insert VLAN tag in case Non-tagged packet was > received on port with PVID set. As per documentation, CPSW never modifies > packet data on Host egress (RX) and as result, without this feature > enabled, Host port will not be able to receive properly packets which > entered switch non-tagged through external Port with PVID set (when > non-tagged packet forwarded from external Port with PVID set to another > external Port - packet will be VLAN tagged properly). > > Implementation details: > - on RX driver will check CPDMA status bit RX_VLAN_ENCAP BIT(19) in CPPI > descriptor to identify when VLAN header encapsulation word is present. > - PKT_Type = 0x01 or 0x02 then ignore VLAN header encapsulation word and > pass packet as is; > - if HDR_PKT_Vid = 0 then ignore VLAN header encapsulation word and pass > packet as is; > - In dual mac mode traffic is separated between ports using default port > vlans, which are not be visible to Host and so should not be reported. > Hence, check for default port vlans in dual mac mode and ignore VLAN header > encapsulation word; > - otherwise fill SKB with VLAN info using __vlan_hwaccel_put_tag(); > - PKT_Type = 0x00 (VLAN-tagged) then strip out VLAN header from SKB. > > Signed-off-by: Grygorii Strashko Applied, thank you.
Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
From: SZ Lin (林上智) Date: Fri, 16 Mar 2018 00:56:01 +0800 > According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and > DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only > available when PHY is configured in RGMII mode with 10Mbps speed. It will > cause some networking issues without RGMII mode, such as carrier sense > errors and low throughput. TI also mentioned this issue in their forum[4]. > > This patch adds the check mechanism for PHY interface with RGMII interface > type, the in-band mode can only be set in RGMII mode with 10Mbps speed. > > References: > [1]: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf > [2]: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf > [3]: http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf > [4]: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/640765/2392155 > > Suggested-by: Holsety Chen (陳憲輝) > Signed-off-by: SZ Lin (林上智) > Signed-off-by: Schuyler Patton Applied and queued up for -stable, thank you.
Re: [PATCH] net: hns: Fix ethtool private flags
From: Matthias Brugger Date: Thu, 15 Mar 2018 17:54:20 +0100 > The driver implementation returns support for private flags, while > no private flags are present. When asked for the number of private > flags it returns the number of statistic flag names. > > Fix this by returning EOPNOTSUPP for not implemented ethtool flags. > > Signed-off-by: Matthias Brugger Looks good, applied, thank you.
Re: [PATCH] MAINTAINERS: update maintainers for MTD and SPI NOR subsystems
On 03/15/2018 08:04 PM, Cyrille Pitchen wrote: > remove myself as MTD and SPI NOR maintainer. > > Signed-off-by: Cyrille Pitchen What happened ? > --- > MAINTAINERS | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3bdc260e36b7..7892db9a9494 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9037,7 +9037,6 @@ M: Brian Norris > M: Boris Brezillon > M: Marek Vasut > M: Richard Weinberger > -M: Cyrille Pitchen > L: linux-...@lists.infradead.org > W: http://www.linux-mtd.infradead.org/ > Q: http://patchwork.ozlabs.org/project/linux-mtd/list/ > @@ -13006,7 +13005,6 @@ F:arch/arm/boot/dts/spear* > F: arch/arm/mach-spear/ > > SPI NOR SUBSYSTEM > -M: Cyrille Pitchen > M: Marek Vasut > L: linux-...@lists.infradead.org > W: http://www.linux-mtd.infradead.org/ > -- Best regards, Marek Vasut
Re: [PATCH v6 15/15] xfs, dax: introduce xfs_break_dax_layouts()
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5]
[cannot apply to next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: x86_64-randconfig-s2-03180641 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
fs//xfs/xfs_file.c: In function 'xfs_break_dax_layouts':
>> fs//xfs/xfs_file.c:786:8: error: implicit declaration of function
>> '___wait_var_event' [-Werror=implicit-function-declaration]
ret = ___wait_var_event(&page->_refcount,
^
fs//xfs/xfs_file.c:788:4: error: invalid use of void expression
0, 0, xfs_wait_var_event(inode, iolock));
^
cc1: some warnings being treated as errors
--
drivers//dax/super.c: In function 'generic_dax_pagefree':
>> drivers//dax/super.c:170:2: error: implicit declaration of function
>> 'wake_up_var' [-Werror=implicit-function-declaration]
wake_up_var(&page->_refcount);
^~~
cc1: some warnings being treated as errors
vim +/___wait_var_event +786 fs//xfs/xfs_file.c
773
774 static int
775 xfs_break_dax_layouts(
776 struct inode*inode,
777 uintiolock)
778 {
779 struct page *page;
780 int ret;
781
782 page = dax_layout_busy_page(inode->i_mapping);
783 if (!page)
784 return 0;
785
> 786 ret = ___wait_var_event(&page->_refcount,
787 atomic_read(&page->_refcount) == 1,
TASK_INTERRUPTIBLE,
788 0, 0, xfs_wait_var_event(inode, iolock));
789 if (ret < 0)
790 return ret;
791 return 1;
792 }
793
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v5 3/8] docs: Add Generic Counter interface documentation
On 03/09/2018 10:42 AM, William Breathitt Gray wrote: > This patch adds high-level documentation about the Generic Counter > interface. > > Signed-off-by: William Breathitt Gray > --- > Documentation/driver-api/generic-counter.rst | 321 > +++ > Documentation/driver-api/index.rst | 1 + > MAINTAINERS | 1 + > 3 files changed, 323 insertions(+) > create mode 100644 Documentation/driver-api/generic-counter.rst > > diff --git a/Documentation/driver-api/generic-counter.rst > b/Documentation/driver-api/generic-counter.rst > new file mode 100644 > index ..bce0cbc31963 > --- /dev/null > +++ b/Documentation/driver-api/generic-counter.rst > @@ -0,0 +1,321 @@ [snip] > +There are three core components to a counter: > + > +COUNT > +- > +A Count represents the count data for a set of Signals. The > +Generic Counter interface provides the following available count > +data types: > + > + * COUNT_POSITION_UNSIGNED: > + Unsigned integer value representing position. > + > + * COUNT_POSITION_SIGNED: > + Signed integer value representing position. > + > +A Count has a count function mode which represents the update > +behavior for the count data. The Generic Counter interface > +provides the following available count function modes: > + > + * Increase: > + Accumulated count is incremented. > + > + * Decrease: > + Accumulated count is decremented. > + > + * Pulse-Direction: > + Rising edges on quadrature pair signal A updates > +the respective count. The input level of > +quadrature pair signal B determines direction. > + > + * Quadrature x1: > + If direction is forward, rising edges on > +quadrature pair signal A updates the respective > +count; if the direction is backward, falling > +edges on quadrature pair signal A updates the > +respective count. Quadrature encoding determines > +the direction. > + > + * Quadrature x2: > + Any state transition on quadrature pair signal A > +updates the respective count. Quadrature > +encoding determines the direction. > + > + * Quadrature x4: > + Any state transition on either quadrature pair > +signals updates the respective count. Quadrature change ^^^ to > +encoding determines the direction. > + > +A Count has a set of one or more associated Signals. > + > +SIGNAL > +-- > +A Signal represents a counter input data; this is the input data > +that is analyzed by the counter to determine the count data; > +e.g. a quadrature signal output line of a rotary encoder. Not > +all counter devices provide user access to the Signal data. > + > +The Generic Counter interface provides the following available > +signal data types for when the Signal data is available for user > +access: > + > + * SIGNAL_LEVEL_LOW: > +Signal line is in a low state. > + > +* SIGNAL_LEVEL_HIGH: > +Signal line is in a high state. > + > +A Signal may be associated to one or more Counts. with (?) Hm, there are around 8 or so instances of "associated to" here -- and at least one of "associated with" (to my surprise :). But it's no big deal. Reviewed-by: Randy Dunlap thanks, -- ~Randy
Re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall
fixed typo in timer_latency.c affecting only -r printout
:
$ gcc -DN_SAMPLES=1000 -o timer timer_latency.c
CLOCK_MONOTONIC ( using rdtscp_ordered() ) :
$ ./timer -m -r 10
sum: 67615
Total time: 0.67615S - Average Latency: 0.00067S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51858
Total time: 0.51858S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51742
Total time: 0.51742S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51944
Total time: 0.51944S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51838
Total time: 0.51838S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52397
Total time: 0.52397S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52428
Total time: 0.52428S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52135
Total time: 0.52135S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52145
Total time: 0.52145S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 53116
Total time: 0.53116S - Average Latency: 0.00053S N zero
deltas: 0 N inconsistent deltas: 0
Average of 10 average latencies of 1000 samples : 0.00053S
CLOCK_MONOTONIC_RAW ( using rdtscp() ) :
$ ./timer -r 10
sum: 25755
Total time: 0.25755S - Average Latency: 0.00025S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21614
Total time: 0.21614S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21616
Total time: 0.21616S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21610
Total time: 0.21610S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21619
Total time: 0.21619S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21617
Total time: 0.21617S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21610
Total time: 0.21610S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16940
Total time: 0.16940S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16939
Total time: 0.16939S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16943
Total time: 0.16943S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
Average of 10 average latencies of 1000 samples : 0.00019S
/*
* Program to measure high-res timer latency.
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef N_SAMPLES
#define N_SAMPLES 100
#endif
#define _STR(_S_) #_S_
#define STR(_S_) _STR(_S_)
#define TS2NS(_TS_) unsigned long long)(_TS_).tv_sec)*10ULL) + (((unsigned long long)((_TS_).tv_nsec
int main(int argc, char *const* argv, char *const* envp)
{ struct timespec sample[N_SAMPLES+1];
unsigned int cnt=N_SAMPLES, s=0 , avg_n=0;
unsigned long long
deltas [ N_SAMPLES ]
, t1, t2, sum=0, zd=0, ic=0, d
, t_start, avg_ns, *avgs=0;
clockid_t clk = CLOCK_MONOTONIC_RAW;
bool do_dump = false;
int argn=1, repeat=1;
for(; argn < argc; argn+=1)
if( argv[argn] != NULL )
if( *(argv[argn]) == '-')
switch( *(argv[argn]+1) )
{ case 'm':
case 'M':
clk = CLOCK_MONOTONIC;
break;
case 'd':
case 'D':
do_dump = true;
break;
case 'r':
case 'R':
if( (argn < argc) && (argv[argn+1] != NULL))
repeat = atoi(argv[argn+=1]);
break;
case '?':
case 'h':
case 'u':
case 'U':
case 'H':
fprintf(stderr,"Usage: timer_latency [\n\t-m : use CLOCK_MONOTONIC clock (not CLOCK_MONOTONIC_RAW)\n\t-d : dump timespec contents. N_SAMPLES: " STR(N_SAMPLES) "\n\t"
"-r \n]\t"
"Calculates average timer latency (minimum time that can be measured) over N_SAMPLES.\n"
);
return 0;
}
if( repeat > 1 )
{ avgs=alloca(sizeof(unsigned long long) * (N_SAMPLES + 1));
if( ((unsigned long) avgs) & 7 )
avgs = ((unsigned long long*)(((unsigned char*)avgs)+(8-((unsigned long) avgs) & 7)));
}
do {
cnt=N_SAMPLES;
s=0;
do
{ if( 0 != clock_gettime(clk, &sample[s++]) )
{ fprintf(stderr,"oops, clock_gettime() failed: %d: '%s'.\n", errno, strerror(errno));
return 1;
}
}while( --cnt );
clock_gettime(clk, &sample[s]);
for(s=1; s < (N_SAMPLES+1); s+=1)
{ t1 = TS2NS(sample[s-1]);
t2 = TS2NS(sample[s]);
if ( (t1 > t2)
||(sample[s-1].tv_sec > sample[s].tv_sec)
||((sample[s-1].tv_sec == sample[s].tv_sec)
&&(sample[s-1].tv_nsec > sample[s].tv_nsec)
)
)
{ fprintf(stderr,"Inconsistency: %llu %llu %lu.%lu %lu.%lu\n", t1 , t2
, sample[s-1].tv_sec, sample[s-1].tv_nsec
, sample[s].tv_sec, sample[s].tv_nsec
);
[PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware
Add a documentation file about the Timer/Counter Unit (TCU) present in the Ingenic JZ47xx SoCs. Signed-off-by: Paul Cercueil --- Documentation/mips/00-INDEX| 3 +++ Documentation/mips/ingenic-tcu.txt | 50 ++ 2 files changed, 53 insertions(+) create mode 100644 Documentation/mips/ingenic-tcu.txt v4: New patch in this series diff --git a/Documentation/mips/00-INDEX b/Documentation/mips/00-INDEX index 8ae9cffc2262..8ab8c3f83771 100644 --- a/Documentation/mips/00-INDEX +++ b/Documentation/mips/00-INDEX @@ -2,3 +2,6 @@ - this file. AU1xxx_IDE.README - README for MIPS AU1XXX IDE driver. +ingenic-tcu.txt + - Information file about the Timer/Counter Unit present + in Ingenic JZ47xx SoCs. diff --git a/Documentation/mips/ingenic-tcu.txt b/Documentation/mips/ingenic-tcu.txt new file mode 100644 index ..2508e5793da8 --- /dev/null +++ b/Documentation/mips/ingenic-tcu.txt @@ -0,0 +1,50 @@ +Ingenic JZ47xx SoCs Timer/Counter Unit hardware +--- + +The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function +hardware block. It features eight channels, that can be used as counters, +timers, or PWM. + +- JZ4770 introduced a separate channel, called Operating System Timer (OST). + It is a 64-bit programmable timer. + +- Each one of the eight channels has its own clock, which can be reparented + to three different clocks (pclk, ext, rtc), gated, and reclocked, through + their TCSR register. + * The watchdog and OST hardware blocks also feature a TCSR register with + the same format in their register space. + * The TCU registers used to gate/ungate can also gate/ungate the watchdog + and OST clocks. + +- On SoCs >= JZ4770, there are two different modes: + * Channels 0, 3-7 operate in TCU1 mode: they cannot work in sleep mode, + but are easier to operate. + * Channels 1-2 operate in TCU2 mode: they can work in sleep mode, but + the operation is a bit more complicated than with TCU1 channels. + +- Each channel can generate an interrupt. Some channels share an interrupt + line, some don't, and this changes between SoC versions: + * on JZ4740, timer 0 and timer 1 have their own interrupt line; others share + one interrupt line. + * on JZ4770 and JZ4780, timer 5 has its own interrupt; timers 0-4 and 6-7 all + use one interrupt line; the OST uses the last interrupt. + +Implementation +-- + +The functionalities of the TCU hardware are spread across multiple drivers: +- interrupts: drivers/irqchip/irq-ingenic-tcu.c +- clocks: drivers/clk/ingenic/tcu.c +- timer:drivers/clocksource/timer-ingenic.c +- PWM: drivers/pwm/pwm-jz4740.c +- watchdog: drivers/watchdog/jz4740_wdt.c +- OST: (none yet) + +Because various functionalities of the TCU that belong to different drivers +and frameworks can be controlled from the same registers, all of these drivers +access their registers through the same regmap. + +In practice, the devicetree nodes for all of these drivers must be children +of a "syscon" node that defines the register area. +For more information regarding the devicetree bindings of the TCU drivers, +have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt. -- 2.11.0
[PATCH v4 6/8] clk: ingenic: Add JZ47xx TCU clocks driver
The TCU (Timer Counter Unit) of the Ingenic JZ47xx SoCs features 8
channels, each one having its own clock, that can be started and
stopped, reparented, and reclocked.
This driver only modifies the bits of the registers of the TCU that are
related to clocks control. It provides one clock per TCU channel (plus
one for the watchdog and one for the OS timer) that can be used by other
drivers.
Signed-off-by: Paul Cercueil
Acked-by: Stephen Boyd
---
drivers/clk/ingenic/Makefile | 2 +-
drivers/clk/ingenic/tcu.c| 319 +++
2 files changed, 320 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/ingenic/tcu.c
v2: - Use SPDX identifier for the license
- Fix broken build caused by typo when correcting patch
v3: - Move documentation to its own patch
- Get rid of ingenic_tcu structure. The "struct regmap *map" was
added to struct ingenic_tcu_clk, the other fields are gone.
- Replace clk_register / clk_register_clockdev /
of_clk_add_provider with their "clk_hw" variant.
v4: No change
diff --git a/drivers/clk/ingenic/Makefile b/drivers/clk/ingenic/Makefile
index 1456e4cdb562..9dcadd4fed4c 100644
--- a/drivers/clk/ingenic/Makefile
+++ b/drivers/clk/ingenic/Makefile
@@ -1,4 +1,4 @@
-obj-y += cgu.o
+obj-y += cgu.o tcu.o
obj-$(CONFIG_MACH_JZ4740) += jz4740-cgu.o
obj-$(CONFIG_MACH_JZ4770) += jz4770-cgu.o
obj-$(CONFIG_MACH_JZ4780) += jz4780-cgu.o
diff --git a/drivers/clk/ingenic/tcu.c b/drivers/clk/ingenic/tcu.c
new file mode 100644
index ..b550b6ac8fb4
--- /dev/null
+++ b/drivers/clk/ingenic/tcu.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic JZ47xx SoC TCU clocks driver
+ * Copyright (C) 2018 Paul Cercueil
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+enum ingenic_version {
+ ID_JZ4740,
+ ID_JZ4770,
+ ID_JZ4780,
+};
+
+struct ingenic_tcu_clk_info {
+ struct clk_init_data init_data;
+ u8 gate_bit;
+ u8 tcsr_reg;
+};
+
+struct ingenic_tcu_clk {
+ struct clk_hw hw;
+
+ struct regmap *map;
+ const struct ingenic_tcu_clk_info *info;
+
+ unsigned int idx;
+};
+
+#define to_tcu_clk(_hw) container_of(_hw, struct ingenic_tcu_clk, hw)
+
+static int ingenic_tcu_enable(struct clk_hw *hw)
+{
+ struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+ const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+
+ regmap_write(tcu_clk->map, TCU_REG_TSCR, BIT(info->gate_bit));
+ return 0;
+}
+
+static void ingenic_tcu_disable(struct clk_hw *hw)
+{
+ struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+ const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+
+ regmap_write(tcu_clk->map, TCU_REG_TSSR, BIT(info->gate_bit));
+}
+
+static int ingenic_tcu_is_enabled(struct clk_hw *hw)
+{
+ struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+ const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+ unsigned int value;
+
+ regmap_read(tcu_clk->map, TCU_REG_TSR, &value);
+
+ return !(value & BIT(info->gate_bit));
+}
+
+static u8 ingenic_tcu_get_parent(struct clk_hw *hw)
+{
+ struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+ const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+ unsigned int val = 0;
+ int ret;
+
+ ret = regmap_read(tcu_clk->map, info->tcsr_reg, &val);
+ WARN_ONCE(ret < 0, "Unable to read TCSR %i", tcu_clk->idx);
+
+ return ffs(val & TCU_TCSR_PARENT_CLOCK_MASK) - 1;
+}
+
+static int ingenic_tcu_set_parent(struct clk_hw *hw, u8 idx)
+{
+ struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+ const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+ struct regmap *map = tcu_clk->map;
+ int ret;
+
+ /*
+* Our clock provider has the CLK_SET_PARENT_GATE flag set, so we know
+* that the clk is in unprepared state. To be able to access TCSR
+* we must ungate the clock supply and we gate it again when done.
+*/
+
+ regmap_write(map, TCU_REG_TSCR, BIT(info->gate_bit));
+
+ ret = regmap_update_bits(map, info->tcsr_reg,
+ TCU_TCSR_PARENT_CLOCK_MASK, BIT(idx));
+ WARN_ONCE(ret < 0, "Unable to update TCSR %i", tcu_clk->idx);
+
+ regmap_write(map, TCU_REG_TSSR, BIT(info->gate_bit));
+
+ return 0;
+}
+
+static unsigned long ingenic_tcu_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+ const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+ unsigned int prescale;
+ int ret;
+
+ ret = regmap_read(tcu_clk->map, info->tcsr_reg, &prescale);
+ WARN_ONCE(ret < 0, "Unable to read TCSR %i", tcu_clk->idx);
+
+ prescale = (prescale & TCU_TCSR_PRESCALE_MASK) >> TCU_TCSR_PRESCALE_LSB;
[PATCH v4 2/8] dt-bindings: ingenic: Add DT bindings for TCU clocks
This header provides clock numbers for the ingenic,tcu DT binding. Signed-off-by: Paul Cercueil Reviewed-by: Rob Herring --- include/dt-bindings/clock/ingenic,tcu.h | 23 +++ 1 file changed, 23 insertions(+) create mode 100644 include/dt-bindings/clock/ingenic,tcu.h v2: Use SPDX identifier for the license v3: No change v4: No change diff --git a/include/dt-bindings/clock/ingenic,tcu.h b/include/dt-bindings/clock/ingenic,tcu.h new file mode 100644 index ..179815d7b3bb --- /dev/null +++ b/include/dt-bindings/clock/ingenic,tcu.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * This header provides clock numbers for the ingenic,tcu DT binding. + */ + +#ifndef __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ +#define __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ + +#define JZ4740_CLK_TIMER0 0 +#define JZ4740_CLK_TIMER1 1 +#define JZ4740_CLK_TIMER2 2 +#define JZ4740_CLK_TIMER3 3 +#define JZ4740_CLK_TIMER4 4 +#define JZ4740_CLK_TIMER5 5 +#define JZ4740_CLK_TIMER6 6 +#define JZ4740_CLK_TIMER7 7 +#define JZ4740_CLK_WDT 8 +#define JZ4740_CLK_LASTJZ4740_CLK_WDT + +#define JZ4770_CLK_OST 9 +#define JZ4770_CLK_LASTJZ4770_CLK_OST + +#endif /* __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ */ -- 2.11.0
[PATCH v4 7/8] clocksource: Add a new timer-ingenic driver
This driver will use the TCU (Timer Counter Unit) present on the Ingenic
JZ47xx SoCs to provide the kernel with a clocksource and timers.
Signed-off-by: Paul Cercueil
---
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/Makefile| 1 +
drivers/clocksource/timer-ingenic.c | 278
3 files changed, 287 insertions(+)
create mode 100644 drivers/clocksource/timer-ingenic.c
v2: Use SPDX identifier for the license
v3: - Move documentation to its own patch
- Search the devicetree for PWM clients, and use all the TCU
channels that won't be used for PWM
v4: - Add documentation about why we search for PWM clients
- Verify that the PWM clients are for the TCU PWM driver
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index d2e5382821a4..481422145fb4 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -592,4 +592,12 @@ config CLKSRC_ST_LPC
Enable this option to use the Low Power controller timer
as clocksource.
+config INGENIC_TIMER
+ bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
+ depends on MACH_INGENIC || COMPILE_TEST
+ select CLKSRC_OF
+ default y
+ help
+ Support for the timer/counter unit of the Ingenic JZ SoCs.
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index d6dec4489d66..98691e8999fe 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -74,5 +74,6 @@ obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
+obj-$(CONFIG_INGENIC_TIMER)+= timer-ingenic.o
obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
obj-$(CONFIG_X86_NUMACHIP) += numachip.o
diff --git a/drivers/clocksource/timer-ingenic.c
b/drivers/clocksource/timer-ingenic.c
new file mode 100644
index ..8c777c0c0023
--- /dev/null
+++ b/drivers/clocksource/timer-ingenic.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic JZ47xx SoC TCU clocksource driver
+ * Copyright (C) 2018 Paul Cercueil
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NUM_CHANNELS 8
+
+struct ingenic_tcu;
+
+struct ingenic_tcu_channel {
+ unsigned int idx;
+ struct clk *clk;
+};
+
+struct ingenic_tcu {
+ struct ingenic_tcu_channel channels[NUM_CHANNELS];
+ unsigned long requested;
+ struct regmap *map;
+};
+
+struct ingenic_clock_event_device {
+ struct clock_event_device cevt;
+ struct ingenic_tcu_channel *channel;
+ char name[32];
+};
+
+#define ingenic_cevt(_evt) \
+ container_of(_evt, struct ingenic_clock_event_device, cevt)
+
+static inline struct ingenic_tcu *to_ingenic_tcu(struct ingenic_tcu_channel
*ch)
+{
+ return container_of(ch, struct ingenic_tcu, channels[ch->idx]);
+}
+
+static int ingenic_tcu_cevt_set_state_shutdown(struct clock_event_device *evt)
+{
+ struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
+ struct ingenic_tcu_channel *channel = jzcevt->channel;
+ struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+ unsigned int idx = channel->idx;
+
+ regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
+ return 0;
+}
+
+static int ingenic_tcu_cevt_set_next(unsigned long next,
+ struct clock_event_device *evt)
+{
+ struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
+ struct ingenic_tcu_channel *channel = jzcevt->channel;
+ struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+ unsigned int idx = channel->idx;
+
+ if (next > 0x)
+ return -EINVAL;
+
+ regmap_write(tcu->map, TCU_REG_TDFRc(idx), (unsigned int) next);
+ regmap_write(tcu->map, TCU_REG_TCNTc(idx), 0);
+ regmap_write(tcu->map, TCU_REG_TESR, BIT(idx));
+
+ return 0;
+}
+
+static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
+{
+ struct clock_event_device *cevt = dev_id;
+ struct ingenic_clock_event_device *jzcevt = ingenic_cevt(cevt);
+ struct ingenic_tcu_channel *channel = jzcevt->channel;
+ struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+ unsigned int idx = channel->idx;
+
+ regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
+
+ if (cevt->event_handler)
+ cevt->event_handler(cevt);
+
+ return IRQ_HANDLED;
+}
+
+static int __init ingenic_tcu_req_channel(struct ingenic_tcu_channel *channel)
+{
+ struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+ char buf[16];
+ int err;
+
+ if (test_and_set_bit(channel->idx, &tcu->requested))
+ return -EBUSY;
+
+ snprintf(buf, sizeof(buf), "timer%u", channel->idx);
[PATCH v4 8/8] MAINTAINERS: Add myself as maintainer for Ingenic TCU drivers
Add myself as maintainer for the ingenic-tcu-intc interrupt controller driver, the ingenic-tcu-clocks clock driver, and the ingenic-tcu clocksource driver. Signed-off-by: Paul Cercueil --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) v2: No change v3: No change v4: No change diff --git a/MAINTAINERS b/MAINTAINERS index 4623caf8d72d..46d3955b92aa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6959,6 +6959,15 @@ L: linux-...@lists.infradead.org S: Maintained F: drivers/mtd/nand/jz4780_* +INGENIC JZ47xx TCU drivers +M: Paul Cercueil +S: Maintained +F: drivers/clk/ingenic/tcu.c +F: drivers/irqchip/irq-ingenic-tcu.c +F: drivers/clocksource/timer-ingenic.c +F: include/linux/mfd/syscon/ingenic-tcu.h +F: include/dt-bindings/clock/ingenic,tcu.h + INOTIFY M: Jan Kara R: Amir Goldstein -- 2.11.0
[PATCH v4 5/8] irqchip: Add the ingenic-tcu-intc driver
This simple driver handles the IRQ chip of the TCU
(Timer Counter Unit) of the JZ47xx Ingenic SoCs.
Signed-off-by: Paul Cercueil
---
drivers/irqchip/Kconfig | 6 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ingenic-tcu.c | 161 ++
3 files changed, 168 insertions(+)
create mode 100644 drivers/irqchip/irq-ingenic-tcu.c
v2: - Use SPDX identifier for the license
- Make KConfig option select CONFIG_IRQ_DOMAIN since we depend on it
v3: - Move documentation to its own patch
- Add comment explaining why we only use IRQCHIP_DECLARE
v4: - Rename variables to avoid splitting long lines
- Add comment about the multiple IRQ parents
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d913aec85109..2b56587d04ed 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -267,6 +267,12 @@ config INGENIC_IRQ
depends on MACH_INGENIC
default y
+config INGENIC_TCU_IRQ
+ bool
+ depends on MACH_INGENIC || COMPILE_TEST
+ select IRQ_DOMAIN
+ default y
+
config RENESAS_H8300H_INTC
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index d27e3e3619e0..48b0bdf2b1a2 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
+obj-$(CONFIG_INGENIC_TCU_IRQ) += irq-ingenic-tcu.o
obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
obj-$(CONFIG_PIC32_EVIC) += irq-pic32-evic.o
obj-$(CONFIG_MVEBU_GICP) += irq-mvebu-gicp.o
diff --git a/drivers/irqchip/irq-ingenic-tcu.c
b/drivers/irqchip/irq-ingenic-tcu.c
new file mode 100644
index ..add3e9cc6f82
--- /dev/null
+++ b/drivers/irqchip/irq-ingenic-tcu.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ47xx SoCs TCU IRQ driver
+ * Copyright (C) 2018 Paul Cercueil
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static void ingenic_tcu_intc_cascade(struct irq_desc *desc)
+{
+ struct irq_chip *irq_chip = irq_data_get_irq_chip(&desc->irq_data);
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(domain, 0);
+ struct regmap *map = gc->private;
+ uint32_t irq_reg, irq_mask;
+ unsigned int i;
+
+ regmap_read(map, TCU_REG_TFR, &irq_reg);
+ regmap_read(map, TCU_REG_TMR, &irq_mask);
+
+ chained_irq_enter(irq_chip, desc);
+
+ irq_reg &= ~irq_mask;
+
+ for (i = 0; i < 32; i++) {
+ if (irq_reg & BIT(i))
+ generic_handle_irq(irq_linear_revmap(domain, i));
+ }
+
+ chained_irq_exit(irq_chip, desc);
+}
+
+static void ingenic_tcu_gc_unmask_enable_reg(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ struct regmap *map = gc->private;
+ u32 mask = d->mask;
+
+ irq_gc_lock(gc);
+ regmap_write(map, ct->regs.ack, mask);
+ regmap_write(map, ct->regs.enable, mask);
+ *ct->mask_cache |= mask;
+ irq_gc_unlock(gc);
+}
+
+static void ingenic_tcu_gc_mask_disable_reg(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ struct regmap *map = gc->private;
+ u32 mask = d->mask;
+
+ irq_gc_lock(gc);
+ regmap_write(map, ct->regs.disable, mask);
+ *ct->mask_cache &= ~mask;
+ irq_gc_unlock(gc);
+}
+
+static void ingenic_tcu_gc_mask_disable_reg_and_ack(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ struct regmap *map = gc->private;
+ u32 mask = d->mask;
+
+ irq_gc_lock(gc);
+ regmap_write(map, ct->regs.ack, mask);
+ regmap_write(map, ct->regs.disable, mask);
+ irq_gc_unlock(gc);
+}
+
+static int __init ingenic_tcu_intc_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+ struct irq_domain *domain;
+ struct irq_chip_generic *gc;
+ struct irq_chip_type *ct;
+ int err, i, irqs;
+ u32 parent_irqs[3];
+ struct regmap *map;
+
+ irqs = of_property_count_elems_of_size(node, "interrupts", sizeof(u32));
+ if (irqs < 0 || irqs > ARRAY_SIZE(parent_irqs))
+ return -EINVAL;
+
+ map = syscon_node_to_regmap(node->parent);
+ if (IS_ERR(map))
+ return PTR_ERR(map);
+
+ domain = irq_domain_add_linear(node, 32, &irq_generic_chip_ops,
[PATCH v4 0/8] Ingenic JZ47xx Timer/Counter Unit drivers
Hi, This is the 4th version of my TCU patchset. The major change is a greatly improved documentation, both in-code and as separate text files, to describe how the hardware works and how the devicetree bindings should be used. There are also cosmetic changes in the irqchip driver, and the clocksource driver will now use as timers all TCU channels not requested by the TCU PWM driver. Cheers, -Paul
[PATCH v4 1/8] mfd: syscon: Add ingenic-tcu.h header
This header contains macros for the registers that are present in the regmap shared by all the drivers related to the TCU (Timer Counter Unit) of the Ingenic JZ47xx SoCs. Signed-off-by: Paul Cercueil Acked-by: Lee Jones --- include/linux/mfd/syscon/ingenic-tcu.h | 54 ++ 1 file changed, 54 insertions(+) create mode 100644 include/linux/mfd/syscon/ingenic-tcu.h v2: Use SPDX identifier for the license v3: - Use macros instead of enum - Add 'TCU_' at the beginning of each macro - Remove useless include v4: No change diff --git a/include/linux/mfd/syscon/ingenic-tcu.h b/include/linux/mfd/syscon/ingenic-tcu.h new file mode 100644 index ..96dd59f7c3b2 --- /dev/null +++ b/include/linux/mfd/syscon/ingenic-tcu.h @@ -0,0 +1,54 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Header file for the Ingenic JZ47xx TCU driver + */ +#ifndef __LINUX_CLK_INGENIC_TCU_H_ +#define __LINUX_CLK_INGENIC_TCU_H_ + +#include + +#define TCU_REG_WDT_TDR0x00 +#define TCU_REG_WDT_TCER 0x04 +#define TCU_REG_WDT_TCNT 0x08 +#define TCU_REG_WDT_TCSR 0x0c +#define TCU_REG_TER0x10 +#define TCU_REG_TESR 0x14 +#define TCU_REG_TECR 0x18 +#define TCU_REG_TSR0x1c +#define TCU_REG_TFR0x20 +#define TCU_REG_TFSR 0x24 +#define TCU_REG_TFCR 0x28 +#define TCU_REG_TSSR 0x2c +#define TCU_REG_TMR0x30 +#define TCU_REG_TMSR 0x34 +#define TCU_REG_TMCR 0x38 +#define TCU_REG_TSCR 0x3c +#define TCU_REG_TDFR0 0x40 +#define TCU_REG_TDHR0 0x44 +#define TCU_REG_TCNT0 0x48 +#define TCU_REG_TCSR0 0x4c +#define TCU_REG_OST_DR 0xe0 +#define TCU_REG_OST_CNTL 0xe4 +#define TCU_REG_OST_CNTH 0xe8 +#define TCU_REG_OST_TCSR 0xec +#define TCU_REG_TSTR 0xf0 +#define TCU_REG_TSTSR 0xf4 +#define TCU_REG_TSTCR 0xf8 +#define TCU_REG_OST_CNTHBUF0xfc + +#define TCU_TCSR_RESERVED_BITS 0x3f +#define TCU_TCSR_PARENT_CLOCK_MASK 0x07 +#define TCU_TCSR_PRESCALE_LSB 3 +#define TCU_TCSR_PRESCALE_MASK 0x38 + +#define TCU_TCSR_PWM_SDBIT(9) /* 0: Shutdown abruptly 1: gracefully */ +#define TCU_TCSR_PWM_INITL_HIGHBIT(8) /* Sets the initial output level */ +#define TCU_TCSR_PWM_ENBIT(7) /* PWM pin output enable */ + +#define TCU_CHANNEL_STRIDE 0x10 +#define TCU_REG_TDFRc(c) (TCU_REG_TDFR0 + ((c) * TCU_CHANNEL_STRIDE)) +#define TCU_REG_TDHRc(c) (TCU_REG_TDHR0 + ((c) * TCU_CHANNEL_STRIDE)) +#define TCU_REG_TCNTc(c) (TCU_REG_TCNT0 + ((c) * TCU_CHANNEL_STRIDE)) +#define TCU_REG_TCSRc(c) (TCU_REG_TCSR0 + ((c) * TCU_CHANNEL_STRIDE)) + +#endif /* __LINUX_CLK_INGENIC_TCU_H_ */ -- 2.11.0
[PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers
Add documentation about how to properly use the Ingenic TCU
(Timer/Counter Unit) drivers from devicetree.
Signed-off-by: Paul Cercueil
---
.../bindings/clock/ingenic,tcu-clocks.txt | 42
.../bindings/interrupt-controller/ingenic,tcu.txt | 39 +++
.../devicetree/bindings/mfd/ingenic,tcu.txt| 56 ++
.../devicetree/bindings/timer/ingenic,tcu.txt | 41
4 files changed, 178 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
create mode 100644 Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt
v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
added content.
diff --git a/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
new file mode 100644
index ..471d27078599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
@@ -0,0 +1,42 @@
+Ingenic SoC TCU binding
+
+The TCU is the Timer/Counter Unit present in all Ingenic SoCs. It features 8
+channels, each one having its own clock, that can be started and stopped,
+reparented, and reclocked.
+
+Required properties:
+- compatible : One of:
+ * ingenic,jz4740-tcu-clocks,
+ * ingenic,jz4770-tcu-clocks,
+ * ingenic,jz4780-tcu-clocks.
+- clocks : List of phandle & clock specifiers for clocks external to the TCU.
+ The "pclk", "rtc" and "ext" clocks should be provided.
+- clock-names : List of name strings for the external clocks.
+- #clock-cells: Should be 1.
+ Clock consumers specify this argument to identify a clock. The valid values
+ may be found in .
+
+Example:
+
+/ {
+ tcu: mfd@10002000 {
+ compatible = "ingenic,tcu", "simple-mfd", "syscon";
+ reg = <0x10002000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x10002000 0x1000>;
+
+ tcu_clk: clocks@10 {
+ compatible = "ingenic,jz4740-tcu-clocks";
+ reg = <0x10 0xff0>;
+
+ clocks = <&ext>, <&rtc>, <&pclk>;
+ clock-names = "ext", "rtc", "pclk";
+
+ #clock-cells = <1>;
+ };
+ };
+};
+
+For information about the top-level "ingenic,tcu" compatible node and other
+children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
new file mode 100644
index ..7f3af2da77cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
@@ -0,0 +1,39 @@
+Ingenic SoCs Timer/Counter Unit Interrupt Controller
+
+Required properties:
+
+- compatible : should be "ingenic,-tcu-intc". Valid strings are:
+ * ingenic,jz4740-tcu-intc
+ * ingenic,jz4770-tcu-intc
+ * ingenic,jz4780-tcu-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 1.
+- interrupt-parent : phandle of the interrupt controller.
+- interrupts : Specifies the interrupt the controller is connected to.
+
+Example:
+
+/ {
+ tcu: mfd@10002000 {
+ compatible = "ingenic,tcu", "simple-mfd", "syscon";
+ reg = <0x10002000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x10002000 0x1000>;
+
+ tcu_irq: interrupt-controller@20 {
+ compatible = "ingenic,jz4740-tcu-intc";
+ reg = <0x20 0x20>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <15>;
+ };
+ };
+};
+
+For information about the top-level "ingenic,tcu" compatible node and other
+children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
diff --git a/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
new file mode 100644
index ..5742c3f21550
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
@@ -0,0 +1,56 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
+--
+
+For a description of the TCU hardware and drivers, have a look at
+Documentation/mips/ingenic-tcu.txt.
+
+The TCU is implemented as a parent node, whose role is to create the
+regmap, and child nodes for the various drivers listed in the aforementioned
+docu
Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0
On Fri, Mar 16, 2018 at 02:46:56PM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
>
> mm_pkey_is_allocated() treats pkey 0 as unallocated. That is
> inconsistent with the manpages, and also inconsistent with
> mm->context.pkey_allocation_map. Stop special casing it and only
> disallow values that are actually bad (< 0).
>
> The end-user visible effect of this is that you can now use
> mprotect_pkey() to set pkey=0.
>
> This is a bit nicer than what Ram proposed because it is simpler
> and removes special-casing for pkey 0. On the other hand, it does
> allow applciations to pkey_free() pkey-0, but that's just a silly
> thing to do, so we are not going to protect against it.
So your proposal
(a) allocates pkey 0 implicitly,
(b) does not stop anyone from freeing pkey-0
(c) and allows pkey-0 to be explicitly associated with any address range.
correct?
My proposal
(a) allocates pkey 0 implicitly,
(b) stops anyone from freeing pkey-0
(c) and allows pkey-0 to be explicitly associated with any address range.
So the difference between the two proposals is just the freeing part i.e (b).
Did I get this right?
Its a philosophical debate; allow the user
to shoot-in-the-feet or stop from not doing so. There is no
clear answer either way. I am fine either way.
So here is my
Reviewed-by: Ram Pai
I will write a corresponding patch for powerpc.
>
> Signed-off-by: Dave Hansen
> Cc: Ram Pai
> Cc: Thomas Gleixner
> Cc: Dave Hansen
> Cc: Michael Ellermen
> Cc: Ingo Molnar
> Cc: Andrew Morton p
> Cc: Shuah Khan
> ---
>
> b/arch/x86/include/asm/mmu_context.h |2 +-
> b/arch/x86/include/asm/pkeys.h |6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff -puN arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated
> arch/x86/include/asm/mmu_context.h
> --- a/arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated
> 2018-03-16 14:46:39.023285476 -0700
> +++ b/arch/x86/include/asm/mmu_context.h 2018-03-16 14:46:39.028285476
> -0700
> @@ -191,7 +191,7 @@ static inline int init_new_context(struc
>
> #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> if (cpu_feature_enabled(X86_FEATURE_OSPKE)) {
> - /* pkey 0 is the default and always allocated */
> + /* pkey 0 is the default and allocated implicitly */
> mm->context.pkey_allocation_map = 0x1;
> /* -1 means unallocated or invalid */
> mm->context.execute_only_pkey = -1;
> diff -puN arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated
> arch/x86/include/asm/pkeys.h
> --- a/arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated
> 2018-03-16 14:46:39.025285476 -0700
> +++ b/arch/x86/include/asm/pkeys.h2018-03-16 14:46:39.028285476 -0700
> @@ -49,10 +49,10 @@ bool mm_pkey_is_allocated(struct mm_stru
> {
> /*
>* "Allocated" pkeys are those that have been returned
> - * from pkey_alloc(). pkey 0 is special, and never
> - * returned from pkey_alloc().
> + * from pkey_alloc() or pkey 0 which is allocated
> + * implicitly when the mm is created.
>*/
> - if (pkey <= 0)
> + if (pkey < 0)
> return false;
> if (pkey >= arch_max_pkey())
> return false;
> _
--
Ram Pai
Re: linux-next: build failure after merge of the y2038 tree
I posted the patch.
The patch has simple changes. Let me know if maybe posting a new
version makes sense.
I also needed this patch to build linux-next:
commit b784c76bb7c1c440a4ce06a18f4b3a936f33967d
Author: Deepa Dinamani
Date: Fri Mar 16 20:57:10 2018 -0700
i40iw: add missing irq.h include
iwarp driver began using irq_get_affinity_mask in commit 7e952b19eb638.
Add the needed include irq.h to get the definition.
This was found while trying allmodconfig for arm64, s390, and sparc.
Signed-off-by: Deepa Dinamani
diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
index a51798578f27..506b10e8ea4e 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -32,6 +32,7 @@
*
***/
+#include
#include
#include
#include
-Deepa
On Fri, Mar 16, 2018 at 1:14 AM, Arnd Bergmann wrote:
> On Fri, Mar 16, 2018 at 6:23 AM, Deepa Dinamani
> wrote:
>> Hi Arnd,
>>
>> Do you want me to send the fix as a patch or should I re-post the series?
>
> Please send a fix relative to linux-next. Due to my travel next week, I might
> not be able to apply it right away but maybe Stephen can add it on top until
> I get back.
>
> Arnd
>
>> On Thu, Mar 15, 2018 at 7:25 PM, Stephen Rothwell
>> wrote:
>>> Hi Arnd,
>>>
>>> After merging the y2038 tree, today's linux-next build (s390 allnoconfig)
>>> failed like this:
>>>
>>> In file included from include/linux/elf.h:5:0,
>>> from include/linux/module.h:15,
>>> from init/main.c:16:
>>> arch/s390/include/asm/elf.h:138:1: error: unknown type name
>>> 's390_compat_regs'
>>>
>>> Caused by commit
>>>
>>> f00689038f71 ("include: Move compat_timespec/ timeval to compat_time.h")
>>>
[PATCH] s390: Use asm/compat.h instead of linux/compat.h
Include asm/compat.h directly for uses of compat_ptr. This includes the compat defines when CONFIG_COMPAT is not on. Also make compat data structure definitions conditional on CONFIG_COMPAT, to remove circular include dependencies in elf.h Cc: David Hildenbrand Cc: linux-s...@vger.kernel.org Signed-off-by: Deepa Dinamani --- arch/s390/hypfs/hypfs_sprp.c | 1 + arch/s390/include/asm/compat.h| 1 + arch/s390/include/asm/elf.h | 2 ++ arch/s390/kvm/priv.c | 2 +- arch/s390/pci/pci_clp.c | 1 + drivers/s390/block/dasd_ioctl.c | 2 +- drivers/s390/char/fs3270.c| 2 +- drivers/s390/char/sclp_ctl.c | 1 + drivers/s390/char/vmcp.c | 1 + drivers/s390/cio/chsc_sch.c | 2 +- drivers/s390/net/qeth_core_main.c | 2 +- 11 files changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/s390/hypfs/hypfs_sprp.c b/arch/s390/hypfs/hypfs_sprp.c index 5d85a039391c..d800b8067042 100644 --- a/arch/s390/hypfs/hypfs_sprp.c +++ b/arch/s390/hypfs/hypfs_sprp.c @@ -7,6 +7,7 @@ *Author(s): Martin Schwidefsky */ +#include #include #include #include diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h index 501aaff85304..1832d98c9328 100644 --- a/arch/s390/include/asm/compat.h +++ b/arch/s390/include/asm/compat.h @@ -4,6 +4,7 @@ /* * Architecture specific compatibility types */ +#include #include #include #include diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h index 7d22a474a040..e572ae613b19 100644 --- a/arch/s390/include/asm/elf.h +++ b/arch/s390/include/asm/elf.h @@ -134,8 +134,10 @@ typedef s390_fp_regs elf_fpregset_t; typedef s390_regs elf_gregset_t; +#ifdef CONFIG_COMPAT typedef s390_fp_regs compat_elf_fpregset_t; typedef s390_compat_regs compat_elf_gregset_t; +#endif #include /* for task_struct */ #include diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c index a3bce0e84346..b7e6d81547bd 100644 --- a/arch/s390/kvm/priv.c +++ b/arch/s390/kvm/priv.c @@ -11,7 +11,7 @@ #include #include #include -#include +#include #include #include diff --git a/arch/s390/pci/pci_clp.c b/arch/s390/pci/pci_clp.c index 19b2d2a9b43d..4b6fe97823b7 100644 --- a/arch/s390/pci/pci_clp.c +++ b/arch/s390/pci/pci_clp.c @@ -9,6 +9,7 @@ #define KMSG_COMPONENT "zpci" #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt +#include #include #include #include diff --git a/drivers/s390/block/dasd_ioctl.c b/drivers/s390/block/dasd_ioctl.c index 2016e0ed5865..288fa9d4d105 100644 --- a/drivers/s390/block/dasd_ioctl.c +++ b/drivers/s390/block/dasd_ioctl.c @@ -13,7 +13,7 @@ #define KMSG_COMPONENT "dasd" #include -#include +#include #include #include #include diff --git a/drivers/s390/char/fs3270.c b/drivers/s390/char/fs3270.c index 16a4e8528bbc..cf4a26c6f76d 100644 --- a/drivers/s390/char/fs3270.c +++ b/drivers/s390/char/fs3270.c @@ -12,7 +12,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/drivers/s390/char/sclp_ctl.c b/drivers/s390/char/sclp_ctl.c index 248b5db3eaa8..bd0d9e5cabd7 100644 --- a/drivers/s390/char/sclp_ctl.c +++ b/drivers/s390/char/sclp_ctl.c @@ -7,6 +7,7 @@ * Author: Michael Holzheu */ +#include #include #include #include diff --git a/drivers/s390/char/vmcp.c b/drivers/s390/char/vmcp.c index 948ce82a7725..0a153741ea88 100644 --- a/drivers/s390/char/vmcp.c +++ b/drivers/s390/char/vmcp.c @@ -14,6 +14,7 @@ #include #include +#include #include #include #include diff --git a/drivers/s390/cio/chsc_sch.c b/drivers/s390/cio/chsc_sch.c index 8d9f36625ba5..3a541e694cb1 100644 --- a/drivers/s390/cio/chsc_sch.c +++ b/drivers/s390/cio/chsc_sch.c @@ -9,7 +9,7 @@ */ #include -#include +#include #include #include #include diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c index d3529ef6e0f7..adde6b30bad6 100644 --- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -10,7 +10,7 @@ #define KMSG_COMPONENT "qeth" #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt -#include +#include #include #include #include -- 2.14.1
Re: [PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall
On Sat, Mar 17, 2018 at 02:29:34PM +, jason.vas.d...@gmail.com wrote: > This patch allows compilation to succeed with compilers that support > -DRETPOLINE - > it was kindly contributed by H.J. Liu in GCC Bugzilla: 84908 : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908 > > Apparently the GCC retpoline implementation has a limitation that it > cannot > handle switch statements with more than 5 clauses, which > vclock_gettime.c's > __vdso_clock_gettime function now conts. That's quite a mischaracterization of the issue. gcc works as intended, but the kernel did not correctly supply a indirect call retpoline thunk to the vdso, and it just happened to work by accident with the old vdso. > > The automated test builds should now succeed with this patch. How about just adding the thunk function to the vdso object instead of this cheap hack? The other option would be to build vdso with inline thunks. But just disabling is completely the wrong action. -Andi > > > diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile > index 1943aeb..cb64e10 100644 > --- a/arch/x86/entry/vdso/Makefile > +++ b/arch/x86/entry/vdso/Makefile > @@ -76,7 +76,7 @@ CFL := $(PROFILING) -mcmodel=small -fPIC -O2 > -fasynchronous-unwind-tables -m64 \ > -fno-omit-frame-pointer -foptimize-sibling-calls \ > -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO > > -$(vobjs): KBUILD_CFLAGS := $(filter-out > $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) $(CFL) > +$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) > $(RETPOLINE_CFLAGS) -DRETPOLINE,$(KBUILD_CFLAGS)) $(CFL) > > # > # vDSO code runs in userspace and -pg doesn't help with profiling anyway. > @@ -143,6 +143,7 @@ KBUILD_CFLAGS_32 := $(filter-out > -mcmodel=kernel,$(KBUILD_CFLAGS_32)) > KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32)) > KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32)) > KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32)) > +KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS) > -DRETPOLINE,$(KBUILD_CFLAGS_32)) > KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic > KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector) > KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls) >
Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
On Sat, Mar 17, 2018 at 01:07:32PM -0700, Kees Cook wrote: > On Sat, Mar 17, 2018 at 11:52 AM, Linus Torvalds > wrote: > > So the above is completely insane, bit there is actually a chance that > > using that completely crazy "x -> sizeof(char[x])" conversion actually > > helps, because it really does have a (very odd) evaluation-time > > change. sizeof() has to be evaluated as part of the constant > > expression evaluation, in ways that "__builtin_constant_p()" isn't > > specified to be done. > > > > But it is also definitely me grasping at straws. If that doesn't work > > for 4.4, there's nothing else I can possibly see. > > No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only > does it not change the complaint about __builtin_choose_expr(), it > also thinks that's a VLA now. > > ./include/linux/mm.h: In function ‘get_mm_hiwater_rss’: > ./include/linux/mm.h:1567: warning: variable length array is used > ./include/linux/mm.h:1567: error: first argument to > ‘__builtin_choose_expr’ not a constant > > 6.8 is happy with it (of course). > > I do think the earlier version (without the > sizeof-hiding-builting_constant_p) provides a template for a > const_max() that both you and Rasmus would be happy with, though! I thought we were dropping support for 4.4 (for other reasons). Isn't it 4.6 we should be looking at? -- Josh
re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall
Hi -
I submitted a new stripped-down to bare essentials version of
the patch, (see LKML emails with $subject) which passes all
checkpatch.pl tests and addresses all concerns raised by reviewers,
which uses only rdtsc_ordered(), and which only only updates in
vsyscall_gtod_data the new fields:
u32 raw_mult, raw_shift ; ...
gtod_long_t monotonic_time_raw_sec /* == tk->raw_sec */ ,
monotonic_time_raw_nsec /* == tk->tkr_raw.nsec */;
(this is NOT the formatting used in vgtod.h - sorry about previous
formatting issues .
) .
I don't see how one could present the raw timespec in user-space
properly without tk->tkr_raw.xtime_nsec and and tk->raw_sec ;
monotonic has gtod->monotonic_time_sec and gtod->monotonic_time_snsec,
and I am only trying to follow exactly the existing algorithm in
timekeeping.c's
getrawmonotonic64() .
When I submitted the initial version of this stripped down patch,
I got an email back from robot reporting a compilation
error saying :
>
> arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
> vclock_gettime.c:(.text+0xf7): undefined reference to
> >`__x86_indirect_thunk_rax'
> /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32
> >against undefined symbol `__x86_indirect_thunk_rax' can not be used when
> making >a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
>>> collect2: error: ld returned 1 exit status
>--
>>> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
>--
>>> objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
>---
I had fixed this problem with the patch to the RHEL kernel attached to
bug #198161 (attachment #274751:
https://bugzilla.kernel.org/attachment.cgi?id=274751) ,
by simply reducing the number of clauses in __vdso_clock_gettime's
switch(clock) from 6 to 5 , but at the cost of an extra test of clock
& second switch(clock).
I reported this as GCC bug :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
because I don't think GCC should fail to do anything
for a switch with 6 clauses and not for one with 5, but
the response I got from H.J. Liu was:
H.J. Lu wrote @ 2018-03-16 22:13:27 UTC:
>
> vDSO isn't compiled with $(KBUILD_CFLAGS). Why does your kernel do it?
>
> Please try my kernel patch at comment 4..
>
So that patch to the arch/x86/vdso/Makefile only prevents it enabling the
RETPOLINE_CFLAGS for building the vDSO .
I defer to H.J.'s expertise on GCC + binutils & advisability of enabling
RETPOLINE_CFLAGS in the VDSO - GCC definitely behaves strangely
for the vDSO when RETPOLINE _CFLAGS are enabled.
Please provide something like the patch in a future version of Linux ,
and I suggest not compiling the vDSO with RETPOLINE_CFLAGS
as does H.J. .
The inconsistency_check program in tools/testing/selftests/timers produces
no errors for long runs and the timer_latency.c program (attached) also
produces no errors and latencies of @ 20ns for CLOCK_MONOTONIC_RAW
and latencies of @ 40ns for CLOCK_MONOTONIC - this is however
with the additional rdtscp patches , and under 4.15.9, for use on my system ;
the 4.16-rc5 version submitted still uses barrier() + rdtsc , and
that has a latency
of @ 30ns for CLOCK_MONOTONIC_RAW and @40ns for CLOCK_MONOTONIC ; but
both are much, much better that
200-1000ns for CLOCK_MONOTONIC_RAW that the unpatched
kernels have (all times refer to 'Average Latency' output produced
by 'timer_latency.c').
I do apologize for whitespace errors, unread emails and resends and confusion
of previous emails - I now understand the process and standards much better
and will attempt to adhere to them more closely in future.
Thanks & Best Regards,
Jason Vas Dias
/*
* Program to measure high-res timer latency.
*
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef N_SAMPLES
#define N_SAMPLES 100
#endif
#define _STR(_S_) #_S_
#define STR(_S_) _STR(_S_)
#define TS2NS(_TS_) unsigned long long)(_TS_).tv_sec)*10ULL) + (((unsigned long long)((_TS_).tv_nsec
int main(int argc, char *const* argv, char *const* envp)
{ struct timespec sample[N_SAMPLES+1];
unsigned int cnt=N_SAMPLES, s=0 , avg_n=0;
unsigned long long
deltas [ N_SAMPLES ]
, t1, t2, sum=0, zd=0, ic=0, d
, t_start, avg_ns, *avgs=0;
clockid_t clk = CLOCK_MONOTONIC_RAW;
bool do_dump = false;
int argn=1, repeat=1;
for(; argn < argc; argn+=1)
if( argv[argn] != NULL )
if( *(argv[argn]) == '-')
switch( *(argv[argn]+1) )
{ case 'm':
case 'M':
clk = CLOCK_MONOTONIC;
break;
case 'd':
case 'D':
do_dump = true;
break;
case 'r':
case 'R':
if( (argn < argc) && (argv[argn+1] != NULL))
repeat = atoi(argv[argn+=1]);
break;
case '?':
case 'h':
case 'u':
case 'U':
case 'H':
fprintf(stderr,"Usage: timer_latency [\n\t-m : use CLOCK_MONOTONIC clock (not CLOCK_MONOTONIC_RAW)\n\t-d : d
Re: [PATCH 0/2] iio: stm32-dfsdm-adc: fix filter & rate setting
On Fri, 16 Mar 2018 10:10:09 +0100 Arnaud Pouliquen wrote: > Hello, > > For the series: > Acked-by: Arnaud Pouliquen Both applied and marked for stable (as I'm not sure exactly when this will hit mainline and it may be after the next merge window) Thanks, Jonathan > > Thanks, > Arnaud > > On 03/13/2018 03:23 PM, Fabrice Gasnier wrote: > > This series brings fixes to STM32 DFSDM ADC driver. > > > > Fabrice Gasnier (2): > > iio: adc: stm32-dfsdm: fix successive oversampling settings > > iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock > > > > drivers/iio/adc/stm32-dfsdm-adc.c | 17 ++--- > > 1 file changed, 14 insertions(+), 3 deletions(-) > >
Re: [PATCH] iio/accel/kxcjk-1013: Improve unlocking of a mutex in three functions
On Tue, 13 Mar 2018 13:47:20 +0100
SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Tue, 13 Mar 2018 13:40:12 +0100
>
> * Add jump targets so that a call of the function "mutex_unlock" is stored
> less often in these function implementations.
>
> * Replace eight calls by goto statements.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
A few minor comments inline, but at first glance at least these look
to be fine in principle.
Jonathan
> ---
> drivers/iio/accel/kxcjk-1013.c | 46
> ++
> 1 file changed, 20 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> index af53a1084ee5..4adf38b6d939 100644
> --- a/drivers/iio/accel/kxcjk-1013.c
> +++ b/drivers/iio/accel/kxcjk-1013.c
> @@ -765,19 +765,18 @@ static int kxcjk1013_read_raw(struct iio_dev *indio_dev,
> ret = -EBUSY;
> else {
> ret = kxcjk1013_set_power_state(data, true);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
> +
> ret = kxcjk1013_get_acc_reg(data, chan->scan_index);
> if (ret < 0) {
> kxcjk1013_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
> *val = sign_extend32(ret >> 4, 11);
> ret = kxcjk1013_set_power_state(data, false);
> }
> +unlock:
> mutex_unlock(&data->mutex);
>
> if (ret < 0)
> @@ -905,8 +904,8 @@ static int kxcjk1013_write_event_config(struct iio_dev
> *indio_dev,
>
> if (!state && data->motion_trigger_on) {
> data->ev_enable_state = 0;
> - mutex_unlock(&data->mutex);
> - return 0;
> + ret = 0;
do this where it is orginally defined rather than here.
int ret = 0;
> + goto unlock;
> }
>
> /*
> @@ -919,23 +918,20 @@ static int kxcjk1013_write_event_config(struct iio_dev
> *indio_dev,
>* is always on so sequence doesn't matter
>*/
> ret = kxcjk1013_set_power_state(data, state);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
>
> ret = kxcjk1013_setup_any_motion_interrupt(data, state);
> if (ret < 0) {
> kxcjk1013_set_power_state(data, false);
> data->ev_enable_state = 0;
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
>
> data->ev_enable_state = state;
> +unlock:
> mutex_unlock(&data->mutex);
> -
> - return 0;
> + return ret;
> }
>
> static int kxcjk1013_buffer_preenable(struct iio_dev *indio_dev)
> @@ -1086,32 +1082,30 @@ static int
> kxcjk1013_data_rdy_trigger_set_state(struct iio_trigger *trig,
>
> if (!state && data->ev_enable_state && data->motion_trigger_on) {
> data->motion_trigger_on = false;
> - mutex_unlock(&data->mutex);
> - return 0;
> + ret = 0;
> + goto unlock;
> }
>
> ret = kxcjk1013_set_power_state(data, state);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
> +
> if (data->motion_trig == trig)
> ret = kxcjk1013_setup_any_motion_interrupt(data, state);
> else
> ret = kxcjk1013_setup_new_data_interrupt(data, state);
> if (ret < 0) {
> kxcjk1013_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
> if (data->motion_trig == trig)
> data->motion_trigger_on = state;
> else
> data->dready_trigger_on = state;
>
> +unlock:
> mutex_unlock(&data->mutex);
> -
Please leave the blank line. It makes it slightly easier for the eye
to pick up on the return.
> - return 0;
> + return ret;
> }
>
> static const struct iio_trigger_ops kxcjk1013_trigger_ops = {
Re: Plan to move cdc:ad7746 driver out of staging
On Mon, 12 Mar 2018 16:25:52 -0300
Hernán Gonzalez wrote:
> Hi,
>
> This is my plan for moving out the ad7746 driver out of staging. I
> have some specific questions that would be really helpful if someone
> can point me in the right direction to go.
>
> 1. Pick up on David's clean-up patch. Finish cleaning CHECKs from
> checkpatch.pl if possible.
>
> 2. Reorder includes alphabetically.
>
> 3. Reorder some variable declarations in an inverse-pyramid scheme.
>
> 4. Fix sysfs attrs naming to comply with the ABI, e.g.:
> in_capacitance0_calibbias_calibration -> in_capacitance0_calibbias
Take a careful look at what these are doing before you do that :)
Then consider what the usecases are. If we need to, we may need
to add new ABI to cover the requirement.
>
> 5. Add documentation to the {cap,vt}_filter_rate tables and to the
> processed info read. There are some magic numbers out there, I will
> read the datasheet and explain the math that I consider appropiate.
>
> 6. There are a few too many defines that are not used at all but they
> do follow the datasheet. I don't know if there are plans to keep
> adding functionalities to this driver or if I should just remove them.
>
> 8. EXCLVL is duplicated. There's a simple macro in ad7746.c and some
> defines in ad7746.h. The latter are not used anywhere in the code.
> Remove them.
>
> 7. Move the struct ad7746_platform_data to include/linux/iio.
>
> As mentioned in earlier mails, I will avoid adding new features as I
> have no access to the hardware and, therefore, could not test it.
Michael has stated he has at least some of the CDCs still so may be able
to help with that.
>
> I guess that'd be all. If I'm missing something I would be really
> grateful if you can let me know or give me some pointers where to look
> at.
It would probably be a good idea to add devicetree bindings if possible.
Hardly anything is done with board files these days - though we should
maintain the platform data for anyone who is using them (for now).
There may well be other things that come out of the woodwork once
we do a formal review of the patch that proposes moving it out of
staging (there almost always is!)
Jonathan
>
> Cheers,
>
> Hernán
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the rtc tree with the asm-generic tree
Hi Alexandre, On Sat, 17 Mar 2018 14:22:52 +0100 Alexandre Belloni wrote: > > I've removed the patch from my tree as there is no point in modifying a > driver that is removed. Thanks for letting me know. -- Cheers, Stephen Rothwell pgpsZMXnkISMY.pgp Description: OpenPGP digital signature
[RFC PATCH 3/3] drm: bridge: lvds-encoder: on request, override the bus format
If the bridge changes the bus format, allow this to be described in
the bridge, instead of providing false information about the bus
format of the panel itself.
Signed-off-by: Peter Rosin
---
.../bindings/display/bridge/lvds-transmitter.txt | 8
drivers/gpu/drm/bridge/lvds-encoder.c | 18 ++
2 files changed, 26 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 9d09190d9210..c0fbe74272e7 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -29,6 +29,14 @@ Required properties:
"ti,ds90c185"
+Optional properties:
+
+- interface-pix-fmt:
+ Override the bus format of the panel, in case the bridge
+ converts the signals. Recognized formats include:
+
+ "rgb565"
+
Required nodes:
This device has two video ports. Their connections are modeled using the OF
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..acff3a5b0562 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -39,6 +39,9 @@ static int lvds_encoder_probe(struct platform_device *pdev)
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
+ u32 bus_format = 0;
+ const char *fmt;
+ int ret;
lvds_encoder = devm_kzalloc(&pdev->dev, sizeof(*lvds_encoder),
GFP_KERNEL);
@@ -79,6 +82,21 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
+ ret = of_property_read_string(pdev->dev.of_node,
+ "interface-pix-fmt", &fmt);
+ if (!ret) {
+ if (!strcmp(fmt, "rgb565")) {
+ bus_format = MEDIA_BUS_FMT_RGB565_1X16;
+ } else {
+ dev_dbg(&pdev->dev,
+ "requested interface-pix-fmt not recognized\n");
+ return -EINVAL;
+ }
+ }
+ if (bus_format)
+ drm_panel_bridge_set_bus_format(lvds_encoder->panel_bridge,
+ bus_format);
+
/* The panel_bridge bridge is attached to the panel's of_node,
* but we need a bridge attached to our of_node for our user
* to look up.
--
2.11.0
[RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format
Useful if the bridge does some kind of conversion of the bus format.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/panel.c | 22 +-
include/drm/drm_bridge.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 6d99d4a3beb3..ccef0283ff41 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -22,6 +22,7 @@ struct panel_bridge {
struct drm_connector connector;
struct drm_panel *panel;
u32 connector_type;
+ u32 bus_format;
};
static inline struct panel_bridge *
@@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct
drm_connector *connector)
{
struct panel_bridge *panel_bridge =
drm_connector_to_panel_bridge(connector);
+ int ret;
+
+ ret = drm_panel_get_modes(panel_bridge->panel);
+
+ if (panel_bridge->bus_format)
+ drm_display_info_set_bus_formats(&connector->display_info,
+&panel_bridge->bus_format, 1);
- return drm_panel_get_modes(panel_bridge->panel);
+ return ret;
}
static const struct drm_connector_helper_funcs
@@ -203,6 +211,18 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
}
EXPORT_SYMBOL(drm_panel_bridge_remove);
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32 bus_format)
+{
+ struct panel_bridge *panel_bridge;
+
+ if (!bridge)
+ return;
+
+ panel_bridge = drm_bridge_to_panel_bridge(bridge);
+ panel_bridge->bus_format = bus_format;
+}
+EXPORT_SYMBOL(drm_panel_bridge_set_bus_format);
+
static void devm_drm_panel_bridge_release(struct device *dev, void *res)
{
struct drm_bridge **bridge = res;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..81903b92f187 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -268,6 +268,7 @@ void drm_bridge_enable(struct drm_bridge *bridge);
struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type);
void drm_panel_bridge_remove(struct drm_bridge *bridge);
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32
bus_format);
struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
struct drm_panel *panel,
u32 connector_type);
--
2.11.0
[RFC PATCH 1/3] dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
Start list of actual chips compatible with "lvds-encoder". Signed-off-by: Peter Rosin --- .../devicetree/bindings/display/bridge/lvds-transmitter.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt index fd39ad34c383..9d09190d9210 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt @@ -24,6 +24,11 @@ Required properties: - compatible: Must be "lvds-encoder" + Known actual chips (these should still use "lvds-encoder" as a + fallback compatible) include: + + "ti,ds90c185" + Required nodes: This device has two video ports. Their connections are modeled using the OF -- 2.11.0
[RFC PATCH 0/3] allow override of bus format in bridges
I'm trying to get something to work that I assumed would not
need patches, so I think I might be missing something completely
obvious...
I have an Atmel sama5d31 hooked up to an lvds encoder and then
on to an lvds panel. Which seems like something that has been
done one or two times before...
The problem (I think) is that the bus_format of the SoC and the
panel do not agree. The SoC driver (atmel-hlcdc) can handle the
rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
wired for the rgb565 case. The lvds encoder supports rgb888 on
its input side with the LSB wires simply pulled down internally
in the encoder in my case. And the panel is expecting lvds
(vesa-24), which is what the encoder outputs.
The reason I "blame" the bus_format of the drm_connector is that
with the below DT snippet, things do not work *exactly* due to
that. At least, it starts to work if I hack the panel-lvds driver
to report the rgb565 bus_format instead of vesa-24.
panel: panel {
compatible = "panel-lvds";
width-mm = <476>;
height-mm = <268>;
data-mapping = "vesa-24";
panel-timing {
// 1024x768 @ 60Hz (typical)
clock-frequency = <5214 6500 7110>;
hactive = <1024>;
vactive = <768>;
hfront-porch = <59 107 107>;
hback-porch = <59 107 107>;
hsync-len = <59 106 106>;
vfront-porch = <8 13 14>;
vback-porch = <8 13 14>;
vsync-len = <8 12 14>;
};
port {
panel_input: endpoint {
remote-endpoint = <&lvds_encoder_output>;
};
};
};
lvds-encoder {
compatible = "ti,ds90c187", "lvds-encoder";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_encoder_input: endpoint {
remote-endpoint = <&hlcdc_output>;
};
};
port@1 {
reg = <1>;
lvds_encoder_output: endpoint {
remote-endpoint = <&panel_input>;
};
};
};
};
But, instead of perverting the panel-lvds driver with support
for a totally fake non-lvds bus_format, I came up with an optional
bus_format override in the lvds-encoder driver, which I trigger with
this addition to the lvds-encoder DT node:
interface-pix-fmt = "rgb565";
There are some issues with the interface-pix-fmt name. I copied it
from the freescale fsl-imx-drm binding, but a) I personally don't
like how that binding uses rgb24 instead of rgb888 and b) I don't
like how the implementation of that binding selects rgb666 when you
say bgr666 in the DT, but for parallel hardware interface the bit
order is not really relevant so I swallowed that. Anyway, it might
be better to use something else than interface-pix-fmt? Perhaps
reuse the "data-mapping" name from the panel-lvds binding? But that
seems somewhat lvds specific? Then there a couple of instances of
"bus-format-override" in some dtsi files, but that name is not
mentioned in any binding, nor in (upstream) code...
And maybe it should be fourcc codes or something instead of these
"rgb565" names?
I threw in the first patch, since that is the actual lvds encoder
I have in this case.
Suggestions welcome.
Cheers,
Peter
Peter Rosin (3):
dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
drm: bridge: panel: allow override of the bus format
drm: bridge: lvds-encoder: on request, override the bus format
.../bindings/display/bridge/lvds-transmitter.txt | 13 +
drivers/gpu/drm/bridge/lvds-encoder.c | 18 ++
drivers/gpu/drm/bridge/panel.c | 22 +-
include/drm/drm_bridge.h | 1 +
4 files changed, 53 insertions(+), 1 deletion(-)
--
2.11.0
Re: [PATCH v6 11/15] mm, fs, dax: handle layout changes to pinned dax mappings
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: x86_64-randconfig-x010-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/dax/super.c: In function 'generic_dax_pagefree':
>> drivers/dax/super.c:170:2: error: implicit declaration of function
>> 'wake_up_var'; did you mean 'wake_up_nr'?
>> [-Werror=implicit-function-declaration]
wake_up_var(&page->_refcount);
^~~
wake_up_nr
cc1: some warnings being treated as errors
vim +170 drivers/dax/super.c
166
167 #if IS_ENABLED(CONFIG_FS_DAX)
168 static void generic_dax_pagefree(struct page *page, void *data)
169 {
> 170 wake_up_var(&page->_refcount);
171 }
172
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v6 15/15] xfs, dax: introduce xfs_break_dax_layouts()
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5]
[cannot apply to next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: x86_64-randconfig-x014-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
fs/xfs/xfs_file.c: In function 'xfs_break_dax_layouts':
>> fs/xfs/xfs_file.c:786:8: error: implicit declaration of function
>> '___wait_var_event'; did you mean 'xfs_wait_var_event'?
>> [-Werror=implicit-function-declaration]
ret = ___wait_var_event(&page->_refcount,
^
xfs_wait_var_event
>> fs/xfs/xfs_file.c:788:10: error: invalid use of void expression
0, 0, xfs_wait_var_event(inode, iolock));
^~
cc1: some warnings being treated as errors
vim +786 fs/xfs/xfs_file.c
773
774 static int
775 xfs_break_dax_layouts(
776 struct inode*inode,
777 uintiolock)
778 {
779 struct page *page;
780 int ret;
781
782 page = dax_layout_busy_page(inode->i_mapping);
783 if (!page)
784 return 0;
785
> 786 ret = ___wait_var_event(&page->_refcount,
787 atomic_read(&page->_refcount) == 1,
TASK_INTERRUPTIBLE,
> 788 0, 0, xfs_wait_var_event(inode, iolock));
789 if (ret < 0)
790 return ret;
791 return 1;
792 }
793
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v5 0/4] new driver for Valve Steam Controller
On 03/15/2018 02:06 PM, Rodrigo Rivas Costa wrote: On Wed, Mar 14, 2018 at 05:39:25PM +0100, Benjamin Tissoires wrote: On Mon, Mar 12, 2018 at 9:51 PM, Rodrigo Rivas Costa wrote: On Mon, Mar 12, 2018 at 03:30:43PM +0100, Clément VUCHENER wrote: 2018-03-11 20:58 GMT+01:00 Rodrigo Rivas Costa : This patchset implements a driver for Valve Steam Controller, based on a reverse analysis by myself. Sorry, I've been out of town for a few weeks and couldn't keep up with this... @Pierre-Loup and @Clément, could you please have another look at this and check if it is worthy? Benjamin will not commit it without an express ACK from Valve. Of course he is right to be cautious, but I checked this driver with the Steam Client and all seems to go just fine. I think that there is a lot of Linux out of the desktop that could use this driver and cannot use the Steam Client. Worst case scenario, this driver can now be blacklisted, but I hope that will not be needed. I tested the driver with my 4.15 fedora kernel (I only built the module not the whole kernel) and I got double inputs (your driver input device + steam uinput device) when testing Shovel Knight with Steam Big Picture. It seems to work fine when the inputs are the same, but after changing the controller configuration in Steam, the issue became apparent. I assumed that when several joysticks are available, games would listen to one one of them. It looks like I'm wrong, and some (many?) games will listen to all available joysticks at the same time. Thus having two logical joysticks that represent the same physical one is not good. Yeah, the general rule of thumb is "think of the worst thing that can happen, someone will do something worst". An easy solution would be that Steam Client grabs this driver (ioctl(EVIOCGRAB)) when creating the uinput device. Another solution would be that Steam Client blacklists this driver, of course. This is 2 solutions that rely on a userspace change, and this is not acceptable in its current form. What if people do not upgrade Steam client but upgrade their kernel? Well, Steam might be able to force people to always run the latest shiny available version, but for other games, you can't expect people to have a compatible version of the userspace stack. Well, if you don't have Steam then you don't have the double input in the first place. Unless you are using a different user-mode driver, of course. Also, "blacklisting the driver" from Steam client is something the OS can do, but not the client when you run on a different distribution. You need root for that, and I don't want to give root permissions to Steam (or to any user space client that shouldn't have root privileges for what it matters). Actually Steam needs a system installation that adds udev rules to grant uaccess to /dev/uinput and the USB raw device for the controller. Adding a /etc/modprobe.d/steam.conf should be possible, too. It would be a bit inconvenient because you'll need a distro update of the steam package, not just the usual user-mode-only auto-update. It's definitely a bit tricky; we've rolled out an update to our reference package whenever we've added support for new devices (the final Steam Controller, direct PS4 gamepad led/gyro access through HID, HTC Vive and its myriad of onboard devices, bootloaders of all these things for firmware updates, etc). Whenever we have to do that, the rollout never is as smooth as desired: many users aren't using our own package; even on the distributions we support directly. Then downstream distributions adopt these udev changes with various delays (sometimes never), and port them to their own mechanism of doing things, since everyone has their own idea of a robust security model. I wish local sessions always had proper access to HID devices connected to the physical computer the user is sitting at, but I realize that the basic gaming desktop is just one of many usecases distros out there have to support and it'd be unreasonable to expect them to focus exclusively on it. And without Steam and your external tool, you get double inputs too. I tried RetroArch and it was unusable because of the keyboard inputs from the lizard mode (e.g. pressing B also presses Esc and quits RetroArch). Having to download and compile an external tool to make the driver work properly may be too difficult for the user. Your goal was to provide an alternative to user space drivers but now you actually depend on (a very simple) one. Yes, I noticed that. TBH, this driver without Steam Client or the user-space tool is not very nice, precisely because you'll get constant Escape and Enter presses, and most games react to those. Frankly speaking, I'm not sure how to proceed. I can think of the following options: 1.Steam Client installation could add a file to blacklist hid-steam, just as it adds a few udev rules. But what about RetroArch? And what if you install Steam but want to play SDL games that c
Re: [PATCH v2 3/3] serial: core: Allow skipping old serial port initialization
Hi Daniel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Kurtz/Add-earlycon-support-for-AMD-Carrizo-Stoneyridge/20180318-025754
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers//acpi/spcr.c: In function 'acpi_parse_spcr':
>> drivers//acpi/spcr.c:212:29: error: assignment of read-only variable
>> 'serial8250_skip_old_ports'
serial8250_skip_old_ports = true;
^
--
>> drivers//tty/serial/8250/8250_core.c:69:6: error: conflicting type
>> qualifiers for 'serial8250_skip_old_ports'
bool serial8250_skip_old_ports;
^
In file included from drivers//tty/serial/8250/8250_core.c:29:0:
include/linux/serial_8250.h:142:19: note: previous declaration of
'serial8250_skip_old_ports' was here
static const bool serial8250_skip_old_ports;
^
sparse warnings: (new ones prefixed by >>)
>> drivers/acpi/spcr.c:212:17: sparse: assignment to const expression
drivers/acpi/spcr.c: In function 'acpi_parse_spcr':
drivers/acpi/spcr.c:212:29: error: assignment of read-only variable
'serial8250_skip_old_ports'
serial8250_skip_old_ports = true;
^
vim +/serial8250_skip_old_ports +212 drivers//acpi/spcr.c
94
95 /**
96 * acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
97 *
98 * @enable_earlycon: set up earlycon for the console specified by the
table
99 * @enable_console: setup the console specified by the table.
100 *
101 * For the architectures with support for ACPI, CONFIG_ACPI_SPCR_TABLE
may be
102 * defined to parse ACPI SPCR table. As a result of the parsing
preferred
103 * console is registered and if @enable_earlycon is true, earlycon is
set up.
104 * If @enable_console is true the system console is also configured.
105 *
106 * When CONFIG_ACPI_SPCR_TABLE is defined, this function should be
called
107 * from arch initialization code as soon as the DT/ACPI decision is
made.
108 *
109 */
110 int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
111 {
112 static char opts[64];
113 struct acpi_table_spcr *table;
114 acpi_status status;
115 char *uart;
116 char *iotype;
117 int baud_rate;
118 int err;
119
120 if (acpi_disabled)
121 return -ENODEV;
122
123 status = acpi_get_table(ACPI_SIG_SPCR, 0,
124 (struct acpi_table_header **)&table);
125
126 if (ACPI_FAILURE(status))
127 return -ENOENT;
128
129 if (table->header.revision < 2)
130 pr_info("SPCR table version %d\n",
table->header.revision);
131
132 if (table->serial_port.space_id ==
ACPI_ADR_SPACE_SYSTEM_MEMORY) {
133 switch (ACPI_ACCESS_BIT_WIDTH((
134 table->serial_port.access_width))) {
135 default:
136 pr_err("Unexpected SPCR Access Width.
Defaulting to byte size\n");
137 /* fall through */
138 case 8:
139 iotype = "mmio";
140 break;
141 case 16:
142 iotype = "mmio16";
143 break;
144 case 32:
145 iotype = "mmio32";
146 break;
147 }
148 } else
149 iotype = "io";
150
151 switch (table->interface_type) {
152 case ACPI_DBG2_ARM_SBSA_32BIT:
153 iotype = "mmio32";
154 /* fall through */
155 case ACPI_DBG2_ARM_PL011:
156 case ACPI_DBG2_ARM_SBSA_GENERIC:
157 case ACPI_DBG2_BCM2835:
158 uart = "pl011";
159 break;
160 case ACPI_DBG2_16550_COMPATIBLE:
161 case ACPI_DBG2_16550_SUBSET:
162 uart = "uart";
163 break;
164 default:
165 err = -ENOENT;
166 goto done;
167 }
168
169 switch (table->baud_rate) {
170 case 3:
171 baud_rate = 9600;
172 break;
173 case 4:
Re: [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation
On Sat, 2018-03-17 at 22:10 +0100, Sebastian Andrzej Siewior wrote: > On 2018-03-17 14:49:54 [-0500], Scott Wood wrote: > > On Fri, 2018-03-16 at 21:18 +0100, Sebastian Andrzej Siewior wrote: > > > The goal here is to make the memory allocation in get_irq_table() > > > not > > > with disabled interrupts and having as little raw_spin_lock as > > > possible > > > while having them if the caller is also holding one (like desc- > > > >lock > > > during IRQ-affinity changes). > > > I reverted one patch one patch in the iommu while rebasing since > > > it > > > make job easier. > > > > If the goal is to have "as little raw_spin_lock as possible" -- and > > presumably also to avoid unnecessary complexity -- wouldn't it be > > better to leave my patch in, and drop patches 4 and 9? > > 9 gives me GFP_KERNEL instead atomic so no. > 4 is needed I think but I could double check on Monday. If that's worth the lock dropping then fine (though why does only one of the two allocations use GFP_KERNEL?), but it doesn't need to be a raw lock if the non-allocating users are separated. Keeping them separate will also preserve the WARNs if we somehow end up in an atomic context with no table (versus relying on atomic sleep debugging that may or may not be enabled), and make the code easier to understand by being explicit about which functions can be used from RT-atomic context. -Scott
Re: [PATCH v2 1/3] staging:iio:ad2s1210: Add channel for fclkin and fexcit
On Tue, 13 Mar 2018 13:05:28 -0300
Rodrigo Siqueira wrote:
> The ad2s1210 does not contain any channel for the fclkin and fexcit. As
> a result, it uses IIO_DEVICE_ATTR to expose this information. This patch
> adds one channel for fclkin and another for fexcit. It also adds an enum
> to easily address the correct channel.
>
> Signed-off-by: Rodrigo Siqueira
Take a step back. What are these new channels actually for?
We aren't looking at a general purpose frequency input and output.
(mind you they are both currently inputs which makes even less sense!)
These are controls for the excitation frequency for a resolver.
What is userspace going to do with them? Nothing of any use certainly.
So what do they actually change that matters to an application?
1) The speed at which we can detect a loss of signal condition.
2) The achievable resolution of the sensor.
So how would userspace know how to configure it? I'm not sure it
would, but it is these things that should be driving the choice
not the actual value of the frequency (which is really just
a weird internal value in the way the resolver system works).
There is a pretty strong argument that we should leave the excitation
frequency alone at 10kHz unless the platform designer knows better,
in which case they should supply it via devicetree rather than
from userspace.
Anyhow, it needs a rethink - exposing these as channels is not
the way to go!
Jonathan
> ---
> drivers/staging/iio/resolver/ad2s1210.c | 43
> ++---
> 1 file changed, 29 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> b/drivers/staging/iio/resolver/ad2s1210.c
> index ac13b99bd9cb..28c3fd439663 100644
> --- a/drivers/staging/iio/resolver/ad2s1210.c
> +++ b/drivers/staging/iio/resolver/ad2s1210.c
> @@ -67,6 +67,11 @@ enum ad2s1210_mode {
> MOD_RESERVED,
> };
>
> +enum ad2s1210_frequency_channel {
> + FCLKIN = 0,
> + FEXCIT,
> +};
> +
> static const unsigned int ad2s1210_resolution_value[] = { 10, 12, 14, 16 };
>
> struct ad2s1210_state {
> @@ -88,6 +93,30 @@ static const int ad2s1210_mode_vals[4][2] = {
> [MOD_CONFIG] = { 1, 0 },
> };
>
> +static const struct iio_chan_spec ad2s1210_channels[] = {
> + {
> + .type = IIO_ANGL,
> + .indexed = 1,
> + .channel = 0,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + }, {
> + .type = IIO_ANGL_VEL,
> + .indexed = 1,
> + .channel = 0,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + }, {
> + .type = IIO_CHAN_INFO_FREQUENCY,
> + .indexed = 1,
> + .channel = FCLKIN,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + }, {
> + .type = IIO_CHAN_INFO_FREQUENCY,
> + .indexed = 1,
> + .channel = FEXCIT,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + },
> +};
> +
This seems broken, you can't just add a channel and not support
it until the following patches.
> static inline void ad2s1210_set_mode(enum ad2s1210_mode mode,
>struct ad2s1210_state *st)
> {
> @@ -552,20 +581,6 @@ static IIO_DEVICE_ATTR(lot_low_thrd, 0644,
> ad2s1210_show_reg, ad2s1210_store_reg,
> AD2S1210_REG_LOT_LOW_THRD);
>
> -static const struct iio_chan_spec ad2s1210_channels[] = {
> - {
> - .type = IIO_ANGL,
> - .indexed = 1,
> - .channel = 0,
> - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> - }, {
> - .type = IIO_ANGL_VEL,
> - .indexed = 1,
> - .channel = 0,
> - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> - }
> -};
> -
> static struct attribute *ad2s1210_attributes[] = {
> &iio_dev_attr_fclkin.dev_attr.attr,
> &iio_dev_attr_fexcit.dev_attr.attr,
Re: [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation
On 2018-03-17 14:49:54 [-0500], Scott Wood wrote: > On Fri, 2018-03-16 at 21:18 +0100, Sebastian Andrzej Siewior wrote: > > The goal here is to make the memory allocation in get_irq_table() not > > with disabled interrupts and having as little raw_spin_lock as > > possible > > while having them if the caller is also holding one (like desc->lock > > during IRQ-affinity changes). > > I reverted one patch one patch in the iommu while rebasing since it > > make job easier. > > If the goal is to have "as little raw_spin_lock as possible" -- and > presumably also to avoid unnecessary complexity -- wouldn't it be > better to leave my patch in, and drop patches 4 and 9? 9 gives me GFP_KERNEL instead atomic so no. 4 is needed I think but I could double check on Monday. > -Scott Sebastian
Re: [PATCH v2] i2c: xlp9xx: Add support for SMBAlert
On Tue, Mar 06, 2018 at 06:46:34AM -0800, George Cherian wrote:
> Add support for SMBus alert mechanism to i2c-xlp9xx driver.
> The second interrupt is parsed to use for SMBus alert.
> The first interrupt is the i2c controller main interrupt.
>
> Signed-off-by: Kamlakant Patel
> Signed-off-by: George Cherian
Are the previous reviewers happy now?
> ---
> drivers/i2c/busses/i2c-xlp9xx.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-xlp9xx.c b/drivers/i2c/busses/i2c-xlp9xx.c
> index eb8913e..d5cadb6 100644
> --- a/drivers/i2c/busses/i2c-xlp9xx.c
> +++ b/drivers/i2c/busses/i2c-xlp9xx.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -84,6 +85,8 @@ struct xlp9xx_i2c_dev {
> struct device *dev;
> struct i2c_adapter adapter;
> struct completion msg_complete;
> + struct i2c_smbus_alert_setup alert_data;
> + struct i2c_client *ara;
> int irq;
> bool msg_read;
> bool len_recv;
> @@ -447,6 +450,19 @@ static int xlp9xx_i2c_get_frequency(struct
> platform_device *pdev,
> return 0;
> }
>
> +static int xlp9xx_i2c_smbus_setup(struct xlp9xx_i2c_dev *priv,
> + struct platform_device *pdev)
> +{
> + if (!priv->alert_data.irq)
> + return -EINVAL;
> +
> + priv->ara = i2c_setup_smbus_alert(&priv->adapter, &priv->alert_data);
> + if (!priv->ara)
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> static int xlp9xx_i2c_probe(struct platform_device *pdev)
> {
> struct xlp9xx_i2c_dev *priv;
> @@ -467,6 +483,10 @@ static int xlp9xx_i2c_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "invalid irq!\n");
> return priv->irq;
> }
> + /* SMBAlert irq */
> + priv->alert_data.irq = platform_get_irq(pdev, 1);
> + if (priv->alert_data.irq <= 0)
'< 0' should do, or?
> + priv->alert_data.irq = 0;
>
> xlp9xx_i2c_get_frequency(pdev, priv);
> xlp9xx_i2c_init(priv);
> @@ -493,6 +513,10 @@ static int xlp9xx_i2c_probe(struct platform_device *pdev)
> if (err)
> return err;
>
> + err = xlp9xx_i2c_smbus_setup(priv, pdev);
> + if (err)
> + dev_info(&pdev->dev, "No active SMBus alert %d\n", err);
> +
Do you really want to print this info every time SMBus alert is not
used? Is it common on this platform
> platform_set_drvdata(pdev, priv);
> dev_dbg(&pdev->dev, "I2C bus:%d added\n", priv->adapter.nr);
>
> --
> 1.8.3.1
>
signature.asc
Description: PGP signature
Re: [PATCH v2 4/8] gpio: pcie-idio-24: Implement get_multiple/set_multiple callbacks
Hi William,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Implement-get_multiple-for-ACCES-and-PC-104-drivers/20180317-224135
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/gpio/gpio-pcie-idio-24.c:231:17: sparse: undefined identifier
'word_mask'
drivers/gpio/gpio-pcie-idio-24.c:232:22: sparse: undefined identifier
'word_mask'
>> drivers/gpio/gpio-pcie-idio-24.c:331:43: sparse: incorrect type in argument
>> 1 (different modifiers) @@expected void [noderef] * @@
>> got unsigned char cvoid [noderef] * @@
drivers/gpio/gpio-pcie-idio-24.c:333:43: sparse: incorrect type in argument
2 (different modifiers) @@expected void [noderef] * @@
got unsigned char cvoid [noderef] * @@
>> drivers/gpio/gpio-pcie-idio-24.c:518:30: sparse: incorrect type in
>> assignment (incompatible argument 2 (different base types)) @@expected
>> void ( *set )( ... ) @@got void ( *set )( ... ) @@
>> drivers/gpio/gpio-pcie-idio-24.c:210:27: sparse: dereference of noderef
>> expression
drivers/gpio/gpio-pcie-idio-24.c:210:52: sparse: dereference of noderef
expression
drivers/gpio/gpio-pcie-idio-24.c:211:27: sparse: dereference of noderef
expression
drivers/gpio/gpio-pcie-idio-24.c:211:54: sparse: dereference of noderef
expression
drivers/gpio/gpio-pcie-idio-24.c:212:27: sparse: dereference of noderef
expression
drivers/gpio/gpio-pcie-idio-24.c:212:52: sparse: dereference of noderef
expression
>> drivers/gpio/gpio-pcie-idio-24.c:231:17: sparse: generating address of
>> non-lvalue (3)
drivers/gpio/gpio-pcie-idio-24.c:306:27: sparse: dereference of noderef
expression
drivers/gpio/gpio-pcie-idio-24.c:306:52: sparse: dereference of noderef
expression
drivers/gpio/gpio-pcie-idio-24.c:307:27: sparse: dereference of noderef
expression
drivers/gpio/gpio-pcie-idio-24.c: In function 'idio_24_gpio_get_multiple':
drivers/gpio/gpio-pcie-idio-24.c:231:3: error: 'word_mask' undeclared (first
use in this function); did you mean 'port_mask'?
word_mask = mask[word_index] & (port_mask << word_offset);
^
port_mask
drivers/gpio/gpio-pcie-idio-24.c:231:3: note: each undeclared identifier is
reported only once for each function it appears in
drivers/gpio/gpio-pcie-idio-24.c:239:25: warning: passing argument 1 of
'ioread8' discards 'const' qualifier from pointer target type
[-Wdiscarded-qualifiers]
port_state = ioread8(ports + i);
^
In file included from arch/x86/include/asm/io.h:223:0,
from arch/x86/include/asm/realmode.h:15,
from arch/x86/include/asm/acpi.h:33,
from arch/x86/include/asm/fixmap.h:19,
from arch/x86/include/asm/apic.h:10,
from arch/x86/include/asm/smp.h:13,
from arch/x86/include/asm/mmzone_64.h:11,
from arch/x86/include/asm/mmzone.h:5,
from include/linux/mmzone.h:912,
from include/linux/gfp.h:6,
from include/linux/idr.h:16,
from include/linux/kernfs.h:14,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from drivers/gpio/gpio-pcie-idio-24.c:20:
include/asm-generic/iomap.h:29:21: note: expected 'void *' but argument is
of type 'const u8 * {aka const unsigned char *}'
extern unsigned int ioread8(void __iomem *);
^~~
drivers/gpio/gpio-pcie-idio-24.c:206:16: warning: unused variable
'mask_word' [-Wunused-variable]
unsigned long mask_word;
^
drivers/gpio/gpio-pcie-idio-24.c: In function 'idio_24_gpio_set_multiple':
drivers/gpio/gpio-pcie-idio-24.c:302:16: error: redeclaration of 'gpio_mask'
with no linkage
unsigned long gpio_mask;
^
drivers/gpio/gpio-pcie-idio-24.c:299:16: note: previous declaration of
'gpio_mask' was here
unsigned long gpio_mask;
^
drivers/gpio/gpio-pcie-idio-24.c:331:23: warning: passing argument 1 of
'ioread8' discards 'const' qualifier from pointer target type
[-Wdiscarded-qualifiers]
out_state = ioread8(ports + i) & ~gpio_mask;
^
Re: [RESEND PATCH v1 2/6] i2c: i2c-stm32f7: Add slave support
> + * @master_mode: boolean to know in which mode the I2C is running (master or > + * slave) It can't do both at the same time? signature.asc Description: PGP signature
Re: [RESEND PATCH v1 6/6] i2c: i2c-stm32f7: Implement I2C recovery mechanism
On Mon, Mar 12, 2018 at 11:53:43AM +0100, Pierre-Yves MORDRET wrote: > Feature prevents I2C lock-ups. Mechanism resets I2C state machine > and releases SCL/SDA signals but preserves I2C registers. Does it release SDA when held down by the slave? Because that is what the recovery mechanism is for. signature.asc Description: PGP signature
Re: [PATCH 2/4] pwm: pwm-jz4740: Implement set_polarity
Hi,
Could this patchset get a bit of love?
I have other changes waiting for this patchset to get in, so it'd be
great
to see it in 4.17-rc1.
Thanks,
-Paul
Le sam. 6 janv. 2018 à 17:58, Paul Cercueil a
écrit :
This permits clients of this driver to specify the polarity to use for
their PWM channel.
Signed-off-by: Paul Cercueil
---
drivers/pwm/pwm-jz4740.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index 2e41ba213f39..6539c001fe32 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -130,10 +130,29 @@ static int jz4740_pwm_config(struct pwm_chip
*chip, struct pwm_device *pwm,
return 0;
}
+static int jz4740_pwm_set_polarity(struct pwm_chip *chip,
+ struct pwm_device *pwm, enum pwm_polarity polarity)
+{
+ uint32_t ctrl = jz4740_timer_get_ctrl(pwm->pwm);
+
+ switch (polarity) {
+ case PWM_POLARITY_NORMAL:
+ ctrl &= ~JZ_TIMER_CTRL_PWM_ACTIVE_LOW;
+ break;
+ case PWM_POLARITY_INVERSED:
+ ctrl |= JZ_TIMER_CTRL_PWM_ACTIVE_LOW;
+ break;
+ }
+
+ jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
+ return 0;
+}
+
static const struct pwm_ops jz4740_pwm_ops = {
.request = jz4740_pwm_request,
.free = jz4740_pwm_free,
.config = jz4740_pwm_config,
+ .set_polarity = jz4740_pwm_set_polarity,
.enable = jz4740_pwm_enable,
.disable = jz4740_pwm_disable,
.owner = THIS_MODULE,
--
2.11.0
Re: [RESEND PATCH v1] i2c: i2c-stm32f7: fix no check on returned setup
On Mon, Mar 12, 2018 at 01:53:21PM +0100, Pierre-Yves MORDRET wrote:
> Before assigning returned setup structure check if not null
>
> Fixes: 463a9215f3ca7600b5ff ("i2c: stm32f7: fix setup structure")
> Signed-off-by: Pierre-Yves MORDRET
Maxime? Alexandre?
signature.asc
Description: PGP signature
Re: [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in platform data
On Sat, Mar 17, 2018 at 10:42:40AM -0700, Dmitry Torokhov wrote: > On Fri, Mar 16, 2018 at 08:40:02PM +, Nick Dyer wrote: > > On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote: > > > Ah, OK, I see. I would really like to drop this > > > pdata->suspend_mode stuff and I do not want to create > > > "pixel-screwed-up" property either... I guess for the time being > > > I'll put a DMI quirk for Link to restore T9 control method, and > > > then look into cleaning it all up. We have quite a bit different > > > code in chromeos kernel trees and I'd like to reconcile > > > it. > > > > Yes, it would be great to get rid of it. The driver does have the > > ability to download configuration via the firmware loader interface. > > So you would be able to grab a copy of the config by saving it with > > mxt-app, tweak it to ensure that the T9 CTRL byte is set correctly, > > then ship it somehow (presumably it could be added to > > linux-firmware). This would override what's currently stored in > > NVRAM on all those units and mean we could remove the T9_CTRL stuff. > > We can't really rely on people fetching updated config. Do you think we > could see if the device has only T9 and not T100 and if coming out of > suspend the T9 CTRL byte is 0 we overwrite it with the 0x83? I think that all we need to do is add something to mxt_read_t9_resolution (and probably rename it to mxt_init_t9_config) that reads the 1st (CTRL) byte, and if it's zero, writes 0x83 (and probably a dev_dbg() wouldn't go amiss) Also call the same logic on reset (look for "Detect reset"), because that wipes out the config. Once we've done that, we can get rid of the MXT_SUSPEND_T9_CTRL and use the normal T7 power up/down logic for suspend/resume on all devices. FWIW there may be two instances of T9, but I've never seen a device that actually had two screens and it's not supported really anyway with this driver. N
Re: Unknown symbols in module (iio)
[adding linux-iio mailing list] Hi, It's always a good idea to include the kernel version in a problem report. On 03/05/2018 03:17 AM, Srishti Sharma wrote: > Hello, > I was trying to work with the iio dummy driver, and when I try to load > the iio_dummy_evgen.ko module I am getting unknown symbols found in > module error on running modprobe. > > These variables are unknown > iio_bus_type >>> in industrialio-core > irq_sim_init >>> in iio_dummy_evgen > irq_sim_fini >>> same > irq_sim_fire >>> same > irq_sim_fini >>> [duplicate] I tested this using Linux 4.16-rc5. As long as I manually load all modules in the needed order, they will all load with no symbol problems. > All of these variables are present in the Module.symvers file in the > /lib/modules//build directory. The kernel and the > modules versions match. I ran make clean, make, and make > modules_install before trying to load them. I am unable to figure out > the problem. Where I might be going wrong any ideas ? Were you expecting some module autoloading based on their internal dependencies? If so, maybe someone on the linux-iio mailing list could comment on that. -- ~Randy
Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working
I trust the reviews of Andy and Sricharan for this series. From what I looked at, the patches look good to me. Only one question left about copyrights (raised seperately), but we are good to go I think. Thanks for all the review! signature.asc Description: PGP signature
Re: [PATCH v2] Staging: iio: adis16209: Move adis16209 driver out of staging
On Fri, 16 Mar 2018 02:33:49 +0530 Shreeya Patel wrote: > On 16 March 2018 00:31:53 GMT+05:30, Shreeya Patel > wrote: > >On Sat, 2018-03-10 at 15:57 +, Jonathan Cameron wrote: > > > >Hi Jonathan, > > > >> On Sat, 10 Mar 2018 15:50:23 +0530 > >> Shreeya Patel wrote: > >> > >> > > >> > Move the adis16209 driver out of staging directory and merge to the > >> > mainline IIO subsystem. > >> > > >> > Signed-off-by: Shreeya Patel > >> As this has a clear dependency on the previous patch, please put them > >> in the same series for the next version. That way I won't miss one! > >> > >> This also doesn't actually seem to have all the patches in place. > >> The sign extend one is definitely missing for some reason. > >> > >> One question on the ABI choice of X for the rotation axis. > >> I think the logical choice is actually Z but would like to know what > >> you and others think. > >> > >> All existing users of IIO_ROT (outside staging) have been > >> magnetometer > >> where we don't have an axis, but rather a magnetic reference frame or > >> a quaternion output which includes all the axes. > >> > >> Jonathan > >> > >> > > >> > --- > >> > > >> > Changes in v2 > >> > -Re-send the patch after having some cleanups in the > >> > file included in this patch. > >> > > >> > drivers/iio/accel/Kconfig | 12 ++ > >> > drivers/iio/accel/Makefile| 1 + > >> > drivers/iio/accel/adis16209.c | 329 > >> > ++ > >> > drivers/staging/iio/accel/Kconfig | 12 -- > >> > drivers/staging/iio/accel/Makefile| 1 - > >> > drivers/staging/iio/accel/adis16209.c | 329 -- > >> > > >> > 6 files changed, 342 insertions(+), 342 deletions(-) > >> > create mode 100644 drivers/iio/accel/adis16209.c > >> > delete mode 100644 drivers/staging/iio/accel/adis16209.c > >> > > >> > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > >> > index c6d9517..f95f43c 100644 > >> > --- a/drivers/iio/accel/Kconfig > >> > +++ b/drivers/iio/accel/Kconfig > >> > @@ -5,6 +5,18 @@ > >> > > >> > menu "Accelerometers" > >> > > >> > +config ADIS16209 > >> > +tristate "Analog Devices ADIS16209 Dual-Axis Digital > >> > Inclinometer and Accelerometer" > >> > +depends on SPI > >> > +select IIO_ADIS_LIB > >> > +select IIO_ADIS_LIB_BUFFER if IIO_BUFFER > >> > +help > >> > + Say Y here to build support for Analog Devices adis16209 > >> > dual-axis digital inclinometer > >> > + and accelerometer. > >> > + > >> > + To compile this driver as a module, say M here: the > >> > module will be > >> > + called adis16209. > >> > + > >> > config ADXL345 > >> > tristate > >> > > >> > diff --git a/drivers/iio/accel/Makefile > >> > b/drivers/iio/accel/Makefile > >> > index 368aedb..40861b9 100644 > >> > --- a/drivers/iio/accel/Makefile > >> > +++ b/drivers/iio/accel/Makefile > >> > @@ -4,6 +4,7 @@ > >> > # > >> > > >> > # When adding new entries keep the list in alphabetical order > >> > +obj-$(CONFIG_ADIS16209) += adis16209.o > >> > obj-$(CONFIG_ADXL345) += adxl345_core.o > >> > obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o > >> > obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o > >> > diff --git a/drivers/iio/accel/adis16209.c > >> > b/drivers/iio/accel/adis16209.c > >> > new file mode 100644 > >> > index 000..ed2e89f > >> > --- /dev/null > >> > +++ b/drivers/iio/accel/adis16209.c > >> > @@ -0,0 +1,329 @@ > >> > +/* > >> > + * ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer > >> > + * > >> > + * Copyright 2010 Analog Devices Inc. > >> > + * > >> > + * Licensed under the GPL-2 or later. > >> > + */ > >> > + > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > + > >> > +#include > >> > +#include > >> > +#include > >> > +#include > >> > + > >> > +#define ADIS16209_STARTUP_DELAY_MS 220 > >> > +#define ADIS16209_FLASH_CNT_REG 0x00 > >> > + > >> > +/* Data Output Register Definitions */ > >> > +#define ADIS16209_SUPPLY_OUT_REG0x02 > >> > +#define ADIS16209_XACCL_OUT_REG 0x04 > >> > +#define ADIS16209_YACCL_OUT_REG 0x06 > >> > +/* Output, auxiliary ADC input */ > >> > +#define ADIS16209_AUX_ADC_REG 0x08 > >> > +/* Output, temperature */ > >> > +#define ADIS16209_TEMP_OUT_REG 0x0A > >> > +/* Output, +/- 90 degrees X-axis inclination */ > >> > +#define ADIS16209_XINCL_OUT_REG 0x0C > >> > +#define ADIS16209_YINCL_OUT_REG 0x0E > >> > +/* Output, +/-180 vertical rotational position */ > >> > +#define ADIS16209_ROT_OUT_REG 0x10 > >> > + > >> > +/* > >> > + * Calibration Register Definitions. > >> > + * Acceleration, inclination or rotation offset null. > >> > + */ > >> > +#define ADIS16209_XACCL_NULL_REG0x12 > >> > +#define ADIS16209_YACCL_NULL_REG
Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working
On Tue, Mar 13, 2018 at 04:12:19PM -0600, Christ, Austin wrote: > Sorry for the miscommunication. I reviewed the patches and tested them on > the Centriq 2400 platform. > > Perhaps the following is the most appropriate. > > Acked-by: Austin Christ If you are okay with that, I'll just read it as "Tested-by" for the whole series. Thanks! signature.asc Description: PGP signature
Re: [PATCH v2 01/13] i2c: qup: fix copyrights and update to SPDX identifier
On Mon, Mar 12, 2018 at 06:44:50PM +0530, Abhishek Sahu wrote: > The file has been updated from 2016 to 2018 so fixed the > copyright years. > > Signed-off-by: Abhishek Sahu > --- > drivers/i2c/busses/i2c-qup.c | 13 ++--- > 1 file changed, 2 insertions(+), 11 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c > index 08f8e01..ac5edfa 100644 > --- a/drivers/i2c/busses/i2c-qup.c > +++ b/drivers/i2c/busses/i2c-qup.c > @@ -1,17 +1,8 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > - * Copyright (c) 2009-2013, The Linux Foundation. All rights reserved. > + * Copyright (c) 2009-2013, 2016-2018, The Linux Foundation. All rights > reserved. Can we do this? I know that CodeAurora is hosted by LF, but can you extend their copyright when working for Qualcomm? > * Copyright (c) 2014, Sony Mobile Communications AB. > * > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 and > - * only version 2 as published by the Free Software Foundation. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > */ > > #include > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of > Code Aurora Forum, hosted by The Linux Foundation > signature.asc Description: PGP signature
Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR
On Wed, 14 Mar 2018 23:12:02 -0700
John Syne wrote:
> Hi Jonathan,
>
> I have been looking at the IIO ABI docs and if I understand
> correctly, the idea is to use consistent naming conventions? So for
> example, looking at the ADE7854 datasheet, the naming matching the
> ADE7854 registers would be as follows:
Welcome to one of the big reasons no one tidied these drivers
up originally. Still we have moved on somewhat since then
so similar circumstances have come up in other types of sensor.
>
> {direction}_{type}_{index}_{modifier}_{info_mask}
>
> AIGAIN- In_current_a_gain
Other than the fact that gain isn't an ABI element and that index
doesn't have
_ before it that is right.
in_voltageA_scale
That was a weird quirk a long time back which we should probably
not have done (copied it from hwmon)
> AVGAIN- in_voltage_a_gain
> BIGAIN- in_current_b_gain
> BVGAIN- in_voltage_b_gain
> —
> How do we represent the rms and offset
> AIRMSOS - in_current_a_rmsoffset
> AVRMSOS - in_voltage_a_rmsoffset
Right now we can't unfortunately though this one is easier to fix.
We already have modifiers for multi axis devices doing sum_squared
so add one of those for root_mean_square - this one is well known
enough that rms is fine in the string.
It's a effectively a different channel be it one derived from a simple
one. This is going to get tricky however as we would normally use
modifier to specialise a channel type - thoughts on this below.
> —
> Here I don’t understand how to represent both the phase and the
> active/reactive/apparent power components. Do we combine the phase and
> quadrature part like this
> AVAGAIN - in_power_a_gain /*
> apparent power */
> —
> AWGAIN- in_power_ai_gain
> /* active power */
And that is the problem. How do we represent the various power types.
Hmm. We could do it with modifiers but above we show that we have already used
them.
It would be easy enough to add yet another field to the channel spec to specify
this but there is a problem - Events. The event format is already pretty full
so where do we put this extra element if we need to define a channel separated
only by it.
One thought is we could instead define these as different top level
IIO_CHAN_TYPES in a similar fashion to we do for relative humidity vs
the proposed absolute humidity.
in_powerreactiveA_scale
in_poweractivceA_scale
(or in_powerrealA_scale to match with what I got taught years ago?)
I presume we keep in_powerA_scale etc for the apparent power and
modify any docs to make that clear.
> —
> AVARGAIN - in_power_aq_gain/*
> reactive power */
> —
> Now here it becomes more complicated. Not sure how this gets handled.
> AFWATTOS - in_power_a_active/fundamental/offset
Yeah, some of these are getting odd.
If I read this correctly this is the active power estimate based on only
the fundamental frequency - so no harmonics?
Hmm. This then becomes a separate channel with additional properties
specifying it is only the fundamental. This feels a bit like a filter
be it an unusual one? Might just be necessary to add a _fundamental_only
element on the end (would be info_mask if this is common enough to
justify that rather than using the extended methods to define it.).
> —
> AWATTHR - in_energy_ai_accumulation
Great, just when I thought we had gone far enough they define reactive
energy which is presumably roughly the same as reactivepower * time?
In that case we need types for that as well.
in_energyreactiveA_*
in_energyactiveA_*
> —
> AVARHR- in_energy_aq_accumulation
> —
> IPEAK - in_current_peak
That one is easy as we have an info_mask element for peak and one
for peak_scale that has always been a bit odd but was needed somewhere.
> —
>
> I’ll leave it there, because there are some even more complicated register
> naming issues.
Something to look forward to. Gah, I always hated power engineering
though I taught it very briefly (I really pity those students :(
Jonathan
>
> Regards,
> John
>
>
>
>
>
> > On Mar 10, 2018, at 7:10 AM, Jonathan Cameron wrote:
> >
> > On Thu, 8 Mar 2018 21:37:33 -0300
> > Rodrigo Siqueira wrote:
> >
> >> On 03/07, Jonathan Cameron wrote:
> >>> On Tue, 6 Mar 2018 21:43:47 -0300
> >>> Rodrigo Siqueira wrote:
> >>>
> The macro IIO_DEV_ATTR_CH_OFF is a wrapper for IIO_DEVICE_ATTR, with a
> tiny change in the name definition. This extra macro does not improve
> the readability and also creates some checkpatch errors.
>
> This patch fixes the checkpatch.pl errors:
>
> staging/iio/meter/ade7753.c:391: ERROR: Use 4 digit octal (0777) not
> decimal permissions
> staging/iio/meter/ade7753.c:395: ERROR: Use 4 digit octal (0777) not
> decim
Re: [PATCH 35/47] i2c: remove bfin-twi driver
On Wed, Mar 14, 2018 at 04:35:48PM +0100, Arnd Bergmann wrote: > The blackfin architecture is getting removed, so the > twi driver can also be removed. > > Signed-off-by: Arnd Bergmann Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH] i2c: xiic: Make suspend function names consistent
On Sat, Mar 10, 2018 at 09:40:56AM -0800, Moritz Fischer wrote: > Suspend functions seem to have been copied from i2c-cadence driver. > Rename the functions to match the rest of the driver. > > Signed-off-by: Moritz Fischer Applied to for-next, thanks! signature.asc Description: PGP signature
[PATCH] MIPS: Fix build with DEBUG_ZBOOT and MACH_JZ4770
The debug definitions were missing for MACH_JZ4770, resulting in a build failure when DEBUG_ZBOOT was set. Since the UART addresses are the same across all Ingenic SoCs, we just use a #ifdef CONFIG_MACH_INGENIC instead of checking for indifidual Ingenic SoCs. Additionally, I added a #define for the UART0 address in-code and dropped the include, for the reason that this include file is slowly being phased out as the whole platform is being moved to devicetree. Signed-off-by: Paul Cercueil --- arch/mips/boot/compressed/uart-16550.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/boot/compressed/uart-16550.c b/arch/mips/boot/compressed/uart-16550.c index b3043c08f769..dd4e6d622184 100644 --- a/arch/mips/boot/compressed/uart-16550.c +++ b/arch/mips/boot/compressed/uart-16550.c @@ -18,9 +18,9 @@ #define PORT(offset) (CKSEG1ADDR(AR7_REGS_UART0) + (4 * offset)) #endif -#if defined(CONFIG_MACH_JZ4740) || defined(CONFIG_MACH_JZ4780) -#include -#define PORT(offset) (CKSEG1ADDR(JZ4740_UART0_BASE_ADDR) + (4 * offset)) +#if CONFIG_MACH_INGENIC +#define INGENIC_UART0_BASE_ADDR0x1003 +#define PORT(offset) (CKSEG1ADDR(INGENIC_UART0_BASE_ADDR) + (4 * offset)) #endif #ifdef CONFIG_CPU_XLR -- 2.11.0
Re: [PATCH v3 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry
Hi Gary,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Gary-R-Hook/Add-debugfs-info-for-the-AMD-IOMMU/20180317-232302
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/iommu/amd_iommu_debugfs.c: In function
'amd_iommu_debugfs_devid_write':
>> drivers/iommu/amd_iommu_debugfs.c:145:3: warning: ignoring return value of
>> 'kstrtoint', declared with attribute warn_unused_result [-Wunused-result]
kstrtoint(obuf, 0, &amd_iommu_devid);
^~~~
vim +/kstrtoint +145 drivers/iommu/amd_iommu_debugfs.c
123
124 static ssize_t amd_iommu_debugfs_devid_write(struct file *filp,
125 const char __user *ubuf,
126 size_t count, loff_t *offp)
127 {
128 unsigned int pci_id, pci_slot, pci_func;
129 unsigned int obuflen = 80;
130 ssize_t ret;
131 char *obuf;
132
133 obuf = kmalloc(OBUFLEN, GFP_KERNEL);
134 if (!obuf)
135 return -ENOMEM;
136
137 ret = simple_write_to_buffer(obuf, OBUFLEN, offp, ubuf, count);
138
139 if (strnchr(obuf, OBUFLEN, ':')) {
140 int n;
141 n = sscanf(obuf, "%x:%x.%x", &pci_id, &pci_slot,
&pci_func);
142 if (n == 3)
143 amd_iommu_devid = PCI_DEVID(pci_id,
PCI_DEVFN(pci_slot, pci_func));
144 } else {
> 145 kstrtoint(obuf, 0, &amd_iommu_devid);
146 }
147
148 kfree(obuf);
149
150 return ret;
151 }
152
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
On Sat, Mar 17, 2018 at 11:52 AM, Linus Torvalds wrote: > So the above is completely insane, bit there is actually a chance that > using that completely crazy "x -> sizeof(char[x])" conversion actually > helps, because it really does have a (very odd) evaluation-time > change. sizeof() has to be evaluated as part of the constant > expression evaluation, in ways that "__builtin_constant_p()" isn't > specified to be done. > > But it is also definitely me grasping at straws. If that doesn't work > for 4.4, there's nothing else I can possibly see. No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only does it not change the complaint about __builtin_choose_expr(), it also thinks that's a VLA now. ./include/linux/mm.h: In function ‘get_mm_hiwater_rss’: ./include/linux/mm.h:1567: warning: variable length array is used ./include/linux/mm.h:1567: error: first argument to ‘__builtin_choose_expr’ not a constant 6.8 is happy with it (of course). I do think the earlier version (without the sizeof-hiding-builting_constant_p) provides a template for a const_max() that both you and Rasmus would be happy with, though! -Kees -- Kees Cook Pixel Security
Re: [PATCH] iio/gyro/bmg160_core: Improve unlocking of a mutex in five functions
On Wed, 14 Mar 2018 16:15:32 +0100
SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Wed, 14 Mar 2018 16:06:49 +0100
>
> * Add jump targets so that a call of the function "mutex_unlock" is stored
> only once in these function implementations.
>
> * Replace 19 calls by goto statements.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Hi Markus,
Some of these are good and sensible changes - others break the code.
Please be careful to fully check all the resulting paths and ensure
we don't change wether the lock is still held in all exit paths.
Note a function that isn't lockdep annotated should not be holding
any locks, that it took, upon exit.
> ---
> drivers/iio/gyro/bmg160_core.c | 103
> ++---
> 1 file changed, 45 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
> index 63ca31628a93..fa367fd7bc8c 100644
> --- a/drivers/iio/gyro/bmg160_core.c
> +++ b/drivers/iio/gyro/bmg160_core.c
> @@ -499,21 +499,19 @@ static int bmg160_get_temp(struct bmg160_data *data,
> int *val)
>
> mutex_lock(&data->mutex);
> ret = bmg160_set_power_state(data, true);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
>
> ret = regmap_read(data->regmap, BMG160_REG_TEMP, &raw_val);
> if (ret < 0) {
> dev_err(dev, "Error reading reg_temp\n");
> bmg160_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
>
> *val = sign_extend32(raw_val, 7);
> ret = bmg160_set_power_state(data, false);
> +unlock:
> mutex_unlock(&data->mutex);
> if (ret < 0)
> return ret;
> @@ -529,22 +527,20 @@ static int bmg160_get_axis(struct bmg160_data *data,
> int axis, int *val)
>
> mutex_lock(&data->mutex);
> ret = bmg160_set_power_state(data, true);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
>
> ret = regmap_bulk_read(data->regmap, BMG160_AXIS_TO_REG(axis), &raw_val,
> sizeof(raw_val));
> if (ret < 0) {
> dev_err(dev, "Error reading axis %d\n", axis);
> bmg160_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
>
> *val = sign_extend32(le16_to_cpu(raw_val), 15);
> ret = bmg160_set_power_state(data, false);
> +unlock:
> mutex_unlock(&data->mutex);
> if (ret < 0)
> return ret;
> @@ -632,19 +628,16 @@ static int bmg160_write_raw(struct iio_dev *indio_dev,
>* mode to power on for other writes.
>*/
> ret = bmg160_set_power_state(data, true);
> - if (ret < 0) {
> - mutex_unlock(&data->mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
> +
> ret = bmg160_set_bw(data, val);
> if (ret < 0) {
> bmg160_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
> - ret = bmg160_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> +
> + goto set_power_state;
> case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
> if (val2)
> return -EINVAL;
> @@ -653,18 +646,15 @@ static int bmg160_write_raw(struct iio_dev *indio_dev,
> ret = bmg160_set_power_state(data, true);
> if (ret < 0) {
> bmg160_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
> ret = bmg160_set_filter(data, val);
> if (ret < 0) {
> bmg160_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> + goto unlock;
> }
> - ret = bmg160_set_power_state(data, false);
> - mutex_unlock(&data->mutex);
> - return ret;
> +
> + goto set_power_state;
> case IIO_CHAN_INFO_SCALE:
> if (val)
> return -EINVAL;
> @@ -672,24 +662,27 @@ static int bmg160_write_raw(struct iio_dev *indio_dev,
> mutex_lock(&data->mutex);
> /* Refer to comments above for the suspend mode ops */
> ret = bmg160_set_power
Re: [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation
On Fri, 2018-03-16 at 21:18 +0100, Sebastian Andrzej Siewior wrote: > The goal here is to make the memory allocation in get_irq_table() not > with disabled interrupts and having as little raw_spin_lock as > possible > while having them if the caller is also holding one (like desc->lock > during IRQ-affinity changes). > I reverted one patch one patch in the iommu while rebasing since it > make job easier. If the goal is to have "as little raw_spin_lock as possible" -- and presumably also to avoid unnecessary complexity -- wouldn't it be better to leave my patch in, and drop patches 4 and 9? -Scott
Re: [PATCH] locks: change POSIX lock ownership on execve when files_struct is displaced
On Sat, 2018-03-17 at 15:52 +, Al Viro wrote: > On Sat, Mar 17, 2018 at 11:43:28AM -0400, Jeff Layton wrote: > > On Sat, 2018-03-17 at 15:05 +, Al Viro wrote: > > > On Sat, Mar 17, 2018 at 10:25:20AM -0400, Jeff Layton wrote: > > > > From: Jeff Layton > > > > > > > > POSIX mandates that open fds and their associated file locks should be > > > > preserved across an execve. This works, unless the process is > > > > multithreaded at the time that execve is called. > > > > > > > > In that case, we'll end up unsharing the files_struct but the locks will > > > > still have their fl_owner set to the address of the old one. Eventually, > > > > when the other threads die and the last reference to the old > > > > files_struct is put, any POSIX locks get torn down since it looks like > > > > a close occurred on them. > > > > > > > > The result is that all of your open files will be intact with none of > > > > the locks you held before execve. The simple answer to this is "use OFD > > > > locks", but this is a nasty surprise and it violates the spec. > > > > > > > > On a successful execve, change ownership of any POSIX file_locks > > > > associated with the old files_struct to the new one, if we ended up > > > > swapping it out. > > > > > > TBH, I don't like the way you implement that. Why not simply use > > > iterate_fd()? > > > > Ahh, I wasn't aware of it. I copied the loop in change_lock_owners from > > close_files. I'll have a look at iterate_fd(). > > BTW, if iterate_fd() turns out to be slower, it might make sense to have it > look at the bitmap to skip unpopulated parts of descriptor table faster - > other users might also benefit from that. Thanks, I'll keep that in mind. Full disclosure: I haven't done any performance testing with this. My assumption is that threaded programs that execve without forking first are rather rare. I don't know of a great way to confirm that though. I made a small change to the v2 patch as well to use struct files_struct * instead of fl_owner_t here. That gives us more type safety and should prevent any problems if Bruce's patch to remove fl_owner_t gets merged. Thanks, -- Jeff Layton
Re: [PATCH] init: no need to wait device probe
Hi,
On 03/15/2018 12:20 AM, ning.a.zh...@intel.com wrote:
> From: Zhang Ning
meta comment (i.e., not about the merits of the patch itself):
You'll need to send the patch to someone if you want it to be merged.
Maintainers don't mine mailing lists for patches to apply.
> there are 2 reasons for no need to wait device probe
>
> reason 1:
> mount root device is very late in kernel initial stage.
> all initcalls are finished. that means most of probe functions
> are returned.
>
> and deferred probe are also finished by late_initcall.
> only async probe driver are possible in probing.
>
> no block devices, device-mapper or nfs are use async probe.
> so no need to wait device probe.
>
> reason 2:
> let's check dd.c, probe_count is increased and decreased only
> in really_probe, and when really_probe returns, probe_count
> always be 0.
>
> when someone really wants to wait device-B probe.
> but code looks like:
>
> thread-1: thread-2:
> probe device-A; wait_for_device_probe();
> msleep(30);
> probe device-B
>
> when device-A probe finishes, thread-2 will be wakeup,
> but device-B is not probed.
>
> wait_for_device_probe can't make sure the device you want is probed.
>
> based on above 2 reasons, no need to wait for device probe.
>
> Signed-off-by: Zhang Ning
> ---
> init/do_mounts.c| 9 -
> init/do_mounts_md.c | 2 --
> 2 files changed, 11 deletions(-)
>
> diff --git a/init/do_mounts.c b/init/do_mounts.c
> index 7cf4f6dafd5f..a9fb2ad44964 100644
> --- a/init/do_mounts.c
> +++ b/init/do_mounts.c
> @@ -555,15 +555,6 @@ void __init prepare_namespace(void)
> ssleep(root_delay);
> }
>
> - /*
> - * wait for the known devices to complete their probing
> - *
> - * Note: this is a potential source of long boot delays.
> - * For example, it is not atypical to wait 5 seconds here
> - * for the touchpad of a laptop to initialize.
> - */
> - wait_for_device_probe();
> -
> md_run_setup();
>
> if (saved_root_name[0]) {
> diff --git a/init/do_mounts_md.c b/init/do_mounts_md.c
> index 3f733c760a8c..4aab3492e71d 100644
> --- a/init/do_mounts_md.c
> +++ b/init/do_mounts_md.c
> @@ -292,8 +292,6 @@ static void __init autodetect_raid(void)
> printk(KERN_INFO "md: Waiting for all devices to be available before
> autodetect\n");
> printk(KERN_INFO "md: If you don't use raid, use raid=noautodetect\n");
>
> - wait_for_device_probe();
> -
> fd = sys_open("/dev/md0", 0, 0);
> if (fd >= 0) {
> sys_ioctl(fd, RAID_AUTORUN, raid_autopart);
>
--
~Randy
Re: NULL pointer dereferences with 4.14.27
On 03/17/18 19:41, Carlos Carvalho wrote: > I've put 4.14.27 this morning in this machine and in about 2h it started > showing null dereferences identical to the following one. There were several > of > them, with about 1/2h of interval. Strangely it continued to work and I saw no > other anomalies. I've just reverted to 4.14.26. > > It only happened in this machine, which has a net traffic of several Gb/s and > thousands of simultaneous connections. > > Mar 17 13:29:21 sagres kernel: : BUG: unable to handle kernel NULL pointer > dereference at 0038 > Mar 17 13:29:21 sagres kernel: : IP: tcp_push+0x4e/0xe7 > Mar 17 13:29:21 sagres kernel: : PGD 0 P4D 0 > Mar 17 13:29:21 sagres kernel: : Oops: 0002 [#1] SMP PTI > Mar 17 13:29:21 sagres kernel: : CPU: 55 PID: 2658 Comm: apache2 Not tainted > 4.14.27 #4 > Mar 17 13:29:21 sagres kernel: : task: 89791cf7e600 task.stack: > abdd91db8000 > Mar 17 13:29:21 sagres kernel: : RIP: 0010:tcp_push+0x4e/0xe7 > Mar 17 13:29:21 sagres kernel: : RSP: 0018:abdd91dbbc10 EFLAGS: 00010246 > Mar 17 13:29:21 sagres kernel: : RAX: RBX: 04c4 > RCX: 0001 > Mar 17 13:29:21 sagres kernel: : RDX: 0001 RSI: 0040 > RDI: 89968330a100 > Mar 17 13:29:21 sagres kernel: : RBP: 89968330a250 R08: 7be8 > R09: e77cbfc4ab00 > Mar 17 13:29:21 sagres kernel: : R10: 89968330a250 R11: > R12: 8987aab3bb80 > Mar 17 13:29:21 sagres kernel: : R13: 89968330a100 R14: 89791cf7e930 > R15: ffe0 > Mar 17 13:29:21 sagres kernel: : FS: 7f0bd67d4700() > GS:89993f4c() knlGS: > Mar 17 13:29:21 sagres kernel: : CS: 0010 DS: ES: CR0: > 80050033 > Mar 17 13:29:21 sagres kernel: : CR2: 0038 CR3: 003ff4842006 > CR4: 003606e0 > Mar 17 13:29:21 sagres kernel: : DR0: DR1: > DR2: > Mar 17 13:29:21 sagres kernel: : DR3: DR6: fffe0ff0 > DR7: 0400 > Mar 17 13:29:21 sagres kernel: : Call Trace: > Mar 17 13:29:21 sagres kernel: : tcp_sendmsg_locked+0xac6/0xc1e > Mar 17 13:29:21 sagres kernel: : tcp_sendmsg+0x23/0x35 > Mar 17 13:29:21 sagres kernel: : sock_sendmsg+0x11/0x1b > Mar 17 13:29:21 sagres kernel: : sock_write_iter+0x71/0x87 > Mar 17 13:29:21 sagres kernel: : do_iter_readv_writev+0xf0/0x111 > Mar 17 13:29:21 sagres kernel: : do_iter_write+0x84/0xf0 > Mar 17 13:29:21 sagres kernel: : vfs_writev+0xad/0xfb > Mar 17 13:29:21 sagres kernel: : ? do_writev+0x56/0x92 > Mar 17 13:29:21 sagres kernel: : do_writev+0x56/0x92 > Mar 17 13:29:21 sagres kernel: : do_syscall_64+0x181/0x210 > Mar 17 13:29:21 sagres kernel: : entry_SYSCALL_64_after_hwframe+0x3d/0xa2 > Mar 17 13:29:21 sagres kernel: : RIP: 0033:0x7f13f1264017 > Mar 17 13:29:21 sagres kernel: : RSP: 002b:7f0bd67d2810 EFLAGS: 0293 > ORIG_RAX: 0014 > Mar 17 13:29:21 sagres kernel: : RAX: ffda RBX: 0079 > RCX: 7f13f1264017 > Mar 17 13:29:21 sagres kernel: : RDX: 000a RSI: 7f0bd67d2970 > RDI: 0079 > Mar 17 13:29:21 sagres kernel: : RBP: 7f0bd67d2970 R08: > R09: 7f13680762c8 > Mar 17 13:29:21 sagres kernel: : R10: 556029c85dd4 R11: 0293 > R12: 000a > Mar 17 13:29:21 sagres kernel: : R13: 7f0bd67d2970 R14: 7f0bd67d28d0 > R15: 556029ea1440 > Mar 17 13:29:21 sagres kernel: : Code: d0 75 02 31 c0 41 89 f3 41 81 e3 00 80 > 00 00 74 1a 44 8b 8f 58 05 00 00 41 d1 e9 44 2b 8f 5c 06 00 00 44 03 8f 64 06 > 00 00 79 10 <80> 48 38 08 8b 8f 5c 06 00 00 89 8f 64 06 00 00 40 80 e6 01 74 > Mar 17 13:29:21 sagres kernel: : RIP: tcp_push+0x4e/0xe7 RSP: abdd91dbbc10 > Mar 17 13:29:21 sagres kernel: : CR2: 0038 > Mar 17 13:29:21 sagres kernel: : ---[ end trace f9a8f71d250d2782 ]--- > Fixed by: https://www.spinics.net/lists/netdev/msg489445.html -h
Re: [PATCH v2 3/8] gpio: pci-idio-16: Implement get_multiple callback
Hi William,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Implement-get_multiple-for-ACCES-and-PC-104-drivers/20180317-224135
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/gpio/gpio-pci-idio-16.c:139:17: sparse: undefined identifier
'word_mask'
drivers/gpio/gpio-pci-idio-16.c:140:22: sparse: undefined identifier
'word_mask'
>> drivers/gpio/gpio-pci-idio-16.c:120:27: sparse: dereference of noderef
>> expression
drivers/gpio/gpio-pci-idio-16.c:120:52: sparse: dereference of noderef
expression
drivers/gpio/gpio-pci-idio-16.c:121:27: sparse: dereference of noderef
expression
drivers/gpio/gpio-pci-idio-16.c:121:51: sparse: dereference of noderef
expression
>> drivers/gpio/gpio-pci-idio-16.c:139:17: sparse: generating address of
>> non-lvalue (3)
drivers/gpio/gpio-pci-idio-16.c: In function 'idio_16_gpio_get_multiple':
drivers/gpio/gpio-pci-idio-16.c:139:3: error: 'word_mask' undeclared (first
use in this function); did you mean 'port_mask'?
word_mask = mask[word_index] & (port_mask << word_offset);
^
port_mask
drivers/gpio/gpio-pci-idio-16.c:139:3: note: each undeclared identifier is
reported only once for each function it appears in
drivers/gpio/gpio-pci-idio-16.c:146:24: warning: passing argument 1 of
'ioread8' discards 'const' qualifier from pointer target type
[-Wdiscarded-qualifiers]
port_state = ioread8(ports + i);
^
In file included from arch/x86/include/asm/io.h:223:0,
from arch/x86/include/asm/realmode.h:15,
from arch/x86/include/asm/acpi.h:33,
from arch/x86/include/asm/fixmap.h:19,
from arch/x86/include/asm/apic.h:10,
from arch/x86/include/asm/smp.h:13,
from arch/x86/include/asm/mmzone_64.h:11,
from arch/x86/include/asm/mmzone.h:5,
from include/linux/mmzone.h:912,
from include/linux/gfp.h:6,
from include/linux/idr.h:16,
from include/linux/kernfs.h:14,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from drivers/gpio/gpio-pci-idio-16.c:16:
include/asm-generic/iomap.h:29:21: note: expected 'void *' but argument is
of type 'const u8 * {aka const unsigned char *}'
extern unsigned int ioread8(void __iomem *);
^~~
drivers/gpio/gpio-pci-idio-16.c:116:16: warning: unused variable 'mask_word'
[-Wunused-variable]
unsigned long mask_word;
^
vim +120 drivers/gpio/gpio-pci-idio-16.c
106
107 static int idio_16_gpio_get_multiple(struct gpio_chip *chip,
108 unsigned long *mask, unsigned long *bits)
109 {
110 struct idio_16_gpio *const idio16gpio = gpiochip_get_data(chip);
111 size_t i;
112 const unsigned int gpio_reg_size = 8;
113 unsigned int bits_offset;
114 size_t word_index;
115 unsigned int word_offset;
116 unsigned long mask_word;
117 const unsigned long port_mask = GENMASK(gpio_reg_size, 0);
118 unsigned long port_state;
119 const u8 __iomem ports[] = {
> 120 idio16gpio->reg->out0_7, idio16gpio->reg->out8_15,
121 idio16gpio->reg->in0_7, idio16gpio->reg->in8_15
122 };
123
124 /* clear bits array to a clean slate */
125 bitmap_zero(bits, chip->ngpio);
126
127 /* get bits are evaluated a gpio port register at a time */
128 for (i = 0; i < ARRAY_SIZE(ports); i++) {
129 /* gpio offset in bits array */
130 bits_offset = i * gpio_reg_size;
131
132 /* word index for bits array */
133 word_index = BIT_WORD(bits_offset);
134
135 /* gpio offset within current word of bits array */
136 word_offset = bits_offset % BITS_PER_LONG;
137
138 /* mask of get bits for current gpio within current
word */
> 139 word_mask = mask[word_index] & (port_mask <<
> word_offset);
140 if (!word_mask) {
141
Re: [PATCH v3 1/8] iio: stx104: Implement get_multiple callback
On Sat, Mar 17, 2018 at 08:51:07PM +0200, Andy Shevchenko wrote:
>On Sat, Mar 17, 2018 at 5:49 PM, William Breathitt Gray
> wrote:
>> The Apex Embedded Systems STX104 series of devices provides 4 TTL
>> compatible lines of inputs accessed via a single 4-bit port. Since four
>> input lines are acquired on a single port input read, the STX104 GPIO
>> driver may improve multiple input reads by utilizing a get_multiple
>> callback. This patch implements the stx104_gpio_get_multiple function
>> which serves as the respective get_multiple callback.
>
>> +static int stx104_gpio_get_multiple(struct gpio_chip *chip, unsigned long
>> *mask,
>> + unsigned long *bits)
>> +{
>> + struct stx104_gpio *const stx104gpio = gpiochip_get_data(chip);
>> +
>
>> + *bits = inb(stx104gpio->base);
>
>I think on LE and BE if will give you different results.
That may be true for a memcpy operation, but in this case I'm relying on
the standard C evaluation rules. I expect we should be fine with the
returned byte assigned to an unsigned long, since it'll be evaluated by
its value rather than memory representation.
William Breathitt Gray
>
>> +
>> + return 0;
>> +}
>
>
>
>--
>With Best Regards,
>Andy Shevchenko
Re: [PATCH 11/12] crypto: inside-secure - hmac(sha256) support
Hi Antoine,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20180309]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2 v4.16-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Antoine-Tenart/crypto-inside-secure-hmac-sha256-sha224-support/20180318-012349
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/crypto/inside-secure/safexcel_hash.c:481:9: sparse: Variable length
array is used.
drivers/crypto/inside-secure/safexcel_hash.c:979:45: sparse: cast to
restricted __le32
drivers/crypto/inside-secure/safexcel_hash.c:980:45: sparse: cast to
restricted __le32
drivers/crypto/inside-secure/safexcel_hash.c:1166:12: sparse: no member
'digest' in struct safexcel_ahash_ctx
drivers/crypto/inside-secure/safexcel_hash.c:189:12: sparse: context
imbalance in 'safexcel_ahash_send_req' - wrong count at exit
drivers/crypto/inside-secure/safexcel_hash.c:1166:12: sparse: generating
address of non-lvalue (8)
drivers/crypto/inside-secure/safexcel_hash.c: In function
'safexcel_hmac_sha256_init':
>> drivers/crypto/inside-secure/safexcel_hash.c:1166:5: error: 'struct
>> safexcel_ahash_ctx' has no member named 'digest'
ctx->digest = CONTEXT_CONTROL_DIGEST_HMAC;
^~
sparse warnings: (new ones prefixed by >>)
drivers/crypto/inside-secure/safexcel_hash.c:481:9: sparse: Variable length
array is used.
drivers/crypto/inside-secure/safexcel_hash.c:979:45: sparse: cast to
restricted __le32
drivers/crypto/inside-secure/safexcel_hash.c:980:45: sparse: cast to
restricted __le32
drivers/crypto/inside-secure/safexcel_hash.c:1166:12: sparse: no member
'digest' in struct safexcel_ahash_ctx
drivers/crypto/inside-secure/safexcel_hash.c:189:12: sparse: context
imbalance in 'safexcel_ahash_send_req' - wrong count at exit
>> drivers/crypto/inside-secure/safexcel_hash.c:1166:12: sparse: generating
>> address of non-lvalue (8)
drivers/crypto/inside-secure/safexcel_hash.c: In function
'safexcel_hmac_sha256_init':
drivers/crypto/inside-secure/safexcel_hash.c:1166:5: error: 'struct
safexcel_ahash_ctx' has no member named 'digest'
ctx->digest = CONTEXT_CONTROL_DIGEST_HMAC;
^~
vim +1166 drivers/crypto/inside-secure/safexcel_hash.c
1160
1161 static int safexcel_hmac_sha256_init(struct ahash_request *areq)
1162 {
1163 struct safexcel_ahash_ctx *ctx =
crypto_ahash_ctx(crypto_ahash_reqtfm(areq));
1164
1165 safexcel_sha256_init(areq);
> 1166 ctx->digest = CONTEXT_CONTROL_DIGEST_HMAC;
1167 return 0;
1168 }
1169
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: what the hell is compat_sys_x86_waitpid() for?
On Sat, Mar 17, 2018 at 11:19:55AM -0700, Linus Torvalds wrote: > On Sat, Mar 17, 2018 at 11:01 AM, Al Viro wrote: > > > > and tell me what is the difference between those. In other words, the > > problem > > with sys32_waitpid() was not that it didn't use proper wrappers - it's that > > it was (and always had been) 100% pointless. > > That long long predates Dominik's patches, though. Sure. > It clearly is worth fixing, but don't blame Dominik for just > mindlessly converting mindless code. The thing is, this area probably won't be looked at for many years in the future, so we'd better take the crap out now. Same problem as with mindless checkpatch.pl "fixes" - something unusually-looking obviously has gotten less attention, so removing the visual indication of that has a good chance of hiding something dumb. Not a problem if the code is actually OK, but that's worth checking. > I suspect the reason is simply that the *regular* waitpid() was writtn > in terms of sys_wait4(), and sys_wait4() needed a compat function, so > then waitpid was basically just carried along. Probably nobody remembers now... Another thing touched by the same commit: pread64(). Comparing it with other biarch architectures shows at least one dubious thing, also there since way back. Namely, s390 has if ((compat_ssize_t) count < 0) return -EINVAL; IOW, size >= 2G => -EINVAL. It *does* match the behaviour on 32bit - on all everything including i386. rw_verify_area() starts with int retval = -EINVAL; inode = file_inode(file); if (unlikely((ssize_t) count < 0)) return retval; 64bit read/write variants quietly truncate to 2Gb, so on amd64 a 32bit binary calling pread() with negative size will do 2Gb read while on i386 the same binary would've gotten -EINVAL. I'm not sure if it's worth bothering with, though - it's not just pread(). read(2) has exact same issue and yes, s390 does have a separate wrapper for it, with the same check. The same goes for write(2) there. Do we care about that, and if not - does s390 really need to bother? The rest of biarch wrappers for sys_pread64() is very close to being unifiable - the only real issue is whether this architecture has a dummy padding argument between count and (halves of) pos. arm64, mips and ppc do; parisc, s390, sparc and x86 do not...
Re: [PATCH v2 1/2] tracing: Improve design of preemptirq tracepoints and its users
Hi Joel, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc5 next-20180316] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Joel-Fernandes/Improve-preemptirq-tracepoint-usage/20180317-155535 config: arm-moxart_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): arch/arm/kernel/entry-common.o: In function `no_work_pending': >> (.entry.text+0x64): undefined reference to `trace_hardirqs_on' arch/arm/kernel/entry-common.o: In function `vector_swi': (.entry.text+0xf8): undefined reference to `trace_hardirqs_on' arch/arm/kernel/entry-armv.o: In function `__dabt_svc': >> (.entry.text+0xa4): undefined reference to `trace_hardirqs_off' (.entry.text+0xb8): undefined reference to `trace_hardirqs_on' (.entry.text+0xc0): undefined reference to `trace_hardirqs_off' arch/arm/kernel/entry-armv.o: In function `__irq_svc': (.entry.text+0x12c): undefined reference to `trace_hardirqs_off' (.entry.text+0x158): undefined reference to `trace_hardirqs_on' arch/arm/kernel/entry-armv.o: In function `__und_svc': (.entry.text+0x1ec): undefined reference to `trace_hardirqs_off' arch/arm/kernel/entry-armv.o: In function `__und_svc_finish': (.entry.text+0x220): undefined reference to `trace_hardirqs_on' (.entry.text+0x228): undefined reference to `trace_hardirqs_off' arch/arm/kernel/entry-armv.o: In function `__pabt_svc': (.entry.text+0x2ac): undefined reference to `trace_hardirqs_off' (.entry.text+0x2c0): undefined reference to `trace_hardirqs_on' (.entry.text+0x2c8): undefined reference to `trace_hardirqs_off' arch/arm/kernel/entry-armv.o: In function `__dabt_usr': (.entry.text+0x4b4): undefined reference to `trace_hardirqs_off' arch/arm/kernel/entry-armv.o: In function `__irq_usr': (.entry.text+0x51c): undefined reference to `trace_hardirqs_off' arch/arm/kernel/entry-armv.o: In function `__und_usr': (.entry.text+0x594): undefined reference to `trace_hardirqs_off' (.entry.text+0x5a8): undefined reference to `trace_hardirqs_on' arch/arm/kernel/entry-armv.o: In function `__pabt_usr': (.entry.text+0x6bc): undefined reference to `trace_hardirqs_off' kernel/softirq.o: In function `tasklet_hi_action': >> softirq.c:(.text+0x144): undefined reference to `trace_hardirqs_off' >> softirq.c:(.text+0x154): undefined reference to `trace_hardirqs_on' softirq.c:(.text+0x1cc): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0x1ec): undefined reference to `trace_hardirqs_on' kernel/softirq.o: In function `tasklet_action': softirq.c:(.text+0x228): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0x240): undefined reference to `trace_hardirqs_on' softirq.c:(.text+0x2b8): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0x2d8): undefined reference to `trace_hardirqs_on' kernel/softirq.o: In function `run_ksoftirqd': softirq.c:(.text+0x40c): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0x420): undefined reference to `trace_hardirqs_on' softirq.c:(.text+0x438): undefined reference to `trace_hardirqs_on' kernel/softirq.o: In function `do_softirq.part.2': softirq.c:(.text+0x460): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0x498): undefined reference to `trace_hardirqs_on' softirq.c:(.text+0x4b8): undefined reference to `trace_hardirqs_off' kernel/softirq.o: In function `__local_bh_enable_ip': softirq.c:(.text+0x520): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0x56c): undefined reference to `trace_hardirqs_on' kernel/softirq.o: In function `raise_softirq': softirq.c:(.text+0x91c): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0x96c): undefined reference to `trace_hardirqs_on' softirq.c:(.text+0x980): undefined reference to `trace_hardirqs_off' kernel/softirq.o: In function `__tasklet_schedule': softirq.c:(.text+0x9bc): undefined reference to `trace_hardirqs_off' softirq.c:(.text+0xa28): undefined reference to `trace_hardirqs_on' softirq.c:(.text+0xa3c): undefined reference to `trace_hardirqs_off' kernel/softirq.o: In function `__tasklet_hi_schedule': softirq.c:(.text+0xa68): undefined
Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0
On Sat, 17 Mar 2018, Dave Hansen wrote: > On 03/17/2018 02:12 AM, Thomas Gleixner wrote: > >> This is a bit nicer than what Ram proposed because it is simpler > >> and removes special-casing for pkey 0. On the other hand, it does > >> allow applciations to pkey_free() pkey-0, but that's just a silly > >> thing to do, so we are not going to protect against it. > > What's the consequence of that? Application crashing and burning itself or > > something more subtle? > > You would have to: > > pkey_free(0) > ... later > new_key = pkey_alloc(); > // now new_key=0 > pkey_deny_access(new_key); // or whatever > > At which point most apps would probably croak because its stack is > inaccessible. The free itself does not make the key inaccessible, *but* > we could also do that within the existing ABI if we want. I think I > called out that behavior as undefined in the manpage. As long as its documented and the change only allows people to shoot them more in the foot, we're all good. Thanks, tglx
Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()
On Sat, Mar 17, 2018 at 12:27 AM, Kees Cook wrote: > > Unfortunately my 4.4 test fails quickly: > > ./include/linux/jiffies.h: In function ‘jiffies_delta_to_clock_t’: > ./include/linux/jiffies.h:444: error: first argument to > ‘__builtin_choose_expr’ not a constant Ok, so it really looks like that same "__builtin_constant_p() doesn't return a constant". Which is really odd, but there you have it. I wonder if you can use that "sizeof()" to force evaluation of it, because sizeof() really does end up being magical when it comes to "integer constant expression". So instead of this: #define __no_side_effects(a,b) \ (__builtin_constant_p(a)&&__builtin_constant_p(b)) that just assumes that __builtin_constant_p() itself always counts as a constant expression, what happens if you do #define __is_constant(a) \ (sizeof(char[__builtin_constant_p(a)])) #define __no_side_effects(a,b) \ (__is_constant(a) && __is_constant(b)) I realize that the above looks completely insane: the whole point is to *not* have VLA's, and we know that __builtin_constant_p() isn't always evaliated as a constant. But hear me out: if the issue is that there's some evaluation ordering between the two builtins, and the problem is that the __builtin_choose_expr() part of the expression is expanded *before* the __builtin_constant_p() has been expanded, then just hiding it inside that bat-shit-crazy sizeof() will force that to be evaluated first (because a sizeof() is defined to be a integer constant expression. So the above is completely insane, bit there is actually a chance that using that completely crazy "x -> sizeof(char[x])" conversion actually helps, because it really does have a (very odd) evaluation-time change. sizeof() has to be evaluated as part of the constant expression evaluation, in ways that "__builtin_constant_p()" isn't specified to be done. But it is also definitely me grasping at straws. If that doesn't work for 4.4, there's nothing else I can possibly see. Linus
Re: [PATCH v3 1/8] iio: stx104: Implement get_multiple callback
On Sat, Mar 17, 2018 at 5:49 PM, William Breathitt Gray
wrote:
> The Apex Embedded Systems STX104 series of devices provides 4 TTL
> compatible lines of inputs accessed via a single 4-bit port. Since four
> input lines are acquired on a single port input read, the STX104 GPIO
> driver may improve multiple input reads by utilizing a get_multiple
> callback. This patch implements the stx104_gpio_get_multiple function
> which serves as the respective get_multiple callback.
> +static int stx104_gpio_get_multiple(struct gpio_chip *chip, unsigned long
> *mask,
> + unsigned long *bits)
> +{
> + struct stx104_gpio *const stx104gpio = gpiochip_get_data(chip);
> +
> + *bits = inb(stx104gpio->base);
I think on LE and BE if will give you different results.
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
NULL pointer dereferences with 4.14.27
I've put 4.14.27 this morning in this machine and in about 2h it started showing null dereferences identical to the following one. There were several of them, with about 1/2h of interval. Strangely it continued to work and I saw no other anomalies. I've just reverted to 4.14.26. It only happened in this machine, which has a net traffic of several Gb/s and thousands of simultaneous connections. Mar 17 13:29:21 sagres kernel: : BUG: unable to handle kernel NULL pointer dereference at 0038 Mar 17 13:29:21 sagres kernel: : IP: tcp_push+0x4e/0xe7 Mar 17 13:29:21 sagres kernel: : PGD 0 P4D 0 Mar 17 13:29:21 sagres kernel: : Oops: 0002 [#1] SMP PTI Mar 17 13:29:21 sagres kernel: : CPU: 55 PID: 2658 Comm: apache2 Not tainted 4.14.27 #4 Mar 17 13:29:21 sagres kernel: : task: 89791cf7e600 task.stack: abdd91db8000 Mar 17 13:29:21 sagres kernel: : RIP: 0010:tcp_push+0x4e/0xe7 Mar 17 13:29:21 sagres kernel: : RSP: 0018:abdd91dbbc10 EFLAGS: 00010246 Mar 17 13:29:21 sagres kernel: : RAX: RBX: 04c4 RCX: 0001 Mar 17 13:29:21 sagres kernel: : RDX: 0001 RSI: 0040 RDI: 89968330a100 Mar 17 13:29:21 sagres kernel: : RBP: 89968330a250 R08: 7be8 R09: e77cbfc4ab00 Mar 17 13:29:21 sagres kernel: : R10: 89968330a250 R11: R12: 8987aab3bb80 Mar 17 13:29:21 sagres kernel: : R13: 89968330a100 R14: 89791cf7e930 R15: ffe0 Mar 17 13:29:21 sagres kernel: : FS: 7f0bd67d4700() GS:89993f4c() knlGS: Mar 17 13:29:21 sagres kernel: : CS: 0010 DS: ES: CR0: 80050033 Mar 17 13:29:21 sagres kernel: : CR2: 0038 CR3: 003ff4842006 CR4: 003606e0 Mar 17 13:29:21 sagres kernel: : DR0: DR1: DR2: Mar 17 13:29:21 sagres kernel: : DR3: DR6: fffe0ff0 DR7: 0400 Mar 17 13:29:21 sagres kernel: : Call Trace: Mar 17 13:29:21 sagres kernel: : tcp_sendmsg_locked+0xac6/0xc1e Mar 17 13:29:21 sagres kernel: : tcp_sendmsg+0x23/0x35 Mar 17 13:29:21 sagres kernel: : sock_sendmsg+0x11/0x1b Mar 17 13:29:21 sagres kernel: : sock_write_iter+0x71/0x87 Mar 17 13:29:21 sagres kernel: : do_iter_readv_writev+0xf0/0x111 Mar 17 13:29:21 sagres kernel: : do_iter_write+0x84/0xf0 Mar 17 13:29:21 sagres kernel: : vfs_writev+0xad/0xfb Mar 17 13:29:21 sagres kernel: : ? do_writev+0x56/0x92 Mar 17 13:29:21 sagres kernel: : do_writev+0x56/0x92 Mar 17 13:29:21 sagres kernel: : do_syscall_64+0x181/0x210 Mar 17 13:29:21 sagres kernel: : entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Mar 17 13:29:21 sagres kernel: : RIP: 0033:0x7f13f1264017 Mar 17 13:29:21 sagres kernel: : RSP: 002b:7f0bd67d2810 EFLAGS: 0293 ORIG_RAX: 0014 Mar 17 13:29:21 sagres kernel: : RAX: ffda RBX: 0079 RCX: 7f13f1264017 Mar 17 13:29:21 sagres kernel: : RDX: 000a RSI: 7f0bd67d2970 RDI: 0079 Mar 17 13:29:21 sagres kernel: : RBP: 7f0bd67d2970 R08: R09: 7f13680762c8 Mar 17 13:29:21 sagres kernel: : R10: 556029c85dd4 R11: 0293 R12: 000a Mar 17 13:29:21 sagres kernel: : R13: 7f0bd67d2970 R14: 7f0bd67d28d0 R15: 556029ea1440 Mar 17 13:29:21 sagres kernel: : Code: d0 75 02 31 c0 41 89 f3 41 81 e3 00 80 00 00 74 1a 44 8b 8f 58 05 00 00 41 d1 e9 44 2b 8f 5c 06 00 00 44 03 8f 64 06 00 00 79 10 <80> 48 38 08 8b 8f 5c 06 00 00 89 8f 64 06 00 00 40 80 e6 01 74 Mar 17 13:29:21 sagres kernel: : RIP: tcp_push+0x4e/0xe7 RSP: abdd91dbbc10 Mar 17 13:29:21 sagres kernel: : CR2: 0038 Mar 17 13:29:21 sagres kernel: : ---[ end trace f9a8f71d250d2782 ]---
Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
+linuxppc-...@lists.ozlabs.org
On 3/17/2018 11:05 AM, Jason Gunthorpe wrote:
> On Sat, Mar 17, 2018 at 12:25:14AM -0400, Sinan Kaya wrote:
>> On 3/17/2018 12:03 AM, Sinan Kaya wrote:
>>> On 3/16/2018 11:40 PM, Sinan Kaya wrote:
I'll change writel_relaxed() with __raw_writel() in the series like you
suggested
and also look at your other comments.
>>>
>>> I spoke too soon.
>>>
>>> Now that I realized, code needs to follow one of the following patterns for
>>> correctness
>>>
>>> 1)
>>> wmb()
>>> writel()/writel_relaxed()
>>>
>>> or
>>>
>>> 2)
>>> wmb()
>>> __raw_wrltel()
>>> mmiowb()
>>>
>>> but definitely not
>>>
>>> wmb()
>>> __raw_wrltel()
>>>
>>> Since #1 == #2, I'll stick to my current implementation of writel_relaxed()
>>>
>>> Changing writel() to writel_relaxed() or __raw_writel() isn't enough.
>>> PowerPC needs mmiowb()
>>> for correctness. ARM's mmiowb() implementation is empty.
>>>
>>> So, there is no one size fits all solution with the current state of
>>> affairs.
>>>
>>>
>>
>> I think I finally got what you mean.
>>
>> Code seems to have
>>
>> wmb()
>> writel()/writeq()
>> wmb()
>>
>> this can be safely replaced with
>>
>> wmb()
>> __raw_writel()/__raw_writeq()
>> wmb()
>>
>> This will work on all arches. Below is the new version. Let me know if this
>> is OK.
>>
>> +++ b/drivers/infiniband/hw/cxgb4/t4.h
>> @@ -457,7 +457,7 @@ static inline void pio_copy(u64 __iomem *dst, u64 *src)
>> int count = 8;
>>
>> while (count) {
>> - writeq(*src, dst);
>> + __raw_writeq(*src, dst);
>> src++;
>> dst++;
>> count--;
>> @@ -477,15 +477,16 @@ static inline void t4_ring_sq_db(struct t4_wq *wq, u16
>> inc, union t4_wr *wqe)
>> (u64 *)wqe);
>> } else {
>> pr_debug("DB wq->sq.pidx = %d\n", wq->sq.pidx);
>> - writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
>> - wq->sq.bar2_va + SGE_UDB_KDOORBELL);
>> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->sq.bar2_qid),
>> +wq->sq.bar2_va + SGE_UDB_KDOORBELL);
>> }
>>
>> /* Flush user doorbell area writes. */
>> wmb();
>> return;
>> }
>> - writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
>> + __raw_writel(QID_V(wq->sq.qid) | PIDX_V(inc), wq->db);
>> + mmiowmb()
>> }
>>
>> static inline void t4_ring_rq_db(struct t4_wq *wq, u16 inc,
>> @@ -502,15 +503,16 @@ static inline void t4_ring_rq_db(struct t4_wq *wq, u16
>> inc,
>> (void *)wqe);
>> } else {
>> pr_debug("DB wq->rq.pidx = %d\n", wq->rq.pidx);
>> - writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
>> - wq->rq.bar2_va + SGE_UDB_KDOORBELL);
>> + __raw_writel(PIDX_T5_V(inc) | QID_V(wq->rq.bar2_qid),
>> +wq->rq.bar2_va + SGE_UDB_KDOORBELL);
>> }
>>
>> /* Flush user doorbell area writes. */
>> wmb();
>> return;
>> }
>> - writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
>> + __raw_writel(QID_V(wq->rq.qid) | PIDX_V(inc), wq->db);
>> + mmiowmb();
>
> No! NAK! Adding *new* barriers to use the *wrong* accessor is crazy!
>
> Your first patch was right, replacing
> wmb()
> writel()
>
> With wmb(); writel_relaxed() is fine, and helps ARM.
>
> The problem with PPC has nothing to do with the writel, it is with the
> spinlock, and we can't improve it without adding some new
> infrastructure. Certainly don't hack around the problem by using
> __raw_writel in multi-arch drivers!
>
> In userspace we settled on something like this as a pattern:
>
> mmio_wc_spin_lock()
> writel_wc_mmio()
> mmio_wc_spin_unlock()
>
> Where mmio_wc_spin_unlock incorporates the mmiowmb and is defined to
> fully contain all MMIO access to WC and UC memory.
>
> Due to our userspace the pattern is specifically used with MMIO writes
> to WC BAR memory, but it could be generalized..
>
> This allows all known arches to use the best code in all cases. x86
> can even optimize a lot and combine the mmiowmb() into the
> spin_unlock, apparently.
Given both Dave [1] and Jason's feedback, we have to ask PowerPC developers
to fix writel_relaxed().
Otherwise, PowerPC won't be able to take advantage of the optimizations
introduced in this series.
I don't think we need writel_really_relaxed() API.
Somebody also has to take a task and work very hard to get rid of __raw_writeX()
APIs in drivers/net directory. It looked like a very common practice though
it clearly violates multiarch portability concerns Jason and Deve highlighted.
This will be the next version:
iff --git a/drivers/infiniband/hw/cxgb4/t4.h b/drivers/
Re: [PATCH 2/2] regulator: pfuze100: update voltage setting for pfuze3000 sw1a
Hi Stefan, On Sat, Mar 17, 2018 at 9:35 AM, Stefan Wahren wrote: > Hi Anson, > >> Anson Huang hat am 17. März 2018 um 07:57 geschrieben: >> >> >> Latest pfuze3000 datasheet from: >> >> http://cache.freescale.com/files/analog/doc/data_sheet/PF3000.pdf?fsrch=1&sr=1&pageNum=1 > > this link goes to Rev. 7.0, 9/2016, which isn't the latest one. > > I guess Rev. 9.0, 8/2017 is the latest. You are right. This is the link to the latest datasheet: https://www.nxp.com/docs/en/data-sheet/PF3000.pdf
Re: [PATCH v3 1/8] iio: stx104: Implement get_multiple callback
On Sat, 17 Mar 2018 11:49:56 -0400
William Breathitt Gray wrote:
> The Apex Embedded Systems STX104 series of devices provides 4 TTL
> compatible lines of inputs accessed via a single 4-bit port. Since four
> input lines are acquired on a single port input read, the STX104 GPIO
> driver may improve multiple input reads by utilizing a get_multiple
> callback. This patch implements the stx104_gpio_get_multiple function
> which serves as the respective get_multiple callback.
>
> Cc: Jonathan Cameron
> Cc: Hartmut Knaack
> Cc: Lars-Peter Clausen
> Cc: Peter Meerwald-Stadler
> Signed-off-by: William Breathitt Gray
This one is simple so applied to the togreg branch of iio.git and pushed
out as testing for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stx104.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/iio/adc/stx104.c b/drivers/iio/adc/stx104.c
> index 17b021f33180..0662ca199eb0 100644
> --- a/drivers/iio/adc/stx104.c
> +++ b/drivers/iio/adc/stx104.c
> @@ -233,6 +233,16 @@ static int stx104_gpio_get(struct gpio_chip *chip,
> unsigned int offset)
> return !!(inb(stx104gpio->base) & BIT(offset));
> }
>
> +static int stx104_gpio_get_multiple(struct gpio_chip *chip, unsigned long
> *mask,
> + unsigned long *bits)
> +{
> + struct stx104_gpio *const stx104gpio = gpiochip_get_data(chip);
> +
> + *bits = inb(stx104gpio->base);
> +
> + return 0;
> +}
> +
> static void stx104_gpio_set(struct gpio_chip *chip, unsigned int offset,
> int value)
> {
> @@ -342,6 +352,7 @@ static int stx104_probe(struct device *dev, unsigned int
> id)
> stx104gpio->chip.direction_input = stx104_gpio_direction_input;
> stx104gpio->chip.direction_output = stx104_gpio_direction_output;
> stx104gpio->chip.get = stx104_gpio_get;
> + stx104gpio->chip.get_multiple = stx104_gpio_get_multiple;
> stx104gpio->chip.set = stx104_gpio_set;
> stx104gpio->chip.set_multiple = stx104_gpio_set_multiple;
> stx104gpio->base = base[id] + 3;
Re: what the hell is compat_sys_x86_waitpid() for?
On Sat, Mar 17, 2018 at 11:01 AM, Al Viro wrote:
>
> and tell me what is the difference between those. In other words, the problem
> with sys32_waitpid() was not that it didn't use proper wrappers - it's that
> it was (and always had been) 100% pointless.
That long long predates Dominik's patches, though.
It clearly is worth fixing, but don't blame Dominik for just
mindlessly converting mindless code.
> For fsck sake, look at the arguments. waitpid(2) takes pid_t, pointer to int
> and an int. How the hell could it possibly have required a compat wrapper?
This seems to go all the way back to the original x86_64 merge in
2002, with the original version of arch/x86_64/ia32/sys_ia32.c
containing
asmlinkage long
sys32_waitpid(__kernel_pid_t32 pid, unsigned int *stat_addr, int options)
{
return sys32_wait4(pid, stat_addr, options, NULL);
}
and it has only been modified syntactically since.
I suspect the reason is simply that the *regular* waitpid() was writtn
in terms of sys_wait4(), and sys_wait4() needed a compat function, so
then waitpid was basically just carried along.
Linus
Re: [RFC PATCH] iio: adc: Add Xilinx AMS driver
On Sat, 17 Mar 2018 01:49:25 +0530
Himanshu Jha wrote:
> On Thu, Mar 15, 2018 at 08:12:27PM +0530, Manish Narani wrote:
> > The AMS includes an ADC as well as on-chip sensors that can be used to
> > sample external voltages and monitor on-die operating conditions, such as
> > temperature and supply voltage levels. The AMS has two SYSMON blocks.
> > PL-SYSMON block is capable of monitoring off chip voltage and temperature.
> > PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring from
> > external master. Out of these interface currently only DRP is supported.
> > Other block PS-SYSMON is memory mapped to PS.
> >
> > The AMS can use internal channels to monitor voltage and temperature
> > as well as one primary and up to 16 auxiliary channels for measuring
> > external voltages.
> >
> > The voltage and temperature monitoring channels also have event
> > capability which allows to generate an interrupt when their value
> > falls below or raises above a set threshold.
> >
> > Signed-off-by: Manish Narani
> > ---
>
> [..]
>
> > +static const struct of_device_id ams_of_match_table[] = {
> > + { .compatible = "xlnx,zynqmp-ams", &ams_pl_apb },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, ams_of_match_table);
>
> [..]
>
> > +static int ams_probe(struct platform_device *pdev)
> > +{
> > + struct iio_dev *indio_dev;
> > + struct ams *ams;
> > + struct resource *res;
> > + const struct of_device_id *id;
> > + int ret;
> > +
> > + if (!pdev->dev.of_node)
> > + return -ENODEV;
> > +
> > + id = of_match_node(ams_of_match_table, pdev->dev.of_node);
> > + if (!id)
> > + return -ENODEV;
>
> Is the above check required ?
>
> Isn't the probe function called if and only if a match is found in
> ams_of_match_table[] since it is a pure OF driver ?
>
> And therefore the above condition would never happen!
Agreed in principle. However, from a reviewer point of view, it is sometimes
easier to have an error check that can never happen than have to check whether
or not it can. Hence I'd keep this in place (well actually not because there
are better ways of doing this block of code, but that is unconnected to your
comment Himanshu!)
Was a good point to raise though and sometimes people add comments
saying "This can never fail but is here for completeness" or similar.
Not necessary but does avoid reviewers then asking why it was done.
Jonathan
>
> > +static struct platform_driver ams_driver = {
> > + .probe = ams_probe,
> > + .remove = ams_remove,
> > + .driver = {
> > + .name = "ams",
> > + .pm = &ams_pm_ops,
> > + .of_match_table = ams_of_match_table,
> > + },
> > +};
> > +module_platform_driver(ams_driver);
>
>
Re: [RFC PATCH] iio: adc: Add Xilinx AMS driver
On Thu, 15 Mar 2018 16:51:31 +0100 (CET)
Peter Meerwald-Stadler wrote:
> minor comments below
>
> > The AMS includes an ADC as well as on-chip sensors that can be used to
> > sample external voltages and monitor on-die operating conditions, such as
> > temperature and supply voltage levels. The AMS has two SYSMON blocks.
> > PL-SYSMON block is capable of monitoring off chip voltage and temperature.
> > PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring from
> > external master. Out of these interface currently only DRP is supported.
> > Other block PS-SYSMON is memory mapped to PS.
> >
> > The AMS can use internal channels to monitor voltage and temperature
> > as well as one primary and up to 16 auxiliary channels for measuring
> > external voltages.
> >
> > The voltage and temperature monitoring channels also have event
> > capability which allows to generate an interrupt when their value
> > falls below or raises above a set threshold.
> >
> > Signed-off-by: Manish Narani
Hi Manish,
First thing is that if you post as an RFC you should say why it is an
RFC. That is normally done to ask for comments on a particular thing,
or to make it clear that you know something still needs doing but
would like comments on the rest of the code.
A few more comments form me. One thing that is always useful when
posting a new driver with a non trivial ABI is to add a listing
of the all the sysfs files created in the patch description. Makes
it very easy to check the ABI is sensible.
Needs dt bindings and ABI docs.
I assume you are thinking of using the iio-hwmon bridge to expose the hwmon
stuff via standard interfaces? If doing so, I would suggest testing that
and also presenting the resulting interface from there with this patch.
One other thing is there is a lot of code to look up values associated with
particular channels. If possible, move all that into constant look up tables.
Thanks,
Jonathan
> > ---
> > drivers/iio/adc/Kconfig | 10 +
> > drivers/iio/adc/Makefile |1 +
> > drivers/iio/adc/xilinx-ams.c | 1115
> > ++
> > drivers/iio/adc/xilinx-ams.h | 278 +++
> > 4 files changed, 1404 insertions(+)
> > create mode 100644 drivers/iio/adc/xilinx-ams.c
> > create mode 100644 drivers/iio/adc/xilinx-ams.h
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 72bc2b7..f1b8a5f 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -931,4 +931,14 @@ config XILINX_XADC
> > The driver can also be build as a module. If so, the module will
> > be called
> > xilinx-xadc.
> >
> > +config XILINX_AMS
> > + tristate "Xilinx AMS driver"
> > + depends on ARCH_ZYNQMP || COMPILE_TEST
> > + depends on HAS_IOMEM
> > + help
> > + Say yes here to have support for the Xilinx AMS.
> > +
> > + The driver can also be build as a module. If so, the module will
> > be called
> > + xilinx-ams.
> > +
> > endmenu
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 28a9423..27ded4f 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -85,3 +85,4 @@ obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> > xilinx-xadc-y := xilinx-xadc-core.o xilinx-xadc-events.o
> > obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o
> > obj-$(CONFIG_SD_ADC_MODULATOR) += sd_adc_modulator.o
> > +obj-$(CONFIG_XILINX_AMS) += xilinx-ams.o
>
> maybe put after xilinx-xadc
Good point. That file should be in alphabetical order. We'll want to
fix that up at somepoint - it greatly reduces the noise as the chances
of patches interfering with each other is much less than when they are
all adding lines at the end.
>
> > diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
> > new file mode 100644
> > index 000..2f519e6
> > --- /dev/null
> > +++ b/drivers/iio/adc/xilinx-ams.c
> > @@ -0,0 +1,1115 @@
> > +/*
> > + * Xilinx AMS driver
> > + *
> > + * Licensed under the GPL-2
> > + *
One of my silly pet hates ;) This blank line has no purpose so don't put one
here.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
If nothing makes another ordering clearer, default is to put headers
in alphabetical ordering.
> > +
> > +#include
> > +#include
> > +#include
> > +#include
>
> iio/buffer is not actually used?
>
> > +#include
> > +
> > +#include "xilinx-ams.h"
> > +#include
>
> the delay #include should be moved up
>
> > +
> > +static const unsigned int AMS_UNMASK_TIMEOUT = 500;
Unit? Best if you put that in the name. Might as well be a define
as well rather than a constant.
Also as it is only ever used in jiffies, perhaps make the define a jiffies
value?
> > +
> > +static inline void ams_read_reg(struct ams *ams, unsigned int offset, u32
> > *data)
> > +{
> > + *data = readl
Re: [RESEND PATCH 2/6] input: synaptics_usb: do not rely on input_dev->users
On Wed, Feb 28, 2018 at 02:37:59PM +0100, Marcus Folkesson wrote:
> If the device is unused and suspended, a call to open will cause the
> device to autoresume through the call to usb_autopm_get_interface().
>
> input_dev->users is already incremented by the input subsystem,
> therefore this expression will always be evaluated to true:
>
> if ((input_dev->users || (synusb->flags & SYNUSB_IO_ALWAYS)) &&
> usb_submit_urb(synusb->urb, GFP_NOIO) < 0) {
> retval = -EIO;
> }
>
> The same URB will then be fail when resubmitted in synusb_open().
>
> Introduce synusb->is_open to keep track of the state instead.
>
> Signed-off-by: Marcus Folkesson
Applied, thank you.
> ---
> drivers/input/mouse/synaptics_usb.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/mouse/synaptics_usb.c
> b/drivers/input/mouse/synaptics_usb.c
> index 2c66913cf5a2..e2b726751220 100644
> --- a/drivers/input/mouse/synaptics_usb.c
> +++ b/drivers/input/mouse/synaptics_usb.c
> @@ -84,6 +84,7 @@ struct synusb {
>
> /* serialize access to open/suspend */
> struct mutex pm_mutex;
> + bool is_open;
>
> /* input device related data structures */
> struct input_dev *input;
> @@ -266,6 +267,7 @@ static int synusb_open(struct input_dev *dev)
> }
>
> synusb->intf->needs_remote_wakeup = 1;
> + synusb->is_open = 1;
>
> out:
> mutex_unlock(&synusb->pm_mutex);
> @@ -283,6 +285,7 @@ static void synusb_close(struct input_dev *dev)
> mutex_lock(&synusb->pm_mutex);
> usb_kill_urb(synusb->urb);
> synusb->intf->needs_remote_wakeup = 0;
> + synusb->is_open = 0;
> mutex_unlock(&synusb->pm_mutex);
>
> if (!autopm_error)
> @@ -485,12 +488,11 @@ static int synusb_suspend(struct usb_interface *intf,
> pm_message_t message)
> static int synusb_resume(struct usb_interface *intf)
> {
> struct synusb *synusb = usb_get_intfdata(intf);
> - struct input_dev *input_dev = synusb->input;
> int retval = 0;
>
> mutex_lock(&synusb->pm_mutex);
>
> - if ((input_dev->users || (synusb->flags & SYNUSB_IO_ALWAYS)) &&
> + if ((synusb->is_open || (synusb->flags & SYNUSB_IO_ALWAYS)) &&
> usb_submit_urb(synusb->urb, GFP_NOIO) < 0) {
> retval = -EIO;
> }
> @@ -513,10 +515,9 @@ static int synusb_pre_reset(struct usb_interface *intf)
> static int synusb_post_reset(struct usb_interface *intf)
> {
> struct synusb *synusb = usb_get_intfdata(intf);
> - struct input_dev *input_dev = synusb->input;
> int retval = 0;
>
> - if ((input_dev->users || (synusb->flags & SYNUSB_IO_ALWAYS)) &&
> + if ((synusb->is_open || (synusb->flags & SYNUSB_IO_ALWAYS)) &&
> usb_submit_urb(synusb->urb, GFP_NOIO) < 0) {
> retval = -EIO;
> }
> --
> 2.16.2
>
--
Dmitry
