Re: [PATCHv2 2/5] x86/tme: Detect if TME and MKTME is activated by BIOS
On Wed, 2018-02-07 at 11:02 -0800, Dave Hansen wrote:
> On 02/07/2018 04:59 AM, Kirill A. Shutemov wrote:
> > IA32_TME_ACTIVATE MSR (0x982) can be used to check if BIOS has
> > enabled
> > TME and MKTME. It includes which encryption policy/algorithm is
> > selected
> > for TME or available for MKTME. For MKTME, the MSR also enumerates
> > how
> > many KeyIDs are available.
>
> The hacking of the phys_addr_bits is a pretty important part of this.
> Are you sure it's not worth calling out in the description?
>
> > +#define MSR_IA32_TME_ACTIVATE 0x982
> > +
> > +#define TME_ACTIVATE_LOCKED(x) (x & 0x1)
> > +#define TME_ACTIVATE_ENABLED(x)(x & 0x2)
> > +
> > +#define TME_ACTIVATE_POLICY(x) ((x >> 4) & 0xf)
> > /* Bits 7:4 */
> > +#define TME_ACTIVATE_POLICY_AES_XTS_1280
> > +
> > +#define TME_ACTIVATE_KEYID_BITS(x) ((x >> 32) & 0xf)
> > /* Bits 35:32 */
> > +
> > +#define TME_ACTIVATE_CRYPTO_ALGS(x)((x >> 48) & 0x)
> > /* Bits 63:48 */
> > +#define TME_ACTIVATE_CRYPTO_AES_XTS_1281
> > +
> > +#define MKTME_ENABLED 0
> > +#define MKTME_DISABLED 1
> > +#define MKTME_UNINITIALIZED2
>
> The indentation there looks a bit wonky. Might want to double-check
> it.
>
> Also, can you clearly spell out which of these things are software
> constructs vs. hardware ones? MKTME_* look like software constructs.
>
> > +static int mktme_status = MKTME_UNINITIALIZED;
> > +
> > +static void detect_keyid_bits(struct cpuinfo_x86 *c, u64
> > tme_activate)
> > +{
> > + int keyid_bits = 0, nr_keyids = 0;
> > +
> > + keyid_bits = TME_ACTIVATE_KEYID_BITS(tme_activate);
> > + nr_keyids = (1UL << keyid_bits) - 1;
> > + if (nr_keyids) {
> > + pr_info_once("x86/mktme: enabled by BIOS\n");
> > + pr_info_once("x86/mktme: %d KeyIDs available\n",
> > nr_keyids);
> > + } else {
> > + pr_info_once("x86/mktme: disabled by BIOS\n");
> > + }
>
> Just curious, but how do you know that this indicates the BIOS
> disabling
> MKTME?
>
> > + if (mktme_status == MKTME_UNINITIALIZED) {
> > + /* MKTME is usable */
> > + mktme_status = MKTME_ENABLED;
> > + }
>
> To me, it's a little bit odd that we "enable" MKTME down in the keyid
> detection code. I wonder if you could just return the resulting
> number
> of keyids and then actually do the mktme_status munging in one place
> (detect_tme()).
>
> > + /*
> > +* Exclude KeyID bits from physical address bits.
> > +*
> > +* We have to do this even if we are not going to use
> > KeyID bits
> > +* ourself. VM guests still have to know that these bits
> > are not usable
> > +* for physical address.
> > +*/
> > + c->x86_phys_bits -= keyid_bits;
> > +}
>
> How do we tell guests about this? kvm_set_mmio_spte_mask()?
Hi Dave,
KVM tells guest physical bits info in CPUID emulating from guest.
Currently KVM uses native CPUID to get physical bits info, and report
it to guest in CPUID emulating. KVM is not consulting c->x86_phys_bits
in CPUID emulation now, but for MK-TME I think it should be reasonable
for KVM to do that.
The kvm_set_mmio_spte_mask() you mentioned is used to setup pte mask to
cause page fault for guest's MMIO pages (in shadow MMU mode only, for
EPT we have different function). It is using
boot_cpu_data.x86_phys_bits (for which we need to do code update for
MK-TME), but this function is not related to reporting physical bits
info to guest.
Thanks,
-Kai
>
> > +static void detect_tme(struct cpuinfo_x86 *c)
> > +{
> > + u64 tme_activate, tme_policy, tme_crypto_algs;
> > + static u64 tme_activate_cpu0 = 0;
> > +
> > + rdmsrl(MSR_IA32_TME_ACTIVATE, tme_activate);
> > +
> > + if (mktme_status != MKTME_UNINITIALIZED) {
> > + if (tme_activate != tme_activate_cpu0) {
> > + /* Broken BIOS? */
> > + pr_err_once("x86/tme: configuation is
> > inconsistent between CPUs\n");
> > + pr_err_once("x86/tme: MKTME is not
> > usable\n");
> > + mktme_status = MKTME_DISABLED;
> > +
> > + /* Proceed. We may need to exclude bits
> > from x86_phys_bits. */
> > + }
> > + } else {
> > + tme_activate_cpu0 = tme_activate;
> > + }
> > +
> > + if (!TME_ACTIVATE_LOCKED(tme_activate) ||
> > !TME_ACTIVATE_ENABLED(tme_activate)) {
> > + pr_info_once("x86/tme: not enabled by BIOS\n");
> > + mktme_status = MKTME_DISABLED;
> > + return;
> > + }
> > +
> > + if (mktme_status != MKTME_UNINITIALIZED)
> > + return detect_keyid_bits(c, tme_activate);
>
> Returning the result of a void function is a bit odd-looking. Would
> it
> look nicer to just have a label and some gotos to the detection?
>
> > + pr_info("x86/tme: enabled by BIOS\n");
> > +
> > + tme_policy = TME_ACTIVATE_POLICY(tme_activate);
> > + if (tme_policy != TME_ACTIVATE_POLICY_AES
Re: [PATCH v5 1/4] cpu_pm: add syscore_suspend error handling
On Wed, 07 Feb 2018 22:01:56 +, Brian Norris wrote: Hi Brian, > Hi Marc, > > On Wed, Feb 07, 2018 at 08:57:27AM +, Marc Zyngier wrote: > > On 07/02/18 01:41, Derek Basehore wrote: > > > If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This > > > will put the CPU in the correct state to resume from the failure. > > > > > > Signed-off-by: Derek Basehore > > > --- > > > kernel/cpu_pm.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c > > > index 67b02e138a47..03bcc0751a51 100644 > > > --- a/kernel/cpu_pm.c > > > +++ b/kernel/cpu_pm.c > > > @@ -186,6 +186,9 @@ static int cpu_pm_suspend(void) > > > return ret; > > > > > > ret = cpu_cluster_pm_enter(); > > > + if (ret) > > > + cpu_pm_exit(); > > > + > > > return ret; > > > } > > > > > > > > > > It is unclear to me why we need this patch as part of the ITS series. I > > probably fixes something for you, but I don't see the connection with > > the other patches. > > Ths bug was noticed (by inspection) along with earlier versions of this > series, when Derek was still adding new cpu_pm callbacks, and new > failure modes within the existing callbacks. It's a proper fix to my > knowledge, but I believe it no longer has any particular relevance to > this series, since we're not really touching cpu_pm in this series any > more. I don't doubt that this is a proper fix, but it has a better chance of being noticed on its own, rather than buried together with a now unrelated series. I'd suggest that when you or Derek respin this series, you don't include this patch, but instead post it on its own for review. Thanks, M. -- Jazz is not dead, it just smell funny.
[PATCH] platform/x86: dell-laptop: Removed duplicates in DMI whitelist
Fixed a mistake in which several entries were duplicated in the DMI list
from the below commit
fe486138 platform/x86: dell-laptop: Add 2-in-1 devices to the DMI whitelist
Signed-off-by: Alexander Abrosimov
---
drivers/platform/x86/dell-laptop.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/platform/x86/dell-laptop.c
b/drivers/platform/x86/dell-laptop.c
index a7b141992cb3..a66a6a6e47b9 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -125,28 +125,10 @@ static const struct dmi_system_id dell_device_table[]
__initconst = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_CHASSIS_TYPE, "32"), /*Detachable*/
},
},
{
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
- DMI_MATCH(DMI_CHASSIS_TYPE, "30"), /*Tablet*/
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
- DMI_MATCH(DMI_CHASSIS_TYPE, "31"), /*Convertible*/
- },
- },
- {
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
- DMI_MATCH(DMI_CHASSIS_TYPE, "32"), /*Detachable*/
- },
- },
- {
.ident = "Dell Computer Corporation",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
DMI_MATCH(DMI_CHASSIS_TYPE, "8"),
},
--
2.13.6
arch/x86/tools/insn_decoder_test: warning: 81000f06: 0f ff 89 da b8 09 00 ud0 0x9b8da(%ecx),%ecx
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 413879a10b0b0eb563a23c4df896773b2d9413f9 commit: 10c91577d5e631773a6394e14cf60125389b71ae x86/tools: Standardize output format of insn_decode_test date: 8 weeks ago config: i386-randconfig-x0-02071922 (attached as .config) compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010 reproduce: git checkout 10c91577d5e631773a6394e14cf60125389b71ae # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 8100052c: 0f ff 83 c4 0c 89 d8 ud0-0x2776f33c(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. >> arch/x86/tools/insn_decoder_test: warning: 81000f06: 0f ff 89 da b8 09 00 >> ud00x9b8da(%ecx),%ecx arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. >> arch/x86/tools/insn_decoder_test: warning: 81000f58: 0f ff 58 e8 >> ud0-0x18(%eax),%ebx arch/x86/tools/insn_decoder_test: warning: objdump says 4 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. >> arch/x86/tools/insn_decoder_test: warning: 81000ff0: 0f ff e8 >> ud0%eax,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 8100192d: 0f ff c7 ud0%edi,%eax arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 8100197e: 0f ff 83 e0 fe 74 0c ud00xc74fee0(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81001b08: 0f ff 89 15 a4 05 95 ud0-0x6afa5beb(%ecx),%ecx arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81001b97: 0f ff 58 8b ud0-0x75(%eax),%ebx arch/x86/tools/insn_decoder_test: warning: objdump says 4 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81001bfa: 0f ff eb ud0%ebx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81001f15: 0f ff 83 c8 01 89 83 ud0-0x7c76fe38(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81001f7d: 0f ff eb ud0%ebx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 8100281a: 0f ff eb ud0%ebx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81002cba: 0f ff eb ud0%ebx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81002cc3: 0f ff eb ud0%ebx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: w
Re: [PATCH BUGFIX V3] block, bfq: add requeue-request hook
On 2/7/18 2:19 PM, Paolo Valente wrote:
> Commit 'a6a252e64914 ("blk-mq-sched: decide how to handle flush rq via
> RQF_FLUSH_SEQ")' makes all non-flush re-prepared requests for a device
> be re-inserted into the active I/O scheduler for that device. As a
> consequence, I/O schedulers may get the same request inserted again,
> even several times, without a finish_request invoked on that request
> before each re-insertion.
>
> This fact is the cause of the failure reported in [1]. For an I/O
> scheduler, every re-insertion of the same re-prepared request is
> equivalent to the insertion of a new request. For schedulers like
> mq-deadline or kyber, this fact causes no harm. In contrast, it
> confuses a stateful scheduler like BFQ, which keeps state for an I/O
> request, until the finish_request hook is invoked on the request. In
> particular, BFQ may get stuck, waiting forever for the number of
> request dispatches, of the same request, to be balanced by an equal
> number of request completions (while there will be one completion for
> that request). In this state, BFQ may refuse to serve I/O requests
> from other bfq_queues. The hang reported in [1] then follows.
>
> However, the above re-prepared requests undergo a requeue, thus the
> requeue_request hook of the active elevator is invoked for these
> requests, if set. This commit then addresses the above issue by
> properly implementing the hook requeue_request in BFQ.
Thanks, applied.
--
Jens Axboe
Re: [PATCH v8 0/7] TDA1997x HDMI video reciver
On 02/07/2018 11:05 PM, Tim Harvey wrote: > On Wed, Feb 7, 2018 at 1:09 AM, Hans Verkuil wrote: >> On 02/07/18 09:22, Hans Verkuil wrote: >>> On 02/07/2018 12:29 AM, Tim Harvey wrote: Media Controller ioctls: fail: v4l2-test-media.cpp(141): ent.function == MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN >>> >>> Weird, this shouldn't happen. I'll look into this a bit more. >> >> Can you run 'mc_nextgen_test -e -i' and post the output? >> >> It's found in contrib/test. >> > > root@ventana:~# ./v4l-utils/contrib/test/mc_nextgen_test -e -i > Device: imx-media (driver imx-media) > Bus: > version: 0 > number of entities: 24 > number of interfaces: 24 > number of pads: 48 > number of links: 50 > entity entity#1: 'unknown entity type' adv7180 2-0020, 1 pad(s), 1 source(s) > entity entity#3: 'unknown entity type' tda19971 2-0048, 1 pad(s), 1 source(s) > entity entity#5: 'unknown entity type' ipu1_vdic, 3 pad(s), 2 sink(s), > 1 source(s) > entity entity#9: 'unknown entity type' ipu2_vdic, 3 pad(s), 2 sink(s), > 1 source(s) > entity entity#13: 'unknown entity type' ipu1_ic_prp, 3 pad(s), 1 > sink(s), 2 source(s) > entity entity#17: 'unknown entity type' ipu1_ic_prpenc, 2 pad(s), 1 > sink(s), 1 source(s) > entity entity#20: 'V4L I/O' ipu1_ic_prpenc capture, 1 pad(s), 1 sink(s) > entity entity#26: 'unknown entity type' ipu1_ic_prpvf, 2 pad(s), 1 > sink(s), 1 source(s) > entity entity#29: 'V4L I/O' ipu1_ic_prpvf capture, 1 pad(s), 1 sink(s) > entity entity#35: 'unknown entity type' ipu2_ic_prp, 3 pad(s), 1 > sink(s), 2 source(s) > entity entity#39: 'unknown entity type' ipu2_ic_prpenc, 2 pad(s), 1 > sink(s), 1 source(s) > entity entity#42: 'V4L I/O' ipu2_ic_prpenc capture, 1 pad(s), 1 sink(s) > entity entity#48: 'unknown entity type' ipu2_ic_prpvf, 2 pad(s), 1 > sink(s), 1 source(s) > entity entity#51: 'V4L I/O' ipu2_ic_prpvf capture, 1 pad(s), 1 sink(s) > entity entity#57: 'unknown entity type' ipu1_csi0, 3 pad(s), 1 > sink(s), 2 source(s) > entity entity#61: 'V4L I/O' ipu1_csi0 capture, 1 pad(s), 1 sink(s) > entity entity#67: 'unknown entity type' ipu1_csi1, 3 pad(s), 1 > sink(s), 2 source(s) > entity entity#71: 'V4L I/O' ipu1_csi1 capture, 1 pad(s), 1 sink(s) > entity entity#77: 'unknown entity type' ipu2_csi0, 3 pad(s), 1 > sink(s), 2 source(s) > entity entity#81: 'V4L I/O' ipu2_csi0 capture, 1 pad(s), 1 sink(s) > entity entity#87: 'unknown entity type' ipu2_csi1, 3 pad(s), 1 > sink(s), 2 source(s) > entity entity#91: 'V4L I/O' ipu2_csi1 capture, 1 pad(s), 1 sink(s) > entity entity#97: 'unknown entity type' ipu1_csi0_mux, 3 pad(s), 2 > sink(s), 1 source(s) > entity entity#101: 'unknown entity type' ipu2_csi1_mux, 3 pad(s), 2 > sink(s), 1 source(s) Yuck. So nobody in imx (and adv7180!) is setting a valid function. And I see the mc_nextgen_test.c doesn't know all the latest functions anyway. That's what happens when you don't have compliance tests, nobody bothers to fill stuff like that in. Anyway, that explains the v4l2-compliance error you got (although I should improve the error to also mentioned the entity in question). In other words, it's not you, it's them :-) Regards, Hans > interface intf_devnode#21: video /dev/video0 > interface intf_devnode#30: video /dev/video1 > interface intf_devnode#43: video /dev/video2 > interface intf_devnode#52: video /dev/video3 > interface intf_devnode#62: video /dev/video4 > interface intf_devnode#72: video /dev/video5 > interface intf_devnode#82: video /dev/video6 > interface intf_devnode#92: video /dev/video7 > interface intf_devnode#141: v4l2-subdev /dev/v4l-subdev0 > interface intf_devnode#143: v4l2-subdev /dev/v4l-subdev1 > interface intf_devnode#145: v4l2-subdev /dev/v4l-subdev2 > interface intf_devnode#147: v4l2-subdev /dev/v4l-subdev3 > interface intf_devnode#149: v4l2-subdev /dev/v4l-subdev4 > interface intf_devnode#151: v4l2-subdev /dev/v4l-subdev5 > interface intf_devnode#153: v4l2-subdev /dev/v4l-subdev6 > interface intf_devnode#155: v4l2-subdev /dev/v4l-subdev7 > interface intf_devnode#157: v4l2-subdev /dev/v4l-subdev8 > interface intf_devnode#159: v4l2-subdev /dev/v4l-subdev9 > interface intf_devnode#161: v4l2-subdev /dev/v4l-subdev10 > interface intf_devnode#163: v4l2-subdev /dev/v4l-subdev11 > interface intf_devnode#165: v4l2-subdev /dev/v4l-subdev12 > interface intf_devnode#167: v4l2-subdev /dev/v4l-subdev13 > interface intf_devnode#169: v4l2-subdev /dev/v4l-subdev14 > interface intf_devnode#171: v4l2-subdev /dev/v4l-subdev15 > > I updated v4l2-compliance and ran again: > root@ventana:~# v4l2-compliance -m0 -M > v4l2-compliance SHA : b2f8f9049056eb6f9e028927dacb2c715a062df8 > Media Driver Info: > Driver name : imx-media > Model: imx-media > Serial : > Bus info : > Media version: 4.15.0 > Hardware revision: 0x (0) > Driver version : 4.15.0 > > Compliance test for device /dev/media0: > > Required ioctls: > test MEDIA_IO
Re: [PATCH 4/6] Protectable Memory
Hi Igor, Thank you for the patch! Yet something to improve: [auto build test ERROR on kees/for-next/pstore] [also build test ERROR on v4.15] [cannot apply to linus/master mmotm/master next-20180207] [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/Igor-Stoppa/mm-security-ro-protection-for-dynamic-data/20180207-171252 base: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/pstore config: um-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=um All errors (new ones prefixed by >>): arch/um/drivers/vde.o: In function `vde_open_real': (.text+0x951): warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking (.text+0x79c): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking (.text+0xab5): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametoaddr': (.text+0xdee5): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametonetaddr': (.text+0xdf85): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametoproto': (.text+0xe1a5): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking arch/um/drivers/pcap.o: In function `pcap_nametoport': (.text+0xdfd7): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking mm/usercopy.o: In function `__check_object_size': >> (.text+0x3aa): undefined reference to `is_pmalloc_object' >> collect2: error: ld returned 1 exit status --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 5/7] ARM: dts: da850: add power-domains properties to device nodes
On 02/07/2018 07:45 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Make all devices managed by PSCs use the genpd driver.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850.dtsi | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index ac2eef4e6b7c..a2a1a3b7de3c 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -83,6 +83,7 @@
ti,intc-size = <101>;
reg = <0xfffee000 0x2000>;
clocks = <&psc0 6>;
+ power-domains = <&pwc0>;
If we are making this a power domain consumer, we can probably drop the
clock property.
};
};
clocks: clocks {
@@ -125,6 +126,7 @@
interrupt-parent = <&intc>;
interrupts = <28>;
clocks = <&psc0 15>;
+ power-domains = <&pwc0>;
status = "disabled";
};
soc@1c0 {
@@ -400,12 +402,14 @@
clocks = <&psc1 1>, <&usb_refclkin>,
<&pll0_auxclk>;
clock-names = "fck", "usb_refclkin", "auxclk";
+ power-domains = <&pwc1>;
If we are going to use a power domain here, this driver will need to be
re-written.
};
ehrpwm_tbclk: ehrpwm_tbclk {
compatible = "ti,da830-tbclksync";
#clock-cells = <0>;
clocks = <&psc1 17>;
clock-names = "fck";
+ power-domains = <&pwc1>;
This is a clock node, not a (platform) device node, so I am not sure having
a power domain here makes sense.
};
div4p5_clk: div4.5 {
compatible = "ti,da830-div4p5ena";
@@ -439,6 +443,7 @@
ti,tptcs = <&edma0_tptc0 7>, <&edma0_tptc1 0>;
clocks = <&psc0 0>;
+ power-domains = <&pwc0>;
We really just need power-domains here, not clocks. Same applies to
the rest of the edma* nodes below.
};
edma0_tptc0: tptc@8000 {
compatible = "ti,edma3-tptc";
@@ -446,6 +451,7 @@
interrupts = <13>;
interrupt-names = "edm3_tcerrint";
clocks = <&psc0 1>;
+ power-domains = <&pwc0>;
};
edma0_tptc1: tptc@8400 {
compatible = "ti,edma3-tptc";
@@ -453,6 +459,7 @@
interrupts = <32>;
interrupt-names = "edm3_tcerrint";
clocks = <&psc0 2>;
+ power-domains = <&pwc0>;
};
edma1: edma@23 {
compatible = "ti,edma3-tpcc";
@@ -465,6 +472,7 @@
ti,tptcs = <&edma1_tptc0 7>;
clocks = <&psc1 0>;
+ power-domains = <&pwc1>;
};
edma1_tptc0: tptc@238000 {
compatible = "ti,edma3-tptc";
@@ -472,6 +480,7 @@
interrupts = <95>;
interrupt-names = "edm3_tcerrint";
clocks = <&psc1 21>;
+ power-domains = <&pwc1>;
};
serial0: serial@42000 {
compatible = "ti,da830-uart", "ns16550a";
@@ -480,6 +489,7 @@
reg-shift = <2>;
interrupts = <25>;
clocks = <&psc0 9>;
+ power-domains = <&pwc0>;
status = "disabled";
};
serial1: serial@10c000 {
@@ -489,6 +499,7 @@
reg-shift = <2>;
interrupts = <53>;
clocks = <&psc1 12>;
+ power-domains = <&pwc1>;
status = "disabled";
};
serial2: serial@10d000 {
@@ -498,6 +509,7 @@
reg-shift = <2>;
interrupts = <61>;
clocks = <&psc1 13>;
+ power-domains = <&pwc1>;
status = "disabled";
};
rtc0: rtc@23000 {
@@ -523,6 +535,7 @@
#address-cells = <1>;
#size-cells = <0>;
clocks = <&psc1 11>;
+ power-domains = <&pwc1>;
status = "disabled";
};
clocksource: timer@2 {
@@ -545,6 +558,7 @@
dmas = <&edma0 16 0>, <&edma0 17 0>;
[PATCH 1/2] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().
Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement the active
transaction counter. But xenbus_transaction_end() has always counted the
transaction as finished regardless of the response.
The new behavior is that xenbus_dev_request_and_reply() and
xenbus_transaction_end() will always count the transaction as finished
regardless the response code (handled in xs_request_exit()).
But xenbus_dev_frontend tries to end a transaction on closing of the
device if the XS_TRANSACTION_END failed before. Trying to close the
transaction twice corrupts the reference count. So fix this by also
considering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.
Cc: # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
xenstore accesses")
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index f3b089b7c0b6..d2edbc79384a 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -365,7 +365,7 @@ void xenbus_dev_queue_reply(struct xb_req_data *req)
if (WARN_ON(rc))
goto out;
}
- } else if (req->msg.type == XS_TRANSACTION_END) {
+ } else if (req->type == XS_TRANSACTION_END) {
trans = xenbus_get_transaction(u, req->msg.tx_id);
if (WARN_ON(!trans))
goto out;
--
2.15.1
[PATCH 2/2] xen: xenbus: WARN_ON XS_TRANSACTION_{START,END} misuse
As the previous commit shows it's quite easy to confuse the transaction
reference counting by ending a transaction twice. So at least try to
detect and report it.
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_xs.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 3e59590c7254..aed954b09b9b 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -137,11 +137,20 @@ static uint32_t xs_request_enter(struct xb_req_data *req)
void xs_request_exit(struct xb_req_data *req)
{
+ unsigned int users_old;
+
spin_lock(&xs_state_lock);
+ users_old = xs_state_users;
xs_state_users--;
if ((req->type == XS_TRANSACTION_START && req->msg.type == XS_ERROR) ||
req->type == XS_TRANSACTION_END)
xs_state_users--;
+ if (WARN_ON(xs_state_users > users_old))
+ /*
+* Someone misused XS_TRANSACTION_{START,END}. Reset the
+* reference counter so we might survive.
+*/
+ xs_state_users = 0;
spin_unlock(&xs_state_lock);
if (xs_suspend_active && !xs_state_users)
--
2.15.1
Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive
Hi Peter, On Wed, Feb 7, 2018 at 8:58 AM, Peter Zijlstra wrote: [...] > >> Lockdep reports this issue when GFP_FS is infact set, and we enter >> this path and acquire the lock. So lockdep seems to be doing the right >> thing however by design it is reporting a false-positive. > > So I'm not seeing how its a false positive. fs/inode.c sets a different > lock class per filesystem type. So recursing on an i_mutex within a > filesystem does sound dodgy. But directory inodes and file inodes in the same filesystem share the same lock class right? All the issues I've seen (both our's and Neil's) are similar in that a directory inode's lock is held followed by a RECLAIM_FS allocation, and in parallel to that, memory reclaim involving the same FS is going on in another thread. In the splat I shared, during the VFS lookup- the d_alloc is called with an inode's lock held (I am guessing this the lock of the directory inode which is locked just before the d_alloc), and in parallel (kswapd or some other thread) is doing memory reclaim. >> The real issue is that the lock being acquired is of the same lock >> class and a different lock instance is acquired under GFP_FS that >> happens to be of the same class. >> >> So the issue seems to me to be: >> Process A kswapd >> - -- >> acquire i_mutexEnter RECLAIM_FS >> >> Enter RECLAIM_FS acquire different i_mutex > > That's not a false positive, that's a 2 process way of writing i_mutex > recursion. Yes, but I mention false positive since the kswapd->ashmem_shrink_scan path can never acquire the mutex of a directory inode AFAIK. So from that perspective it seems a false-positive. > > What are the rules of acquiring two i_mutexes within a filesystem? > I am not fully sure. I am CC'ing Ted and linux-fs-devel as well for any input on this question. >> Neil tried to fix this sometime back: >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg623909.html >> but it was kind of NAK'ed. > > So that got nacked because Neil tried to fix it in the vfs core. Also > not entirely sure that's the same problem. Yes, a similar fix was proposed internally here, I would say the signature of the problem reported there is quite similar (its just that there its nfsd mentioned as doing the reclaim instead of kswapd). thanks, - Joel [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg623986.html
Re: [PATCH v2] x86/retpoline: Add clang support
On Wed, 2018-02-07 at 13:52 -0800, Guenter Roeck wrote: > clang has its own set of compiler options for retpoline support. > > Link: > https://github.com/llvm-mirror/clang/commit/0d816739a82da29748caf88570affb9715e18b69 > Link: > https://github.com/llvm-mirror/llvm/commit/fd5a8723ce9f2a6b250e85972ef859e4253ea95d > Link: > https://github.com/llvm-mirror/llvm/commit/59b64490fda69d29bb42cfdf7eec37bcc31ff833 > Cc: David Woodhouse > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: gno...@lxorguk.ukuu.org.uk > Cc: Rik van Riel > Cc: Andi Kleen > Cc: Josh Poimboeuf > Cc: thomas.lenda...@amd.com > Cc: Peter Zijlstra > Cc: Linus Torvalds > Cc: Jiri Kosina > Cc: Andy Lutomirski > Cc: Dave Hansen > Cc: Kees Cook > Cc: Tim Chen > Cc: Greg Kroah-Hartman > Cc: Paul Turner > Signed-off-by: Guenter Roeck > --- > v2: llvm has been updated to use the same thunk names as gcc. > Tested with: > clang version 7.0.0 > (https://git.llvm.org/git/clang.git/ > 848874aed95a913fb45f363120500cebfe54e2ef) > (https://git.llvm.org/git/llvm.git/ > 3afd566557f3616881505db0d69f5d19bf55ae14) > cross-checked with gcc 7.3.0 (x86_64-linux-gcc.br_real (Buildroot > 2018.02-rc1) 7.3.0). > > Tested with 64-bit builds only; 32-bit images fail to build with clang > with various unrelated errors and are difficult to test. > > I had to change '+=' to '=' below since make otherwise sets > RETPOLINE_CFLAGS to " ", and the subsequent ifneq would always match. > This is also the reason for the "ifeq ($(RETPOLINE_CFLAGS),)". > If there is another/different/better way to handle this, please let > me know. See http://git.infradead.org/users/dwmw2/linux-retpoline.git/commitdiff/82a1f41600 > There are curently lots of warnings when building an image with clang. > > ./include/linux/init.h:134:6: warning: > unknown attribute 'indirect_branch' ignored > > I was inclined to add "&& !defined(__clang__)" to the condition for the > __noretpoline define to fix the problem, but concluded that this should > be a separate patch unless it can be addressed in clang. ... where I fixed that too as well as providing the __x86_indirect_thunk for 32-bit builds (which are broken for other reasons anyway). We do still need the %V asm constraint modifier to work in clang though, because otherwise it still doesn't build if you have any hypervisor guest support. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC, PATCH v1] platform/x86: intel-vbtn: Convert to pure ACPI driver
On Wednesday, February 7, 2018 10:55:22 AM CET Pali Rohár wrote: > On Wednesday 07 February 2018 10:47:57 Rafael J. Wysocki wrote: > > BTW, please CC patches with ACPI material to linux-acpi. They are less > > likely > > to be overlooked by me then and the others on that list may have opinions on > > them too. > > Maybe we can update MAINTAINERS file for acpi based platform-x86 drivers > to include linux-acpi list? Darren, Andy, any idea? You could, but generally, if you have ACPI material in your patch, CCing linux-acpi won't hurt.
Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME
On Tue, Feb 6, 2018 at 10:52 PM, Wu Hao wrote: > On Tue, Feb 06, 2018 at 12:53:44PM -0600, Alan Tull wrote: >> On Tue, Feb 6, 2018 at 12:47 AM, Wu Hao wrote: >> > On Mon, Feb 05, 2018 at 10:25:54PM -0600, Alan Tull wrote: >> >> On Mon, Feb 5, 2018 at 7:47 PM, Wu Hao wrote: >> >> > On Mon, Feb 05, 2018 at 10:36:45AM -0800, Luebbers, Enno wrote: >> >> >> Hi Hao, >> >> >> >> >> >> On Sun, Feb 04, 2018 at 05:37:06PM +0800, Wu Hao wrote: >> >> >> > On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote: >> >> >> > > Hi Hao, Alan, >> >> >> > > >> >> >> > > On Fri, Feb 02, 2018 at 05:42:13PM +0800, Wu Hao wrote: >> >> >> > > > On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote: >> >> >> > > > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao >> >> >> > > > > wrote: >> >> >> > > > > >> >> >> > > > > Hi Hao, >> >> >> > > > > >> >> >> > > > > A few comments below. Besides that, looks good. >> >> >> > > > > >> >> >> > > > > > This patch adds fpga manager driver for FPGA Management >> >> >> > > > > > Engine (FME). It >> >> >> > > > > > implements fpga_manager_ops for FPGA Partial Reconfiguration >> >> >> > > > > > function. >> >> >> > > > > > >> >> >> > > > > > Signed-off-by: Tim Whisonant >> >> >> > > > > > Signed-off-by: Enno Luebbers >> >> >> > > > > > Signed-off-by: Shiva Rao >> >> >> > > > > > Signed-off-by: Christopher Rauer >> >> >> > > > > > >> >> >> > > > > > Signed-off-by: Kang Luwei >> >> >> > > > > > Signed-off-by: Xiao Guangrong >> >> >> > > > > > >> >> >> > > > > > Signed-off-by: Wu Hao >> >> >> > > > > > >> >> >> > > > > > v3: rename driver to dfl-fpga-fme-mgr >> >> >> > > > > > implemented status callback for fpga manager >> >> >> > > > > > rebased due to fpga api changes >> >> >> > > > > > --- >> >> >> > > > > > .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr| 8 + >> >> >> > > > > > drivers/fpga/Kconfig | 6 + >> >> >> > > > > > drivers/fpga/Makefile | 1 + >> >> >> > > > > > drivers/fpga/fpga-dfl-fme-mgr.c| 318 >> >> >> > > > > > + >> >> >> > > > > > drivers/fpga/fpga-dfl.h| 39 ++- >> >> >> > > > > > 5 files changed, 371 insertions(+), 1 deletion(-) >> >> >> > > > > > create mode 100644 >> >> >> > > > > > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr >> >> >> > > > > > create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c >> >> >> > > > > > >> >> >> > > > > > diff --git >> >> >> > > > > > a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr >> >> >> > > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr >> >> >> > > > > > new file mode 100644 >> >> >> > > > > > index 000..2d4f917 >> >> >> > > > > > --- /dev/null >> >> >> > > > > > +++ >> >> >> > > > > > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr >> >> >> > > > > > @@ -0,0 +1,8 @@ >> >> >> > > > > > +What: >> >> >> > > > > > /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id >> >> >> > > > > > +Date: November 2017 >> >> >> > > > > > +KernelVersion: 4.15 >> >> >> > > > > > +Contact: Wu Hao >> >> >> > > > > > +Description: Read-only. It returns interface id of >> >> >> > > > > > partial reconfiguration >> >> >> > > > > > + hardware. Userspace could use this >> >> >> > > > > > information to check if >> >> >> > > > > > + current hardware is compatible with given >> >> >> > > > > > image before FPGA >> >> >> > > > > > + programming. >> >> >> > > > > >> >> >> > > > > I'm a little confused by this. I can understand that the PR >> >> >> > > > > bitstream >> >> >> > > > > has a dependency on the FPGA's static image, but I don't >> >> >> > > > > understand >> >> >> > > > > the dependency of the bistream on the hardware that is used to >> >> >> > > > > program >> >> >> > > > > the bitstream to the FPGA. >> >> >> > > > >> >> >> > > > Sorry for the confusion, the interface_id is used to indicate >> >> >> > > > the version of >> >> >> > > > the hardware for partial reconfiguration (it's part of the >> >> >> > > > static image of >> >> >> > > > the FPGA device). Will improve the description on this. >> >> >> > > > >> >> >> > > >> >> >> > > The interface_id expresses the compatibility of the static region >> >> >> > > with PR >> >> >> > > bitstreams generated for it. It changes every time a new static >> >> >> > > region is >> >> >> > > generated. >> >> >> > > >> >> >> > > Would it make more sense to have the interface_id exposed as part >> >> >> > > of the FME >> >> >> > > device (which represents the static region)? I'm not sure - it >> >> >> > > kind of also >> >> >> > > makes sense here, where you would have all the information in one >> >> >> > > place (if the >> >> >> > > interface_id matches, I can use this component to program a >> >> >> > > bitstream). >> >> >> > >> >> >> > Hi Enno >> >> >> > >> >> >> > Yes, this interface is unde
[PATCH v9 4/8] MAINTAINERS: add entry for NXP TDA1997x driver
Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 845fc25..439b500 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13262,6 +13262,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F: drivers/media/tuners/tda18271* +TDA1997x MEDIA DRIVER +M: Tim Harvey +L: linux-me...@vger.kernel.org +W: https://linuxtv.org +Q: http://patchwork.linuxtv.org/project/linux-media/list/ +S: Maintained +F: drivers/media/i2c/tda1997x.* + TDA827x MEDIA DRIVER M: Michael Krufky L: linux-me...@vger.kernel.org -- 2.7.4
[PATCH v9 1/8] v4l2-dv-timings: add v4l2_hdmi_colorimetry()
From: Hans Verkuil
Add the v4l2_hdmi_colorimetry() function so we have a single function
that determines the colorspace, YCbCr encoding, quantization range and
transfer function from the InfoFrame data.
Cc: Randy Dunlap
Signed-off-by: Hans Verkuil
---
v9:
- fix kernel-doc format (Randy)
- remove redundant pad bounds check already in v4l2-subdev.c
- assign entity function (Hans)
- properly assign/check/free ctrl_handler (Hans)
- fixed typo 'Rull Range' -> 'Full Range'
- update csc after quant range change
drivers/media/v4l2-core/v4l2-dv-timings.c | 141 ++
include/media/v4l2-dv-timings.h | 21 +
2 files changed, 162 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 930f9c5..5663d86 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Hans Verkuil");
MODULE_DESCRIPTION("V4L2 DV Timings Helper Functions");
@@ -814,3 +815,143 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8
hor_landscape, u8 vert_portrait)
return aspect;
}
EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
+
+/** v4l2_hdmi_rx_colorimetry - determine HDMI colorimetry information
+ * based on various InfoFrames.
+ * @avi: the AVI InfoFrame
+ * @hdmi: the HDMI Vendor InfoFrame, may be NULL
+ * @height: the frame height
+ *
+ * Determines the HDMI colorimetry information, i.e. how the HDMI
+ * pixel color data should be interpreted.
+ *
+ * Note that some of the newer features (DCI-P3, HDR) are not yet
+ * implemented: the hdmi.h header needs to be updated to the HDMI 2.0
+ * and CTA-861-G standards.
+ */
+struct v4l2_hdmi_colorimetry
+v4l2_hdmi_rx_colorimetry(const struct hdmi_avi_infoframe *avi,
+const struct hdmi_vendor_infoframe *hdmi,
+unsigned int height)
+{
+ struct v4l2_hdmi_colorimetry c = {
+ V4L2_COLORSPACE_SRGB,
+ V4L2_YCBCR_ENC_DEFAULT,
+ V4L2_QUANTIZATION_FULL_RANGE,
+ V4L2_XFER_FUNC_SRGB
+ };
+ bool is_ce = avi->video_code || (hdmi && hdmi->vic);
+ bool is_sdtv = height <= 576;
+ bool default_is_lim_range_rgb = avi->video_code > 1;
+
+ switch (avi->colorspace) {
+ case HDMI_COLORSPACE_RGB:
+ /* RGB pixel encoding */
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_EXTENDED:
+ switch (avi->extended_colorimetry) {
+ case HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB:
+ c.colorspace = V4L2_COLORSPACE_ADOBERGB;
+ c.xfer_func = V4L2_XFER_FUNC_ADOBERGB;
+ break;
+ case HDMI_EXTENDED_COLORIMETRY_BT2020:
+ c.colorspace = V4L2_COLORSPACE_BT2020;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ switch (avi->quantization_range) {
+ case HDMI_QUANTIZATION_RANGE_LIMITED:
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ case HDMI_QUANTIZATION_RANGE_FULL:
+ break;
+ default:
+ if (default_is_lim_range_rgb)
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ break;
+ }
+ break;
+
+ default:
+ /* YCbCr pixel encoding */
+ c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
+ switch (avi->colorimetry) {
+ case HDMI_COLORIMETRY_NONE:
+ if (!is_ce)
+ break;
+ if (is_sdtv) {
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ } else {
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+ }
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_601:
+ c.colorspace = V4L2_COLORSPACE_SMPTE170M;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_601;
+ c.xfer_func = V4L2_XFER_FUNC_709;
+ break;
+ case HDMI_COLORIMETRY_ITU_709:
+ c.colorspace = V4L2_COLORSPACE_REC709;
+ c.ycbcr_enc = V4L2_YCBCR_ENC_709;
+
[PATCH v9 0/8] TDA1997x HDMI video reciver
This is a v4l2 subdev driver supporting the TDA1997x HDMI video receiver. I've tested this on a Gateworks GW54xx/GW551x with an IMX6Q/IMX6DL which uses the TDA19971 with 16bits connected to the IMX6 CSI and single-lane I2S audio providing 2-channel audio. For this configuration I've tested both 16bit YUV422 and 8bit BT656 parallel video bus modes. While the driver should support the TDA1993 I do not have one for testing. Further potential development efforts include: - CEC support - HDCP support - TDA19972 support (2 inputs) Media graphs can be found at http://dev.gateworks.com/docs/linux/media History: v9: - add digital video decoder video interface entity function v8: - fix clearing pad for VIDIOC_DV_TIMIGNS_CAP - support full range of input modes based on timings_cap - add patch to fix clearing pad for VIDIOC_DV_TIMIGINGS - fix available formats for tda19971 bt656 bus width >12 - fix set_format (compliance) - fixed get/set edid (compliance) - add init_cfg to setup default pad config (compliance) - added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance) - fix alignment of if statement and whitespace in comment (Hans) - move regs to tda1997x_regs.h to clean up (Hans) - add define and sanity check for num of mbus_codes (Hans) v7: - fix interlaced mode - support no AVI infoframe (ie DVI) (Hans) - add support for multiple output formats (Hans) v6: - tda1997x: fix return on regulator enablei in tda1997x_set_power() (Fabio) - tda1997x: fix colorspace handling (Hans) - bindings: added Robs's ack (Rob) - replace copyright with SPDX tag (Philippe) v5: - added v4l2_hdmi_colorimetry() patch from Hans to series - bindings: added Sakari's ack - tda1997x: uppercase string constants - tda1997x: use v4l2_hdmi_rx_coloriemtry to fill format - tda1997x: fix V4L2_CID_DV_RX_RGB_RANGE - tda1997x: fix interlaced mode format - dts: remove leading 0 from unit address - dts: add newline between property list and child node - dts: added missing audmux in GW551x dts v4: - move include/dt-bindings/media/tda1997x.h to bindings patch - clarify port node details in bindings - fix typos - fix default quant range for VGA - fix quant range handling and conv matrix - add additional standards and capabilities to timings_cap v3: - fix typo in dt bindings - added dt bindings for GW551x - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros - fixed missing break - use only hdmi_infoframe_log for infoframe logging - simplify tda1997x_s_stream error handling - add delayed work proc to handle hotplug enable/disable - fix set_edid (disable HPD before writing, enable after) - remove enabling edid by default - initialize timings - take quant range into account in colorspace conversion - remove vendor/product tracking (we provide this in log_status via infoframes) - add v4l_controls - add more detail to log_status - calculate vhref generator timings - timing detection fixes (rounding errors, hswidth errors) - rename configure_input/configure_conv functions v2: - encorporate feedback into dt bindings - change audio dt bindings - implement dv timings enum/cap - remove deprecated g_mbus_config op - fix dv_query_timings - add EDID get/set handling - remove max-pixel-rate support - add audio codec DAI support - added media-ctl and v4l2-compliance details v1: - initial RFC # media-ctl -d /dev/media0 -p Media controller API version 4.15.0 Media device information driver imx-media model imx-media serial bus info hw revision 0x0 driver version 4.15.0 Device topology - entity 1: adv7180 2-0020 (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 20004 device node name /dev/v4l-subdev0 pad0: Source [fmt:UYVY8_2X8/720x480 field:interlaced colorspace:smpte170m] -> "ipu2_csi1_mux":1 [] - entity 3: tda19971 2-0048 (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1280x720 field:none colorspace:srgb] [dv.caps:BT.656/1120 min:640x350@1300 max:1920x1200@16500 stds:CEA-861,DMT,CVT,GTF caps:interlaced,progressive,reduced-blanking,custom] [dv.detect:BT.656/1120 1280x720p60 (1650x750) stds:CEA-861 flags:can-reduce-fps,CE-video,has-cea861-vic] [dv.current:BT.656/1120 1280x720p60 (1650x750) stds:CEA-861 flags:can-reduce-fps,CE-video,has-cea861-vic] -> "ipu1_csi0_mux":1 [ENABLED] - entity 5: ipu1_vdic (3 pads, 3 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:AYUV8_1X32/640x480@1/30 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ipu1_csi0":1 [] <- "ipu1_csi1":1 [] pad1: Sink [fmt
[PATCH v9 8/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW551x
Signed-off-by: Tim Harvey
---
v5:
- add missing audmux config
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 138 ++
1 file changed, 138 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 30d4662..749548a 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -46,6 +46,8 @@
*/
#include
+#include
+#include
/ {
/* these are used by bootloader for disabling nodes */
@@ -98,6 +100,50 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>; /* AUD5<->tda1997x */
+ status = "okay";
+
+ ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ (IMX_AUDMUX_V2_PTCR_TFSDIR |
+ IMX_AUDMUX_V2_PTCR_TFSEL(4+8) | /* RXFS */
+ IMX_AUDMUX_V2_PTCR_TCLKDIR |
+ IMX_AUDMUX_V2_PTCR_TCSEL(4+8) | /* RXC */
+ IMX_AUDMUX_V2_PTCR_SYN)
+ IMX_AUDMUX_V2_PDCR_RXDSEL(4)
+ >;
+ };
+
+ aud5 {
+ fsl,audmux-port = <4>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN
+ IMX_AUDMUX_V2_PDCR_RXDSEL(0)>;
+ };
};
&can1 {
@@ -263,6 +309,60 @@
#gpio-cells = <2>;
};
+ tda1997x: tda1997x@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3>;
+ AVDD-supply = <®_1p8b>;
+ DVDD-supply = <®_1p8a>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&pcie {
@@ -320,6 +420,14 @@
};
&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD0x130b0
+ MX6QDL_PAD_DISP0_DAT14__AUD5_RXC0x130b0
+ MX6QDL_PAD_DISP0_DAT13__AUD5_RXFS 0x130b0
+ >;
+ };
+
pinctrl_flexcan1: flexcan1grp {
fsl,pins = <
MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX0x1b0b1
@@ -375,6 +483,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1_csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_D
[PATCH v9 7/8] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx
The GW54xx has a front-panel microHDMI connector routed to a TDA19971
which is connected the the IPU CSI when using IMX6Q.
Signed-off-by: Tim Harvey
---
v5:
- remove leading 0 from unit address
- add newline between property list and child node
v4: no changes
v3: no changes
v2:
- add HDMI audio input support
arch/arm/boot/dts/imx6q-gw54xx.dts| 105 ++
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 29 +-
2 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw54xx.dts
b/arch/arm/boot/dts/imx6q-gw54xx.dts
index 56e5b50..0477120 100644
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -12,10 +12,30 @@
/dts-v1/;
#include "imx6q.dtsi"
#include "imx6qdl-gw54xx.dtsi"
+#include
/ {
model = "Gateworks Ventana i.MX6 Dual/Quad GW54XX";
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
+
+ sound-digital {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "tda1997x-audio";
+
+ simple-audio-card,dai-link@0 {
+ format = "i2s";
+
+ cpu {
+ sound-dai = <&ssi2>;
+ };
+
+ codec {
+ bitclock-master;
+ frame-master;
+ sound-dai = <&tda1997x>;
+ };
+ };
+ };
};
&i2c3 {
@@ -35,6 +55,61 @@
};
};
};
+
+ tda1997x: codec@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <&sw4_reg>;
+ DVDD-supply = <&sw4_reg>;
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same cycle
+* which we map to VP[15:08]<->CSI_DATA[19:12]
+*/
+ nxp,vidout-portcfg =
+ /*G_Y_11_8<->VP[15:12]<->CSI_DATA[19:16]*/
+ < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >,
+ /*G_Y_7_4<->VP[11:08]<->CSI_DATA[15:12]*/
+ < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >,
+ /*R_CR_CBCR_11_8<->VP[07:04]<->CSI_DATA[11:08]*/
+ < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >,
+ /*R_CR_CBCR_7_4<->VP[03:00]<->CSI_DATA[07:04]*/
+ < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >;
+
+ port {
+ tda1997x_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint =
<&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <16>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ data-active = <1>;
+ };
+ };
+ };
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <16>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
+ bus-width = <16>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
};
&ipu2_csi1_from_ipu2_csi1_mux {
@@ -63,6 +138,30 @@
>;
};
+ pinctrl_ipu1_csi0: ipu1_csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
Re: [PATCH 0/7] ARM: davinci: add genpd support
On 02/07/2018 07:45 AM, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Hi Sekhar et al, please take a look at the following patches. They add a simple genpd driver and use it in DT mode on da850 boards. I was trying to use genpd in legacy mode too, but couldn't find neither any interfaces nor users that would do that. For now I added a check in arch/arm/mach-davinci/pm_domain.c that disables the clock pm setup if we're using genpd. This series applies on top of and has been tested with David Lechner's for-bartosz branch. It fixes the clock look-up issues we faced with lcdc and emac. I'm starting to think that it makes more sense to just make the PSC driver a power-domain and reset provider rather than a clock provider. It is unfortunate that genpd is DT only.
[PATCH v9 5/8] media: dt-bindings: Add bindings for TDA1997X
Acked-by: Rob Herring
Acked-by: Sakari Ailus
Signed-off-by: Tim Harvey
---
v6:
- replace copyright with SPDX tag
- added Rob's ack
v5:
- added Sakari's ack
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- clarify port node details
v3:
- fix typo
v2:
- add vendor prefix and remove _ from vidout-portcfg
- remove _ from labels
- remove max-pixel-rate property
- describe and provide example for single output port
- update to new audio port bindings
.../devicetree/bindings/media/i2c/tda1997x.txt | 179 +
include/dt-bindings/media/tda1997x.h | 74 +
2 files changed, 253 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
create mode 100644 include/dt-bindings/media/tda1997x.h
diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
new file mode 100644
index 000..9ab53c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
@@ -0,0 +1,179 @@
+Device-Tree bindings for the NXP TDA1997x HDMI receiver
+
+The TDA19971/73 are HDMI video receivers.
+
+The TDA19971 Video port output pins can be used as follows:
+ - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
+ - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
+ - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
+ - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
+ - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0]
+ - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
+ - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The TDA19973 Video port output pins can be used as follows:
+ - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
+ - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
+ - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
+ - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
+
+The Video port output pins are mapped via 4-bit 'pin groups' allowing
+for a variety of connection possibilities including swapping pin order within
+pin groups. The video_portcfg device-tree property consists of register mapping
+pairs which map a chip-specific VP output register to a 4-bit pin group. If
+the pin group needs to be bit-swapped you can use the *_S pin-group defines.
+
+Required Properties:
+ - compatible :
+ - "nxp,tda19971" for the TDA19971
+ - "nxp,tda19973" for the TDA19973
+ - reg : I2C slave address
+ - interrupts : The interrupt number
+ - DOVDD-supply: Digital I/O supply
+ - DVDD-supply : Digital Core supply
+ - AVDD-supply : Analog supply
+ - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups.
+
+Optional Properties:
+ - nxp,audout-format : DAI bus format: "i2s" or "spdif".
+ - nxp,audout-width: width of audio output data bus (1-4).
+ - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
+ - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec
+ mclk.
+
+The port node shall contain one endpoint child node for its digital
+output video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional Endpoint Properties:
+ The following three properties are defined in video-interfaces.txt and
+ are valid for the output parallel bus endpoint:
+ - hsync-active: Horizontal synchronization polarity. Defaults to active high.
+ - vsync-active: Vertical synchronization polarity. Defaults to active high.
+ - data-active: Data polarity. Defaults to active high.
+
+Examples:
+ - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
+ 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
+ hdmi-receiver@48 {
+ compatible = "nxp,tda19971";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tda1997x>;
+ reg = <0x48>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+ DOVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_1p8v>;
+ DVDD-supply = <®_1p8v>;
+ /* audio */
+ #sound-dai-cells = <0>;
+ nxp,audout-format = "i2s";
+ nxp,audout-layout = <0>;
+ nxp,audout-width = <16>;
+ nxp,audout-mclk-fs = <128>;
+ /*
+* The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
+* and Y[11:4] across 16bits in the same pixclk cycle.
+*/
+ nxp,vidout-portcfg =
+ /* Y[11:8]<->VP[15:12]<->CSI_DATA[1
[PATCH v9 6/8] media: i2c: Add TDA1997x HDMI receiver driver
Add support for the TDA1997x HDMI receivers.
Cc: Hans Verkuil
Signed-off-by: Tim Harvey
---
v9:
- remove redundant pad bounds check already in v4l2-subdev.c
- assign entity function (Hans)
- properly assign/check/free ctrl_handler (Hans)
- fixed typo 'Rull Range' -> 'Full Range'
- update csc after quant range change
v8:
- fix available formats for tda19971 bt656 bus width >12
- support full range of input modes based on timings_cap
- fix set_format (compliance)
- fixed get/set edid (compliance)
- add init_cfg to setup default pad config (compliance)
- added missing pad checks to get_dv_timings_cap/enum_dv_timings (compliance)
- fix alignment of if statement and whitespace in comment (Hans)
- move regs to tda1997x_regs.h to clean up (Hans)
- add define and sanity check for num of mbus_codes (Hans)
v7:
- fix interlaced mode
- support no AVI infoframe (ie DVI) (Hans)
- add support for multiple output formats (Hans)
v6:
- fix return on regulator enablei in tda1997x_set_power()
- replace copyright with SPDX tag
- fix colorspace handling
v5:
- uppercase string constants
- use v4l2_hdmi_rx_coloriemtry to fill format
- fix V4L2_CID_DV_RX_RGB_RANGE
- fix interlaced mode format
v4:
- move include/dt-bindings/media/tda1997x.h to bindings patch
- fix typos
- fix default quant range for VGA
- fix quant range handling and conv matrix
- add additional standards and capabilities to timings_cap
v3:
- use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
- fixed missing break
- use only hdmi_infoframe_log for infoframe logging
- simplify tda1997x_s_stream error handling
- add delayed work proc to handle hotplug enable/disable
- fix set_edid (disable HPD before writing, enable after)
- remove enabling edid by default
- initialize timings
- take quant range into account in colorspace conversion
- remove vendor/product tracking (we provide this in log_status via infoframes)
- add v4l_controls
- add more detail to log_status
- calculate vhref generator timings
- timing detection fixes (rounding errors, hswidth errors)
- rename configure_input/configure_conv functions
v2:
- implement dv timings enum/cap
- remove deprecated g_mbus_config op
- fix dv_query_timings
- add EDID get/set handling
- remove max-pixel-rate support
- add audio codec DAI support
- change audio bindings
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile|1 +
drivers/media/i2c/tda1997x.c | 2848 +
drivers/media/i2c/tda1997x_regs.h | 641 +
include/media/i2c/tda1997x.h | 42 +
5 files changed, 3541 insertions(+)
create mode 100644 drivers/media/i2c/tda1997x.c
create mode 100644 drivers/media/i2c/tda1997x_regs.h
create mode 100644 include/media/i2c/tda1997x.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff..3522641 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -56,6 +56,15 @@ config VIDEO_TDA9840
To compile this driver as a module, choose M here: the
module will be called tda9840.
+config VIDEO_TDA1997X
+ tristate "NXP TDA1997x HDMI receiver"
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tda1997x.
+
config VIDEO_TEA6415C
tristate "Philips TEA6415C audio processor"
depends on I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9ef..adfcae9 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
+obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
new file mode 100644
index 000..87af02b
--- /dev/null
+++ b/drivers/media/i2c/tda1997x.c
@@ -0,0 +1,2848 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Gateworks Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "tda1997x_regs.h"
+
+#define TDA1997X_MBUS_CODES5
+
+/* debug level */
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+/* Audio formats */
+static const char * const audtype_names[] = {
+ "PCM", /* PCM Samples */
+ "HBR", /* High Bit Rate Audio */
+ "OBA", /*
[PATCH v9 3/8] media: add digital video decoder entity function
Add a new media entity function definition for digital TV decoders:
MEDIA_ENT_F_DTV_DECODER
Signed-off-by: Tim Harvey
---
Documentation/media/uapi/mediactl/media-types.rst | 11 +++
include/uapi/linux/media.h| 5 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/media/uapi/mediactl/media-types.rst
b/Documentation/media/uapi/mediactl/media-types.rst
index 8d64b0c..195400e 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -321,6 +321,17 @@ Types and flags used to represent the media graph elements
MIPI CSI-2, ...), and outputs them on its source pad to an output
video bus of another type (eDP, MIPI CSI-2, parallel, ...).
+- .. row 31
+
+ .. _MEDIA-ENT-F-DTV-DECODER:
+
+ - ``MEDIA_ENT_F_DTV_DECODER``
+
+ - Digital video decoder. The basic function of the video decoder is
+ to accept digital video from a wide variety of sources
+ and output it in some digital video standard, with appropriate
+ timing signals.
+
.. tabularcolumns:: |p{5.5cm}|p{12.0cm}|
.. _media-entity-flag:
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index b9b9446..2f12328 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -110,6 +110,11 @@ struct media_device_info {
#define MEDIA_ENT_F_VID_IF_BRIDGE (MEDIA_ENT_F_BASE + 0x5002)
/*
+ * Digital video decoder entities
+ */
+#define MEDIA_ENT_F_DTV_DECODER(MEDIA_ENT_F_BASE +
0x6001)
+
+/*
* Connectors
*/
/* It is a responsibility of the entity drivers to add connectors and links */
--
2.7.4
[PATCH v9 2/8] media: v4l-ioctl: fix clearing pad for VIDIOC_DV_TIMIGNS_CAP
Signed-off-by: Tim Harvey
---
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 7961499..5f3670d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2638,7 +2638,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_FNC(VIDIOC_PREPARE_BUF, v4l_prepare_buf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_STD(VIDIOC_ENUM_DV_TIMINGS, vidioc_enum_dv_timings,
v4l_print_enum_dv_timings, INFO_FL_CLEAR(v4l2_enum_dv_timings, pad)),
IOCTL_INFO_STD(VIDIOC_QUERY_DV_TIMINGS, vidioc_query_dv_timings,
v4l_print_dv_timings, INFO_FL_ALWAYS_COPY),
- IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
+ IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, pad)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl,
v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl,
id)),
--
2.7.4
Re: Documentation: networking: ixgb: Remove reference to IXGB_NAPI
> -Original Message-
> Date: Mon, 29 Jan 2018 12:17:54 +
> From: Corentin Labbe
> List-Id: Intel Wired Ethernet Linux Kernel Driver Development
>
>
> NAPI is enabled by default and IXGB_NAPI was removed since
> commit 6d37ab282e24 ("ixgb: make NAPI the only option and the default")
> Update the doc accordingly.
>
> Signed-off-by: Corentin Labbe
> ---
> Documentation/networking/ixgb.txt | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Tested-by: Aaron Brown
Re: [RFC, PATCH v1] platform/x86: intel-vbtn: Convert to pure ACPI driver
On Wednesday, February 7, 2018 2:18:52 PM CET Andy Shevchenko wrote: > On Wed, 2018-02-07 at 13:08 +, mario.limoncie...@dell.com wrote: > > > -Original Message- > > > From: Pali Rohár [mailto:pali.ro...@gmail.com] > > > Sent: Wednesday, February 7, 2018 3:55 AM > > > To: Rafael J. Wysocki > > > Cc: Andy Shevchenko ; Limonciello, Mario > > > ; andriy.shevche...@linux.intel.com; > > > dvh...@infradead.org; platform-driver-...@vger.kernel.org; > > > acelan@canonical.com; linux-kernel@vger.kernel.org > > > Subject: Re: [RFC, PATCH v1] platform/x86: intel-vbtn: Convert to > > > pure ACPI driver > > > > > > On Wednesday 07 February 2018 10:47:57 Rafael J. Wysocki wrote: > > > > BTW, please CC patches with ACPI material to linux-acpi. They are > > > > less likely > > > > to be overlooked by me then and the others on that list may have > > > > opinions on > > > > them too. > > > > > > Maybe we can update MAINTAINERS file for acpi based platform-x86 > > > drivers > > > to include linux-acpi list? Darren, Andy, any idea? > > > > > > > I would also wonder if the intel-vbtn driver should still live in > > platform-x86 as it's > > now pure ACPI driver with this change Andy proposed. > > > > Btw Andy for your v2 with your fixups that were in your review branch > > feel free > > to add: > > Tested-by: Mario Limonciello > > > > When you resubmit it. > > Mario, Rafael clarifies the matter and NACKed this one (which kinda was > expected by me, that's why RFC was in the first place). > > I'm going to drop this patch from my queue. Thanks!
Re: [PATCH 02/14] kconfig: do not write choice values when their dependency becomes n
On Tue, Feb 06, 2018 at 09:34:42AM +0900, Masahiro Yamada wrote:
> "# CONFIG_... is not set" for choice values are wrongly written into
> the .config file if they are once visible, then become invisible later.
>
> Test case
> -
>
> ---(Kconfig)
> config A
> bool "A"
>
> choice
> prompt "Choice ?"
> depends on A
>
> config CHOICE_B
> bool "Choice B"
>
> config CHOICE_C
> bool "Choice C"
>
> endchoice
>
>
> ---(.config)
> CONFIG_A=y
>
>
> With the Kconfig and .config above,
>
> $ make config
> scripts/kconfig/conf --oldaskconfig Kconfig
> *
> * Linux Kernel Configuration
> *
> A (A) [Y/n] n
> #
> # configuration written to .config
> #
> $ cat .config
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux Kernel Configuration
> #
> # CONFIG_A is not set
> # CONFIG_CHOICE_B is not set
> # CONFIG_CHOICE_C is not set
>
> Here,
>
> # CONFIG_CHOICE_B is not set
> # CONFIG_CHOICE_C is not set
>
> should not be written into the .config file because their dependency
> "depends on A" is unmet.
>
> Currently, there is no code that clears SYMBOL_WRITE of choice values.
>
> Clear SYMBOL_WRITE for all symbols in sym_calc_value(), then set it
> again after calculating visibility.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/symbol.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
> index c9123ed..5d6f6b1 100644
> --- a/scripts/kconfig/symbol.c
> +++ b/scripts/kconfig/symbol.c
> @@ -371,8 +371,7 @@ void sym_calc_value(struct symbol *sym)
> sym->curr.tri = no;
> return;
> }
> - if (!sym_is_choice_value(sym))
> - sym->flags &= ~SYMBOL_WRITE;
> + sym->flags &= ~SYMBOL_WRITE;
>
> sym_calc_visibility(sym);
>
> @@ -385,6 +384,7 @@ void sym_calc_value(struct symbol *sym)
> if (sym_is_choice_value(sym) && sym->visible == yes) {
> prop = sym_get_choice_prop(sym);
> newval.tri = (prop_get_symbol(prop)->curr.val == sym) ?
> yes : no;
> + sym->flags |= SYMBOL_WRITE;
> } else {
> if (sym->visible != no) {
> /* if the symbol is visible use the user value
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
There's a possible simplification here:
All defined symbols, regardless of type, and regardless of whether
they're choice value symbols or not, always get written out if they have
non-n visibility. Therefore, the sym->visible != no check for
SYMBOL_WRITE can be moved to before the symbol type check, which gets
rid of two SYMBOL_WRITE assignments and makes it clear that the logic is
the same for all paths.
This is safe for symbols defined without a type (S_UNKNOWN) too, because
conf_write() skips those (plus they already generate a warning).
This matches how I do it in the tri_value() function in Kconfiglib:
https://github.com/ulfalizer/Kconfiglib/blob/master/kconfiglib.py#L2574.
SYMBOL_WRITE corresponds to _write_to_conf.
I've included a patch below. I tested it with the Kconfiglib test suite,
which verifies that the C implementation still generates the same
.config file for all defconfig files as well as for
all{no,yes,def}config, for all ARCHes.
(The Kconfiglib test suite runs scripts/kconfig/conf and compares its
output against it, which means it doubles as a regression test for the C
tools.)
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index c9123ed2b791..13f7fdfe328d 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -371,11 +371,13 @@ void sym_calc_value(struct symbol *sym)
sym->curr.tri = no;
return;
}
- if (!sym_is_choice_value(sym))
- sym->flags &= ~SYMBOL_WRITE;
+ sym->flags &= ~SYMBOL_WRITE;
sym_calc_visibility(sym);
+ if (sym->visible != no)
+ sym->flags |= SYMBOL_WRITE;
+
/* set default if recursively called */
sym->curr = newval;
@@ -390,7 +392,6 @@ void sym_calc_value(struct symbol *sym)
/* if the symbol is visible use the user value
* if available, otherwise try the default value
*/
- sym->flags |= SYMBOL_WRITE;
if (sym_has_value(sym)) {
newval.tri =
EXPR_AND(sym->def[S_DEF_USER].tri,
sym->visible);
@@ -433,12 +434,9 @@ void sym_calc_value(struct symbol *sym)
case S
Re: [PATCH] binder: replace "%p" with "%pK"
On Wed, Feb 07, 2018 at 01:57:37PM -0800, Todd Kjos wrote: > The format specifier "%p" can leak kernel addresses. Use > "%pK" instead. There were 4 remaining cases in binder.c. Luckily this isn't an issue in mainline as we don't print %p values out anymore as of 4.15. That being said, this is a good fix and I'll queue it up after 4.16-rc1 is out, thanks. greg k-h
Re: [PATCH] net: ethernet: ti: cpsw: fix net watchdog timeout
On Wed, Feb 07, 2018 at 12:19:11PM -0600, Grygorii Strashko wrote:
On 02/07/2018 07:31 AM, Ivan Khoronzhuk wrote:
On Wed, Feb 07, 2018 at 05:03:19AM +0200, Ivan Khoronzhuk wrote:
On Tue, Feb 06, 2018 at 07:17:06PM -0600, Grygorii Strashko wrote:
It was discovered that simple program which indefinitely sends 200b UDP
packets and runs on TI AM574x SoC (SMP) under RT Kernel triggers network
watchdog timeout in TI CPSW driver (<6 hours run). The network watchdog
timeout is triggered due to race between cpsw_ndo_start_xmit() and
cpsw_tx_handler() [NAPI]
cpsw_ndo_start_xmit()
if (unlikely(!cpdma_check_free_tx_desc(txch))) {
txq = netdev_get_tx_queue(ndev, q_idx);
netif_tx_stop_queue(txq);
^^ as per [1] barrier has to be used after set_bit() otherwise new value
might not be visible to other cpus
}
cpsw_tx_handler()
if (unlikely(netif_tx_queue_stopped(txq)))
netif_tx_wake_queue(txq);
and when it happens ndev TX queue became disabled forever while driver's HW
TX queue is empty.
I'm sure it fixes test case somehow but there is some strangeness.
(I've thought about this some X months ago):
1. If no free desc, then there is bunch of descs on the queue ready to be sent
2. If one of this desc while this process was missed then next will wake queue,
because there is bunch of them on the fly. So, if desc on top of the sent queue
missed to enable the queue, then next one more likely will enable it anyway..
then how it could happen? The described race is possible only on last
descriptor, yes, packets are small the speed is hight, possibility is very small
.but then next situation is also possible:
- packets are sent fast
- all packets were sent, but no any descriptors are freed now by sw interrupt
(NAPI)
- when interrupt had started NAPI, the queue was enabled, all other next
interrupts are throttled once NAPI not finished it's work yet.
- when new packet submitted, no free descs are present yet (NAPI has not freed
any yet), but all packets are sent, so no one can awake tx queue, as interrupt
will not arise when NAPI is started to free first descriptor interrupts are
disabled.because h/w queue to be sent is empty...
- how it can happen as submitting packet and handling packet operations is under
channel lock? Not exactly, a period between handling and freeing the descriptor
to the pool is not under channel lock, here:
spin_unlock_irqrestore(&chan->lock, flags);
if (unlikely(status & CPDMA_DESC_TD_COMPLETE))
cb_status = -ENOSYS;
else
cb_status = status;
__cpdma_chan_free(chan, desc, outlen, cb_status);
return status;
unlock_ret:
spin_unlock_irqrestore(&chan->lock, flags);
return status;
And:
__cpdma_chan_free(chan, desc, outlen, cb_status);
-> cpdma_desc_free(pool, desc, 1);
As result, queue deadlock as you've described.
Just thought, not checked, but theoretically possible.
What do you think?
Yep. And if this happens desc_alloc_fail should be >0 while i usually see it 0
when
watchdog triggers.
It has to be 0 for situation I trying to describe.
See below re example for keeping all in one place
I was able to reproduce this situation once, but with bunch of debug code added
which changes timings:
I also unintentionally observed it several times but usually was thinking
that it was connected with my other experiments. It was with am572x.
But now seems it actually can happen with plane sources. And maybe here not
only 1 fix is needed, that's my concern.
Prerequisite: only one free desc available.
cpsw_ndo_start_xmit1cpsw_tx_poll
prepare and send packet
->Free desc queue is empty at this moment
if (unlikely(!cpdma_check_free_tx_desc(txch)))
netif_tx_stop_queue(txq);
--- tx queue stopped
cpdma_chan_process()
spin_lock_irqsave(&chan->lock, flags);
chan->count--
spin_unlock_irqrestore(&chan->lock, flags)
cpsw_tx_handler()
if
(unlikely(netif_tx_queue_stopped(txq)))
netif_tx_wake_queue(txq);
--- tx queue is woken up
cpsw_ndo_start_xmit2
prepare packet
ret = cpsw_tx_packet_submit(priv, skb, txch);
//fail as desc not returned to the pool yet
if (unlikely(ret != 0)) {
cpsw_err(priv, tx_err, "desc submit failed\n");
goto fail;
}
cpdma_desc_free()
fail:
ndev->stats.tx_dropped++;
netif_tx_stop_queue(txq);
// oops.
That's why I added double check and barrier in fail path also
Seems to
Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance
On 02/07/2018 12:42 AM, Peter Zijlstra wrote: On Tue, Feb 06, 2018 at 04:30:03PM -0800, Subhra Mazumdar wrote: I meant the SMT balance patch. That does comparison with only one other random core and takes the decision in O(1). Any potential scan of all cores or cpus is O(n) and doesn't scale and will only get worse in future. That applies to both select_idle_core() and select_idle_cpu(). We only do the full scan if we think to know there is indeed an idle core to be had, and if there are idle cores the machine isn't terribly busy. If there are no idle cores, we do not in fact scan everything. We limit the amount of scanning based on the average idle time with a minimum of 4. This logic may not be working as well as you may think it to be. I had sent the cost of select_idle_sibling() w/ and w/o my patch and there was huge difference: Following is the cost (in us) of select_idle_sibling() with hackbench 16 groups: function baseline-rc6 %stdev patch %stdev select_idle_sibling() 0.556 1.72 0.263 (-52.70%) 0.78 (Except when you switch off things like SIS_PROP, then you scan unconditionally and reduce tail latency at the cost of throughput -- like said, some people want this). O(1) sounds nice, but it has horrible worst case latencies. And like I said, I don't see how a rotor is particularly more random than the previous cpu the task you happen to be waking ran on. The rotor randomness is not the main point here. I think the benchmark improvements come from the fact that select_idle_sibling() cost has reduced a lot. To reduce it while still maintaining good spread of threads can be achieved by this SMT balance scheme which in turn requires a fast decent random number generator and rotor is just an easy way to achieve that. Is there any reason this randomized approach is not acceptable even if benchmarks show improvement? Are there other benchmarks I should try? Looking at just one other core has a fairly high chance of not finding idle. I really cannot remember all the benchmarks, but Mike did something a little less random but still O(1) a few years back and that crashed and burned. Also your suggestion to keep the SMT utilization but still do a traversal of cores in select_idle_core() while remembering the least loaded core will still have the problem of potentially traversing all cores. I can compare this with a core level only SMT balancing, is that useful to decide? I will also test on SPARC machines with higher degree of SMT. Please learn to use your email client, that's near unreadable for whitespace damage, time is really too precious to try and untangle crap like that. Sorry about that You had also mentioned to do it for only SMT >2, not sure I understand why as even for SMT=2 (intel) benchmarks show improvement. This clearly shows the scalability problem. For SMT2 you don't need the occupation counter with atomic crud, a simple !atomic core-idle works just fine. And your 'patch' had soo many moving parts it was too hard to say which aspect changed what. hackbench really isn't _that_ interesting a benchmark and its fairly easy to make it go faster, but doing so typically wrecks something else. I also had uperf and Oracle DB TPC-C numbers in the patch which showed improvements There's a whole array of netperf benchmarks which you have to run at different utilization levels, there's the sysbench oltp stuff, which you can run on MariaDB and PostgreSQL, again at different utilization levels (both databases behave quite differently). There's ebizzy, tbench, dbench and others. There's also NUMA stuff, like NAS benchmarks and specJBB nonsense. There's the facebook schbench, which is a bit finnicky to set up. And I'm sure I'm forgetting half, look at the patches and regression reports for more clues, that's what Google is for. You could have figured all that out yourself, much of these are listed in the changelogs and if you'd bothered to find lkml regression reports you could find more. Ok, will find out and run them. Thanks, Subhra
Re: [PATCH 3.18 00/36] 3.18.94-stable review
On Wed, Feb 07, 2018 at 03:19:07PM +, Harsh Shandilya wrote: > On Tue 6 Feb, 2018, 12:09 AM Greg Kroah-Hartman, > wrote: > > > This is the start of the stable review cycle for the 3.18.94 release. > > There are 36 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Feb 7 18:23:41 UTC 2018. > > Anything received after that time might be too late. > > > > Let's find out if I am too late. > > https://www.spinics.net/lists/stable/msg213160.html will have to be lined > up for 3.18.94, or to .95 if I'm late since it's fixing a erroneous > backport from 3.18.93 which went unnoticed until after release. The email > bringing it up and the subsequent patch were probably lost in the usual > stable noise. I have applied it to the CAF tree for the oneplus3 and > verified that it does not break compilation or userspace for arm64. It will be queued up for the next release, I missed it this time, sorry. greg k-h
Re: [PATCH 00/14] Add Kconfig unit tests
On Tue, Feb 6, 2018 at 10:38 AM, Greg Kroah-Hartman
wrote:
> On Tue, Feb 06, 2018 at 09:34:40AM +0900, Masahiro Yamada wrote:
>> I am applying various patches to Kconfig these days.
>>
>> However, I fear regressions. I have been thinking of unit-tests.
>>
>> There are various cryptic parts in Kconfig and corner cases where
>> it is difficult to notice breakage. If unit-tests cover those,
>> I will be able to apply changes more confidently.
>>
>> So, here is the trial.
>>
>> After fixing some problems, I will add a basic test framework.
>> This is based on pytest. Also, this is written in Python 3.
>> Python 2 will return in 2020. So, I believe new python tools should be
>> written in Python 3.
>>
>> This is my Python 3 and pytest versions.
>>
>> $ python3 --version
>> Python 3.5.2
>> $ python3 -m pytest --version
>> This is pytest version 3.4.0, imported from
>> /home/masahiro/.local/lib/python3.5/site-packages/pytest.py
>>
>> If I use old pytest version, some parts did not work as expected.
>> If this does not work for you, please consider using newer pytest.
>>
>> I will brush up the code more and add more test cases to do a better job.
>> Before proceeding more, I'd like to get consensus for this approach.
>> If you have an idea for better implementation, comments are appreciated.
>
> Personally I think this is great stuff. I too have never wanted to
> touch Kconfig stuff due to the complexity, and having unit tests like
> this is a great idea to help ensure that things do not break.
>
> Your first 5 patches should be queued up for the next merge window, no
> problem (see my comments on the 6th). As for the rest, I don't have any
> objection to them, and using python3 over python2 is a good idea. And
> anyone who wants to do Kconfig work can easily install the needed
> packages, it's not required by any "normal" kernel developer.
>
> Anyway, nice job, it's great to see this happening, no objection from me
> at all!
>
> greg k-h
Yeah, breaking Kconfig is a sure way to feel the wrath.
The only reason I feel somewhat confident modifying Kconfig is that
the Kconfiglib test suite happens to work as a regression test for the
C implementation as well. It compares the .config files produced by
the two implementations for all defconfig files and for
all{no,yes,def}config, for all ARCHes, meaning any changes to the
output of the C tools get flagged as well (with a diff).
Having some "native" tests is great as well. I'm a big fan of
automatic testing. :)
In case you want to run the Kconfiglib test suite at any point, here's
how to do it (in the kernel root):
$ git clone git://github.com/ulfalizer/Kconfiglib.git
$ git am Kconfiglib/makefile.patch
$ python Kconfiglib/testsuite.py speedy
Cheers,
Ulf
Re: [PATCH v5 4/4] irqchip/gic-v3-its: add ability to resend MAPC on resume
Hi Marc, I'm really not an expert on this, so take my observations with a large grain of salt: On Wed, Feb 07, 2018 at 08:46:42AM +, Marc Zyngier wrote: > On 07/02/18 01:41, Derek Basehore wrote: > > This adds functionality to resend the MAPC command to an ITS node on > > resume. If the ITS is powered down during suspend and the collections > > are not backed by memory, the ITS will lose that state. This just sets > > up the known state for the collections after the ITS is restored. > > > > This is enabled via the reset-on-suspend flag in the DTS for an ITS > > that has a non-zero number of collections stored in it. > > > > Signed-off-by: Derek Basehore > > --- > > drivers/irqchip/irq-gic-v3-its.c | 80 > > -- > > include/linux/irqchip/arm-gic-v3.h | 1 + > > 2 files changed, 43 insertions(+), 38 deletions(-) > > > > diff --git a/drivers/irqchip/irq-gic-v3-its.c > > b/drivers/irqchip/irq-gic-v3-its.c > > index 5e63635e2a7b..dd6cd6e68ed0 100644 > > --- a/drivers/irqchip/irq-gic-v3-its.c > > +++ b/drivers/irqchip/irq-gic-v3-its.c > > @@ -1942,52 +1942,53 @@ static void its_cpu_init_lpis(void) > > dsb(sy); > > } > > > > -static void its_cpu_init_collection(void) > > +static void its_cpu_init_collection(struct its_node *its) ... > > @@ -3127,6 +3128,9 @@ static void its_restore_enable(void) > > its_write_baser(its, baser, baser->val); > > } > > writel_relaxed(its->ctlr_save, base + GITS_CTLR); > > + > > + if (GITS_TYPER_HWCOLLCNT(gic_read_typer(base + GITS_TYPER)) > 0) > > + its_cpu_init_collection(its); > > This isn't correct. Think of a system where half the collections are in > HW, and the other half memory based (nothing in the spec forbids this). > You must evaluate the CID of each collection and replay the MAPC *only* > if it falls into the range [0..HCC-1]. The memory-based collections are > already mapped, and remapping an already mapped collection requires > extra care (see MAPC and the UNPREDICTABLE behaviour when V=1), so don't > go there. IIUC, this is only run on CPU0 (it's in syscore resume), so implicitly, CID is 0. Thus, the current condition is already doing what you ask: HCC > 0 == CID which is equivalent to: HCC - 1 >= CID Or should we really double check what CPU we're running on? Brian
Re: [PATCH v2] x86/retpoline: Add clang support
On Wed, Feb 07, 2018 at 10:28:38PM +, David Woodhouse wrote: > > > On Wed, 2018-02-07 at 13:52 -0800, Guenter Roeck wrote: > > clang has its own set of compiler options for retpoline support. > > > > Link: > > https://github.com/llvm-mirror/clang/commit/0d816739a82da29748caf88570affb9715e18b69 > > Link: > > https://github.com/llvm-mirror/llvm/commit/fd5a8723ce9f2a6b250e85972ef859e4253ea95d > > Link: > > https://github.com/llvm-mirror/llvm/commit/59b64490fda69d29bb42cfdf7eec37bcc31ff833 > > Cc: David Woodhouse > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > Cc: gno...@lxorguk.ukuu.org.uk > > Cc: Rik van Riel > > Cc: Andi Kleen > > Cc: Josh Poimboeuf > > Cc: thomas.lenda...@amd.com > > Cc: Peter Zijlstra > > Cc: Linus Torvalds > > Cc: Jiri Kosina > > Cc: Andy Lutomirski > > Cc: Dave Hansen > > Cc: Kees Cook > > Cc: Tim Chen > > Cc: Greg Kroah-Hartman > > Cc: Paul Turner > > Signed-off-by: Guenter Roeck > > --- > > v2: llvm has been updated to use the same thunk names as gcc. > > Tested with: > > clang version 7.0.0 > > (https://git.llvm.org/git/clang.git/ > > 848874aed95a913fb45f363120500cebfe54e2ef) > > (https://git.llvm.org/git/llvm.git/ > > 3afd566557f3616881505db0d69f5d19bf55ae14) > > cross-checked with gcc 7.3.0 (x86_64-linux-gcc.br_real (Buildroot > > 2018.02-rc1) 7.3.0). > > > > Tested with 64-bit builds only; 32-bit images fail to build with clang > > with various unrelated errors and are difficult to test. > > > > I had to change '+=' to '=' below since make otherwise sets > > RETPOLINE_CFLAGS to " ", and the subsequent ifneq would always match. > > This is also the reason for the "ifeq ($(RETPOLINE_CFLAGS),)". > > If there is another/different/better way to handle this, please let > > me know. > > See > http://git.infradead.org/users/dwmw2/linux-retpoline.git/commitdiff/82a1f41600 > Nice. > > > There are curently lots of warnings when building an image with clang. > > > > ./include/linux/init.h:134:6: warning: > > unknown attribute 'indirect_branch' ignored > > > > I was inclined to add "&& !defined(__clang__)" to the condition for the > > __noretpoline define to fix the problem, but concluded that this should > > be a separate patch unless it can be addressed in clang. > > ... where I fixed that too as well as providing the > __x86_indirect_thunk for 32-bit builds (which are broken for other > reasons anyway). > Much better and more comprehensive than my patch. Let's go with yours. > We do still need the %V asm constraint modifier to work in clang > though, because otherwise it still doesn't build if you have any > hypervisor guest support. Let's see what Chandler's feedback is. Worst case we can handle that in a separate patch; we won't be able to fix all clang problems in a single patch anyway. Thanks, Guenter
Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device
Hi Laurent, On 07/02/18 21:59, Laurent Pinchart wrote: > Hi Kieran, > > On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote: >> On 29/01/18 10:26, Laurent Pinchart wrote: >>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote: The ADV7511 has four 256-byte maps that can be accessed via the main I²C ports. Each map has it own I²C address and acts as a standard slave device on the I²C bus. Allow a device tree node to override the default addresses so that address conflicts with other devices on the same bus may be resolved at the board description level. Signed-off-by: Kieran Bingham --- .../bindings/display/bridge/adi,adv7511.txt| 10 +- >>> >>> I don't mind personally, but device tree maintainers usually ask for DT >>> bindings changes to be split to a separate patch. >>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 +++ drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 36 ++- 3 files changed, 37 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index 0047b1394c70..f6bb9f6d3f48 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -70,6 +70,9 @@ Optional properties: rather than generate its own timings for HDMI output. - clocks: from common clock binding: reference to the CEC clock. - clock-names: from common clock binding: must be "cec". +- reg-names : Names of maps with programmable addresses. + It can contain any map needing a non-default address. + Possible maps names are : "main", "edid", "cec", "packet" >>> >>> Is the reg-names property (and the additional maps) mandatory or optional >>> ? If mandatory you should also update the existing DT sources that use >>> those bindings. >> >> They are currently optional. I do prefer it that way - but perhaps due to an >> issue mentioned below we might need to make this driver mandatory ? >> >>> If optional you should define which I2C addresses will be used when >>> the maps are not specified (and in that case I think we should go for >>> the addresses listed as default in the datasheet, which correspond to the >>> current driver implementation when the main address is 0x3d/0x7a). >> >> The current addresses do not correspond to the datasheet, even when the >> implementation main address is set to 0x3d. > > Don't they ? The driver currently uses the following (8-bit) I2C addresses: > > EDID: main + 4 = 0x7e (0x3f) > Packet: main - 10 = 0x70 (0x38) > CEC:main - 2 = 0x78 (0x3c) > > Those are the default addresses according to section 4.1 of the ADV7511W > programming guide (rev. B), and they match the ones you set in this patch. Sorry - I was clearly subtracting 8bit values from a 7bit address in my failed assertion, to both you and Archit. >> Thus, in my opinion - they are currently 'wrong' - but perhaps changing them >> is considered breakage too. >> >> A particular issue will arise here too - as on this device - when the device >> is in low-power mode (after probe, before use) - the maps will respond on >> their *hardware default* addresses (the ones implemented in this patch), >> and thus consume that address on the I2C bus regardless of their settings >> in the driver. > > We've discussed this previously and I share you concern. Just to make sure I > remember correctly, did all the secondary maps reset to their default > addresses, or just the EDID map ? The following responds on the bus when programmed at alternative addresses, and in low power mode. The responses are all 0, but that's still going to conflict with other hardware if it tries to use the 'un-used' addresses. Packet (0x38), Main (0x39), Fixed (set to 0 by software, but shows up at 0x3e) and EDID (0x3f). So actually it's only the CEC which don't respond when in "low-power-mode". As far as I can see, (git grep -B3 adi,adv75) - The r8a7792-wheat.dts is the only instance of a device using 0x3d, which means that Sergei's patch changed the behaviour of all the existing devices before that. Thus - this patch could be seen to be a 'correction' back to the original behaviour for all devices except the Wheat, and possibly devices added after Sergei's patch went in. However - by my understanding, - any device which has only one ADV75(3,1)+ should use the hardware defined addresses (the hardware defaults will be conflicting on the bus anyway, thus should be assigned to the ADV7511) Any platform which uses *two* ADV7511 devices on the same bus should actually set *both* devices to use entirely separate addresses - or they will still conflict with each other. Now - if my understanding is correct - then I believe - that means that
Re: [PATCH] net: ethernet: ti: cpsw: fix net watchdog timeout
Rechecked once again, seems it covers every case, at this moment, so Reviewed-by: Ivan Khoronzhuk -- Regards, Ivan Khoronzhuk
Re: [PATCH v2] x86/retpoline: Add clang support
On Wed, Feb 07, 2018 at 10:28:38PM +, David Woodhouse wrote: > > > On Wed, 2018-02-07 at 13:52 -0800, Guenter Roeck wrote: > > clang has its own set of compiler options for retpoline support. > > > > Link: > > https://github.com/llvm-mirror/clang/commit/0d816739a82da29748caf88570affb9715e18b69 > > Link: > > https://github.com/llvm-mirror/llvm/commit/fd5a8723ce9f2a6b250e85972ef859e4253ea95d > > Link: > > https://github.com/llvm-mirror/llvm/commit/59b64490fda69d29bb42cfdf7eec37bcc31ff833 > > Cc: David Woodhouse > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > Cc: gno...@lxorguk.ukuu.org.uk > > Cc: Rik van Riel > > Cc: Andi Kleen > > Cc: Josh Poimboeuf > > Cc: thomas.lenda...@amd.com > > Cc: Peter Zijlstra > > Cc: Linus Torvalds > > Cc: Jiri Kosina > > Cc: Andy Lutomirski > > Cc: Dave Hansen > > Cc: Kees Cook > > Cc: Tim Chen > > Cc: Greg Kroah-Hartman > > Cc: Paul Turner > > Signed-off-by: Guenter Roeck > > --- > > v2: llvm has been updated to use the same thunk names as gcc. > > Tested with: > > clang version 7.0.0 > > (https://git.llvm.org/git/clang.git/ > > 848874aed95a913fb45f363120500cebfe54e2ef) > > (https://git.llvm.org/git/llvm.git/ > > 3afd566557f3616881505db0d69f5d19bf55ae14) > > cross-checked with gcc 7.3.0 (x86_64-linux-gcc.br_real (Buildroot > > 2018.02-rc1) 7.3.0). > > > > Tested with 64-bit builds only; 32-bit images fail to build with clang > > with various unrelated errors and are difficult to test. > > > > I had to change '+=' to '=' below since make otherwise sets > > RETPOLINE_CFLAGS to " ", and the subsequent ifneq would always match. > > This is also the reason for the "ifeq ($(RETPOLINE_CFLAGS),)". > > If there is another/different/better way to handle this, please let > > me know. > > See > http://git.infradead.org/users/dwmw2/linux-retpoline.git/commitdiff/82a1f41600 > You have __x86_indirect_thunk within #ifdef CONFIG_64BIT. I think it should be in the else case. Guenter
Re: [PATCH 04/14] kconfig: print additional new line for choice for redirection
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> If stdout is redirected to a file, prompts look differently due to
> missing new lines.
>
> Currently, conf_askvalue() takes care of this by putting additional
> new line, but conf_choice() does not. Do likewise so that prompts
> after 'choice' look properly.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/conf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index d346642..6ce06c8 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -317,6 +317,8 @@ static int conf_choice(struct menu *menu)
> case oldaskconfig:
> fflush(stdout);
> xfgets(line, sizeof(line), stdin);
> + if (!tty_stdio)
> + printf("\n");
> strip(line);
> if (line[0] == '?') {
> print_help(menu);
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
Maybe this could be moved into the xfgets() function as well.
Cheers,
Ulf
Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device
Hi Archit, On 07/02/18 12:33, Kieran Bingham wrote: > Hi Archit, > > Thank you for your review, > >>> unsigned int val; >>> int ret; >>> @@ -1153,24 +1151,35 @@ static int adv7511_probe(struct i2c_client *i2c, >>> const struct i2c_device_id *id) >>> if (ret) >>> goto uninit_regulators; >>> - regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, >>> edid_i2c_addr); >>> - regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR, >>> - main_i2c_addr - 0xa); > > > Packet address here is written as an offset of -0x0a, which gives 0x2f or > 0x33 ... ? > > I think these current offsets are platform specific to a specific platform :) I appear to be using platform specific maths specific to a non-conforming platform or universe :-) Sorry for the incorrect assertion here. - I mixed up 8bit and 7bit values. The offsets are valid (when calculated correctly) - however - as per my reply to Laurent - I believe the patch which determined the offsets was using the wrong base :). Also - due to a hardware issue on the ADV7511 - the Wheat (as the only known user of two chips on the same bus) will need to be updated to ensure the current assignments don't conflict. -- Kieran
Re: [PATCH 05/14] kconfig: remove 'config*' pattern from .gitignnore
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> I could not figure out why this pattern should be ignored.
> Checking commit 1e65174a3378 ("Add some basic .gitignore files")
> did not help.
>
> Let's remove this pattern, then see if it is really needed.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/.gitignore | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/scripts/kconfig/.gitignore b/scripts/kconfig/.gitignore
> index 51f1c87..a76856e 100644
> --- a/scripts/kconfig/.gitignore
> +++ b/scripts/kconfig/.gitignore
> @@ -1,7 +1,6 @@
> #
> # Generated files
> #
> -config*
> *.lex.c
> *.tab.c
> *.tab.h
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
Re: [PATCH 6/6] s390: introduce execute-trampolines for branches
2018-02-08 2:55 GMT+09:00 Linus Torvalds :
> On Wed, Feb 7, 2018 at 4:17 AM, Martin Schwidefsky
> wrote:
>>> That isn't, though. Linus asked us to drop the $(warning) part.
>>>
>>> ... and then spent a week building with a non-retpoline compiler and
>>> not noticing, so he might have changed his mind ;)
>>
>> I found the warning to have some value, it helps for the case where my
>> fingers are faster than my brain and I type "make" instead of "smake"
>> which uses the alternative compiler with the required support.
>>
>> @Linus: do you want a warning or prefer not to have one ?
>
> Honestly, I think I'd be much happier with the warning as part of the
> "make config" phase.
>
> What really annoyed me was that it showed up at every build.
>
> What I would really want - and this is entirely unrelated to this
> particular case - is to have those damn compiler option tests as part
> of the config phase in general. We now have about a million of these
> crazy things, where we have config options that simply depend on which
> compiler we have, and we have no sane way to show them at
> configuration time.
>
> Though Andrew's tree I got yet another ugly hack
> (CONFIG_CC_STACKPROTECTOR_AUTO) that handles just _one_ special case
> by turning it into a special magic Kconfig entry in the main Makefile.
> See commit 44c6dc940b19 ("Makefile: introduce
> CONFIG_CC_STACKPROTECTOR_AUTO"). I wasn't sure if I really wanted it,
> and honestly, I'm still thinking of just reverting it, because it's
> _so_ ugly and _so_ wrong.
>
> What we need is an extension to the Kconfig language itself so that we can do
>
>config CC_HAS_RETPOLINE
> cc_option "-mindirect-branch=thunk -mindirect-branch-table"
>
> or something. And then we can make sane _conditional_ dependencies at
> Kconfig time, and our makefiles would be much cleaner too when you
> could just do
>
> cflags-$(USE_RETPOLINE) += -mfunction-return=thunk
> -mindirect-branch-table
>
> because the validity of the C compiler flag has been tested when configuring.
>
> And then we could add that warning at configure time (or just disable
> the option there thanks to "depends on CC_HAS_xyz" logic).
>
> All our compiler option handling right now is just nasty nasty nasty crud.
>
> Adding more people in the hopes that somebody gets motivated.. I've
> talked about this before, so far we haven't made any progress.
Sorry for slow progress.
I agreed this before, and still motivated.
(because I also motivated to remove kbuild cache.
This turned out not so clever as I first thought)
I was trying to do this, but in this development cycle
I spent most of my time to flush out lots of piled up Kconfig patches.
Sorry.
Unless somebody is working, I will.
--
Best Regards
Masahiro Yamada
[PATCH] x86/xen: Calculate __max_logical_packages on PV domains
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava
Tested-and-reported-by: Simon Gaiser
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Dou Liyang
Cc: Prarit Bhargava
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: Andy Lutomirski
Cc: Andi Kleen
Cc: Vitaly Kuznetsov
Cc: xen-de...@lists.xenproject.org
---
arch/x86/include/asm/smp.h | 1 +
arch/x86/kernel/smpboot.c | 10 --
arch/x86/xen/smp.c | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 461f53d27708..a4189762b266 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -129,6 +129,7 @@ static inline void arch_send_call_function_ipi_mask(const
struct cpumask *mask)
void cpu_disable_common(void);
void native_smp_prepare_boot_cpu(void);
void native_smp_prepare_cpus(unsigned int max_cpus);
+void calculate_max_logical_packages(void);
void native_smp_cpus_done(unsigned int max_cpus);
void common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 6f27facbaa9b..767573b7f2db 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1281,11 +1281,10 @@ void __init native_smp_prepare_boot_cpu(void)
cpu_set_state_online(me);
}
-void __init native_smp_cpus_done(unsigned int max_cpus)
+void __init calculate_max_logical_packages(void)
{
int ncpus;
- pr_debug("Boot done\n");
/*
* Today neither Intel nor AMD support heterogenous systems so
* extrapolate the boot cpu's data to all packages.
@@ -1293,6 +1292,13 @@ void __init native_smp_cpus_done(unsigned int max_cpus)
ncpus = cpu_data(0).booted_cores * topology_max_smt_threads();
__max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
pr_info("Max logical packages: %u\n", __max_logical_packages);
+}
+
+void __init native_smp_cpus_done(unsigned int max_cpus)
+{
+ pr_debug("Boot done\n");
+
+ calculate_max_logical_packages();
if (x86_has_numa_in_package)
set_sched_topology(x86_numa_in_package_topology);
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 77c959cf81e7..7a43b2ae19f1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -122,6 +122,8 @@ void __init xen_smp_cpus_done(unsigned int max_cpus)
if (xen_hvm_domain())
native_smp_cpus_done(max_cpus);
+ else
+ calculate_max_logical_packages();
if (xen_have_vcpu_info_placement)
return;
--
2.15.0.rc0.39.g2f0e14e64
arch/x86/tools/insn_decoder_test: warning: 81002146: 0f ff 83 05 20 00 ac ud0 -0x53ffdffb(%ebx),%eax
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffefb181728f7b97df49ceba18cacfb6c5ee19f2 commit: 10c91577d5e631773a6394e14cf60125389b71ae x86/tools: Standardize output format of insn_decode_test date: 8 weeks ago config: i386-randconfig-x0-02071052 (attached as .config) compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010 reproduce: git checkout 10c91577d5e631773a6394e14cf60125389b71ae # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 8100077b: 0f ff 83 05 f0 eb ab ud0-0x54140ffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81001d5e: 0f ff 83 05 20 00 ac ud0-0x53ffdffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81001efe: 0f ff 83 05 20 00 ac ud0-0x53ffdffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. >> arch/x86/tools/insn_decoder_test: warning: 81002146: 0f ff 83 05 20 00 ac >> ud0-0x53ffdffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81002456: 0f ff 83 05 20 00 ac ud0-0x53ffdffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81002606: 0f ff 83 05 20 00 ac ud0-0x53ffdffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81003784: 0f ff 83 05 f0 0e ac ud0-0x53f10ffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 8100391e: 0f ff c7 ud0%edi,%eax arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81003a9e: 0f ff e9 ud0%ecx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81003cce: 0f ff eb ud0%ebx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81003e6e: 0f ff 83 05 f0 1f ac ud0-0x53e00ffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81004796: 0f ff eb ud0%ebx,%ebp arch/x86/tools/insn_decoder_test: warning: objdump says 3 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 810048b2: 0f ff 83 05 30 16 ac ud0-0x53e9cffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: 81006a3e: 0f ff 83 05 10 14 ac ud0-0x53ebeffb(%ebx),%eax arch/x86/tools/insn_decoder_test: warning: objdump says 7 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please
Re: [PATCH 08/14] kconfig: test: add basic 'choice' tests
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> The calculation of 'choice' is a bit complicated part in Kconfig.
>
> The behavior of 'y' choice is intuitive. If choice values are tristate,
> the choice can be 'm' where each value can be enabled independently.
> Also, if a choice is marked as 'optional', the whole choice can be
> invisible.
>
> Test basic functionality of choice.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/tests/choice/Kconfig | 54
> ++
> scripts/kconfig/tests/choice/__init__.py | 37 +++
> .../kconfig/tests/choice/alldef_expected_config| 5 ++
> .../kconfig/tests/choice/allmod_expected_config| 9
> scripts/kconfig/tests/choice/allno_expected_config | 5 ++
> .../kconfig/tests/choice/allyes_expected_config| 9
> .../kconfig/tests/choice/oldask0_expected_stdout | 10
> scripts/kconfig/tests/choice/oldask1_config| 2 +
> .../kconfig/tests/choice/oldask1_expected_stdout | 15 ++
> 9 files changed, 146 insertions(+)
> create mode 100644 scripts/kconfig/tests/choice/Kconfig
> create mode 100644 scripts/kconfig/tests/choice/__init__.py
> create mode 100644 scripts/kconfig/tests/choice/alldef_expected_config
> create mode 100644 scripts/kconfig/tests/choice/allmod_expected_config
> create mode 100644 scripts/kconfig/tests/choice/allno_expected_config
> create mode 100644 scripts/kconfig/tests/choice/allyes_expected_config
> create mode 100644 scripts/kconfig/tests/choice/oldask0_expected_stdout
> create mode 100644 scripts/kconfig/tests/choice/oldask1_config
> create mode 100644 scripts/kconfig/tests/choice/oldask1_expected_stdout
>
> diff --git a/scripts/kconfig/tests/choice/Kconfig
> b/scripts/kconfig/tests/choice/Kconfig
> new file mode 100644
> index 000..cc60e9c
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice/Kconfig
> @@ -0,0 +1,54 @@
> +config MODULES
> + bool "Enable loadable module support"
> + option modules
> + default y
> +
> +choice
> + prompt "boolean choice"
> + default BOOL_CHOICE1
> +
> +config BOOL_CHOICE0
> + bool "choice 0"
> +
> +config BOOL_CHOICE1
> + bool "choice 1"
> +
> +endchoice
> +
> +choice
> + prompt "optional boolean choice"
> + optional
> + default OPT_BOOL_CHOICE1
> +
> +config OPT_BOOL_CHOICE0
> + bool "choice 0"
> +
> +config OPT_BOOL_CHOICE1
> + bool "choice 1"
> +
> +endchoice
> +
> +choice
> + prompt "tristate choice"
> + default TRI_CHOICE1
> +
> +config TRI_CHOICE0
> + tristate "choice 0"
> +
> +config TRI_CHOICE1
> + tristate "choice 1"
> +
> +endchoice
> +
> +choice
> + prompt "optional tristate choice"
> + optional
> + default OPT_TRI_CHOICE1
> +
> +config OPT_TRI_CHOICE0
> + tristate "choice 0"
> +
> +config OPT_TRI_CHOICE1
> + tristate "choice 1"
> +
> +endchoice
> diff --git a/scripts/kconfig/tests/choice/__init__.py
> b/scripts/kconfig/tests/choice/__init__.py
> new file mode 100644
> index 000..42022ac
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice/__init__.py
> @@ -0,0 +1,37 @@
> +"""
> +Basic choice tests
> +==
> +
> +The handling of 'choice' is a bit complicated part in Kconfig.
> +
> +The behavior of 'y' choice is intuitive. If choice values are tristate,
> +the choice can be 'm' where each value can be enabled independently.
> +Also, if a choice is marked as 'optional', the whole choice can be
> +invisible.
> +
> +Test basic functionality of choice.
> +"""
> +
> +def test_oldask0(conf):
> +assert conf.oldaskconfig() == 0
> +assert conf.stdout_contains('oldask0_expected_stdout')
> +
> +def test_oldask1(conf):
> +assert conf.oldaskconfig('oldask1_config') == 0
> +assert conf.stdout_contains('oldask1_expected_stdout')
> +
> +def test_allyes(conf):
> +assert conf.allyesconfig() == 0
> +assert conf.config_contains('allyes_expected_config')
> +
> +def test_allmod(conf):
> +assert conf.allmodconfig() == 0
> +assert conf.config_contains('allmod_expected_config')
> +
> +def test_allno(conf):
> +assert conf.allnoconfig() == 0
> +assert conf.config_contains('allno_expected_config')
> +
> +def test_alldef(conf):
> +assert conf.alldefconfig() == 0
> +assert conf.config_contains('alldef_expected_config')
> diff --git a/scripts/kconfig/tests/choice/alldef_expected_config
> b/scripts/kconfig/tests/choice/alldef_expected_config
> new file mode 100644
> index 000..7a754bf
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice/alldef_expected_config
> @@ -0,0 +1,5 @@
> +CONFIG_MODULES=y
> +# CONFIG_BOOL_CHOICE0 is not set
> +CONFIG_BOOL_CHOICE1=y
> +# CONFIG_TRI_CHOICE0 is not set
> +# CONFIG_TRI_CHOICE1 is not set
> diff --git a/scripts/kconfig/tests/choice/allmod_expected_config
> b/scripts/kconfig/tests/choice/allmod_expected_config
> new file mode 100644
> index 000..f1f5dcd
> --- /dev/null
> +++ b/s
Re: [PATCH 09/14] kconfig: test: test automatic submenu creation
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> If a symbols has dependency on the preceding symbol, the menu entry
> should become the submenu of the preceding one, and displayed with
> deeper indentation.
>
> This is done by restructuring the menu tree in menu_finalize().
> It is a bit complicated computation, so let's add a test case.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> .../kconfig/tests/auto_submenu_creation/Kconfig| 50
> ++
> .../tests/auto_submenu_creation/__init__.py| 12 ++
> .../tests/auto_submenu_creation/expected_stdout| 10 +
> 3 files changed, 72 insertions(+)
> create mode 100644 scripts/kconfig/tests/auto_submenu_creation/Kconfig
> create mode 100644 scripts/kconfig/tests/auto_submenu_creation/__init__.py
> create mode 100644
> scripts/kconfig/tests/auto_submenu_creation/expected_stdout
>
> diff --git a/scripts/kconfig/tests/auto_submenu_creation/Kconfig
> b/scripts/kconfig/tests/auto_submenu_creation/Kconfig
> new file mode 100644
> index 000..9e11502
> --- /dev/null
> +++ b/scripts/kconfig/tests/auto_submenu_creation/Kconfig
> @@ -0,0 +1,50 @@
> +config A
> + bool "A"
> + default y
> +
> +config A0
> + bool "A0"
> + depends on A
> + default y
> + help
> + This depends on A, so should be a submenu of A.
> +
> +config A0_0
> + bool "A1_0"
> + depends on A0
> + help
> + Submenus are created recursively.
> + This should be a submenu of A0.
> +
> +config A1
> + bool "A1"
> + depends on A
> + default y
> + help
> + This should line up with A0.
> +
> +choice
> + prompt "choice"
> + depends on A1
> + help
> + Choice should become a submenu as well.
> +
> +config A1_0
> + bool "A1_0"
> +
> +config A1_1
> + bool "A1_1"
> +
> +endchoice
> +
> +config B
> + bool "B"
> + help
> + This is independent of A.
> +
> +config C
> + bool "C"
> + depends on A
> + help
> + This depends on A, but not a consecutive item, so should not
> + be a submenu.
> diff --git a/scripts/kconfig/tests/auto_submenu_creation/__init__.py
> b/scripts/kconfig/tests/auto_submenu_creation/__init__.py
> new file mode 100644
> index 000..dda866d
> --- /dev/null
> +++ b/scripts/kconfig/tests/auto_submenu_creation/__init__.py
> @@ -0,0 +1,12 @@
> +"""
> +Create submenu for symbols that depend on the preceding one
> +===
> +
> +If a symbols has dependency on the preceding symbol, the menu entry
> +should become the submenu of the preceding one, and displayed with
> +deeper indentation.
> +"""
> +
> +def test(conf):
> +assert conf.oldaskconfig() == 0
> +assert conf.stdout_contains('expected_stdout')
> diff --git a/scripts/kconfig/tests/auto_submenu_creation/expected_stdout
> b/scripts/kconfig/tests/auto_submenu_creation/expected_stdout
> new file mode 100644
> index 000..bf5236f
> --- /dev/null
> +++ b/scripts/kconfig/tests/auto_submenu_creation/expected_stdout
> @@ -0,0 +1,10 @@
> +A (A) [Y/n/?] (NEW)
> + A0 (A0) [Y/n/?] (NEW)
> +A1_0 (A0_0) [N/y/?] (NEW)
> + A1 (A1) [Y/n/?] (NEW)
> +choice
> +> 1. A1_0 (A1_0) (NEW)
> + 2. A1_1 (A1_1) (NEW)
> +choice[1-2?]:
> +B (B) [N/y/?] (NEW)
> +C (C) [N/y/?] (NEW)
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
[PATCH] mmc: core: optimize mmc_calc_max_discard
If the max_discard value is zero, the conditional branch that checks the
trim capabilities will never update this value with max_trim.
Change the condition statement to also check the max_discard value in order
to avoid an unnecessary call to mmc_do_calc_max_discard.
Signed-off-by: Sergio Valverde
---
drivers/mmc/core/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 1f0f44f..97856b1 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2567,7 +2567,7 @@ unsigned int mmc_calc_max_discard(struct mmc_card *card)
return card->pref_erase;
max_discard = mmc_do_calc_max_discard(card, MMC_ERASE_ARG);
- if (mmc_can_trim(card)) {
+ if (mmc_can_trim(card) && max_discard) {
max_trim = mmc_do_calc_max_discard(card, MMC_TRIM_ARG);
if (max_trim < max_discard)
max_discard = max_trim;
--
2.7.4
Re: [PATCH v5 4/4] irqchip/gic-v3-its: add ability to resend MAPC on resume
On Wed, Feb 7, 2018 at 3:22 PM, Brian Norris wrote: > Hi Marc, > > I'm really not an expert on this, so take my observations with a large > grain of salt: > > On Wed, Feb 07, 2018 at 08:46:42AM +, Marc Zyngier wrote: >> On 07/02/18 01:41, Derek Basehore wrote: >> > This adds functionality to resend the MAPC command to an ITS node on >> > resume. If the ITS is powered down during suspend and the collections >> > are not backed by memory, the ITS will lose that state. This just sets >> > up the known state for the collections after the ITS is restored. >> > >> > This is enabled via the reset-on-suspend flag in the DTS for an ITS >> > that has a non-zero number of collections stored in it. >> > >> > Signed-off-by: Derek Basehore >> > --- >> > drivers/irqchip/irq-gic-v3-its.c | 80 >> > -- >> > include/linux/irqchip/arm-gic-v3.h | 1 + >> > 2 files changed, 43 insertions(+), 38 deletions(-) >> > >> > diff --git a/drivers/irqchip/irq-gic-v3-its.c >> > b/drivers/irqchip/irq-gic-v3-its.c >> > index 5e63635e2a7b..dd6cd6e68ed0 100644 >> > --- a/drivers/irqchip/irq-gic-v3-its.c >> > +++ b/drivers/irqchip/irq-gic-v3-its.c >> > @@ -1942,52 +1942,53 @@ static void its_cpu_init_lpis(void) >> > dsb(sy); >> > } >> > >> > -static void its_cpu_init_collection(void) >> > +static void its_cpu_init_collection(struct its_node *its) > > ... > >> > @@ -3127,6 +3128,9 @@ static void its_restore_enable(void) >> > its_write_baser(its, baser, baser->val); >> > } >> > writel_relaxed(its->ctlr_save, base + GITS_CTLR); >> > + >> > + if (GITS_TYPER_HWCOLLCNT(gic_read_typer(base + GITS_TYPER)) > >> > 0) >> > + its_cpu_init_collection(its); >> >> This isn't correct. Think of a system where half the collections are in >> HW, and the other half memory based (nothing in the spec forbids this). >> You must evaluate the CID of each collection and replay the MAPC *only* >> if it falls into the range [0..HCC-1]. The memory-based collections are >> already mapped, and remapping an already mapped collection requires >> extra care (see MAPC and the UNPREDICTABLE behaviour when V=1), so don't >> go there. > > IIUC, this is only run on CPU0 (it's in syscore resume), so implicitly, > CID is 0. Thus, the current condition is already doing what you ask: > > HCC > 0 == CID > > which is equivalent to: > > HCC - 1 >= CID > > Or should we really double check what CPU we're running on? There seems to be the edge case where you hotplug CPU 0 before suspending. In that case, I believe you're on the lowest number CPU left? It seems that all of the CPUs that are disabled have the ITS reinitialized from scratch via enable_nonboot_cpus(). This code runs on only the CPU that firmware resumes with. If that CPU isn't CPU 0 for whatever reason, we need to make sure that it's processor ID is less than HCC. > > Brian
Re: [PATCH 6/6] s390: introduce execute-trampolines for branches
On Wed, Feb 7, 2018 at 3:44 PM, Masahiro Yamada wrote: > > I agreed this before, and still motivated. > (because I also motivated to remove kbuild cache. I actually wish I still had my old "run shell script" thing. I had some very preliminary patches that actually worked for simple things, and you could do something like config SOME_NAME bool option shell "true" and it would act basically like "option env", except it didn't do "getenv()", it did "system()" and checked the return value. So the above would make SOME_NAME have the value 'y', because when you executed "true" it was successful. I have this dim memory of allowing it to set strings too (filling in the default value with the stdout output from the shell execution). So I had some experimental patch like that, and it kind of worked, but I never finished it. But the reason I never completed it was that for the compiler option case, it really wanted more than a shell command, it needed to get the whole $(CC) etc from the make environment. I don't remember the exact syntax I used, but I think it was based on that "option env" syntax, just replacing "env" with "shell". But searching my mail archives I can't find anything, so I may never have sent anything out. And so the patch is long gone. Maybe I'll get frustrated enough and try to recreate it. I don't think the patch was that big (but as mentioned, it really wasn't in a form where it was _useful_ yet). Linus
Re: [PATCH 10/14] kconfig: test: check if new symbols in choice are asked
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> If new choice values are added with new dependency, and they become
> visible during user configuration, oldconfig should recognize them
> as (NEW), and ask the user for choice.
>
> This issue was fixed by commit 5d09598d488f ("kconfig: fix new choices
> being skipped upon config update").
>
> This is a subtle corner case. Add a test case to avoid breakage.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/tests/new_choice_with_dep/Kconfig | 37
> ++
> .../kconfig/tests/new_choice_with_dep/__init__.py | 14
> scripts/kconfig/tests/new_choice_with_dep/config | 3 ++
> .../tests/new_choice_with_dep/expected_stdout | 10 ++
> 4 files changed, 64 insertions(+)
> create mode 100644 scripts/kconfig/tests/new_choice_with_dep/Kconfig
> create mode 100644 scripts/kconfig/tests/new_choice_with_dep/__init__.py
> create mode 100644 scripts/kconfig/tests/new_choice_with_dep/config
> create mode 100644 scripts/kconfig/tests/new_choice_with_dep/expected_stdout
>
> diff --git a/scripts/kconfig/tests/new_choice_with_dep/Kconfig
> b/scripts/kconfig/tests/new_choice_with_dep/Kconfig
> new file mode 100644
> index 000..53ef1b8
> --- /dev/null
> +++ b/scripts/kconfig/tests/new_choice_with_dep/Kconfig
> @@ -0,0 +1,37 @@
> +config A
> + bool "A"
> + help
> + This is a new symbol.
> +
> +choice
> + prompt "Choice ?"
> + depends on A
> + help
> + "depends on A" has been newly added.
> +
> +config CHOICE_B
> + bool "Choice B"
> +
> +config CHOICE_C
> + bool "Choice C"
> + help
> + This is a new symbol, so should be asked.
> +
> +endchoice
> +
> +choice
> + prompt "Choice2 ?"
> +
> +config CHOICE_D
> + bool "Choice D"
> +
> +config CHOICE_E
> + bool "Choice E"
> +
> +config CHOICE_F
> + bool "Choice F"
> + depends on A
> + help
> + This is a new symbol, so should be asked.
> +
> +endchoice
> diff --git a/scripts/kconfig/tests/new_choice_with_dep/__init__.py
> b/scripts/kconfig/tests/new_choice_with_dep/__init__.py
> new file mode 100644
> index 000..4306ccf
> --- /dev/null
> +++ b/scripts/kconfig/tests/new_choice_with_dep/__init__.py
> @@ -0,0 +1,14 @@
> +"""
> +Ask new choice values when they become visible
> +==
> +
> +If new choice values are added with new dependency, and they become
> +visible during user configuration, oldconfig should recognize them
> +as (NEW), and ask the user for choice.
> +
> +Related Linux commit: 5d09598d488f081e3be23f885ed65cbbe2d073b5
> +"""
> +
> +def test(conf):
> +assert conf.oldconfig('config', 'y') == 0
> +assert conf.stdout_contains('expected_stdout')
> diff --git a/scripts/kconfig/tests/new_choice_with_dep/config
> b/scripts/kconfig/tests/new_choice_with_dep/config
> new file mode 100644
> index 000..47ef95d
> --- /dev/null
> +++ b/scripts/kconfig/tests/new_choice_with_dep/config
> @@ -0,0 +1,3 @@
> +CONFIG_CHOICE_B=y
> +# CONFIG_CHOICE_D is not set
> +CONFIG_CHOICE_E=y
> diff --git a/scripts/kconfig/tests/new_choice_with_dep/expected_stdout
> b/scripts/kconfig/tests/new_choice_with_dep/expected_stdout
> new file mode 100644
> index 000..358d5cf
> --- /dev/null
> +++ b/scripts/kconfig/tests/new_choice_with_dep/expected_stdout
> @@ -0,0 +1,10 @@
> +A (A) [N/y/?] (NEW)
> + Choice ?
> + > 1. Choice B (CHOICE_B)
> +2. Choice C (CHOICE_C) (NEW)
> + choice[1-2?]:
> +Choice2 ?
> + 1. Choice D (CHOICE_D)
> +> 2. Choice E (CHOICE_E)
> + 3. Choice F (CHOICE_F) (NEW)
> +choice[1-3?]:
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
Re: [PATCH 11/14] kconfig: test: check .config sanity for choice values with unmet dep
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> I fixed a problem where "# CONFIG_..." for choice values are wrongly
> written into the .config file when they are once visible, then become
> invisible later.
>
> Add a test for this subtle case.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/tests/no_write_if_dep_unmet/Kconfig | 14 ++
> scripts/kconfig/tests/no_write_if_dep_unmet/__init__.py | 17
> +
> scripts/kconfig/tests/no_write_if_dep_unmet/config | 1 +
> .../kconfig/tests/no_write_if_dep_unmet/expected_config | 5 +
> 4 files changed, 37 insertions(+)
> create mode 100644 scripts/kconfig/tests/no_write_if_dep_unmet/Kconfig
> create mode 100644 scripts/kconfig/tests/no_write_if_dep_unmet/__init__.py
> create mode 100644 scripts/kconfig/tests/no_write_if_dep_unmet/config
> create mode 100644
> scripts/kconfig/tests/no_write_if_dep_unmet/expected_config
>
> diff --git a/scripts/kconfig/tests/no_write_if_dep_unmet/Kconfig
> b/scripts/kconfig/tests/no_write_if_dep_unmet/Kconfig
> new file mode 100644
> index 000..c00b8fe
> --- /dev/null
> +++ b/scripts/kconfig/tests/no_write_if_dep_unmet/Kconfig
> @@ -0,0 +1,14 @@
> +config A
> + bool "A"
> +
> +choice
> + prompt "Choice ?"
> + depends on A
> +
> +config CHOICE_B
> + bool "Choice B"
> +
> +config CHOICE_C
> + bool "Choice C"
> +
> +endchoice
> diff --git a/scripts/kconfig/tests/no_write_if_dep_unmet/__init__.py
> b/scripts/kconfig/tests/no_write_if_dep_unmet/__init__.py
> new file mode 100644
> index 000..d096622
> --- /dev/null
> +++ b/scripts/kconfig/tests/no_write_if_dep_unmet/__init__.py
> @@ -0,0 +1,17 @@
> +"""
> +Do not write choice values to .config if the dependency is unmet
> +
> +
> +"# CONFIG_... is not set" should not be written into the .config file
> +for symbols with unmet dependency.
> +
> +This was not working correctly for choice values because choice needs
> +a bit different symbol computation.
> +
> +This checks that no unneeded "# COFIG_... is not set" is contained in
> +the .config file.
> +"""
> +
> +def test(conf):
> +assert conf.oldaskconfig('config', 'n') == 0
> +assert conf.config_matches('expected_config')
> diff --git a/scripts/kconfig/tests/no_write_if_dep_unmet/config
> b/scripts/kconfig/tests/no_write_if_dep_unmet/config
> new file mode 100644
> index 000..abd280e
> --- /dev/null
> +++ b/scripts/kconfig/tests/no_write_if_dep_unmet/config
> @@ -0,0 +1 @@
> +CONFIG_A=y
> diff --git a/scripts/kconfig/tests/no_write_if_dep_unmet/expected_config
> b/scripts/kconfig/tests/no_write_if_dep_unmet/expected_config
> new file mode 100644
> index 000..0d15e41
> --- /dev/null
> +++ b/scripts/kconfig/tests/no_write_if_dep_unmet/expected_config
> @@ -0,0 +1,5 @@
> +#
> +# Automatically generated file; DO NOT EDIT.
> +# Linux Kernel Configuration
> +#
> +# CONFIG_A is not set
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
This indirectly tests that choices specified without a type get the
type of the first choice value specified with a type too.
Cheers,
Ulf
Re: [PATCH 12/14] kconfig: test: check visibility of tristate choice values in y choice
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> If tristate choice values depend on symbols set to 'm', they should be
> hidden when the choice containing them is changed from 'm' to 'y'
> (i.e. exclusive choice).
>
> This issue was fixed by commit fa64e5f6a35e ("kconfig/symbol.c: handle
> choice_values that depend on 'm' symbols").
>
> Add a test case to avoid regression.
>
> For the input in this unit test, there is a room for argument if
> "# CONFIG_CHOICE1 is not set" should be written to the .config file.
>
> After commit fa64e5f6a35e, this line was written to the .config file.
>
> Then, it is not written after my fix "kconfig: do not write choice
> values when their dependency becomes n".
>
> In this test, "# CONFIG_CHOICE1 is not set" is don't care.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> .../kconfig/tests/choice_value_with_m_dep/Kconfig| 20
>
> .../tests/choice_value_with_m_dep/__init__.py| 15 +++
> scripts/kconfig/tests/choice_value_with_m_dep/config | 2 ++
> .../tests/choice_value_with_m_dep/expected_config| 3 +++
> .../tests/choice_value_with_m_dep/expected_stdout| 4
> 5 files changed, 44 insertions(+)
> create mode 100644 scripts/kconfig/tests/choice_value_with_m_dep/Kconfig
> create mode 100644 scripts/kconfig/tests/choice_value_with_m_dep/__init__.py
> create mode 100644 scripts/kconfig/tests/choice_value_with_m_dep/config
> create mode 100644
> scripts/kconfig/tests/choice_value_with_m_dep/expected_config
> create mode 100644
> scripts/kconfig/tests/choice_value_with_m_dep/expected_stdout
>
> diff --git a/scripts/kconfig/tests/choice_value_with_m_dep/Kconfig
> b/scripts/kconfig/tests/choice_value_with_m_dep/Kconfig
> new file mode 100644
> index 000..dbc49e2
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice_value_with_m_dep/Kconfig
> @@ -0,0 +1,20 @@
> +config MODULES
> + bool
> + default y
> + option modules
> +
> +config DEP
> + tristate
> + default m
> +
> +choice
> + prompt "Tristate Choice"
> +
> +config CHOICE0
> + tristate "Choice 0"
> +
> +config CHOICE1
> + tristate "Choice 1"
> + depends on DEP
> +
> +endchoice
> diff --git a/scripts/kconfig/tests/choice_value_with_m_dep/__init__.py
> b/scripts/kconfig/tests/choice_value_with_m_dep/__init__.py
> new file mode 100644
> index 000..ec71777
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice_value_with_m_dep/__init__.py
> @@ -0,0 +1,15 @@
> +"""
> +Hide tristate choice values with mod dependency in y choice
> +===
> +
> +If tristate choice values depend on symbols set to 'm', they should be
> +hidden when the choice containing them is changed from 'm' to 'y'
> +(i.e. exclusive choice).
> +
> +Related Linux commit: fa64e5f6a35efd5e77d639125d973077ca506074
> +"""
> +
> +def test(conf):
> +assert conf.oldaskconfig('config', 'y') == 0
> +assert conf.config_contains('expected_config')
> +assert conf.stdout_contains('expected_stdout')
> diff --git a/scripts/kconfig/tests/choice_value_with_m_dep/config
> b/scripts/kconfig/tests/choice_value_with_m_dep/config
> new file mode 100644
> index 000..3a126b7
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice_value_with_m_dep/config
> @@ -0,0 +1,2 @@
> +CONFIG_CHOICE0=m
> +CONFIG_CHOICE1=m
> diff --git a/scripts/kconfig/tests/choice_value_with_m_dep/expected_config
> b/scripts/kconfig/tests/choice_value_with_m_dep/expected_config
> new file mode 100644
> index 000..4d07b44
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice_value_with_m_dep/expected_config
> @@ -0,0 +1,3 @@
> +CONFIG_MODULES=y
> +CONFIG_DEP=m
> +CONFIG_CHOICE0=y
> diff --git a/scripts/kconfig/tests/choice_value_with_m_dep/expected_stdout
> b/scripts/kconfig/tests/choice_value_with_m_dep/expected_stdout
> new file mode 100644
> index 000..5eac85d
> --- /dev/null
> +++ b/scripts/kconfig/tests/choice_value_with_m_dep/expected_stdout
> @@ -0,0 +1,4 @@
> +Tristate Choice [M/y/?]
> +Tristate Choice
> +> 1. Choice 0 (CHOICE0)
> +choice[1]: 1
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
Re: [PATCH 13/14] kconfig: test: check if recursive dependencies are detected
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> Recursive dependency should be detected and warned. Test this.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/tests/warn_recursive_dep/Kconfig | 62
> ++
> .../kconfig/tests/warn_recursive_dep/__init__.py | 10
> .../tests/warn_recursive_dep/expected_stderr | 33
> 3 files changed, 105 insertions(+)
> create mode 100644 scripts/kconfig/tests/warn_recursive_dep/Kconfig
> create mode 100644 scripts/kconfig/tests/warn_recursive_dep/__init__.py
> create mode 100644 scripts/kconfig/tests/warn_recursive_dep/expected_stderr
>
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/Kconfig
> b/scripts/kconfig/tests/warn_recursive_dep/Kconfig
> new file mode 100644
> index 000..9ab2474
> --- /dev/null
> +++ b/scripts/kconfig/tests/warn_recursive_dep/Kconfig
> @@ -0,0 +1,62 @@
> +# depends on itself
> +
> +config A
> + bool "A"
> + depends on A
> +
> +# select itself
> +
> +config B
> + bool
> + select B
> +
> +# depends on each other
> +
> +config C1
> + bool "C1
Missing end quote here. Noticed because the output contains
"Kconfig:16:warning: multi-line strings not supported". :)
> + depends on C2
> +
> +config C2
> + bool "C2"
> + depends on C1
> +
> +# depends on and select
> +
> +config D1
> + bool "D1"
> + depends on D2
> + select D2
> +
> +config D2
> + bool
> +
> +# depends on and imply
> +# This is not recursive dependency
> +
> +config E1
> + bool "E1"
> + depends on E2
> + imply E2
> +
> +config E2
> + bool "E2"
> +
> +# property
> +
> +config F1
> + bool "F1"
> + default F2
> +
> +config F2
> + bool "F2"
> + depends on F1
> +
> +# menu
> +
> +menu "menu depending on its content"
> + depends on G
> +
> +config G
> + bool "G"
> +
> +endmenu
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> b/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> new file mode 100644
> index 000..cdf2c13
> --- /dev/null
> +++ b/scripts/kconfig/tests/warn_recursive_dep/__init__.py
> @@ -0,0 +1,10 @@
> +"""
> +Warn recursive inclusion
> +
> +
> +Recursive dependency should be warned.
> +"""
> +
> +def test(conf):
> +assert conf.oldaskconfig() == 0
> +assert conf.stderr_contains('expected_stderr')
> diff --git a/scripts/kconfig/tests/warn_recursive_dep/expected_stderr
> b/scripts/kconfig/tests/warn_recursive_dep/expected_stderr
> new file mode 100644
> index 000..ea47cae
> --- /dev/null
> +++ b/scripts/kconfig/tests/warn_recursive_dep/expected_stderr
> @@ -0,0 +1,33 @@
> +Kconfig:16:warning: multi-line strings not supported
> +Kconfig:9:error: recursive dependency detected!
> +Kconfig:9: symbol B is selected by B
> +For a resolution refer to Documentation/kbuild/kconfig-language.txt
> +subsection "Kconfig recursive dependency limitations"
> +
> +Kconfig:3:error: recursive dependency detected!
> +Kconfig:3: symbol A depends on A
> +For a resolution refer to Documentation/kbuild/kconfig-language.txt
> +subsection "Kconfig recursive dependency limitations"
> +
> +Kconfig:15:error: recursive dependency detected!
> +Kconfig:15:symbol C1 depends on C2
> +Kconfig:19:symbol C2 depends on C1
> +For a resolution refer to Documentation/kbuild/kconfig-language.txt
> +subsection "Kconfig recursive dependency limitations"
> +
> +Kconfig:30:error: recursive dependency detected!
> +Kconfig:30:symbol D2 is selected by D1
> +Kconfig:25:symbol D1 depends on D2
> +For a resolution refer to Documentation/kbuild/kconfig-language.txt
> +subsection "Kconfig recursive dependency limitations"
> +
> +Kconfig:59:error: recursive dependency detected!
> +Kconfig:59:symbol G depends on G
> +For a resolution refer to Documentation/kbuild/kconfig-language.txt
> +subsection "Kconfig recursive dependency limitations"
> +
> +Kconfig:50:error: recursive dependency detected!
> +Kconfig:50:symbol F2 depends on F1
> +Kconfig:48:symbol F1 default value contains F2
> +For a resolution refer to Documentation/kbuild/kconfig-language.txt
> +subsection "Kconfig recursive dependency limitations"
> --
> 2.7.4
>
Besides the missing end quote:
Reviewed-by: Ulf Magnusson
Re: [PATCH 14/14] kconfig: test: check if recursive inclusion is detected
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> If recursive inclusion is detected, it should fail with error messages.
> Test this.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/tests/err_recursive_inc/Kconfig | 1 +
> scripts/kconfig/tests/err_recursive_inc/Kconfig.inc | 1 +
> scripts/kconfig/tests/err_recursive_inc/__init__.py | 10 ++
> scripts/kconfig/tests/err_recursive_inc/expected_stderr | 4
> 4 files changed, 16 insertions(+)
> create mode 100644 scripts/kconfig/tests/err_recursive_inc/Kconfig
> create mode 100644 scripts/kconfig/tests/err_recursive_inc/Kconfig.inc
> create mode 100644 scripts/kconfig/tests/err_recursive_inc/__init__.py
> create mode 100644 scripts/kconfig/tests/err_recursive_inc/expected_stderr
>
> diff --git a/scripts/kconfig/tests/err_recursive_inc/Kconfig
> b/scripts/kconfig/tests/err_recursive_inc/Kconfig
> new file mode 100644
> index 000..3ce7a3f
> --- /dev/null
> +++ b/scripts/kconfig/tests/err_recursive_inc/Kconfig
> @@ -0,0 +1 @@
> +source "Kconfig.inc"
> diff --git a/scripts/kconfig/tests/err_recursive_inc/Kconfig.inc
> b/scripts/kconfig/tests/err_recursive_inc/Kconfig.inc
> new file mode 100644
> index 000..1fab1c1
> --- /dev/null
> +++ b/scripts/kconfig/tests/err_recursive_inc/Kconfig.inc
> @@ -0,0 +1 @@
> +source "Kconfig"
> diff --git a/scripts/kconfig/tests/err_recursive_inc/__init__.py
> b/scripts/kconfig/tests/err_recursive_inc/__init__.py
> new file mode 100644
> index 000..1dae64f
> --- /dev/null
> +++ b/scripts/kconfig/tests/err_recursive_inc/__init__.py
> @@ -0,0 +1,10 @@
> +"""
> +Detect recursive inclusion error
> +
> +
> +If recursive inclusion is detected, it should fail with error messages.
> +"""
> +
> +def test(conf):
> +assert conf.oldaskconfig() != 0
> +assert conf.stderr_contains('expected_stderr')
> diff --git a/scripts/kconfig/tests/err_recursive_inc/expected_stderr
> b/scripts/kconfig/tests/err_recursive_inc/expected_stderr
> new file mode 100644
> index 000..b256c91
> --- /dev/null
> +++ b/scripts/kconfig/tests/err_recursive_inc/expected_stderr
> @@ -0,0 +1,4 @@
> +Kconfig:1: recursive inclusion detected. Inclusion path:
> + current file : 'Kconfig'
> + included from: 'Kconfig.inc:1'
> + included from: 'Kconfig:3'
> --
> 2.7.4
>
Reviewed-by: Ulf Magnusson
Re: [PATCH 06/10] perf tools: Use machine__set_kernel_mmap instead of map_groups__fixup_end
Hi Jiri,
On Wed, Feb 07, 2018 at 03:48:34PM +0100, Jiri Olsa wrote:
> The machine__set_kernel_mmap does the same job as map_groups__fixup_end
> when used on kernel maps within machine__create_kernel_maps call.
I'm not sure. Modules have end address after machine__create_module()
but vmlinux_maps is not. So map_groups__fixup() will set the end of
vmlinux_maps but with this change it will have ~0ULL.
Thanks,
Namhyung
>
> This way we can also remove map_groups__fixup_end function, because there's
> no user to it. Also moving machine__set_kernel_mmap up in code, so we don't
> need forward declaration.
>
> Link: http://lkml.kernel.org/n/tip-9kqrs3bsojwe4ktwpnkxc...@git.kernel.org
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/util/machine.c | 49
> ++-
> 1 file changed, 19 insertions(+), 30 deletions(-)
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 7563b750137d..49ebd451151a 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1028,13 +1028,6 @@ int machine__load_vmlinux_path(struct machine
> *machine, enum map_type type)
> return ret;
> }
>
> -static void map_groups__fixup_end(struct map_groups *mg)
> -{
> - int i;
> - for (i = 0; i < MAP__NR_TYPES; ++i)
> - __map_groups__fixup_end(mg, i);
> -}
> -
> static char *get_kernel_version(const char *root_dir)
> {
> char version[PATH_MAX];
> @@ -1220,6 +1213,24 @@ static int machine__create_modules(struct machine
> *machine)
> return 0;
> }
>
> +static void machine__set_kernel_mmap(struct machine *machine,
> + u64 start, u64 end)
> +{
> + int i;
> +
> + for (i = 0; i < MAP__NR_TYPES; i++) {
> + machine->vmlinux_maps[i]->start = start;
> + machine->vmlinux_maps[i]->end = end;
> +
> + /*
> + * Be a bit paranoid here, some perf.data file came with
> + * a zero sized synthesized MMAP event for the kernel.
> + */
> + if (machine->vmlinux_maps[i]->end == 0)
> + machine->vmlinux_maps[i]->end = ~0ULL;
> + }
> +}
> +
> int machine__create_kernel_maps(struct machine *machine)
> {
> struct dso *kernel = machine__get_kernel(machine);
> @@ -1244,11 +1255,6 @@ int machine__create_kernel_maps(struct machine
> *machine)
>"continuing anyway...\n", machine->pid);
> }
>
> - /*
> - * Now that we have all the maps created, just set the ->end of them:
> - */
> - map_groups__fixup_end(&machine->kmaps);
> -
> if (!machine__get_running_kernel_start(machine, &name, &addr)) {
> if (name &&
> maps__set_kallsyms_ref_reloc_sym(machine->vmlinux_maps,
> name, addr)) {
> @@ -1257,27 +1263,10 @@ int machine__create_kernel_maps(struct machine
> *machine)
> }
> }
>
> + machine__set_kernel_mmap(machine, addr, 0);
> return 0;
> }
>
> -static void machine__set_kernel_mmap(struct machine *machine,
> - u64 start, u64 end)
> -{
> - int i;
> -
> - for (i = 0; i < MAP__NR_TYPES; i++) {
> - machine->vmlinux_maps[i]->start = start;
> - machine->vmlinux_maps[i]->end = end;
> -
> - /*
> - * Be a bit paranoid here, some perf.data file came with
> - * a zero sized synthesized MMAP event for the kernel.
> - */
> - if (machine->vmlinux_maps[i]->end == 0)
> - machine->vmlinux_maps[i]->end = ~0ULL;
> - }
> -}
> -
> static bool machine__uses_kcore(struct machine *machine)
> {
> struct dso *dso;
> --
> 2.13.6
>
Re: [PATCH 07/14] kconfig: test: add framework for Kconfig unit-tests
On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
wrote:
> I admit various parts in Kconfig are cryptic and need refactoring,
> but at the same time, I fear regressions.
>
> There are several subtle corner cases where it is difficult to notice
> breakage. It is time to add unit-tests.
>
> Here is a simple framework based on pytest. The conftest.py provides
> a fixture useful to run commands such as 'oldaskconfig' etc. and
> to compare the resulted .config, stdout, stderr with expectations.
>
> How to add test cases?
> --
>
> For each test case, you should create a subdirectory under
> scripts/kconfig/tests/ (so test cases are seperated from each other).
> Every test case directory must contain the following files:
>
> - __init__.py: describes test functions
> - Kconfig: the top level Kconfig file for this test
>
> To do a useful job, test cases generally need additional data like
> input .config and information about expected results.
>
> How to run tests?
> -
>
> You need python3 and pytest. Then, run "make testconfig".
> O= option is supported. If V=1 is given, details logs during tests
> are displayed.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/Makefile | 8 ++
> scripts/kconfig/tests/conftest.py | 255
> ++
> scripts/kconfig/tests/pytest.ini | 6 +
> 3 files changed, 269 insertions(+)
> create mode 100644 scripts/kconfig/tests/conftest.py
> create mode 100644 scripts/kconfig/tests/pytest.ini
>
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index cb3ec53..c5d1d1a 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -135,6 +135,14 @@ PHONY += tinyconfig
> tinyconfig:
> $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
>
> +# CHECK: -o cache_dir= working?
> +PHONY += testconfig
> +testconfig: $(obj)/conf
> + $(PYTHON3) -B -m pytest $(srctree)/$(src)/tests \
> + -o cache_dir=$(abspath $(obj)/tests/.cache) \
> + $(if $(findstring 1,$(KBUILD_VERBOSE)),--capture=no)
> +clean-dirs += tests/.cache
> +
> # Help text used by make help
> help:
> @echo ' config - Update current config utilising a
> line-oriented program'
> diff --git a/scripts/kconfig/tests/conftest.py
> b/scripts/kconfig/tests/conftest.py
> new file mode 100644
> index 000..f0f3237
> --- /dev/null
> +++ b/scripts/kconfig/tests/conftest.py
> @@ -0,0 +1,255 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Copyright (C) 2018 Masahiro Yamada
> +#
> +
> +import os
> +import pytest
> +import shutil
> +import subprocess
> +import tempfile
> +
> +conf_path = os.path.abspath(os.path.join('scripts', 'kconfig', 'conf'))
> +
> +class Conf:
> +
> +def __init__(self, request):
> +"""Create a new Conf object, which is a scripts/kconfig/conf
> +runner and result checker.
> +
> +Arguments:
> +request - object to introspect the requesting test module
> +"""
> +
> +# the directory of the test being run
> +self.test_dir = os.path.dirname(str(request.fspath))
> +
> +def __run_conf(self, mode, dot_config=None, out_file='.config',
> + interactive=False, in_keys=None, extra_env={}):
> +"""Run scripts/kconfig/conf
> +
> +mode: input mode option (--oldaskconfig, --defconfig= etc.)
> +dot_config: the .config file for input.
> +out_file: file name to contain the output config data.
> +interactive: flag to specify the interactive mode.
> +in_keys: key inputs for interactive modes.
> +extra_env: additional environment.
> +"""
> +
> +command = [conf_path, mode, 'Kconfig']
> +
> +# Override 'srctree' environment to make the test as the top
> directory
> +extra_env['srctree'] = self.test_dir
> +
> +# scripts/kconfig/conf is run in a temporary directory.
> +# This directory is automatically removed when done.
> +with tempfile.TemporaryDirectory() as temp_dir:
> +
> +# if .config is given, copy it to the working directory
> +if dot_config:
> +shutil.copyfile(os.path.join(self.test_dir, dot_config),
> +os.path.join(temp_dir, '.config'))
> +
> +ps = subprocess.Popen(command,
> + stdin=subprocess.PIPE,
> + stdout=subprocess.PIPE,
> + stderr=subprocess.PIPE,
> + cwd=temp_dir,
> + env=dict(os.environ, **extra_env))
> +
> +# If user key input is specified, feed it into stdin.
> +if in_keys:
> +ps.stdin.write(in_keys.encode('utf-8'))
> +
> +while ps.poll() == None:
> +# For interactive modes such as 'make config', 'make
> oldconfig',
> +# send 'En
Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive
On Wed, Feb 07 2018, Joel Fernandes wrote:
> Hi Peter,
>
> On Wed, Feb 7, 2018 at 8:58 AM, Peter Zijlstra wrote:
> [...]
>>
>>> Lockdep reports this issue when GFP_FS is infact set, and we enter
>>> this path and acquire the lock. So lockdep seems to be doing the right
>>> thing however by design it is reporting a false-positive.
>>
>> So I'm not seeing how its a false positive. fs/inode.c sets a different
>> lock class per filesystem type. So recursing on an i_mutex within a
>> filesystem does sound dodgy.
>
> But directory inodes and file inodes in the same filesystem share the
> same lock class right?
Not since v2.6.24
Commit: 14358e6ddaed ("lockdep: annotate dir vs file i_mutex")
You were using 4.9.60. so they should be separate
Maybe shmem_get_inode() needs to call unlock_new_inode() or just
lockdep_annotate_inode_mutex_key() after inode_init_owner().
Maybe inode_init_owner() should call lockdep_annotate_inode_mutex_key()
directly.
NeilBrown
signature.asc
Description: PGP signature
Re: [patches] [PATCH v3 0/6] Add dynamic ftrace support for RISC-V platforms
On Thu, 18 Jan 2018 07:45:39 PST (-0800), noner...@gmail.com wrote: This patch set includes the building blocks of dynamic ftrace features for RISC-V machines. Changes in v3: - Replace the nops at the tracer call sites into a "call ftrace_stub" instruction for better understanding (1/6 and 2/6) Changes in v2: - Fix the return value as writing to kernel text goes wrong (2/6) - Replace manual comparisons by calling memcmp (2/6) - Simplify the conditional assignment in the Makefile (1/6) Alan Kao (6): riscv/ftrace: Add RECORD_MCOUNT support riscv/ftrace: Add dynamic function tracer support riscv/ftrace: Add dynamic function graph tracer support riscv/ftrace: Add ARCH_SUPPORTS_FTRACE_OPS support riscv/ftrace: Add DYNAMIC_FTRACE_WITH_REGS support riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support arch/riscv/Kconfig | 3 + arch/riscv/Makefile | 3 + arch/riscv/include/asm/ftrace.h | 47 arch/riscv/kernel/Makefile | 5 +- arch/riscv/kernel/ftrace.c | 142 ++- arch/riscv/kernel/mcount-dyn.S | 241 arch/riscv/kernel/mcount.S | 22 ++-- arch/riscv/kernel/stacktrace.c | 6 + scripts/recordmcount.pl | 5 + 9 files changed, 461 insertions(+), 13 deletions(-) create mode 100644 arch/riscv/kernel/mcount-dyn.S Sorry it took me a while to get around to these. Do you mind submitting a v4 that's based on linux-4.15? I'm getting all sorts of merge errors trying to "git am" these.
Re: [PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device
On Mon, Feb 5, 2018 at 3:11 AM, Ryder Lee wrote: > On Mon, 2018-02-05 at 00:08 -0600, Rob Herring wrote: >> On Wed, Jan 31, 2018 at 03:42:44PM +0800, Ryder Lee wrote: >> > As the MediaTek audio hardware block that expose functionalities that are >> > handled by separate subsystems in the kernel, and there are registers that >> > are shared between related drivers. >> > >> > Switch the current device to an MFD device, add more descriptions about the >> > subsystem and modify example accordingly. >> > >> > Signed-off-by: Ryder Lee >> > --- >> > .../bindings/arm/mediatek/mediatek,audsys.txt | 37 >> > ++ >> > 1 file changed, 30 insertions(+), 7 deletions(-) >> > >> > diff --git >> > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt >> > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt >> > index 9b8f578..677af40 100644 >> > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt >> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt >> > @@ -1,22 +1,45 @@ >> > -MediaTek AUDSYS controller >> > +MediaTek Audio Subsystem >> > >> > +The audio subsystem is one of the multi-function blocks of MediaTek SoCs. >> > +It contains a system controller, which provides a number registers giving >> > +access to two features: AUDSYS clocks and Audio Front End (AFE) >> > components. >> > >> > +For the top level node: >> > +- compatible: must be: "syscon", "simple-mfd"; >> >> This should have some SoC specific compatible. > > As we don't have a specific driver (compatible string) for it and if we > need to add that I think the term '*-audsys' is very suitable here, but > unfortunately, it has already picked for clock driver (see child node). Perhaps the clocks block should have "-clk" on the end or something. Why do you really need to change this in the first place? You don't have to have DT child nodes to create child (struct) devices and child drivers. > > I also took ../../marvell/*-system-controller.txt as examples for my > case. Thus, I'm not sure should we still need a new one here? > >> > +- reg: register area of the Audio Subsystem >> > + >> > +Required sub-nodes: >> > + >> > +AUDSYS clocks: >> > +--- >> > The MediaTek AUDSYS controller provides various clocks to the system. >> > >> > Required Properties: >> > >> > - compatible: Should be one of: >> > - - "mediatek,mt7622-audsys", "syscon" >> > + - "mediatek,mt2701-audsys"; >> > + - "mediatek,mt7622-audsys"; >> > - #clock-cells: Must be 1 >> > >> > The AUDSYS controller uses the common clk binding from >> > Documentation/devicetree/bindings/clock/clock-bindings.txt >> > The available clocks are defined in dt-bindings/clock/mt*-clk.h. >> >> There's no register range associated with the clocks? If there is, add a >> reg property. > > No, we don't need reg property here, as the two sub-drivers will obtain > the regmap which is propagated from the parent. I know regmap doesn't need it. That's not what I asked. If you have a range of registers for the clocks, then define that in reg. Only if the clock control bits are mixed up with other functions within the same registers, then you can omit it. Rob
Re: [patches] [PATCH v3 0/6] Add dynamic ftrace support for RISC-V platforms
On Wed, Feb 07, 2018 at 04:37:10PM -0800, Palmer Dabbelt wrote: > On Thu, 18 Jan 2018 07:45:39 PST (-0800), noner...@gmail.com wrote: > > This patch set includes the building blocks of dynamic ftrace features > > for RISC-V machines. > > > > Changes in v3: > > - Replace the nops at the tracer call sites into a "call ftrace_stub" > >instruction for better understanding (1/6 and 2/6) > > > > Changes in v2: > > - Fix the return value as writing to kernel text goes wrong (2/6) > > - Replace manual comparisons by calling memcmp (2/6) > > - Simplify the conditional assignment in the Makefile (1/6) > > > > Alan Kao (6): > > riscv/ftrace: Add RECORD_MCOUNT support > > riscv/ftrace: Add dynamic function tracer support > > riscv/ftrace: Add dynamic function graph tracer support > > riscv/ftrace: Add ARCH_SUPPORTS_FTRACE_OPS support > > riscv/ftrace: Add DYNAMIC_FTRACE_WITH_REGS support > > riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support > > > > arch/riscv/Kconfig | 3 + > > arch/riscv/Makefile | 3 + > > arch/riscv/include/asm/ftrace.h | 47 > > arch/riscv/kernel/Makefile | 5 +- > > arch/riscv/kernel/ftrace.c | 142 ++- > > arch/riscv/kernel/mcount-dyn.S | 241 > > > > arch/riscv/kernel/mcount.S | 22 ++-- > > arch/riscv/kernel/stacktrace.c | 6 + > > scripts/recordmcount.pl | 5 + > > 9 files changed, 461 insertions(+), 13 deletions(-) > > create mode 100644 arch/riscv/kernel/mcount-dyn.S > > Sorry it took me a while to get around to these. Do you mind submitting a > v4 that's based on linux-4.15? I'm getting all sorts of merge errors trying > to "git am" these. Sure. But do you mean the riscv-linux-4.15 at the github repo or Linus's linux-4.15-rc..,says, rc8? Also, we have fixed our internal email server issue, so I will send this v4 set using alan...@andestech.com, by which I signed off all previous ftrace patches, instead of the current gmail one. I hope this won't be confusing to you. Thanks, Alan
Re: [PATCH 2/2] staging: android: ion: Combine cache and uncache pools
Hi Sumit,
On 2018/2/7 22:34, Sumit Semwal wrote:
> Hello Yisheng,
>
> On 7 February 2018 at 09:29, Yisheng Xie wrote:
>> Now we call dma_map in the dma_buf API callbacks and handle explicit
>> caching by the dma_buf sync API, which make cache and uncache pools
>> in the same handling flow, which can be combined.
>>
> Thanks for the patch! Perhaps you should also put the version history
> here, to capture the changes from previous versions?
hmm, this is first version of this patch. Except for the resent ones, all
of the patches I have sent about ion is v1 with different cleanup. Maybe
I can send them into one patchset in v2 after merge window. Sorry for not
having put them together.
Thanks
Yisheng
>
>> Signed-off-by: Yisheng Xie
> With that done, please feel free to add
> Acked-by: Sumit Semwal
>
>> ---
>> drivers/staging/android/ion/ion.c | 5 --
>> drivers/staging/android/ion/ion.h | 13 +
>> drivers/staging/android/ion/ion_page_pool.c | 5 +-
>> drivers/staging/android/ion/ion_system_heap.c | 76
>> +--
>> 4 files changed, 16 insertions(+), 83 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 461b193..c094be2 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -33,11 +33,6 @@
>> static struct ion_device *internal_dev;
>> static int heap_id;
>>
>> -bool ion_buffer_cached(struct ion_buffer *buffer)
>> -{
>> - return !!(buffer->flags & ION_FLAG_CACHED);
>> -}
>> -
>> /* this function should only be called while dev->lock is held */
>> static void ion_buffer_add(struct ion_device *dev,
>>struct ion_buffer *buffer)
>> diff --git a/drivers/staging/android/ion/ion.h
>> b/drivers/staging/android/ion/ion.h
>> index 1bc443f..ea08978 100644
>> --- a/drivers/staging/android/ion/ion.h
>> +++ b/drivers/staging/android/ion/ion.h
>> @@ -185,14 +185,6 @@ struct ion_heap {
>> };
>>
>> /**
>> - * ion_buffer_cached - this ion buffer is cached
>> - * @buffer:buffer
>> - *
>> - * indicates whether this ion buffer is cached
>> - */
>> -bool ion_buffer_cached(struct ion_buffer *buffer);
>> -
>> -/**
>> * ion_device_add_heap - adds a heap to the ion device
>> * @heap: the heap to add
>> */
>> @@ -302,7 +294,6 @@ size_t ion_heap_freelist_shrink(struct ion_heap *heap,
>> * @gfp_mask: gfp_mask to use from alloc
>> * @order: order of pages in the pool
>> * @list: plist node for list of pools
>> - * @cached:it's cached pool or not
>> *
>> * Allows you to keep a pool of pre allocated pages to use from your heap.
>> * Keeping a pool of pages that is ready for dma, ie any cached mapping have
>> @@ -312,7 +303,6 @@ size_t ion_heap_freelist_shrink(struct ion_heap *heap,
>> struct ion_page_pool {
>> int high_count;
>> int low_count;
>> - bool cached;
>> struct list_head high_items;
>> struct list_head low_items;
>> struct mutex mutex;
>> @@ -321,8 +311,7 @@ struct ion_page_pool {
>> struct plist_node list;
>> };
>>
>> -struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int
>> order,
>> - bool cached);
>> +struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int
>> order);
>> void ion_page_pool_destroy(struct ion_page_pool *pool);
>> struct page *ion_page_pool_alloc(struct ion_page_pool *pool);
>> void ion_page_pool_free(struct ion_page_pool *pool, struct page *page);
>> diff --git a/drivers/staging/android/ion/ion_page_pool.c
>> b/drivers/staging/android/ion/ion_page_pool.c
>> index 6d2caf0..db8f614 100644
>> --- a/drivers/staging/android/ion/ion_page_pool.c
>> +++ b/drivers/staging/android/ion/ion_page_pool.c
>> @@ -123,8 +123,7 @@ int ion_page_pool_shrink(struct ion_page_pool *pool,
>> gfp_t gfp_mask,
>> return freed;
>> }
>>
>> -struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int
>> order,
>> - bool cached)
>> +struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int
>> order)
>> {
>> struct ion_page_pool *pool = kmalloc(sizeof(*pool), GFP_KERNEL);
>>
>> @@ -138,8 +137,6 @@ struct ion_page_pool *ion_page_pool_create(gfp_t
>> gfp_mask, unsigned int order,
>> pool->order = order;
>> mutex_init(&pool->mutex);
>> plist_node_init(&pool->list, order);
>> - if (cached)
>> - pool->cached = true;
>>
>> return pool;
>> }
>> diff --git a/drivers/staging/android/ion/ion_system_heap.c
>> b/drivers/staging/android/ion/ion_system_heap.c
>> index bc19cdd..701eb9f 100644
>> --- a/drivers/staging/android/ion/ion_system_heap.c
>> +++ b/drivers/staging/android/ion/ion_system_heap.c
>> @@ -41,31 +41,16 @@ static inline unsigned int order_to_size(int order)
>>
>> struct io
Re: A problem about 'perf sched latency'
Hello, On Tue, Feb 06, 2018 at 09:50:02PM +0800, Du, Changbin wrote: > Hello all, > I am using perf sched tool to analyzer sched data on my machine. But it seems > that > 'perf sched latency' report incorrect 'Switches'. What I did is as below. > > First, record... > $ sudo perf sched record time pi 200 > /dev/null > > Then check statistics. It says 'pi' only sched-in 1 time. > $ sudo ./perf sched latency | grep pi > compiz:4054 | 6.389 ms | 30 | avg:0.023 ms | max: > 0.122 ms | max at: 94546.021080 s > pi:4059 | 2083.241 ms |1 | avg:0.007 ms | max: > 0.007 ms | max at: 94545.201435 s > > But the sched event show 'pi' has been sched-in 7 times. > $ sudo ./perf sched script | grep pi: > pi 4059 [001] 94545.820858: sched:sched_switch: pi:4059 > [120] S ==> kworker/1:1:32237 [120] > kworker/1:1 32237 [001] 94545.820868: sched:sched_switch: > kworker/1:1:32237 [120] R ==> pi:4059 [120] > pi 4059 [001] 94545.885412: sched:sched_switch: pi:4059 > [120] S ==> kworker/1:1H:320 [100] > kworker/1:1H 320 [001] 94545.885419: sched:sched_switch: > kworker/1:1H:320 [100] R ==> pi:4059 [120] > pi 4059 [001] 94545.907869: sched:sched_switch: pi:4059 > [120] S ==> kworker/1:1H:320 [100] > kworker/1:1H 320 [001] 94545.907875: sched:sched_switch: > kworker/1:1H:320 [100] R ==> pi:4059 [120] > pi 4059 [001] 94545.908104: sched:sched_switch: pi:4059 > [120] S ==> kworker/1:1H:320 [100] > kworker/1:1H 320 [001] 94545.908108: sched:sched_switch: > kworker/1:1H:320 [100] R ==> pi:4059 [120] > pi 4059 [001] 94545.916135: sched:sched_switch: pi:4059 > [120] S ==> kworker/1:1H:320 [100] > kworker/1:1H 320 [001] 94545.916154: sched:sched_switch: > kworker/1:1H:320 [100] R ==> pi:4059 [120] > pi 4059 [001] 94546.812856: sched:sched_switch: pi:4059 > [120] S ==> kworker/1:1:32237 [120] > kworker/1:1 32237 [001] 94546.813148: sched:sched_switch: > kworker/1:1:32237 [120] R ==> pi:4059 [120] > pi 4059 [001] 94546.885227: sched:sched_switch: pi:4059 > [120] S ==> i915/signal:1:207 [98] >i915/signal:1 207 [001] 94546.885232: sched:sched_switch: > i915/signal:1:207 [98] D ==> pi:4059 [120] > pi 4059 [001] 94547.285049: sched:sched_switch: pi:4059 > [120] x ==> swapper/1:0 [120] > > Does anyone know why? Thank you! :) It seems your data doesn't have wakeup event which is required by the 'perf sched latency'. Thanks, Namhyung > > -- > Thanks, > Changbin Du > -- > To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] s390: introduce execute-trampolines for branches
On Thu, Feb 8, 2018 at 10:44 AM, Masahiro Yamada
wrote:
> 2018-02-08 2:55 GMT+09:00 Linus Torvalds :
>> What I would really want - and this is entirely unrelated to this
>> particular case - is to have those damn compiler option tests as part
>> of the config phase in general. We now have about a million of these
>> crazy things, where we have config options that simply depend on which
>> compiler we have, and we have no sane way to show them at
>> configuration time.
>>
>> Though Andrew's tree I got yet another ugly hack
>> (CONFIG_CC_STACKPROTECTOR_AUTO) that handles just _one_ special case
>> by turning it into a special magic Kconfig entry in the main Makefile.
>> See commit 44c6dc940b19 ("Makefile: introduce
>> CONFIG_CC_STACKPROTECTOR_AUTO"). I wasn't sure if I really wanted it,
>> and honestly, I'm still thinking of just reverting it, because it's
>> _so_ ugly and _so_ wrong.
>>
>> What we need is an extension to the Kconfig language itself so that we can do
>>
>>config CC_HAS_RETPOLINE
>> cc_option "-mindirect-branch=thunk -mindirect-branch-table"
>>
>> or something. And then we can make sane _conditional_ dependencies at
>> Kconfig time, and our makefiles would be much cleaner too when you
>> could just do
>>
>> cflags-$(USE_RETPOLINE) += -mfunction-return=thunk
>> -mindirect-branch-table
>>
>> because the validity of the C compiler flag has been tested when configuring.
>>
>> And then we could add that warning at configure time (or just disable
>> the option there thanks to "depends on CC_HAS_xyz" logic).
>>
>> All our compiler option handling right now is just nasty nasty nasty crud.
>>
>> Adding more people in the hopes that somebody gets motivated.. I've
>> talked about this before, so far we haven't made any progress.
>
>
> Sorry for slow progress.
>
> I agreed this before, and still motivated.
> (because I also motivated to remove kbuild cache.
> This turned out not so clever as I first thought)
>
> I was trying to do this, but in this development cycle
> I spent most of my time to flush out lots of piled up Kconfig patches.
> Sorry.
>
> Unless somebody is working, I will.
FWIW, I did try to do this before I went with the STACKPROTECTOR_AUTO
solution, and it defeated me at every turn. Between the circular
dependency of the Makefile setting up KBUILD flags and Kconfig wanting
to know about the compiler, I got stuck. And it also seemed like the
cache was a problem too, as I couldn't find a way to re-evaluate the
script-controlled CONFIG items once it got cached.
And ultimately, a lot of the operational logic ended up sticking
around in the Makefile anyway (to provide fallback decisions, warns,
and errors). To correctly deal with the complex corner-cases for
stack-protector, I end up with three pieces:
the user config:
- do you want auto, weak, strong, or off?
the compiler tests:
- which of weak, strong, or off are supported?
- does the flag _actually produce working code_ for this
architecture/compiler version/etc?
and the build behavior:
- for auto, choose best available flag and warn if none
- for user-selected weak or strong, stop if unavailable/non-functional
- for off (or auto-none) use the "off" flag, if it is supported (to
force-disable it on ssp-by-default distro compilers)
And all of this needs to bypass the Kconfig cache, since if it gets
cached, it won't get re-evaluated when a selection is changed. If we
had a working "option shell $(CC) ..." then I could do the "compiler
tests" part in Kconfig, and I could probably do the bulk of the "build
behavior" logic in Kconfig too, though any intermediate configs would
need to avoid getting cached too.
The ssp handling has always been extremely complex due to all its gory
details, but I've tried _really_ hard to improve it, keep it
documented, and in one place (e.g. the compiler tests used to be
stuffed in per-arch Makefile).
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH] tile/pci_gx: Make setup_pcie_rc_delay __init
On Tue, 16 Jan 2018 19:45:05 PST (-0800), douly.f...@cn.fujitsu.com wrote:
The early_param() is only called during kernel initialization, So Linux
marks the functions of it with __init macro to save memory.
But it forgot to mark setup_pcie_rc_delay(). So, Make it __init as well.
Cc: Bjorn Helgaas
Cc: Palmer Dabbelt
Cc: Chris Metcalf
Cc: Andrew Morton
Signed-off-by: Dou Liyang
---
arch/tile/kernel/pci_gx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index 9aa238ac7b35..9a874e98b1cc 100644
--- a/arch/tile/kernel/pci_gx.c
+++ b/arch/tile/kernel/pci_gx.c
@@ -617,7 +617,7 @@ static void fixup_read_and_payload_sizes(struct
pci_controller *controller)
}
}
-static int setup_pcie_rc_delay(char *str)
+static int __init setup_pcie_rc_delay(char *str)
{
unsigned long delay = 0;
unsigned long trio_index;
Sorry this sat in my inbox for a while. I talked to Chris and he's not
maintaining Linux any more. I maintain the RISC-V port, so I'm not actually
sure how this got to me, but I don't mind collecting Tilera patches and
submitting them to Linus. Note that I don't have any TileGx hardware or even a
compiler, so it'd be a very low bar for maintenance.
If that's OK with everyone there then I can submit something that's more of a
direct question to the mailing list.
Re: [PATCH] x86/xen: Calculate __max_logical_packages on PV domains
On 02/07/2018 06:49 PM, Prarit Bhargava wrote:
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava
Tested-and-reported-by: Simon Gaiser
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Dou Liyang
Cc: Prarit Bhargava
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: Andy Lutomirski
Cc: Andi Kleen
Cc: Vitaly Kuznetsov
Cc: xen-de...@lists.xenproject.org
Reviewed-by: Boris Ostrovsky
(+ Simon)
---
arch/x86/include/asm/smp.h | 1 +
arch/x86/kernel/smpboot.c | 10 --
arch/x86/xen/smp.c | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 461f53d27708..a4189762b266 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -129,6 +129,7 @@ static inline void arch_send_call_function_ipi_mask(const
struct cpumask *mask)
void cpu_disable_common(void);
void native_smp_prepare_boot_cpu(void);
void native_smp_prepare_cpus(unsigned int max_cpus);
+void calculate_max_logical_packages(void);
void native_smp_cpus_done(unsigned int max_cpus);
void common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 6f27facbaa9b..767573b7f2db 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1281,11 +1281,10 @@ void __init native_smp_prepare_boot_cpu(void)
cpu_set_state_online(me);
}
-void __init native_smp_cpus_done(unsigned int max_cpus)
+void __init calculate_max_logical_packages(void)
{
int ncpus;
- pr_debug("Boot done\n");
/*
* Today neither Intel nor AMD support heterogenous systems so
* extrapolate the boot cpu's data to all packages.
@@ -1293,6 +1292,13 @@ void __init native_smp_cpus_done(unsigned int max_cpus)
ncpus = cpu_data(0).booted_cores * topology_max_smt_threads();
__max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
pr_info("Max logical packages: %u\n", __max_logical_packages);
+}
+
+void __init native_smp_cpus_done(unsigned int max_cpus)
+{
+ pr_debug("Boot done\n");
+
+ calculate_max_logical_packages();
if (x86_has_numa_in_package)
set_sched_topology(x86_numa_in_package_topology);
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 77c959cf81e7..7a43b2ae19f1 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -122,6 +122,8 @@ void __init xen_smp_cpus_done(unsigned int max_cpus)
if (xen_hvm_domain())
native_smp_cpus_done(max_cpus);
+ else
+ calculate_max_logical_packages();
if (xen_have_vcpu_info_placement)
return;
Re: [PATCH v12 0/9] LPC: legacy ISA I/O support
On Tue, Jan 23, 2018 at 9:36 AM, John Garry wrote: > This patchset supports the IPMI-bt device attached to the Low-Pin-Count > interface implemented on Hisilicon Hip06/Hip07 SoC. > --- > | LPC host| > | | > --- > | > _V___LPC > | | > V V > > | BT(ipmi)| > > > When master accesses those peripherals beneath the Hip06/Hip07 LPC, a specific > LPC driver is needed to make LPC host generate the standard LPC I/O cycles > with > the target peripherals'I/O port addresses. But on curent arm64 world, there is > no real I/O accesses. All the I/O operations through in/out accessors are > based > on MMIO ranges; on Hip06/Hip07 LPC the I/O accesses are performed through > driver > specific accessors rather than MMIO. > To solve this issue and keep the relevant existing peripherals' drivers > untouched, > this patchset: >- introduces a generic I/O space management framework, LIBIO, to support > I/O > operations on host controllers operating either on MMIO buses or on buses > requiring specific driver I/O accessors; >- redefines the in/out accessors to provide a unified interface for both > MMIO > and driver specific I/O operations. Using LIBIO, th call of in/out() from > the host children drivers, such as ipmi-si, will be redirected to the > corresponding device-specific I/O hooks to perform the I/O accesses. > > Based on this patch-set, all the I/O accesses to Hip06/Hip07 LPC peripherals > can > be supported without any changes on the existing ipmi-si driver. > > The whole patchset has been tested on Hip07 D05 board both using DTB and ACPI. fyi, tested successfully here as well on a D05: Tested-by: dann frazier -dann > Differences to v11: > - fixed build errors for i386, m68k, and tile > - added a comment in LPC driver commit log why we set >the kernel config as bool > - some tidying logic_pio code > > Differences to v10: > - dropped CONFIG_LOGIC_PIO. Reason is that CONFIG_PCI > depends on this, and CONFIG_PCI is a per-arch CONFIG. > So we would require all arch's kconfig to select this. > - Addressed Dann Frazier's comments on LPC driver, and > sopme other cleanup > - Moved logic_pio.h to be included in generic asm io.h > - Fixed ACPI indirect IO host setup to handle >1 child > - Relocated ACPI indirect IO host setup code to > drivers/acpi > - Rebased to linux next-20180118 > > Changes from v9: > - patch 2 has been split into 3 patches according to Bjorn comments on > v9 thread > - patch 1 has been reworked accordign to Bjorn comments on v9 > - now logic_pio_trans_hwaddr() has a sanity check to make sure the resource > size fits into the assigned range > - in patch 5 the MFD framework has been used to probe the LPC children > according to the suggestion from Mika Westerberg > - Maintaner has changed to Huawei Linuxarm mailing list > > Changes from v8: > - Simplified LIB IO framewrok > - Moved INDIRECT PIO ACPI framework under acpi/arm64 > - Renamed occurrences of "lib io" and "indirect io" to "lib pio" and > "indirect pio" to keep the patchset nomenclature consistent > - Removed Alignment reuqirements > - Moved LPC specific code out of ACPI common framework > - Now PIO indirect HW ranges can overlap > - Changed HiSilicon LPC driver maintainer (Gabriele Paoloni now) and split > maintaner file modifications in a separate commit > - Removed the commit with the DT nodes support for hip06 and hip07 (to be > pushed separately) > - Added a checking on ioport_map() not to break that function as Arnd points > out in V7 review thread; > - fixed the compile issues on alpha, m68k; > > Changes from V7: > - Based on Arnd's comment, rename the LIBIO as LOGIC_PIO; > - Improved the mapping process in LOGIC_PIO to gain better efficiency when > redirecting the I/O accesses to right device driver; > - To reduce the impact on PCI MMIO to a minimum, add a new > CONFIG_INDIRECT_PIO for indirect-IO hosts/devices; > - Added a new ACPI handler for indirect-IO hosts/devices; > - Fixed the compile issues on V6; > > Changes from V6: > - According to the comments from Bjorn and Alex, merge PCI IO and > indirect-IO > into a generic I/O space management, LIBIO; > - Adopted the '_DEP' to replace the platform bus notifier. In this way, we > can > ensure the LPC peripherals' I/O resources had been translated to logical > IO > before the LPC peripheral enumeration; > - Replaced the rwlock with rcu list based on Alex's suggestion; > - Applied rela
Re: [PATCH v3 12/16] mmc: tmio: support IP-builtin card detection logic
2018-02-08 4:34 GMT+09:00 Wolfram Sang :
> On Thu, Jan 18, 2018 at 01:28:12AM +0900, Masahiro Yamada wrote:
>> A card detect GPIO is set up only for platforms with "cd-gpios"
>> DT property or TMIO_MMC_USE_GPIO_CD flag. However, the driver
>> core always uses mmc_gpio_get_cd, which just fails with -ENOSYS
>> if ctx->cd_gpio is unset.
>>
>> The bit 5 of the status register provides the current signal level
>> of the CD line. Allow to use it if the GPIO is unused.
>>
>> Signed-off-by: Masahiro Yamada
>
> Reviewed-by: Wolfram Sang
>
>> @@ -1095,7 +1103,7 @@ static const struct mmc_host_ops tmio_mmc_ops = {
>
> I just wonder why the diff-tool puts 'const' in the definition. There is
> no const in my version here. And there shouldn't be because we modify
> the struct in this patch.
>
Which kernel version are you seeing?
The following patch was applied and it is in Linus'tree.
commit c055fc75c1757b220108489038cfe60496b13865
Author: Masahiro Yamada
Date: Sat Nov 25 01:24:41 2017 +0900
mmc: tmio: move mmc_host_ops to struct tmio_mmc_host from static data
Currently, tmio_mmc_ops is static data and tmio_mmc_host_probe()
updates some hooks in the static data. This is a problem when
two or more instances call tmio_mmc_host_probe() and each of them
requests to use its own card_busy/start_signal_voltage_switch.
We can borrow a solution from sdhci_alloc_host(). Copy the whole
ops structure to host->mmc_host_ops, then override the hooks in
malloc'ed data. Constify tmio_mmc_ops since it is now a template
ops used by default.
Signed-off-by: Masahiro Yamada
Reviewed-by: Wolfram Sang
Tested-by: Wolfram Sang
Signed-off-by: Ulf Hansson
--
Best Regards
Masahiro Yamada
Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c
On Wed, 2018-02-07 at 12:51 -0800, Matthias Kaehlcke wrote: > El Wed, Feb 07, 2018 at 02:35:59PM -0600 Larry Finger ha dit: > > > On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote: > > > In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal > > > is assigned to itself in an if ... else statement, apparently only to > > > document that the branch condition is handled and that a previously read > > > value should be returned unmodified. The self-assignment causes clang to > > > raise the following warning: > > > > > > drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13: > > >error: explicitly assigning value of variable of type 'u32' > > > (aka 'unsigned int') to itself [-Werror,-Wself-assign] > > >writeVal = writeVal; > > > > > > Replace the self-assignment with a semicolon, which still serves to > > > document the 'handling' of the branch condition. > > > > > > Signed-off-by: Matthias Kaehlcke > > > --- > > > drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c > b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c > > > index 9cff6bc4049c..4db92496c122 100644 > > > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c > > > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c > > > @@ -301,7 +301,7 @@ static void > > > _rtl92c_get_txpower_writeval_by_regulatory(struct ieee80211_hw > *hw, > > > writeVal = writeVal - 0x06060606; > > > else if (rtlpriv->dm.dynamic_txhighpower_lvl == > > > TXHIGHPWRLEVEL_BT2) > > > - writeVal = writeVal; > > > + ; > > > *(p_outwriteval + rf) = writeVal; > > > } > > > } > > > > > > > As the branch condition does nothing, why not remove it and save the > > compiler's optimizer a bit of work? The code looks strange, but it matches > > the rest of Realtek's USB drivers. Agree Larry's comment. > > Sure, I am happy to change it to whatever the authors/maintainers prefer. > > I'll wait a bit before respinning for if others feel strongly about > keeping the branch. > > --Please consider the environment before printing this e-mail.
Re: [PATCH v3 14/16] mmc: tmio: move TMIO_MASK_{READOP,WRITEOP} handling to correct place
2018-02-08 6:47 GMT+09:00 Wolfram Sang :
> On Thu, Jan 18, 2018 at 01:28:14AM +0900, Masahiro Yamada wrote:
>> As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ}
>> are asserted for DMA mode as well as for PIO. I need to disable the
>> those IRQs in dma_ops->start hook, otherwise the DMA transfer fails
>> with the following error message:
>> PIO IRQ in DMA mode!
>>
>> Renesas chips are the same cases since I see their dma_ops->start
>> hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!).
>>
>> If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling
>> should be entirely moved to the core. tmio_mmc_cmd_irq() will
>> be a suitable place to disable them.
>>
>> The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd.
>>
>> /* Unmask the IRQs we want to know about */
>> if (!_host->chan_rx)
>> irq_mask |= TMIO_MASK_READOP;
>> if (!_host->chan_tx)
>> irq_mask |= TMIO_MASK_WRITEOP;
>>
>> At this point, _host->{chan_rx,chan_tx} are _always_ NULL because
>> tmio_mmc_request_dma() is called after this code. Consequently,
>> TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not.
>> Remove this pointless code.
>>
>> Signed-off-by: Masahiro Yamada
>
> I need to stop reviewing here because I'd need the applied version for
> checking. I hope Ulf can give me a base tomorrow.
>
> Or Yamada-san, do you meanwhile have a git repo somewhere?
>
Patch 1-6 were pulled merged in this MW.
Patch 7-16 are cleanly applicable onto Linus' tree.
(commit 581e400ff935d34 as of writing)
--
Best Regards
Masahiro Yamada
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/07/2018 08:45 PM, Baoquan He wrote: On 02/07/18 at 08:34pm, Dou Liyang wrote: At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to I add 'nokaslr' to disable the KASLR feature. # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. Oh, I will recompile the kernel with KASLR disabled in .config. Thanks, dou. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. Shutemov Date: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: ea000120 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: ea000140 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: ea000160 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: ea000180 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: ea0001a0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map: ea0001
[PATCH 2/2] amdgpu/dc/dml: Support clang option for stack alignment
DML uses the compiler option -mpreferred-stack-boundary=4 to configure a stack alignment of 16 bytes. Clang uses the option -mstack-alignment instead, which expects as parameter the alignment in bytes, and not a power of two like -mpreferred-stack-boundary. Probe for both compiler options and use the correct one, similar to what is done in arch/x86/Makefile. Reported-by: Guenter Roeck Signed-off-by: Matthias Kaehlcke --- drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index b8cadf833e71..740975931d21 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -24,7 +24,13 @@ # It provides the general basic services required by other DAL # subcomponents. -subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) + cc_stack_align=-mpreferred-stack-boundary=4 +else ifneq ($(call cc-option, -mstack-alignment=16),) + cc_stack_align := -mstack-alignment=16 +endif + +subdir-ccflags-y += -mhard-float -msse $(cc_stack_align) DML = display_mode_lib.o display_rq_dlg_calc.o \ display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \ -- 2.16.0.rc1.238.g530d649a79-goog
[PATCH 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS
Use subdir-ccflags instead of specifying the same flags for every source file. Signed-off-by: Matthias Kaehlcke --- drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index 3488af2b5786..b8cadf833e71 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -24,15 +24,7 @@ # It provides the general basic services required by other DAL # subcomponents. -CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_pipe_clocks.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4 - +subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 DML = display_mode_lib.o display_rq_dlg_calc.o \ display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \ -- 2.16.0.rc1.238.g530d649a79-goog
Re: [RFC PATCH] vfio/pci: Add ioeventfd support
On 08/02/18 01:12, Alex Williamson wrote:
> On Wed, 7 Feb 2018 15:48:26 +1100
> Alexey Kardashevskiy wrote:
>
>> On 07/02/18 15:25, Alex Williamson wrote:
>>> On Wed, 7 Feb 2018 15:09:22 +1100
>>> Alexey Kardashevskiy wrote:
On 07/02/18 11:08, Alex Williamson wrote:
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index e3301dbd27d4..07966a5f0832 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -503,6 +503,30 @@ struct vfio_pci_hot_reset {
>
> #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE + 13)
>
> +/**
> + * VFIO_DEVICE_IOEVENTFD - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + * struct vfio_device_ioeventfd)
> + *
> + * Perform a write to the device at the specified device fd offset, with
> + * the specified data and width when the provided eventfd is triggered.
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +struct vfio_device_ioeventfd {
> + __u32 argsz;
> + __u32 flags;
> +#define VFIO_DEVICE_IOEVENTFD_8 (1 << 0) /* 1-byte write */
> +#define VFIO_DEVICE_IOEVENTFD_16 (1 << 1) /* 2-byte write */
> +#define VFIO_DEVICE_IOEVENTFD_32 (1 << 2) /* 4-byte write */
> +#define VFIO_DEVICE_IOEVENTFD_64 (1 << 3) /* 8-byte write */
> +#define VFIO_DEVICE_IOEVENTFD_SIZE_MASK (0xf)
> + __u64 offset; /* device fd offset of write */
> + __u64 data; /* data to be written */
> + __s32 fd; /* -1 for de-assignment */
> +};
> +
> +#define VFIO_DEVICE_IOEVENTFD_IO(VFIO_TYPE, VFIO_BASE + 14)
>
Is this a first ioctl with endianness fixed to little-endian? I'd suggest
to comment on that as things like vfio_info_cap_header do use the host
endianness.
>>>
>>> Look at our current read and write interface, we call leXX_to_cpu
>>> before calling iowriteXX there and I think a user would logically
>>> expect to use the same data format here as they would there.
>>
>> If the data is "char data[8]" (i.e. bytestream), then it can be expected to
>> be device/bus endian (i.e. PCI == little endian), but if it is u64 - then I
>> am not so sure really, and this made me look around. It could be "__le64
>> data" too.
>>
>>> Also note
>>> that iowriteXX does a cpu_to_leXX, so are we really defining the
>>> interface as little-endian or are we just trying to make ourselves
>>> endian neutral and counter that implicit conversion? Thanks,
>>
>> Defining it LE is fine, I just find it a bit confusing when
>> vfio_info_cap_header is host endian but vfio_device_ioeventfd is not.
>
> But I don't think we are defining the interface as little-endian.
> iowriteXX does a cpu_to_leXX byteswap. Therefore in order to maintain
> endian neutrality, if the data does a cpu->le swap on the way out, I
> need to do a le->cpu swap on the way in, right? Please defend the
> assertion that we're creating a little-endian interface. Thanks,
vfio_pci_ioctl() passes "endian-neutral" ioeventfd.data to
vfio_pci_ioeventfd() which immediately does the leXX_to_cpu() conversion
(and uses the result later on in iowriteXX(), which is not VFIO API) so I
read it as the ioctl really expects LE.
The QEMU part - vfio_nvidia_mirror_quirk MR - does not swap bytes but the
MR itself it declared DEVICE_LITTLE_ENDIAN which means
vfio_nvidia_quirk_mirror_write() receives byteswapped @data in the host
endian == bigendian on a big endian host. So the ioctl() handler will
receive a BE value, do byteswap #1 in leXX_to_cpu(), and then do byteswap
#2 in iowriteXX() so after all a BE will be written to a device. So I'd say
we rather do not need leXX_to_cpu() in vfio_pci_ioeventfd(). Correct me
where I am wrong. Thanks,
--
Alexey
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/08/18 at 09:14am, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:45 PM, Baoquan He wrote: > > On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > > > > > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > > > On 02/07/18 at 08:17pm, Dou Liyang wrote: > > > > > Hi Baoquan, > > > > > > > > > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > > > > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > > > > > Hi Kirill,Mike > > > > > > > > > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which > > > > > > > > > > contained > > > > > > > > > > this patch. Did I missed something else? > > > > > > > > > > > > > > > > > > None I'm aware of. > > > > > > > > > > > > > > > > > > Is there a reason to suspect that the issue is related to the > > > > > > > > > bug this patch > > > > > > > > > fixed? > > > > > > > > > > > > > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > > > OK, I may get the reason. kaslr is enabled, right? You can try to > > I add 'nokaslr' to disable the KASLR feature. ~~~added?? > > # cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b > ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 > > > disable kaslr and try them again. Because phys_base and kaslr_offset are > > got from vmlinux, while these are generated at compiling time. Just a > > guess. > > > > Oh, I will recompile the kernel with KASLR disabled in .config. Then it's not what I guessed. Need debug makedumpfile since using vmlinux is another code path, few people use it usually. > > > Thanks, > dou. > > > > > > > > > > > > > > Revert your two commits: > > > > > > > > > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > > > > > Author: Kirill A. Shutemov > > > > > > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > > > > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > > > > > Author: Kirill A. Shutemov > > > > > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > > > > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > > > > > > > > > Still works fine for me with .today. Box is only 16GB desktop > > > > > > > > box though. > > > > > > > > > > > > > > > Btw, In the upstream kernel which contained this patch, I did two > > > > > > > tests: > > > > > > > > > > > > > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, > > > > > > > then > > > > > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > > > > > makedumpfile works well and I can get the vmcore file. > > > > > > > > > > > > > > ..It is OK > > > > > > > > > > > > > > 2) use cp as core_collector, do the same operation to get the > > > > > > > vmcore file. > > > > > > > then use makedumpfile to do like above: > > > > > > > > > > > > > >[douly@localhost code]$ ./makedumpfile -d 31 > > > > > > > --message-level 31 -x > > > > > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > > > > > > > > > Oh, then please ignore my previous comment. Adding '-D' can give > > > > > > more > > > > > > debugging message. > > > > > > > > > > I added '-D', Just like before, no more debugging message: > > > > > > > > > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > > > > > > > > > > ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > > > > > ../makedumpfile/code/vmlinux_4.15+ > > > > > > > > > > the crash works well, It's so interesting. > > > > > > > > > > Thanks, > > > > > dou. > > > > > > > > > > The debugging message with '-D': > > > > > > > > And what's the debugging printing when trigger crash by sysrq? > > > > > > > > > > kdump: dump target is /dev/vda2 > > > kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ > > > [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered > > > kdump: saving vmcore-dmesg.txt > > > kdump: saving vmcore-dmesg.txt complete > > > kdump: saving vmcore > > > sadump: does not have partition header > > > sadump: read dump device as unknown format > > > sadump: unknown format > > > LOAD (0) > > >phys_start : 100 > > >phys_end : 2a86000 > > >virt_start : 8100 > > >virt_end : 82a86000 > > > LOAD (1) > > >phys_start : 1000 > > >phys_end : 9fc00 > > >virt_start : 88001000 > > >virt_end : 8809fc00 > > > LOAD (2) > > >phys_start : 10 > > >phys_end : 1300 > > >virt_start : 8810 > > >virt_end : 88001300 > > > LOAD (3) > > >phys_start : 3300 > > >phys_end : 7ffd7000 > > >virt_start : 8800
Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled
Andrew Morton writes:
> On Wed, 7 Feb 2018 15:00:35 +0800 "Huang, Ying" wrote:
>
>> From: Huang Ying
>>
>> It was reported by Sergey Senozhatsky that if THP (Transparent Huge
>> Page) and frontswap (via zswap) are both enabled, when memory goes low
>> so that swap is triggered, segfault and memory corruption will occur
>> in random user space applications as follow,
>>
>> kernel: urxvt[338]: segfault at 20 ip 7fc08889ae0d sp 7ffc73a7fc40
>> error 6 in libc-2.26.so[7fc08881a000+1ae000]
>> #0 0x7fc08889ae0d _int_malloc (libc.so.6)
>> #1 0x7fc08889c2f3 malloc (libc.so.6)
>> #2 0x560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
>> #3 0x560e6005e75c n/a (urxvt)
>> #4 0x560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez
>> (urxvt)
>> #5 0x560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
>> #6 0x560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
>> #7 0x560e6005c10f _Z17ev_invoke_pendingv (urxvt)
>> #8 0x560e6005cb55 ev_run (urxvt)
>> #9 0x560e6003b9b9 main (urxvt)
>> #10 0x7fc08883af4a __libc_start_main (libc.so.6)
>> #11 0x560e6003f9da _start (urxvt)
>>
>> After bisection, it was found the first bad commit is
>> bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped
>> out").
>>
>> The root cause is as follow.
>>
>> When the pages are written to swap device during swapping out in
>> swap_writepage(), zswap (fontswap) is tried to compress the pages
>> instead to improve the performance. But zswap (frontswap) will treat
>> THP as normal page, so only the head page is saved. After swapping
>> in, tail pages will not be restored to its original contents, so cause
>> the memory corruption in the applications.
>>
>> This is fixed via splitting THP before writing the page to swap device
>> if frontswap is enabled. To deal with the situation where frontswap
>> is enabled at runtime, whether the page is THP is checked before using
>> frontswap during swapping out too.
>>
>> ...
>>
>> --- a/mm/page_io.c
>> +++ b/mm/page_io.c
>> @@ -250,7 +250,7 @@ int swap_writepage(struct page *page, struct
>> writeback_control *wbc)
>> unlock_page(page);
>> goto out;
>> }
>> -if (frontswap_store(page) == 0) {
>> +if (!PageTransHuge(page) && frontswap_store(page) == 0) {
>> set_page_writeback(page);
>> unlock_page(page);
>> end_page_writeback(page);
>> diff --git a/mm/swapfile.c b/mm/swapfile.c
>> index 006047b16814..0b7c7883ce64 100644
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -934,6 +934,9 @@ int get_swap_pages(int n_goal, bool cluster, swp_entry_t
>> swp_entries[])
>>
>> /* Only single cluster request supported */
>> WARN_ON_ONCE(n_goal > 1 && cluster);
>> +/* Frontswap doesn't support THP */
>> +if (frontswap_enabled() && cluster)
>> +goto noswap;
>>
>
> hm. This is assuming that "cluster==true" means "this is thp swap".
> That's presently true, but is it appropriate that get_swap_pages() is
> peeking at "cluster" to work out why it is being called?
>
> Or would it be cleaner to do this in get_swap_page()? Something like
>
> --- a/mm/swap_slots.c~a
> +++ a/mm/swap_slots.c
> @@ -317,8 +317,11 @@ swp_entry_t get_swap_page(struct page *p
> entry.val = 0;
>
> if (PageTransHuge(page)) {
> - if (IS_ENABLED(CONFIG_THP_SWAP))
> - get_swap_pages(1, true, &entry);
> + /* Frontswap doesn't support THP */
> + if (!frontswap_enabled()) {
> + if (IS_ENABLED(CONFIG_THP_SWAP))
> + get_swap_pages(1, true, &entry);
> + }
> return entry;
> }
>
Sure. I will do this.
Best Regards,
Huang, Ying
Re: [PATCH 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS
On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke wrote: > Use subdir-ccflags instead of specifying the same flags for every source > file. > > Signed-off-by: Matthias Kaehlcke Reviewed-by: Guenter Roeck > --- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index 3488af2b5786..b8cadf833e71 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -24,15 +24,7 @@ > # It provides the general basic services required by other DAL > # subcomponents. > > -CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4 > -CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4 > -CFLAGS_display_pipe_clocks.o := -mhard-float -msse > -mpreferred-stack-boundary=4 > -CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse > -mpreferred-stack-boundary=4 > -CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse > -mpreferred-stack-boundary=4 > -CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse > -mpreferred-stack-boundary=4 > -CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4 > -CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4 > - > +subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 > > DML = display_mode_lib.o display_rq_dlg_calc.o \ > display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \ > -- > 2.16.0.rc1.238.g530d649a79-goog >
Re: [PATCH 2/2] amdgpu/dc/dml: Support clang option for stack alignment
On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke wrote: > DML uses the compiler option -mpreferred-stack-boundary=4 to configure > a stack alignment of 16 bytes. Clang uses the option -mstack-alignment > instead, which expects as parameter the alignment in bytes, and not a > power of two like -mpreferred-stack-boundary. > > Probe for both compiler options and use the correct one, similar to > what is done in arch/x86/Makefile. > > Reported-by: Guenter Roeck > Signed-off-by: Matthias Kaehlcke > --- > drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index b8cadf833e71..740975931d21 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -24,7 +24,13 @@ > # It provides the general basic services required by other DAL > # subcomponents. > > -subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 > +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) > + cc_stack_align=-mpreferred-stack-boundary=4 > +else ifneq ($(call cc-option, -mstack-alignment=16),) > + cc_stack_align := -mstack-alignment=16 > +endif > + Any reason for using both = and := ? > +subdir-ccflags-y += -mhard-float -msse $(cc_stack_align) > > DML = display_mode_lib.o display_rq_dlg_calc.o \ > display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \ > -- > 2.16.0.rc1.238.g530d649a79-goog >
Re: [PATCH -mm -v2] mm, swap, frontswap: Fix THP swap if frontswap enabled
On (02/07/18 13:05), Andrew Morton wrote:
[..]
> hm. This is assuming that "cluster==true" means "this is thp swap".
> That's presently true, but is it appropriate that get_swap_pages() is
> peeking at "cluster" to work out why it is being called?
>
> Or would it be cleaner to do this in get_swap_page()? Something like
>
> --- a/mm/swap_slots.c~a
> +++ a/mm/swap_slots.c
> @@ -317,8 +317,11 @@ swp_entry_t get_swap_page(struct page *p
> entry.val = 0;
>
> if (PageTransHuge(page)) {
> - if (IS_ENABLED(CONFIG_THP_SWAP))
> - get_swap_pages(1, true, &entry);
> + /* Frontswap doesn't support THP */
> + if (!frontswap_enabled()) {
> + if (IS_ENABLED(CONFIG_THP_SWAP))
> + get_swap_pages(1, true, &entry);
> + }
> return entry;
> }
I have proposed exactly the same thing [1], Minchan commented that
it would introduce frontswap dependency to swap_slots.c [2]. Which
is true, but I'd still probably prefer to handle it all in
get_swap_page. Minchan, any objections?
[1] https://marc.info/?l=linux-mm&m=151791052007719&w=2
[2] https://marc.info/?l=linux-mm&m=151792646812617&w=2
-ss
Re: [PATCH 2/2] amdgpu/dc/dml: Support clang option for stack alignment
El Wed, Feb 07, 2018 at 05:34:44PM -0800 Guenter Roeck ha dit: > On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke wrote: > > DML uses the compiler option -mpreferred-stack-boundary=4 to configure > > a stack alignment of 16 bytes. Clang uses the option -mstack-alignment > > instead, which expects as parameter the alignment in bytes, and not a > > power of two like -mpreferred-stack-boundary. > > > > Probe for both compiler options and use the correct one, similar to > > what is done in arch/x86/Makefile. > > > > Reported-by: Guenter Roeck > > Signed-off-by: Matthias Kaehlcke > > --- > > drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > > index b8cadf833e71..740975931d21 100644 > > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > > @@ -24,7 +24,13 @@ > > # It provides the general basic services required by other DAL > > # subcomponents. > > > > -subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 > > +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) > > + cc_stack_align=-mpreferred-stack-boundary=4 > > +else ifneq ($(call cc-option, -mstack-alignment=16),) > > + cc_stack_align := -mstack-alignment=16 > > +endif > > + > Any reason for using both = and := ? Not really, will fix. Thanks!
Re: [PATCH v27 3/4] mm/page_poison: expose page_poisoning_enabled to kernel modules
On 02/08/2018 02:34 AM, Michael S. Tsirkin wrote:
On Wed, Feb 07, 2018 at 02:54:30PM +0800, Wei Wang wrote:
In some usages, e.g. virtio-balloon, a kernel module needs to know if
page poisoning is in use. This patch exposes the page_poisoning_enabled
function to kernel modules.
Signed-off-by: Wei Wang
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Michael S. Tsirkin
---
mm/page_poison.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mm/page_poison.c b/mm/page_poison.c
index e83fd44..c08d02a 100644
--- a/mm/page_poison.c
+++ b/mm/page_poison.c
@@ -30,6 +30,11 @@ bool page_poisoning_enabled(void)
debug_pagealloc_enabled()));
}
+/**
+ * page_poisoning_enabled - check if page poisoning is enabled
+ *
+ * Return true if page poisoning is enabled, or false if not.
+ */
static void poison_page(struct page *page)
{
void *addr = kmap_atomic(page);
@@ -37,6 +42,7 @@ static void poison_page(struct page *page)
memset(addr, PAGE_POISON, PAGE_SIZE);
kunmap_atomic(addr);
}
+EXPORT_SYMBOL_GPL(page_poisoning_enabled);
static void poison_pages(struct page *page, int n)
{
Looks like both the comment and the export are in the wrong place.
Thanks. Will be more careful.
I'm a bit concerned that callers also in fact poke at the
PAGE_POISON - exporting that seems to be more of an accident
as it's only used without page_poisoning.c - it might be
better to have page_poisoning_enabled get u8 * and set it.
PAGE_POISON is a macro defined in the header, why would callers using it
be a concern?
Do you suggest to have:
bool page_poisoning_get(u8 *val)
{
if (page_poisoning_enabled()) {
*val = PAGE_POISON;
return true;
}
return false;
}
EXPORT_SYMBOL_GPL(page_poisoning_get);
Best,
Wei
Re: [PATCH 2/6] nvme-pci: fix the freeze and quiesce for shutdown and reset case
Hi Keith Really thanks for your your precious time and kindly directive. That's really appreciated. :) On 02/08/2018 12:13 AM, Keith Busch wrote: > On Wed, Feb 07, 2018 at 10:13:51AM +0800, jianchao.wang wrote: >> What's the difference ? Can you please point out. >> I have shared my understanding below. >> But actually, I don't get the point what's the difference you said. > > It sounds like you have all the pieces. Just keep this in mind: we don't > want to fail IO if we can prevent it. > Yes, absolutely. > A request is allocated from an hctx pool of tags. Once the request is > allocated, it is permently tied to that hctx because that's where its > tag came from. If that hctx becomes invalid, the request has to be ended > with an error, and we can't do anything about that[*]. > > Prior to a reset, we currently halt new requests from being allocated by > freezing the request queues. We unfreeze the queues after the new state > of the hctx's is established. This way all IO requests that were gating > on the unfreeze are guaranteed to enter into a valid context. > > You are proposing to skip freeze on a reset. New requests will then be > allocated before we've established the hctx map. Any request allocated > will have to be terminated in failure if the hctx is no longer valid > once the reset completes. Yes, if any previous hctx doesn't come back, the requests on that hctx will be drained with BLK_STS_IOERR. __blk_mq_update_nr_hw_queues -> blk_mq_freeze_queue -> blk_freeze_queue -> blk_mq_freeze_queue_wait But the nvmeq's cq_vector is -1. > Yes, it's entirely possible today a request allocated prior to the reset > may need to be terminated after the reset. There's nothing we can do > about those except end them in failure, but we can prevent new ones from > sharing the same fate. You are removing that prevention, and that's what > I am complaining about. Thanks again for your precious time to detail this. So I got what you concern about is that this patch doesn't freeze the queue for reset case any more. And there maybe new requests enter, which will be failed when the associated hctx doesn't come back during reset procedure. And this should be avoided. I will change this in next V3 version. > * Future consideration: we recently obtained a way to "steal" bios that > looks like it may be used to back out certain types of requests and let > the bio create a new one. > Yeah, that will be a great idea to reduce the loss when hctx is gone. Sincerely Jianchao
[PATCH] ftrace: fix the file mode of graph tracer and stack tracer
It's something looks weird that those files could be written by root
but shows with no write permission by ll command.
Chen LinX has sent a similar patch to fix
graph function file mode in 2000, I didn't get the reason why that
patch wasn't applied so I resend it.
Signed-off-by: Zhengyuan Liu
---
kernel/trace/ftrace.c | 4 ++--
kernel/trace/trace_stack.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index ccdf366..fe903dc8 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -5513,10 +5513,10 @@ static __init int ftrace_init_dyn_tracefs(struct dentry
*d_tracer)
ftrace_create_filter_files(&global_ops, d_tracer);
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- trace_create_file("set_graph_function", 0444, d_tracer,
+ trace_create_file("set_graph_function", 0644, d_tracer,
NULL,
&ftrace_graph_fops);
- trace_create_file("set_graph_notrace", 0444, d_tracer,
+ trace_create_file("set_graph_notrace", 0644, d_tracer,
NULL,
&ftrace_graph_notrace_fops);
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index 734accc..4356f14 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -468,7 +468,7 @@ static __init int stack_trace_init(void)
NULL, &stack_trace_fops);
#ifdef CONFIG_DYNAMIC_FTRACE
- trace_create_file("stack_trace_filter", 0444, d_tracer,
+ trace_create_file("stack_trace_filter", 0644, d_tracer,
&trace_ops, &stack_trace_filter_fops);
#endif
--
2.7.4
[PATCH] net: Whitelist the skbuff_head_cache "cb" field
Most callers of put_cmsg() use a "sizeof(foo)" for the length argument.
Within put_cmsg(), a copy_to_user() call is made with a dynamic size, as a
result of the cmsg header calculations. This means that hardened usercopy
will examine the copy, even though it was technically a fixed size and
should be implicitly whitelisted. All the put_cmsg() calls being built
from values in skbuff_head_cache are coming out of the protocol-defined
"cb" field, so whitelist this field entirely instead of creating per-use
bounce buffers, for which there are concerns about performance.
Original report was:
Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from
SLAB object 'skbuff_head_cache' (offset 64, size 16)!
WARNING: CPU: 0 PID: 3663 at mm/usercopy.c:81 usercopy_warn+0xdb/0x100
mm/usercopy.c:76
...
__check_heap_object+0x89/0xc0 mm/slab.c:4426
check_heap_object mm/usercopy.c:236 [inline]
__check_object_size+0x272/0x530 mm/usercopy.c:259
check_object_size include/linux/thread_info.h:112 [inline]
check_copy_size include/linux/thread_info.h:143 [inline]
copy_to_user include/linux/uaccess.h:154 [inline]
put_cmsg+0x233/0x3f0 net/core/scm.c:242
sock_recv_errqueue+0x200/0x3e0 net/core/sock.c:2913
packet_recvmsg+0xb2e/0x17a0 net/packet/af_packet.c:3296
sock_recvmsg_nosec net/socket.c:803 [inline]
sock_recvmsg+0xc9/0x110 net/socket.c:810
___sys_recvmsg+0x2a4/0x640 net/socket.c:2179
__sys_recvmmsg+0x2a9/0xaf0 net/socket.c:2287
SYSC_recvmmsg net/socket.c:2368 [inline]
SyS_recvmmsg+0xc4/0x160 net/socket.c:2352
entry_SYSCALL_64_fastpath+0x29/0xa0
Reported-by: syzbot+e2d6cfb305e9f3911...@syzkaller.appspotmail.com
Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Signed-off-by: Kees Cook
---
I tried the inlining, it was awful. Splitting put_cmsg() was awful. So,
instead, whitelist the "cb" field as the least bad option if bounce
buffers are unacceptable. Dave, do you want to take this through net, or
should I take it through the usercopy tree?
---
net/core/skbuff.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6b0ff396fa9d..201b96c8f414 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3889,10 +3889,12 @@ EXPORT_SYMBOL_GPL(skb_gro_receive);
void __init skb_init(void)
{
- skbuff_head_cache = kmem_cache_create("skbuff_head_cache",
+ skbuff_head_cache = kmem_cache_create_usercopy("skbuff_head_cache",
sizeof(struct sk_buff),
0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC,
+ offsetof(struct sk_buff, cb),
+ sizeof_field(struct sk_buff, cb),
NULL);
skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
sizeof(struct sk_buff_fclones),
--
2.7.4
--
Kees Cook
Pixel Security
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/08/2018 09:23 AM, Baoquan He wrote: On 02/08/18 at 09:14am, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:45 PM, Baoquan He wrote: On 02/07/18 at 08:34pm, Dou Liyang wrote: At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to I add 'nokaslr' to disable the KASLR feature. ~~~added?? oops! yes, the kaslr had already disabled by this option when I tested. # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. Oh, I will recompile the kernel with KASLR disabled in .config. Then it's not what I guessed. Need debug makedumpfile since using vmlinux is another code path, few people use it usually. Understood, I will try to look into it. Thanks, dou Thanks, dou. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. Shutemov Date: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: ea000120 pfn_start
Re: [PATCH 01/14] kconfig: send error messages to stderr
2018-02-08 5:24 GMT+09:00 Ulf Magnusson :
> On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
> wrote:
>> These messages should be directed to stderr.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> scripts/kconfig/conf.c | 18 +++---
>> scripts/kconfig/zconf.l | 27 +++
>> 2 files changed, 26 insertions(+), 19 deletions(-)
>>
>> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
>> index 307bc3f..90a76aa2 100644
>> --- a/scripts/kconfig/conf.c
>> +++ b/scripts/kconfig/conf.c
>> @@ -75,9 +75,11 @@ static void strip(char *str)
>> static void check_stdin(void)
>> {
>> if (!valid_stdin) {
>> - printf(_("aborted!\n\n"));
>> - printf(_("Console input/output is redirected. "));
>> - printf(_("Run 'make oldconfig' to update
>> configuration.\n\n"));
>> + fprintf(stderr,
>> + _("Aborted!\n"
>> + "Console input/output is redirected.\n"
>> + "Run 'make oldconfig' to update
>> configuration.\n\n")
>> + );
>
> This could use fputs() too, moving the stderr to the last argument.
In general, I am not keen on replacement of (f)printf with (f)puts.
If '%' does not appear in the format literal, compiler will automatically
replace the function call with a faster one.
My compiler replaced both fprintf(stderr, "blah\n") and fputs("blah\n", stderr)
with fwrite.
At this moment, right, the compiler cannot optimize it
because it never knows the result of _(...).
If we rip off the gettext things, it will be optimized.
> I think the _() thingies around the strings are for gettext
> (https://www.gnu.org/software/gettext/manual/html_node/Mark-Keywords.html).
> This would break it if there are existing translations, since the
> msgids change.
Right. I will keep inside _(...) as-is just in case
to not break gettext.
> More practically, I doubt anyone is translating these tools. IMO we
> should remove the gettext stuff unless we find traces of translations.
I agree. Probably, it should not hurt to eliminate gettext,
but out of scope of this series.
>> exit(1);
>> }
>> }
>> @@ -565,7 +567,7 @@ int main(int ac, char **av)
>> }
>> }
>> if (ac == optind) {
>> - printf(_("%s: Kconfig file missing\n"), av[0]);
>> + fprintf(stderr, _("%s: Kconfig file missing\n"), av[0]);
>> conf_usage(progname);
>> exit(1);
>> }
>> @@ -590,9 +592,11 @@ int main(int ac, char **av)
>> if (!defconfig_file)
>> defconfig_file = conf_get_default_confname();
>> if (conf_read(defconfig_file)) {
>> - printf(_("***\n"
>> - "*** Can't find default configuration
>> \"%s\"!\n"
>> - "***\n"), defconfig_file);
>> + fprintf(stderr,
>> + _("***\n"
>> + "*** Can't find default configuration
>> \"%s\"!\n"
>> + "***\n"),
>> + defconfig_file);
>> exit(1);
>> }
>> break;
>> diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
>> index 07e074d..0ba4900 100644
>> --- a/scripts/kconfig/zconf.l
>> +++ b/scripts/kconfig/zconf.l
>> @@ -184,7 +184,9 @@ n [A-Za-z0-9_-]
>> append_string(yytext, 1);
>> }
>> \n {
>> - printf("%s:%d:warning: multi-line strings not supported\n",
>> zconf_curname(), zconf_lineno());
>> + fprintf(stderr,
>> + "%s:%d:warning: multi-line strings not supported\n",
>> + zconf_curname(), zconf_lineno());
>
> Whether stuff is translated seems inconsistent too.
Right. Many people change the same tool, it is difficult to
keep the consistency.
>> current_file->lineno++;
>> BEGIN(INITIAL);
>> return T_EOL;
>> @@ -294,7 +296,7 @@ void zconf_initscan(const char *name)
>> {
>> yyin = zconf_fopen(name);
>> if (!yyin) {
>> - printf("can't find file %s\n", name);
>> + fprintf(stderr, "can't find file %s\n", name);
>> exit(1);
>> }
>>
>> @@ -315,8 +317,8 @@ void zconf_nextfile(const char *name)
>> current_buf->state = YY_CURRENT_BUFFER;
>> yyin = zconf_fopen(file->name);
>> if (!yyin) {
>> - printf("%s:%d: can't open file \"%s\"\n",
>> - zconf_curname(), zconf_lineno(), file->name);
>> + fprintf(stderr, "%s:%d: can't open file \"%s\"\n",
>> + zconf_curname(), zconf_lineno(), file->name);
>> exit(1);
>> }
>> yy_switch_to_buffe
[PATCH v2 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS
Use subdir-ccflags instead of specifying the same flags for every source file. Signed-off-by: Matthias Kaehlcke Reviewed-by: Guenter Roeck --- Changes in v2: - added 'Reviewed-by: Guenter Roeck ' tag drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index 3488af2b5786..b8cadf833e71 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -24,15 +24,7 @@ # It provides the general basic services required by other DAL # subcomponents. -CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_pipe_clocks.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4 -CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4 - +subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 DML = display_mode_lib.o display_rq_dlg_calc.o \ display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \ -- 2.16.0.rc1.238.g530d649a79-goog
[PATCH v2 2/2] amdgpu/dc/dml: Support clang option for stack alignment
DML uses the compiler option -mpreferred-stack-boundary=4 to configure a stack alignment of 16 bytes. Clang uses the option -mstack-alignment instead, which expects as parameter the alignment in bytes, and not a power of two like -mpreferred-stack-boundary. Probe for both compiler options and use the correct one, similar to what is done in arch/x86/Makefile. Reported-by: Guenter Roeck Signed-off-by: Matthias Kaehlcke --- Changes in v2: - use consistent syntax and formatting for assignment of cc_stack_align drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index b8cadf833e71..a92189eddab0 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -24,7 +24,13 @@ # It provides the general basic services required by other DAL # subcomponents. -subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) + cc_stack_align := -mpreferred-stack-boundary=4 +else ifneq ($(call cc-option, -mstack-alignment=16),) + cc_stack_align := -mstack-alignment=16 +endif + +subdir-ccflags-y += -mhard-float -msse $(cc_stack_align) DML = display_mode_lib.o display_rq_dlg_calc.o \ display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \ -- 2.16.0.rc1.238.g530d649a79-goog
Re: [PATCH v9 35/37] tracing: Increase trace_recursive_lock() limit for synthetic events
On Mon, 15 Jan 2018 20:52:09 -0600
Tom Zanussi wrote:
> static __always_inline int
> trace_recursive_lock(struct ring_buffer_per_cpu *cpu_buffer)
> {
> - if (cpu_buffer->current_context >= 4)
> + if (cpu_buffer->current_context >= 6)
I can't apply this patch because the new context counting broke tracing
suspend and resume because it depended on the context recursive locking.
Link: http://lkml.kernel.org/r/20180116020051.776011...@goodmis.org
I added the attached two patches which appear to do the job.
Let me know what you think.
-- Steve
>From f932ff1d98c482716b4b71a5d76b2aa3d65f66f0 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)"
Date: Wed, 7 Feb 2018 17:26:32 -0500
Subject: [PATCH] ring-buffer: Add nesting for adding events within events
The ring-buffer code has recusion protection in case tracing ends up tracing
itself, the ring-buffer will detect that it was called at the same context
(normal, softirq, interrupt or NMI), and not continue to record the event.
With the histogram synthetic events, they are called while tracing another
event at the same context. The recusion protection triggers because it
detects tracing at the same context and stops it.
Add ring_buffer_nest_start() and ring_buffer_nest_end() that will notify the
ring buffer that a trace is about to happen within another trace and that it
is intended, and not to trigger the recursion blocking.
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ring_buffer.h | 3 +++
kernel/trace/ring_buffer.c | 57 ++---
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index b37a5df05e81..467db0a7b82d 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -117,6 +117,9 @@ int ring_buffer_unlock_commit(struct ring_buffer *buffer,
int ring_buffer_write(struct ring_buffer *buffer,
unsigned long length, void *data);
+void ring_buffer_nest_start(struct ring_buffer *buffer);
+void ring_buffer_nest_end(struct ring_buffer *buffer);
+
struct ring_buffer_event *
ring_buffer_peek(struct ring_buffer *buffer, int cpu, u64 *ts,
unsigned long *lost_events);
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 9c4d6cbfd258..d09e453b6c52 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -477,6 +477,7 @@ struct ring_buffer_per_cpu {
struct buffer_page *reader_page;
unsigned long lost_events;
unsigned long last_overrun;
+ unsigned long nest;
local_tentries_bytes;
local_tentries;
local_toverrun;
@@ -2624,10 +2625,10 @@ trace_recursive_lock(struct ring_buffer_per_cpu *cpu_buffer)
bit = pc & NMI_MASK ? RB_CTX_NMI :
pc & HARDIRQ_MASK ? RB_CTX_IRQ : RB_CTX_SOFTIRQ;
- if (unlikely(val & (1 << bit)))
+ if (unlikely(val & (1 << (bit + cpu_buffer->nest
return 1;
- val |= (1 << bit);
+ val |= (1 << (bit + cpu_buffer->nest));
cpu_buffer->current_context = val;
return 0;
@@ -2636,7 +2637,57 @@ trace_recursive_lock(struct ring_buffer_per_cpu *cpu_buffer)
static __always_inline void
trace_recursive_unlock(struct ring_buffer_per_cpu *cpu_buffer)
{
- cpu_buffer->current_context &= cpu_buffer->current_context - 1;
+ cpu_buffer->current_context &=
+ cpu_buffer->current_context - (1 << cpu_buffer->nest);
+}
+
+/* The recursive locking above uses 4 bits */
+#define NESTED_BITS 4
+
+/**
+ * ring_buffer_nest_start - Allow to trace while nested
+ * @buffer: The ring buffer to modify
+ *
+ * The ring buffer has a safty mechanism to prevent recursion.
+ * But there may be a case where a trace needs to be done while
+ * tracing something else. In this case, calling this function
+ * will allow this function to nest within a currently active
+ * ring_buffer_lock_reserve().
+ *
+ * Call this function before calling another ring_buffer_lock_reserve() and
+ * call ring_buffer_nest_end() after the nested ring_buffer_unlock_commit().
+ */
+void ring_buffer_nest_start(struct ring_buffer *buffer)
+{
+ struct ring_buffer_per_cpu *cpu_buffer;
+ int cpu;
+
+ /* Enabled by ring_buffer_nest_end() */
+ preempt_disable_notrace();
+ cpu = raw_smp_processor_id();
+ cpu_buffer = buffer->buffers[cpu];
+ /* This is the shift value for the above recusive locking */
+ cpu_buffer->nest += NESTED_BITS;
+}
+
+/**
+ * ring_buffer_nest_end - Allow to trace while nested
+ * @buffer: The ring buffer to modify
+ *
+ * Must be called after ring_buffer_nest_start() and after the
+ * ring_buffer_unlock_commit().
+ */
+void ring_buffer_nest_end(struct ring_buffer *buffer)
+{
+ struct ring_buffer_per_cpu *cpu_buffer;
+ int cpu;
+
+ /* disabled by ring_buffer_nest_start() */
+ cpu = raw_smp_processor_id();
+ cpu_buffer = buffer->buffers[cpu];
+ /* This is the shift value for the above recusive locking */
+ cpu_buffer->nest -= NESTED_BITS;
+ preempt_enable_notrace();
}
/**
--
2.13.6
>From 92c571543120ffed5e725f5b57b9de0b535e9d0a Mon
Re: [PATCH 01/14] kconfig: send error messages to stderr
On Thu, Feb 8, 2018 at 2:49 AM, Masahiro Yamada
wrote:
> 2018-02-08 5:24 GMT+09:00 Ulf Magnusson :
>> On Tue, Feb 6, 2018 at 1:34 AM, Masahiro Yamada
>> wrote:
>>> These messages should be directed to stderr.
>>>
>>> Signed-off-by: Masahiro Yamada
>>> ---
>>>
>>> scripts/kconfig/conf.c | 18 +++---
>>> scripts/kconfig/zconf.l | 27 +++
>>> 2 files changed, 26 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
>>> index 307bc3f..90a76aa2 100644
>>> --- a/scripts/kconfig/conf.c
>>> +++ b/scripts/kconfig/conf.c
>>> @@ -75,9 +75,11 @@ static void strip(char *str)
>>> static void check_stdin(void)
>>> {
>>> if (!valid_stdin) {
>>> - printf(_("aborted!\n\n"));
>>> - printf(_("Console input/output is redirected. "));
>>> - printf(_("Run 'make oldconfig' to update
>>> configuration.\n\n"));
>>> + fprintf(stderr,
>>> + _("Aborted!\n"
>>> + "Console input/output is redirected.\n"
>>> + "Run 'make oldconfig' to update
>>> configuration.\n\n")
>>> + );
>>
>> This could use fputs() too, moving the stderr to the last argument.
>
>
> In general, I am not keen on replacement of (f)printf with (f)puts.
>
> If '%' does not appear in the format literal, compiler will automatically
> replace the function call with a faster one.
>
> My compiler replaced both fprintf(stderr, "blah\n") and fputs("blah\n",
> stderr)
> with fwrite.
>
> At this moment, right, the compiler cannot optimize it
> because it never knows the result of _(...).
>
> If we rip off the gettext things, it will be optimized.
No problem with me. Just some personal OCD. :)
>
>
>
>> I think the _() thingies around the strings are for gettext
>> (https://www.gnu.org/software/gettext/manual/html_node/Mark-Keywords.html).
>> This would break it if there are existing translations, since the
>> msgids change.
>
> Right. I will keep inside _(...) as-is just in case
> to not break gettext.
>
>
>
>
>> More practically, I doubt anyone is translating these tools. IMO we
>> should remove the gettext stuff unless we find traces of translations.
>
> I agree. Probably, it should not hurt to eliminate gettext,
> but out of scope of this series.
Yeah, out of scope.
>
>
>>> exit(1);
>>> }
>>> }
>>> @@ -565,7 +567,7 @@ int main(int ac, char **av)
>>> }
>>> }
>>> if (ac == optind) {
>>> - printf(_("%s: Kconfig file missing\n"), av[0]);
>>> + fprintf(stderr, _("%s: Kconfig file missing\n"), av[0]);
>>> conf_usage(progname);
>>> exit(1);
>>> }
>>> @@ -590,9 +592,11 @@ int main(int ac, char **av)
>>> if (!defconfig_file)
>>> defconfig_file = conf_get_default_confname();
>>> if (conf_read(defconfig_file)) {
>>> - printf(_("***\n"
>>> - "*** Can't find default configuration
>>> \"%s\"!\n"
>>> - "***\n"), defconfig_file);
>>> + fprintf(stderr,
>>> + _("***\n"
>>> + "*** Can't find default configuration
>>> \"%s\"!\n"
>>> + "***\n"),
>>> + defconfig_file);
>>> exit(1);
>>> }
>>> break;
>>> diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
>>> index 07e074d..0ba4900 100644
>>> --- a/scripts/kconfig/zconf.l
>>> +++ b/scripts/kconfig/zconf.l
>>> @@ -184,7 +184,9 @@ n [A-Za-z0-9_-]
>>> append_string(yytext, 1);
>>> }
>>> \n {
>>> - printf("%s:%d:warning: multi-line strings not supported\n",
>>> zconf_curname(), zconf_lineno());
>>> + fprintf(stderr,
>>> + "%s:%d:warning: multi-line strings not supported\n",
>>> + zconf_curname(), zconf_lineno());
>>
>> Whether stuff is translated seems inconsistent too.
>
>
> Right. Many people change the same tool, it is difficult to
> keep the consistency.
>
>
>
>
>>> current_file->lineno++;
>>> BEGIN(INITIAL);
>>> return T_EOL;
>>> @@ -294,7 +296,7 @@ void zconf_initscan(const char *name)
>>> {
>>> yyin = zconf_fopen(name);
>>> if (!yyin) {
>>> - printf("can't find file %s\n", name);
>>> + fprintf(stderr, "can't find file %s\n", name);
>>> exit(1);
>>> }
>>>
>>> @@ -315,8 +317,8 @@ void zconf_nextfile(const char *name)
>>> current_buf->state = YY_CURRENT_BUFFER;
>>> yyin = zconf_fopen(file->name);
>>> if (!yyin) {
>>> - printf("%s:%d: can't open file \"%s\"\n",
>
Re: [PATCH v2 2/2] amdgpu/dc/dml: Support clang option for stack alignment
On Wed, Feb 7, 2018 at 5:51 PM, Matthias Kaehlcke wrote: > DML uses the compiler option -mpreferred-stack-boundary=4 to configure > a stack alignment of 16 bytes. Clang uses the option -mstack-alignment > instead, which expects as parameter the alignment in bytes, and not a > power of two like -mpreferred-stack-boundary. > > Probe for both compiler options and use the correct one, similar to > what is done in arch/x86/Makefile. > > Reported-by: Guenter Roeck > Signed-off-by: Matthias Kaehlcke Reviewed-by: Guenter Roeck Guenter > --- > Changes in v2: > - use consistent syntax and formatting for assignment of cc_stack_align > > drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index b8cadf833e71..a92189eddab0 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -24,7 +24,13 @@ > # It provides the general basic services required by other DAL > # subcomponents. > > -subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4 > +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),) > + cc_stack_align := -mpreferred-stack-boundary=4 > +else ifneq ($(call cc-option, -mstack-alignment=16),) > + cc_stack_align := -mstack-alignment=16 > +endif > + > +subdir-ccflags-y += -mhard-float -msse $(cc_stack_align) > > DML = display_mode_lib.o display_rq_dlg_calc.o \ > display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \ > -- > 2.16.0.rc1.238.g530d649a79-goog >
[RFC] Warn the user when they could overflow mapcount
Kirill and I were talking about trying to overflow page->_mapcount
the other day and realised that the default settings of pid_max and
max_map_count prevent it [1]. But there isn't even documentation to
warn a sysadmin that they've just opened themselves up to the possibility
that they've opened their system up to a sufficiently-determined attacker.
I'm not sufficiently wise in the ways of the MM to understand exactly
what goes wrong if we do wrap mapcount. Kirill says:
rmap depends on mapcount to decide when the page is not longer mapped.
If it sees page_mapcount() == 0 due to 32-bit wrap we are screwed;
data corruption, etc.
That seems pretty bad. So here's a patch which adds documentation to the
two sysctls that a sysadmin could use to shoot themselves in the foot,
and adds a warning if they change either of them to a dangerous value.
It's possible to get into a dangerous situation without triggering this
warning (already have the file mapped a lot of times, then lower pid_max,
then raise max_map_count, then map the file a lot more times), but it's
unlikely to happen.
Comments?
[1] map_count counts the number of times that a page is mapped to
userspace; max_map_count restricts the number of times a process can
map a page and pid_max restricts the number of processes that can exist.
So map_count can never be larger than pid_max * max_map_count.
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 412314eebda6..ec90cd633e99 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -718,6 +718,8 @@ pid_max:
PID allocation wrap value. When the kernel's next PID value
reaches this value, it wraps back to a minimum PID value.
PIDs of value pid_max or larger are not allocated.
+Increasing this value without decreasing vm.max_map_count may
+allow a hostile user to corrupt kernel memory
==
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index ff234d229cbb..0ab306ea8f80 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -379,7 +379,8 @@ While most applications need less than a thousand maps,
certain
programs, particularly malloc debuggers, may consume lots of them,
e.g., up to one or two maps per allocation.
-The default value is 65536.
+The default value is 65530. Increasing this value without decreasing
+pid_max may allow a hostile user to corrupt kernel memory.
=
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 173d2484f6e3..ebc301b21589 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -123,8 +123,6 @@ extern int mmap_rnd_compat_bits __read_mostly;
#define MAPCOUNT_ELF_CORE_MARGIN (5)
#define DEFAULT_MAX_MAP_COUNT (USHRT_MAX - MAPCOUNT_ELF_CORE_MARGIN)
-extern int sysctl_max_map_count;
-
extern unsigned long sysctl_user_reserve_kbytes;
extern unsigned long sysctl_admin_reserve_kbytes;
diff --git a/include/linux/pid.h b/include/linux/pid.h
index 7633d55d9a24..7bb10c1b3be3 100644
--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -4,6 +4,8 @@
#include
+extern int pid_max;
+
enum pid_type
{
PIDTYPE_PID,
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 992bc9948232..c939f403ad08 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -235,5 +235,9 @@ static inline void setup_sysctl_set(struct ctl_table_set *p,
int sysctl_max_threads(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos);
+int sysctl_pid_max(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos);
+int sysctl_max_map_count(struct ctl_table *table, int write,
+void __user *buffer, size_t *lenp, loff_t *ppos);
#endif /* _LINUX_SYSCTL_H */
diff --git a/kernel/pid.c b/kernel/pid.c
index 5d30c87e3c42..9e230ae214c9 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -61,6 +61,27 @@ int pid_max = PID_MAX_DEFAULT;
int pid_max_min = RESERVED_PIDS + 1;
int pid_max_max = PID_MAX_LIMIT;
+extern int max_map_count;
+
+int sysctl_pid_max(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct ctl_table t;
+ int ret;
+
+ t = *table;
+ t.data = &pid_max;
+ t.extra1 = &pid_max_min;
+ t.extra2 = &pid_max_max;
+
+ ret = proc_douintvec_minmax(&t, write, buffer, lenp, ppos);
+ if (ret || !write)
+ return ret;
+
+ if ((INT_MAX / max_map_count) > pid_max)
+ pr_warn("pid_max is dangerously large\n");
+ return 0;
+}
/*
* PID-map pages start out as NULL, they get allocated upon
diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
index 0b53eef7d34b..e24becc39020 100644
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -308,7 +308,6
Re: [PATCH 0/8] Clean up kernel-doc and fix literal-block handling
On Wed, Feb 07, 2018 at 10:26:16AM -0700, Jonathan Corbet wrote: > So once upon a time I set out to fix the problem reported by Tobin wherein > a literal block within a kerneldoc comment would be corrupted in > processing. On the way, though, I got annoyed at the way I have to learn > how kernel-doc works from the beginning every time I tear into it. Awesome. The patch that exposed that problem hasn't landed yet but I tested this series and can confirm that it fixes it. FTR to test I did: - update function docs for include/linux/rcupdate.h:rcu_pointer_hadoff() removed enclosing '``' and added leading '::' - apply this series - rebuild docs - profit thanks, Tobin.
Re: [PATCH RFC] ashmem: Fix lockdep RECLAIM_FS false positive
On Wed, Feb 7, 2018 at 4:35 PM, NeilBrown wrote:
>> On Wed, Feb 7, 2018 at 8:58 AM, Peter Zijlstra wrote:
>> [...]
>>>
Lockdep reports this issue when GFP_FS is infact set, and we enter
this path and acquire the lock. So lockdep seems to be doing the right
thing however by design it is reporting a false-positive.
>>>
>>> So I'm not seeing how its a false positive. fs/inode.c sets a different
>>> lock class per filesystem type. So recursing on an i_mutex within a
>>> filesystem does sound dodgy.
>>
>> But directory inodes and file inodes in the same filesystem share the
>> same lock class right?
>
> Not since v2.6.24
> Commit: 14358e6ddaed ("lockdep: annotate dir vs file i_mutex")
>
> You were using 4.9.60. so they should be separate
>
> Maybe shmem_get_inode() needs to call unlock_new_inode() or just
> lockdep_annotate_inode_mutex_key() after inode_init_owner().
>
> Maybe inode_init_owner() should call lockdep_annotate_inode_mutex_key()
> directly.
Thanks for the ideas! I will test lockdep_annotate_inode_mutex_key
after inode_init_owner in shmem and let you know if the issue goes
away. It seems hugetlbfs does this too (I think for similar reasons).
- Joel
Compliment of the day to you. Dear Friend.
Compliment of the day to you. Dear Friend. for security reason contact me Through this email (mrschantal.sonian.k...@gmail.com) Dear Friend. I am Mrs.Chantal Sonian Kadi. am sending this brief letter to solicit your partnership to transfer $10.5 million US Dollars. I shall send you more information and procedures when I receive positive response from you. please send me a message in my Email box (mrschantal.sonian. k...@gmail.com) Coupy This Email Id (mrschantal.sonian.k...@gmail.com)To Reply Me with this Id(mrschantal.sonian.k...@gmail.com) Mrs.Chantal Sonian Kadi
Re: [PATCH 7/8] docs: kernel-doc: Finish moving STATE_* code out of process_file()
On Wed, Feb 07, 2018 at 10:26:23AM -0700, Jonathan Corbet wrote:
> Move STATE_INLINE and STATE_DOCBLOCK code out of process_file(), which now
> actually fits on a single screen. Delete an unused variable and add a
> couple of comments while I'm at it.
>
> Signed-off-by: Jonathan Corbet
> ---
> scripts/kernel-doc | 145
> ++---
> 1 file changed, 83 insertions(+), 62 deletions(-)
>
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 2deddb876156..c6c9370a1e49 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1990,10 +1990,86 @@ sub process_proto($$) {
> }
> }
>
> +#
> +# STATE_DOCBLOCK: within a DOC: block.
> +#
> +sub process_docblock($$) {
> +my $file = shift;
> +
> +if (/$doc_end/)
> +{
> + dump_doc_section($file, $section, $contents);
> + $section = $section_default;
> + $contents = "";
> + $function = "";
> + %parameterdescs = ();
> + %parametertypes = ();
> + @parameterlist = ();
> + %sections = ();
> + @sectionlist = ();
> + $prototype = "";
> + $state = STATE_NORMAL;
> +}
> +elsif (/$doc_content/)
> +{
> + if ( $1 eq "" )
> + {
> + $contents .= $blankline;
> + }
> + else
> + {
> + $contents .= $1 . "\n";
> + }
> +}
> +}
It doesn't appear to be introduced by you but the brace positions are
non-uniform in this patch.
if
{
...
}
else
{
...
}
instead of
if {
...
} else {
eee
}
Hope this helps,
Tobin.
(rest of patch left intentionally for reference)
> +
> +#
> +# STATE_INLINE: docbook comments within a prototype.
> +#
> +sub process_inline($$) {
> +my $file = shift;
> +
> +# First line (state 1) needs to be a @parameter
> +if ($inline_doc_state == STATE_INLINE_NAME && /$doc_inline_sect/o) {
> + $section = $1;
> + $contents = $2;
> + $new_start_line = $.;
> + if ($contents ne "") {
> + while (substr($contents, 0, 1) eq " ") {
> + $contents = substr($contents, 1);
> + }
> + $contents .= "\n";
> + }
> + $inline_doc_state = STATE_INLINE_TEXT;
> + # Documentation block end */
> +} elsif (/$doc_inline_end/) {
> + if (($contents ne "") && ($contents ne "\n")) {
> + dump_section($file, $section, $contents);
> + $section = $section_default;
> + $contents = "";
> + }
> + $state = STATE_PROTO;
> + $inline_doc_state = STATE_INLINE_NA;
> + # Regular text
> +} elsif (/$doc_content/) {
> + if ($inline_doc_state == STATE_INLINE_TEXT) {
> + $contents .= $1 . "\n";
> + # nuke leading blank lines
> + if ($contents =~ /^\s*$/) {
> + $contents = "";
> + }
> + } elsif ($inline_doc_state == STATE_INLINE_NAME) {
> + $inline_doc_state = STATE_INLINE_ERROR;
> + print STDERR "${file}:$.: warning: ";
> + print STDERR "Incorrect use of kernel-doc format: $_";
> + ++$warnings;
> + }
> +}
> +}
> +
>
> sub process_file($) {
> my $file;
> -my $func;
> my $initial_section_counter = $section_counter;
> my ($orig_file) = @_;
>
> @@ -2014,6 +2090,8 @@ sub process_file($) {
> }
> # Replace tabs by spaces
> while ($_ =~ s/\t+/' ' x (length($&) * 8 - length($`) % 8)/e) {};
> +
> + # Hand this line to the appropriate state handler
> if ($state == STATE_NORMAL) {
> process_normal();
> } elsif ($state == STATE_NAME) {
> @@ -2021,72 +2099,15 @@ sub process_file($) {
> } elsif ($state == STATE_BODY || $state == STATE_BODY_MAYBE) {
> process_body($file, $_);
> } elsif ($state == STATE_INLINE) { # scanning for inline parameters
> - # First line (state 1) needs to be a @parameter
> - if ($inline_doc_state == STATE_INLINE_NAME && /$doc_inline_sect/o) {
> - $section = $1;
> - $contents = $2;
> -$new_start_line = $.;
> - if ($contents ne "") {
> - while (substr($contents, 0, 1) eq " ") {
> - $contents = substr($contents, 1);
> - }
> - $contents .= "\n";
> - }
> - $inline_doc_state = STATE_INLINE_TEXT;
> - # Documentation block end */
> - } elsif (/$doc_inline_end/) {
> - if (($contents ne "") && ($contents ne "\n")) {
> - dump_section($file, $section, $contents);
> - $section = $section_default;
> - $contents = "";
> - }
> - $state = STATE_PROTO;
> - $inline_doc_state = STATE_INLINE_NA;
> - # Regular text
> - } elsif (/$doc_content/) {
> - if ($inline_doc_state == STATE_INLINE_TEXT) {
> - $contents .= $1 . "\n";
> - # nuke leading blank lines
> - if ($contents =~ /^\s*$/) {
> -
Re: [PATCH 8/8] docs: kernel-doc: Don't mangle literal code blocks in comments
On Wed, Feb 07, 2018 at 10:26:24AM -0700, Jonathan Corbet wrote: [snip] >if (desperate) >run_in_circles(); this is gold :)
[PATCH v6 2/3] DT/arm,gic-v3-its: add reset-on-suspend property
This adds documentation for the new reset-on-suspend property. This property enables saving and restoring the ITS for when it loses state in system suspend. Signed-off-by: Derek Basehore --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt index 0a57f2f4167d..a470147d4f14 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt @@ -78,6 +78,9 @@ These nodes must have the following properties: Optional: - socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated address and size of the pre-ITS window. +- reset-on-suspend: Boolean property. Indicates that the ITS state is + reset on suspend. The state is then saved on suspend and restored on + resume. The main GIC node must contain the appropriate #address-cells, #size-cells and ranges properties for the reg property of all ITS -- 2.16.0.rc1.238.g530d649a79-goog
[PATCH v6 0/3] GICv3 Save and Restore
A lot of changes in v2. The distributor and redistributor saving and restoring is left to the PSCI/firmware implementation after discussions with ARM. This reduces the line changes by a lot and removes now unneeded patches. Patches are verified on an RK3399 platform with pending patches in the ARM-Trusted-Firmware project. Just a couple minor changes in v3 to formatting. Fixed a false ITS wedged detection due to the cmd_write and creadr offsets not matching up on reset in v4. Also minor formatting changes. Got rid of additional device tree property with detecting if there are collections stored in the ITS in v5. Made other minor changes. v6: Fixed reinitialized collections to only happen when the collection is stored in the ITS. Changed error handling to avoid undefined behavior of the ITS. Derek Basehore (3): irqchip/gic-v3-its: add ability to save/restore ITS state DT/arm,gic-v3-its: add reset-on-suspend property irqchip/gic-v3-its: add ability to resend MAPC on resume .../bindings/interrupt-controller/arm,gic-v3.txt | 3 + drivers/irqchip/irq-gic-v3-its.c | 189 - include/linux/irqchip/arm-gic-v3.h | 1 + 3 files changed, 155 insertions(+), 38 deletions(-) -- 2.16.0.rc1.238.g530d649a79-goog
[PATCH v6 3/3] irqchip/gic-v3-its: add ability to resend MAPC on resume
This adds functionality to resend the MAPC command to an ITS node on
resume. If the ITS is powered down during suspend and the collections
are not backed by memory, the ITS will lose that state. This just sets
up the known state for the collections after the ITS is restored.
This is enabled via the reset-on-suspend flag in the DTS. It only runs
for collections stored in the ITS itself.
Signed-off-by: Derek Basehore
---
drivers/irqchip/irq-gic-v3-its.c | 86 +-
include/linux/irqchip/arm-gic-v3.h | 1 +
2 files changed, 49 insertions(+), 38 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 35ad48f51dfa..a564a92ab169 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1942,52 +1942,53 @@ static void its_cpu_init_lpis(void)
dsb(sy);
}
-static void its_cpu_init_collection(void)
+static void its_cpu_init_collection(struct its_node *its)
{
- struct its_node *its;
- int cpu;
-
- spin_lock(&its_lock);
- cpu = smp_processor_id();
-
- list_for_each_entry(its, &its_nodes, entry) {
- u64 target;
+ int cpu = smp_processor_id();
+ u64 target;
- /* avoid cross node collections and its mapping */
- if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
- struct device_node *cpu_node;
+ /* avoid cross node collections and its mapping */
+ if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
+ struct device_node *cpu_node;
- cpu_node = of_get_cpu_node(cpu, NULL);
- if (its->numa_node != NUMA_NO_NODE &&
- its->numa_node != of_node_to_nid(cpu_node))
- continue;
- }
+ cpu_node = of_get_cpu_node(cpu, NULL);
+ if (its->numa_node != NUMA_NO_NODE &&
+ its->numa_node != of_node_to_nid(cpu_node))
+ return;
+ }
+ /*
+* We now have to bind each collection to its target
+* redistributor.
+*/
+ if (gic_read_typer(its->base + GITS_TYPER) & GITS_TYPER_PTA) {
/*
-* We now have to bind each collection to its target
+* This ITS wants the physical address of the
* redistributor.
*/
- if (gic_read_typer(its->base + GITS_TYPER) & GITS_TYPER_PTA) {
- /*
-* This ITS wants the physical address of the
-* redistributor.
-*/
- target = gic_data_rdist()->phys_base;
- } else {
- /*
-* This ITS wants a linear CPU number.
-*/
- target = gic_read_typer(gic_data_rdist_rd_base() +
GICR_TYPER);
- target = GICR_TYPER_CPU_NUMBER(target) << 16;
- }
+ target = gic_data_rdist()->phys_base;
+ } else {
+ /* This ITS wants a linear CPU number. */
+ target = gic_read_typer(gic_data_rdist_rd_base() + GICR_TYPER);
+ target = GICR_TYPER_CPU_NUMBER(target) << 16;
+ }
- /* Perform collection mapping */
- its->collections[cpu].target_address = target;
- its->collections[cpu].col_id = cpu;
+ /* Perform collection mapping */
+ its->collections[cpu].target_address = target;
+ its->collections[cpu].col_id = cpu;
- its_send_mapc(its, &its->collections[cpu], 1);
- its_send_invall(its, &its->collections[cpu]);
- }
+ its_send_mapc(its, &its->collections[cpu], 1);
+ its_send_invall(its, &its->collections[cpu]);
+}
+
+static void its_cpu_init_collections(void)
+{
+ struct its_node *its;
+
+ spin_lock(&its_lock);
+
+ list_for_each_entry(its, &its_nodes, entry)
+ its_cpu_init_collection(its);
spin_unlock(&its_lock);
}
@@ -3131,6 +3132,15 @@ static void its_restore_enable(void)
its_write_baser(its, baser, baser->val);
}
writel_relaxed(its->ctlr_save, base + GITS_CTLR);
+
+ /*
+* Reinit the collection if it's stored in the ITS. This is
+* indicated by the col_id being less than the HWCOLLCNT.
+* CID < HCC as specified in the GIC v3 Documentation.
+*/
+ if (its->collections[smp_processor_id()].col_id <
+ GITS_TYPER_HWCOLLCNT(gic_read_typer(base + GITS_TYPER)))
+ its_cpu_init_collection(its);
}
spin_unlock(&its_lock);
}
@@ -3397,7 +3407,7 @@ int its_cpu_init(void)
return -ENXIO;
}
[PATCH v6 1/3] irqchip/gic-v3-its: add ability to save/restore ITS state
Some platforms power off GIC logic in suspend, so we need to
save/restore state. The distributor and redistributor registers need
to be handled in platform code due to access permissions on those
registers, but the ITS registers can be restored in the kernel.
Signed-off-by: Derek Basehore
---
drivers/irqchip/irq-gic-v3-its.c | 103 +++
1 file changed, 103 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 06f025fd5726..35ad48f51dfa 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -46,6 +47,7 @@
#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
#define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
#define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
+#define ITS_FLAGS_SAVE_SUSPEND_STATE (1ULL << 3)
#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
@@ -101,6 +103,8 @@ struct its_node {
struct its_collection *collections;
struct fwnode_handle*fwnode_handle;
u64 (*get_msi_base)(struct its_device *its_dev);
+ u64 cbaser_save;
+ u32 ctlr_save;
struct list_headits_device_list;
u64 flags;
unsigned long list_nr;
@@ -3042,6 +3046,100 @@ static void its_enable_quirks(struct its_node *its)
gic_enable_quirks(iidr, its_quirks, its);
}
+static int its_save_disable(void)
+{
+ struct its_node *its;
+ int err = 0;
+
+ spin_lock(&its_lock);
+ list_for_each_entry(its, &its_nodes, entry) {
+ void __iomem *base;
+
+ if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
+ continue;
+
+ base = its->base;
+ its->ctlr_save = readl_relaxed(base + GITS_CTLR);
+ err = its_force_quiescent(base);
+ if (err) {
+ pr_err("ITS failed to quiesce\n");
+ writel_relaxed(its->ctlr_save, base + GITS_CTLR);
+ goto err;
+ }
+
+ its->cbaser_save = gits_read_cbaser(base + GITS_CBASER);
+ }
+
+err:
+ if (err) {
+ list_for_each_entry_continue_reverse(its, &its_nodes, entry) {
+ void __iomem *base;
+
+ if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
+ continue;
+
+ base = its->base;
+ writel_relaxed(its->ctlr_save, base + GITS_CTLR);
+ }
+ }
+ spin_unlock(&its_lock);
+
+ return err;
+}
+
+static void its_restore_enable(void)
+{
+ struct its_node *its;
+
+ spin_lock(&its_lock);
+ list_for_each_entry(its, &its_nodes, entry) {
+ void __iomem *base;
+ int i;
+
+ if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE))
+ continue;
+
+ base = its->base;
+
+ /*
+* Make sure that the ITS is disabled. If it fails to quiesce,
+* don't restore it since writing to CBASER or BASER
+* registers is undefined according to the GIC v3 ITS
+* Specification.
+*/
+ if (its_force_quiescent(base)) {
+ pr_err("ITS(%p): failed to quiesce on resume\n", base);
+ continue;
+ }
+
+ gits_write_cbaser(its->cbaser_save, base + GITS_CBASER);
+
+ /*
+* Writing CBASER resets CREADR to 0, so make CWRITER and
+* cmd_write line up with it.
+*/
+ its->cmd_write = its->cmd_base;
+ gits_write_cwriter(0, base + GITS_CWRITER);
+
+ /* Restore GITS_BASER from the value cache. */
+ for (i = 0; i < GITS_BASER_NR_REGS; i++) {
+ struct its_baser *baser = &its->tables[i];
+
+ if (!(baser->val & GITS_BASER_VALID))
+ continue;
+
+ its_write_baser(its, baser, baser->val);
+ }
+ writel_relaxed(its->ctlr_save, base + GITS_CTLR);
+ }
+ spin_unlock(&its_lock);
+}
+
+static struct syscore_ops its_syscore_ops = {
+ .suspend = its_save_disable,
+ .resume = its_restore_enable,
+};
+
static int its_init_domain(struct fwnode_handle *handle, struct its_node *its)
{
struct irq_domain *inner_domain;
@@ -3261,6 +3359,9 @@ static int __init its_probe_one(struct resource *res,
ctlr |= GITS_CTLR_ImDe;
writel_relaxed(ctlr, its->base + GITS_CTLR);
+ if (fwnode_property_present(handle, "reset-on-suspend"))
+ its->flags |= ITS_FLA
Re: [PATCH] ACPI/IORT: Remove linker section for IORT entries again
On 2/7/2018 7:41 PM, Lorenzo Pieralisi Wrote:
On Tue, Feb 06, 2018 at 08:11:34PM -0800, Jia He wrote:
In commit 316ca8804ea8 ("ACPI/IORT: Remove linker section for IORT entries
probing"), iort entries was removed in vmlinux.lds.h. But in
commit 2fcc112af37f ("clocksource/drivers: Rename clksrc table to timer"),
this line was back incorrectly.
It does no harm except for adding some useless symbols, so fix it.
Signed-off-by: Jia He
forget to add another Signed-off-by line(because of my company's
opensource rules)
Signed-off-by: Jia He
---
include/asm-generic/vmlinux.lds.h | 1 -
1 file changed, 1 deletion(-)
Acked-by: Lorenzo Pieralisi
Who is picking this up ?
Sorry, do you mean who is picking up acpi/iort subsystem?
I can't answer this question. I find this minor bug while doing the code
review.
Cheers,
Jia
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 1ab0e52..58b1dab 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -589,7 +589,6 @@
IRQCHIP_OF_MATCH_TABLE()\
ACPI_PROBE_TABLE(irqchip) \
ACPI_PROBE_TABLE(timer) \
- ACPI_PROBE_TABLE(iort) \
EARLYCON_TABLE()
#define INIT_TEXT \
--
2.7.4
