Re: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
On Fri, 2015-02-20 at 16:23 +0100, Peter Meerwald wrote:
> > > > > +
> > > > > + values[i] = data & 0xFF;
> > > > > + values[i+1] = data >> 8;
> > > >
> > > > this is incorrect; it forces the data to be little endian, however, the
> > > > endianness (as specified in the driver's .scan_type) is IIO_CPU -- the
> > > > code breaks for big-endian CPUs
> > > >
> > > > since _read_i2c_block_data() can't do endianness conversion (and the
> > > > chip
> > > > does i2c endianness, i.e. little-endian), the .scan_type should become
> > > > IIO_LE and above code is correct again but still ugly :)
> > > >
> > > > bottom line: change .scan_type to IIO_LE
> > > >
> > > Good point. Changing the endianess to IIO_LE is correct for either
> > > kxcjk1013_read_block_data or i2c_smbus_read_i2c_block_data.
> > > Will fix this in the next version. Thanks for catching this!
> > >
> > I don't think changing to IIO_LE is good idea as when i2c_read_bock..
> > then the scan type will be CPU. So better to fix endianness in this
> > function.
>
> the chip has little-endian data registers; i2c_read_block() just transfers
> the data (no endianness conversion), so the data will still be
> little-endian
You are right.
>
> p.
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
> > > > + > > > > + values[i] = data & 0xFF; > > > > + values[i+1] = data >> 8; > > > > > > this is incorrect; it forces the data to be little endian, however, the > > > endianness (as specified in the driver's .scan_type) is IIO_CPU -- the > > > code breaks for big-endian CPUs > > > > > > since _read_i2c_block_data() can't do endianness conversion (and the chip > > > does i2c endianness, i.e. little-endian), the .scan_type should become > > > IIO_LE and above code is correct again but still ugly :) > > > > > > bottom line: change .scan_type to IIO_LE > > > > > Good point. Changing the endianess to IIO_LE is correct for either > > kxcjk1013_read_block_data or i2c_smbus_read_i2c_block_data. > > Will fix this in the next version. Thanks for catching this! > > > I don't think changing to IIO_LE is good idea as when i2c_read_bock.. > then the scan type will be CPU. So better to fix endianness in this > function. the chip has little-endian data registers; i2c_read_block() just transfers the data (no endianness conversion), so the data will still be little-endian p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] thinkpad_acpi: Add adaptive_kbd_mode sysfs attr
On Fri, 2015-02-20 at 17:20 +0200, Mika Westerberg wrote: > On Fri, Feb 20, 2015 at 03:44:22PM +0100, Bastien Nocera wrote: > > Add a sysfs attribute to allow privileged users to change the keyboard > > mode. This could be used by desktop environments to change the keyboard > > mode depending on the application focused, as the Windows application > > does. > > If you are adding new sysfs attributes, you should document them as well > in Documentation/ABI/*. None of the thinkpad_acpi sysfs attributes are documented there, or I'm missing something obvious. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models
> Am 20.02.2015 um 16:00 schrieb Michael Mueller :
>
> On Fri, 20 Feb 2015 14:54:23 +0100
> Alexander Graf wrote:
>
>>>
>>> +/* machine related properties */
>>> +typedef struct S390CPUMachineProps {
>>> +uint16_t class; /* machine class */
>>> +uint16_t ga; /* availability number of machine */
>>> +uint16_t order; /* order of availability */
>>> +} S390CPUMachineProps;
>>> +
>>> +/* processor related properties */
>>> +typedef struct S390CPUProcessorProps {
>>> +uint16_t gen;/* S390 CMOS generation */
>>> +uint16_t ver;/* version of processor */
>>> +uint32_t id; /* processor identification*/
>>> +uint16_t type; /* machine type */
>>> +uint16_t ibc;/* IBC value */
>>> +uint64_t *fac_list; /* list of facilities */
>>
>> Just make this uint64_t fac_list[2]. That way we don't have to track any
>> messy allocations.
>
> It will be something like "uint64_t fac_list[S390_CPU_FAC_LIST_SIZE_UINT64]"
> and in total 2KB not
> just 16 bytes but I will change it.
Why? Do we actually need that many? This is a qemu internal struct.
Alex--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] thinkpad_acpi: Add adaptive_kbd_mode sysfs attr
On Fri, Feb 20, 2015 at 03:44:22PM +0100, Bastien Nocera wrote: > Add a sysfs attribute to allow privileged users to change the keyboard > mode. This could be used by desktop environments to change the keyboard > mode depending on the application focused, as the Windows application > does. If you are adding new sysfs attributes, you should document them as well in Documentation/ABI/*. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -stable] ath6kl: fix struct hif_scatter_req list handling
Josh Cartwright writes: > From: Kalle Valo > > commit 31b9cc9a873dcab161999622314f98a75d838975 upstream. > > Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf > command: > > iperf -c $TARGET_IP -i 5 -t 50 -w 1M > > The crash was: > > Unable to handle kernel paging request at virtual address 1a48 > pgd = 80004000 > [1a48] *pgd= > Internal error: Oops: 805 [#1] SMP ARM > Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core] > CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1 > Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio] > task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000 > PC is at v7_dma_clean_range+0x20/0x38 > LR is at dma_cache_maint_page+0x50/0x54 > pc : [<8001a6f8>]lr : [<800170fc>]psr: 2093 > sp : dc9afcf8 ip : 8001a748 fp : 0004 > r10: r9 : 0001 r8 : > r7 : 0001 r6 : r5 : 80cb7000 r4 : 03f9a480 > r3 : 001f r2 : 0020 r1 : 1a48 r0 : 1a48 > Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 10c53c7d Table: 6cc5004a DAC: 0015 > Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238) > Stack: (0xdc9afcf8 to 0xdc9b) > fce0: 80c9b29c > fd00: 80017134 8001a748 dc302ac0 dc454a00 80c12ed8 > fd20: dc115410 80017238 dc454a10 0001 80017588 0001 > fd40: dc302ac0 dc9afe38 dc9afe68 0004 80c12ed8 dc454a00 > fd60: 0004 80436f88 0600 000c 80c113c4 > fd80: 80c9b29c 0001 0004 dc115470 6013 dc302ac0 dc46e000 dc302800 > fda0: dc9afe10 dc302b78 6013 dc302ac0 dc46e000 0035 dc46e5b0 80438c90 > fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 0005 dc9afe10 > fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00 > fe00: 01b5 7f619d64 dcc7c830 dc9afe38 dc9afe68 > fe20: dc9afe28 dc9afe28 80424d80 0035 9cac0034 > fe40: 01b5 > fe60: dc9afe68 dc9afe10 3b9aca00 0080 0034 0100 > fe80: dc9afe10 0004 dc454a00 dc46e010 dc46e96c > fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 0600 80c0e770 > fec0: dc15a900 dcc7c838 dc46e954 8042d434 dcc44680 dc46e954 dc004400 > fee0: dc454500 dc9ae038 dc004400 8003c450 dcc44680 dc004414 > ff00: dc46e954 dc454500 0001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030 > ff20: 0001 dc9ae000 dc004400 8003d158 8003d020 80c53941 > ff40: dc9aff64 dcb71ea0 dcc44680 8003d020 > ff60: 80042480 00f8 dcc44680 > ff80: dc9aff80 dc9aff80 dc9aff90 dc9aff90 dc9affac dcb71ea0 > ffa0: 800423cc 8000e018 > ffc0: > ffe0: 0013 > [<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] > (dma_cache_maint_page+0x50/0x54) > [<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] > (__dma_page_cpu_to_dev+0x34/0x9c) > [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] > (arm_dma_map_page+0x64/0x68) > [<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] > (arm_dma_map_sg+0x7c/0xf4) > [<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] > (sdhci_send_command+0x894/0xe00) > [<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] > (sdhci_request+0xc0/0x1ec) > [<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] > (mmc_start_request+0xb8/0xd4) > [<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] > (__mmc_start_req+0x60/0x84) > [<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] > (mmc_wait_for_req+0x10/0x20) > [<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] > (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) > [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from > [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) > [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from > [<8003c450>] (process_one_work+0x10c/0x370) > [<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] > (worker_thread+0x138/0x3fc) > [<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] (kthread+0xb4/0xb8) > [<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c) > Code: e1a02312 e2423001 e1c3 f57ff04f (ee070f3a) > ---[ end trace 0c038f0b8e0b67a3 ]--- > Kernel panic - not syncing: Fatal exception > > Jason's analysis: > > "The GCC 4.8.1 compiler will not do the for-loop till scat_entries,
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
> > * The pmc looks like it could be a valid use of the new flag. It also > > seems to function as an irqchip. > > > > Do any of its child IRQs need to be handled during the suspend-resume > > cycle? If so using IRQF_NO_SUSPEND would seem to be valid. > > No they don't, they are used for clock activation only, and thus should > be disabled on suspend. Ok. So the IRQF_SHARED_TIMER_OK flag would make sense here. > > * atmel_serial seems to be intended to be used as a wakeup device (given > > it calls device_set_wakeup_enable). Therefore it needs to call > > enable_irq_wake, and when it does so it can share an IRQ with other > > interrupts, just not IRQF_NO_SUSPEND interrupts. > > I'll have a look, but AFAIR serial core already taking care of that. > > > > > None of the approaches thus far can fix the fundamental mismatch > > between wakeup interrupts and IRQF_NO_SUSPEND interrupts. > > > > * Similarly, rtc-at91rm9200 and rtc-at91sam9 are intended to be used as > > wakeup devices. They call enable_irq_wake (though don't bother > > checking the return value). They can share an IRQ with other > > interrupts, just not IRQF_NO_SUSPEND interrupts. > > Yep. > > > > > * at91sam9_wdt seems to be fundamentally incompatible with suspend. If > > the watchdog cannot be disabled, and you need to handle it during > > suspend, then it needs to be a wakeup interrupt, not an > > IRQF_NO_SUSPEND interrupt. If they're not shared with an IRQF_NO_SUSPEND IRQ, then everything is already OK. If they are shared with an IRQF_NO_SUSPEND IRQ, then the fundamental problem is not solved by any approach so far. > You forgot the PIT timer, which is the one in cause here (no other > drivers are specifying this IRQF_NO_SUSPEND flag), and, as you already > know, a timer sets the IRQF_NO_SUSPEND flag. > > > As far as I can see, the flag or virtual irqchip approaches only help > > the PMC case, and even then might not be necessary. All the others seem > > to be relying on guarantees the genirq layer don't provide, and fixing > > that would mean moving them further from IRQF_NO_SUSPEND. > > I don't know what you're trying to prove here, but I never said my goal > was to set IRQF_NO_SUSPEND flags on existing at91 drivers ? > The problem here, is that all those IPs are sharing the irq line with a > timer which sets IRQF_NO_SUSPEND. As Rafael and I described, sharing an IRQ between a wakeup device (the serial, rtc, and wdt) and an IRQF_NO_SUSPEND device is broken. You have the choice between losing wakeup events or masking timer events. So those device above which operate as wakeup devices cannot share a line with a timer. > I just want to be able to share an irq line with a timer and other > devices that do not set IRQF_NO_SUSPEND. > Could we focus on that ? I'm trying to focus on the cases we can actually salvage. An IRQ cannot be shared between a device with IRQF_NO_SUSPEND and a device that wishes to operate as a wakeup device, because the semantics don't align. One wishes to handle IRQs continuously and one wants to abort suspend at the first IRQ (waiting until part-way through the resume before handling it). So those devices above which wish to operate as wakeup devices are either irrelevant or unsalvageable with the current approaches. The flag or demux chip only happens to mask the problem in the absence of strict sanity checking. If you want to be able to share the line then you will need to fundamentally rework the way wakeup interrupts work in order to be able to decide when you've encountered a real wakeup event. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [RFC PATCH v2 09/15] cpu-model/s390: Add KVM VM attribute interface routines
On Fri, 20 Feb 2015 14:59:20 +0100
Alexander Graf wrote:
> > +typedef struct S390ProcessorProps {
> > +uint64_t cpuid;
> > +uint16_t ibc;
> > +uint8_t pad[6];
> > +uint64_t fac_list[S390_ARCH_FAC_LIST_SIZE_UINT64];
> > +} S390ProcessorProps;
> > +
> > +typedef struct S390MachineProps {
> > +uint64_t cpuid;
> > +uint32_t ibc_range;
> > +uint8_t pad[4];
> > +uint64_t fac_list_mask[S390_ARCH_FAC_LIST_SIZE_UINT64];
> > +uint64_t fac_list[S390_ARCH_FAC_LIST_SIZE_UINT64];
> > +} S390MachineProps;
>
> What are those structs there for? To convert between a kvm facing
> interface to an internal interface?
Yes, that's their current use, but if the interface structs:
+struct kvm_s390_vm_cpu_processor {
+ __u64 cpuid;
+ __u16 ibc;
+ __u8 pad[6];
+ __u64 fac_list[256];
+};
+
+/* kvm S390 machine related attributes are r/o */
+#define KVM_S390_VM_CPU_MACHINE1
+struct kvm_s390_vm_cpu_machine {
+ __u64 cpuid;
+ __u32 ibc_range;
+ __u8 pad[4];
+ __u64 fac_mask[256];
+ __u64 fac_list[256];
+};
are visible here, I'll reuse them... But stop, that will not work in the
--disable-kvm case... I need them!
>
> I don't think they're necessary. The internal layout is visible from the
> KVM code. Just either spawn the class straight from the kvm file or if
> you consider that ugly, pass the values of that struct that you need as
> function parameters to a function in cpu-models.c.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 02/20/2015 04:10 PM, Paolo Bonzini wrote: > On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote: >> On 02/20/2015 03:57 PM, Paolo Bonzini wrote: > >>> Yes, but large latencies just mean the code has to be rewritten (x86 >>> doesn't anymore do event injection in an atomic regions for example). >>> Until it is, using raw_spin_lock is correct. >> >> It does not sound like it. It sounds more like disabling interrupts to >> get things run faster and then limit it on a different corner to not >> blow up everything. > > "This patchset enables running KVM SMP guests with external interrupts > on an underlying RT-enabled Linux. Previous to this patch, a guest with > in-kernel MPIC emulation could easily panic the kernel due to preemption > when delivering IPIs and external interrupts, because of the openpic > spinlock becoming a sleeping mutex on PREEMPT_RT_FULL Linux". > >> Max latencies was decreased "Max latency (us) 7062" and that >> is why this is done? For 8 us and possible DoS in case there are too >> many cpus? > > My understanding is that: > > 1) netperf can get you a BUG KVM, and raw_spinlock fixes that May I please see a backtrace with context tracking which states where the interrupts / preemption gets disabled and where the lock was taken? I'm not totally against this patch I just want to make sure this is not a blind raw conversation to shup up the warning the kernel throws. > 2) cyclictest did not trigger the BUG, and you can also get reduced > latency from using raw_spinlock. > > I think we agree that (2) is not a factor in accepting the patch. good :) > > Paolo > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] of: DT quirks infrastructure
On 02/20/2015 09:35 AM, Ludovic Desroches wrote: > On Fri, Feb 20, 2015 at 09:21:38AM -0500, Peter Hurley wrote: >> On 02/19/2015 12:38 PM, Pantelis Antoniou wrote: >>> On Feb 19, 2015, at 19:30 , Frank Rowand wrote: On 2/19/2015 9:00 AM, Pantelis Antoniou wrote: > Hi Frank, > >> On Feb 19, 2015, at 18:48 , Frank Rowand wrote: >> >> On 2/19/2015 6:29 AM, Pantelis Antoniou wrote: >>> Hi Mark, >>> On Feb 18, 2015, at 19:31 , Mark Rutland wrote: >>> +While this may in theory work, in practice it is very cumbersome >>> +for the following reasons: >>> + >>> +1. The act of selecting a different boot device tree blob requires >>> +a reasonably advanced bootloader with some kind of configuration or >>> +scripting capabilities. Sadly this is not the case many times, the >>> +bootloader is extremely dumb and can only use a single dt blob. >> >> You can have several bootloader builds, or even a single build with >> something like appended DTB to get an appropriate DTB if the same >> binary >> will otherwise work across all variants of a board. >> > > No, the same DTB will not work across all the variants of a board. I wasn't on about the DTB. I was on about the loader binary, in the case the FW/bootloader could be common even if the DTB couldn't. To some extent there must be a DTB that will work across all variants (albeit with limited utility) or the quirk approach wouldn't work… >>> >>> That’s not correct; the only part of the DTB that needs to be common >>> is the model property that would allow the quirk detection logic to >>> fire. >>> >>> So, there is a base DTB that will work on all variants, but that only >>> means >>> that it will work only up to the point that the quirk detector method >>> can work. So while in recommended practice there are common subsets >>> of the DTB that might work, they might be unsafe. >>> >>> For instance on the beaglebone the regulator configuration is different >>> between white and black, it is imperative you get them right otherwise >>> you risk board damage. >>> >> So it's not necessarily true that you need a complex bootloader. >> > >>> +2. On many instances boot time is extremely critical; in some cases >>> +there are hard requirements like having working video feeds in >>> under >>> +2 seconds from power-up. This leaves an extremely small time >>> budget for >>> +boot-up, as low as 500ms to kernel entry. The sanest way to get >>> there >>> +is by removing the standard bootloader from the normal boot >>> sequence >>> +altogether by having a very small boot shim that loads the kernel >>> and >>> +immediately jumps to kernel, like falcon-boot mode in u-boot does. >> >> Given my previous comments above I don't see why this is relevant. >> You're already passing _some_ DTB here, so if you can organise for >> the >> board to statically provide a sane DTB that's fine, or you can >> resort to >> appended DTB if it's not possible to update the board configuration. >> > > You’re missing the point. I can’t use the same DTB for each revision > of the > board. Each board is similar but it’s not identical. I think you've misunderstood my point. If you program the board with the relevant DTB, or use appended DTB, then you will pass the correct DTB to the kernel without need for quirks. I understand that each variant is somewhat incompatible (and hence needs its own DTB). >>> >>> In theory it might work, in practice this does not. Ludovic mentioned >>> that they >>> have 27 different DTBs in use at the moment. At a relatively common 60k >>> per DTB >>> that’s 27x60k = 1.6MB of DTBs, that need to be installed. >> >> < snip > >> >> Or you can install the correct DTB on the board. You trust your >> manufacturing line >> to install the correct resistors. You trust your manufacturing line to >> install the >> correct kernel version (eg an updated version to resolve a security >> issue). >> >> I thought the DT blob was supposed to follow the same standard that >> other OS's or >> bootloaders understood. Are you willing to break that? (This is one of >> those >> ripples I mentioned in my other emails.) >> > > Trust no-one. > > This is one of those things that the kernel community doesn’t understand > which makes people > who push product quite mad. >>
Re: [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models
On Fri, 20 Feb 2015 14:54:23 +0100
Alexander Graf wrote:
> >
> > +/* machine related properties */
> > +typedef struct S390CPUMachineProps {
> > +uint16_t class; /* machine class */
> > +uint16_t ga; /* availability number of machine */
> > +uint16_t order; /* order of availability */
> > +} S390CPUMachineProps;
> > +
> > +/* processor related properties */
> > +typedef struct S390CPUProcessorProps {
> > +uint16_t gen;/* S390 CMOS generation */
> > +uint16_t ver;/* version of processor */
> > +uint32_t id; /* processor identification*/
> > +uint16_t type; /* machine type */
> > +uint16_t ibc;/* IBC value */
> > +uint64_t *fac_list; /* list of facilities */
>
> Just make this uint64_t fac_list[2]. That way we don't have to track any
> messy allocations.
It will be something like "uint64_t fac_list[S390_CPU_FAC_LIST_SIZE_UINT64]"
and in total 2KB not
just 16 bytes but I will change it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] input: Add keycodes used by Lenovo Carbon X1 2014
On Fri, Feb 20, 2015 at 9:44 AM, Bastien Nocera wrote:
> Signed-off-by: Bastien Nocera
> ---
> include/uapi/linux/input.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index b0a8130..affe40e 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -740,6 +740,16 @@ struct input_keymap_entry {
> #define KEY_BRIGHTNESS_MIN 0x250 /* Set Brightness to Minimum
> */
> #define KEY_BRIGHTNESS_MAX 0x251 /* Set Brightness to Maximum
> */
>
> +#define KEY_CLIPPING_TOOL 0x252 /* Screenshot clipping tool */
> +#define KEY_CLOUD 0x253 /* Cloud Settings */
> +#define KEY_CAMERA_GESTURES0x254 /* Toggle Camera gestures */
> +#define KEY_NEW_TAB0x255 /* Open a new tab */
> +#define KEY_MICUP 0x256 /* Microphone Up */
> +#define KEY_MICDOWN0x257 /* Microphone Down */
> +#define KEY_MICCANCEL_MODE 0x258 /* Toggle Microphone
> cancellation mode */
> +#define KEY_CAMERA_ZOOM_MODE 0x259 /* Toggle camera zoom mode */
> +#define KEY_ROTATE_DISPLAY 0x25a /* Rotate screen by 90
> degrees */
> +
This one should be acked by Dmitry (in CC)
Cheers,
Benjamin
> #define KEY_KBDINPUTASSIST_PREV0x260
> #define KEY_KBDINPUTASSIST_NEXT0x261
> #define KEY_KBDINPUTASSIST_PREVGROUP 0x262
> --
> 2.1.0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> platform-driver-x86" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote: > On 02/20/2015 03:57 PM, Paolo Bonzini wrote: >> Yes, but large latencies just mean the code has to be rewritten (x86 >> doesn't anymore do event injection in an atomic regions for example). >> Until it is, using raw_spin_lock is correct. > > It does not sound like it. It sounds more like disabling interrupts to > get things run faster and then limit it on a different corner to not > blow up everything. "This patchset enables running KVM SMP guests with external interrupts on an underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel MPIC emulation could easily panic the kernel due to preemption when delivering IPIs and external interrupts, because of the openpic spinlock becoming a sleeping mutex on PREEMPT_RT_FULL Linux". > Max latencies was decreased "Max latency (us) 7062" and that > is why this is done? For 8 us and possible DoS in case there are too > many cpus? My understanding is that: 1) netperf can get you a BUG KVM, and raw_spinlock fixes that 2) cyclictest did not trigger the BUG, and you can also get reduced latency from using raw_spinlock. I think we agree that (2) is not a factor in accepting the patch. Paolo >> Paolo >> > > Sebastian > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] staging: writeboost: Add dm-writeboost
On Fri, Feb 20, 2015 at 05:44:01PM +0900, Akira Hayakawa wrote: > I will wait for ack from dm maintainers. Are you still copying the contents of every bio to your own memory buffer before writing it to disk? - Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 02/20/2015 03:57 PM, Paolo Bonzini wrote: > > > On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote: >> Usually you see "scheduling while atomic" on -RT and convert them to >> raw locks if it is appropriate. >> >> Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder >> not cause a DoS and large latencies in the host. I haven't seen an >> answer to my why question. Because if the conversation leads to >> large latencies in the host then it does not look right. >> >> Each host PIC has a rawlock and does mostly just mask/unmask and the >> raw lock makes sure the value written is not mixed up due to >> preemption. >> This hardly increase latencies because the "locked" path is very short. >> If this conversation leads to higher latencies then the locked path is >> too long and hardly suitable to become a rawlock. > > Yes, but large latencies just mean the code has to be rewritten (x86 > doesn't anymore do event injection in an atomic regions for example). > Until it is, using raw_spin_lock is correct. It does not sound like it. It sounds more like disabling interrupts to get things run faster and then limit it on a different corner to not blow up everything. Max latencies was decreased "Max latency (us) 7062" and that is why this is done? For 8 us and possible DoS in case there are too many cpus? > Paolo > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Gmail.com: Ищешь подарок на 23 февраля?
Рубишься в World of Tanks? Коллекционные модели танков. http://bit.ly/1Cg6gJ0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: wacom: add full support of the Wacom Bamboo PAD
On Feb 18 2015 or thereabouts, jsanchezf wrote:
> > So could you run "sudo hid-recorder /dev/hidraw*" while making some
> > inputs on the touchpad?
>
> Moving my finger and pressing the buttons on the touchpad seemed to show no
> events on hid-recorder. This is the full log for it:
> http://pastebin.com/YqZfkvLy
>
> I just realised maybe you meant stylus input, so this is another log with
> some stylus input on it: http://pastebin.com/WSCY6Zq0
>
Arf, it looks like the wacom driver ignores the debug interface.
Can you re-run hid-recorder on all interfaces with the stock 3.19 kernel
(or whichever you had that allowed the pen to work, but without my
latest patches).
Cheers,
Benjamin
>
>
> 2015-02-18 23:07 GMT+01:00 Benjamin Tissoires >:
>
> > On Feb 18 2015 or thereabouts, jsanchezf wrote:
> > > Hello Benjamin
> > >
> > > Following your instructions I managed to compile and install the wacom
> > > module properly (actually I had to run automake and autoconf to make it
> > all
> > > work but no problems after that).
> > >
> > > The stylus is working just fine now. Unfortunately the touch pad part
> > > doesn't seem to be working at all, and Xorg isn't mapping it to an event
> > > file like it used to. The stylus event file is not seeing any data when I
> > > touch the pad either.
> > >
> > > By the way, I'm actually using the USB variant of the Bamboo Pad.
> > >
> >
> > Yep, I know. That's why I asked you to test :)
> >
> > So could you run "sudo hid-recorder /dev/hidraw*" while making some
> > inputs on the touchpad?
> >
> > I'd like to check if your touchpad is actually switched to the debug
> > mode.
> >
> > Cheers,
> > Benjamin
> >
> > > Looking at the log file from Xorg, though, I can see how it's properly
> > > detecting the "Wacom USB Bamboo PAD Pen stylus" device and adding "Wacom
> > > USB Bamboo PAD Pen touch" as an extended input device. Here's the full
> > log:
> > > http://pastebin.com/k3SqtQN5
> > >
> > > I should mention I have no Xorg configuration done whatsoever besides the
> > > monitor resolution setup (which is not really relevant
> > >
> > >
> > >
> > > 2015-02-17 20:27 GMT+01:00 Benjamin Tissoires <
> > benjamin.tissoi...@redhat.com
> > > >:
> > >
> > > > The stylus of this device works just fine out of the box.
> > > > The touch is seen by default as a mouse with relative events and some
> > > > gestures.
> > > > Switching the default in raw mode allows us to retrieve the touch data
> > > > and have a consistent user experience accross all the multitouch
> > touchpads.
> > > >
> > > > Note that the buttons of this devices are reported through the touch
> > > > interface. There is no 'Pad' interface. It seemed more natural to have
> > > > the BTN_LEFT and BTN_RIGHT reported with the touch because they are
> > > > placed under the touch interface and it looks like they belong to the
> > > > touch part.
> > > >
> > > > Signed-off-by: Benjamin Tissoires
> > > > ---
> > > >
> > > > Hi,
> > > >
> > > > several things before we can merge this:
> > > >
> > > > Josep, Frederic:
> > > > Would you mind testing this patch with your Bamboo pads? I bought the
> > > > wireless
> > > > variant and the USB one has a different ProductID. Hopefully, it will
> > go
> > > > smoothly with the current patch.
> > > >
> > > > Peter, Ping, Jason:
> > > > Given the nature of the device, I did not exported the 2 buttons as a
> > > > separate
> > > > pad device.
> > > > Do you back me up with this choice?
> > > >
> > > > Jiri:
> > > > As mentioned to Josep and Frederic, this has not been tested against
> > the
> > > > USB
> > > > (wired) version of the device. So please wait at least for one
> > tested-by
> > > > before
> > > > considering including this patch.
> > > >
> > > > Thanks everyone!
> > > > Benjamin
> > > >
> > > > drivers/hid/wacom_sys.c | 23 ++
> > > > drivers/hid/wacom_wac.c | 62
> > > > +
> > > > drivers/hid/wacom_wac.h | 3 +++
> > > > 3 files changed, 88 insertions(+)
> > > >
> > > > diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> > > > index e1ec192..ef4d147 100644
> > > > --- a/drivers/hid/wacom_sys.c
> > > > +++ b/drivers/hid/wacom_sys.c
> > > > @@ -410,6 +410,9 @@ static int wacom_query_tablet_data(struct
> > hid_device
> > > > *hdev,
> > > > else if (features->type == WACOM_27QHDT) {
> > > > return wacom_set_device_mode(hdev, 131, 3, 2);
> > > > }
> > > > + else if (features->type == BAMBOO_PAD) {
> > > > + return wacom_set_device_mode(hdev, 2, 2, 3);
> > > > + }
> > > > } else if (features->device_type == BTN_TOOL_PEN) {
> > > > if (features->type <= BAMBOO_PT && features->type !=
> > > > WIRELESS) {
> > > > return wacom_set_device_mode(hdev, 2, 2, 2);
> > > > @@ -1417,6 +1420,20 @@ static int wacom_probe(struct hid_device *hdev,
> > > >
Re: [PATCH 2/4] of: DT quirks infrastructure
Hi Peter, > On Feb 20, 2015, at 17:00 , Peter Hurley wrote: > > On 02/20/2015 09:35 AM, Ludovic Desroches wrote: >> On Fri, Feb 20, 2015 at 09:21:38AM -0500, Peter Hurley wrote: >>> On 02/19/2015 12:38 PM, Pantelis Antoniou wrote: > On Feb 19, 2015, at 19:30 , Frank Rowand wrote: > > On 2/19/2015 9:00 AM, Pantelis Antoniou wrote: >> Hi Frank, >> >>> On Feb 19, 2015, at 18:48 , Frank Rowand wrote: >>> >>> On 2/19/2015 6:29 AM, Pantelis Antoniou wrote: Hi Mark, > On Feb 18, 2015, at 19:31 , Mark Rutland wrote: > +While this may in theory work, in practice it is very cumbersome +for the following reasons: + +1. The act of selecting a different boot device tree blob requires +a reasonably advanced bootloader with some kind of configuration or +scripting capabilities. Sadly this is not the case many times, the +bootloader is extremely dumb and can only use a single dt blob. >>> >>> You can have several bootloader builds, or even a single build with >>> something like appended DTB to get an appropriate DTB if the same >>> binary >>> will otherwise work across all variants of a board. >>> >> >> No, the same DTB will not work across all the variants of a board. > > I wasn't on about the DTB. I was on about the loader binary, in the > case > the FW/bootloader could be common even if the DTB couldn't. > > To some extent there must be a DTB that will work across all variants > (albeit with limited utility) or the quirk approach wouldn't work… > That’s not correct; the only part of the DTB that needs to be common is the model property that would allow the quirk detection logic to fire. So, there is a base DTB that will work on all variants, but that only means that it will work only up to the point that the quirk detector method can work. So while in recommended practice there are common subsets of the DTB that might work, they might be unsafe. For instance on the beaglebone the regulator configuration is different between white and black, it is imperative you get them right otherwise you risk board damage. >>> So it's not necessarily true that you need a complex bootloader. >>> >> +2. On many instances boot time is extremely critical; in some cases +there are hard requirements like having working video feeds in under +2 seconds from power-up. This leaves an extremely small time budget for +boot-up, as low as 500ms to kernel entry. The sanest way to get there +is by removing the standard bootloader from the normal boot sequence +altogether by having a very small boot shim that loads the kernel and +immediately jumps to kernel, like falcon-boot mode in u-boot does. >>> >>> Given my previous comments above I don't see why this is relevant. >>> You're already passing _some_ DTB here, so if you can organise for >>> the >>> board to statically provide a sane DTB that's fine, or you can >>> resort to >>> appended DTB if it's not possible to update the board configuration. >>> >> >> You’re missing the point. I can’t use the same DTB for each revision >> of the >> board. Each board is similar but it’s not identical. > > I think you've misunderstood my point. If you program the board with > the > relevant DTB, or use appended DTB, then you will pass the correct DTB > to > the kernel without need for quirks. > > I understand that each variant is somewhat incompatible (and hence > needs > its own DTB). In theory it might work, in practice this does not. Ludovic mentioned that they have 27 different DTBs in use at the moment. At a relatively common 60k per DTB that’s 27x60k = 1.6MB of DTBs, that need to be installed. >>> >>> < snip > >>> >>> Or you can install the correct DTB on the board. You trust your >>> manufacturing line >>> to install the correct resistors. You trust your manufacturing line to >>> install the >>> correct kernel version (eg an updated version to resolve a security >>> issue). >>> >>> I thought the DT blob was supposed to follow the same standard that >>> other OS's or >>> bootloaders understood. Are you willing to break that? (This is one >>> of th
Re: [PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting
On 02/19/2015 08:03 PM, valdis.kletni...@vt.edu wrote: On Fri, 20 Feb 2015 01:53:44 +0100, "Luis R. Rodriguez" said: Wider community: anyone aware of any *need* in the kernel to know whether one is indoor or not on a device running Linux other than wifi? Clearly it should be something that might be of interest to at least other RF devices, so that is at least one possibilty to consider already, but what else? I can think of a lot of reasons for the kernel to make indoor/outdoor status available to userspace, but am coming up empty why the kernel itself should care That made me try to think of the possible uses for such a variable but I imagine that they can all be handled by userspace as well. Powering down GPS chips for energy consumption. Applying filters to cameras for fluorescent lights. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models
On Fri, 20 Feb 2015 14:55:32 +0100
Alexander Graf wrote:
> > /**
> > * S390CPUClass:
> > * @parent_realize: The parent class' realize handler.
> > @@ -52,6 +69,11 @@ typedef struct S390CPUClass {
> > void (*load_normal)(CPUState *cpu);
> > void (*cpu_reset)(CPUState *cpu);
> > void (*initial_cpu_reset)(CPUState *cpu);
> > +bool is_active[ACCEL_ID_MAX]; /* model enabled for given host and
> > accel */
> > +bool is_host[ACCEL_ID_MAX]; /* model markes host for given accel */
> > +uint64_t *fac_list; /* active facility list */
> > +S390CPUMachineProps *mach; /* machine specific properties */
> > +S390CPUProcessorProps *proc; /* processor specific properties */
>
> Sorry, same here. Just put the structs straight into the class struct.
Yep, consistent.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote: > Usually you see "scheduling while atomic" on -RT and convert them to > raw locks if it is appropriate. > > Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder > not cause a DoS and large latencies in the host. I haven't seen an > answer to my why question. Because if the conversation leads to > large latencies in the host then it does not look right. > > Each host PIC has a rawlock and does mostly just mask/unmask and the > raw lock makes sure the value written is not mixed up due to > preemption. > This hardly increase latencies because the "locked" path is very short. > If this conversation leads to higher latencies then the locked path is > too long and hardly suitable to become a rawlock. Yes, but large latencies just mean the code has to be rewritten (x86 doesn't anymore do event injection in an atomic regions for example). Until it is, using raw_spin_lock is correct. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in trigger handler
On Fri, 2015-02-20 at 12:02 +, Tirdea, Irina wrote:
>
> > -Original Message-
> > From: Peter Meerwald [mailto:pme...@pmeerw.net]
> > Sent: 16 February, 2015 21:26
> > To: Tirdea, Irina
> > Cc: Jonathan Cameron; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Pandruvada, Srinivas; Reus, Adriana
> > Subject: Re: [PATCH 2/2] iio: accel: kxcjk-1013: optimize i2c transfers in
> > trigger handler
> >
> >
> > > Reading all axis values in one i2c transfer reduces the delays
> > > introduced by the i2c bus. In case i2c block read is not supported,
> > > fallback to reading each axis as a separate word.
> >
> > see comments inline below
> >
> Thanks for the review, Peter!
>
> > > Signed-off-by: Adriana Reus
> > > Signed-off-by: Irina Tirdea
> > > Reviewed-by: Srinivas Pandruvada
> > > ---
> > > drivers/iio/accel/kxcjk-1013.c | 44
> > > +-
> > > 1 file changed, 35 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/iio/accel/kxcjk-1013.c
> > > b/drivers/iio/accel/kxcjk-1013.c
> > > index 5f27787..bfa2899 100644
> > > --- a/drivers/iio/accel/kxcjk-1013.c
> > > +++ b/drivers/iio/accel/kxcjk-1013.c
> > > @@ -109,6 +109,8 @@ struct kxcjk1013_data {
> > > int64_t timestamp;
> > > enum kx_chipset chipset;
> > > bool is_smo8500_device;
> > > + s32 (*read_block_data)(const struct i2c_client *client, u8 command,
> > > +u8 length, u8 *values);
> >
> > probably this could/should be done in the i2c layer or we end up adding a
> > similar function in every driver?
> >
> Actually this is exactly what I did: adding this code in a couple of drivers
> :)
> You are right, this belongs to the i2c core. Will move it there.
>
> > > };
> > >
> > > enum kxcjk1013_axis {
> > > @@ -216,6 +218,23 @@ static const struct {
> > >{800, 0, 0x06},
> > >{1600, 0, 0x06} };
> > >
> > > +static s32 kxcjk1013_read_block_data(const struct i2c_client *client,
> > > + u8 command, u8 length, u8 *values)
> > > +{
> > > + s32 data;
> > > + u8 i;
> > > +
> > > + for (i = 0; i < length; i += 2) {
> > > + data = i2c_smbus_read_word_data(client, command + i);
> > > + if (data < 0)
> > > + return data;
> > > +
> > > + values[i] = data & 0xFF;
> > > + values[i+1] = data >> 8;
> >
> > this is incorrect; it forces the data to be little endian, however, the
> > endianness (as specified in the driver's .scan_type) is IIO_CPU -- the
> > code breaks for big-endian CPUs
> >
> > since _read_i2c_block_data() can't do endianness conversion (and the chip
> > does i2c endianness, i.e. little-endian), the .scan_type should become
> > IIO_LE and above code is correct again but still ugly :)
> >
> > bottom line: change .scan_type to IIO_LE
> >
> Good point. Changing the endianess to IIO_LE is correct for either
> kxcjk1013_read_block_data or i2c_smbus_read_i2c_block_data.
> Will fix this in the next version. Thanks for catching this!
>
I don't think changing to IIO_LE is good idea as when i2c_read_bock..
then the scan type will be CPU. So better to fix endianness in this
function.
> > > + }
> > > + return i;
> > > +}
> > > +
> > > static int kxcjk1013_set_mode(struct kxcjk1013_data *data,
> > > enum kxcjk1013_mode mode)
> > > {
> > > @@ -955,18 +974,14 @@ static irqreturn_t kxcjk1013_trigger_handler(int
> > > irq, void *p)
> > > struct iio_poll_func *pf = p;
> > > struct iio_dev *indio_dev = pf->indio_dev;
> > > struct kxcjk1013_data *data = iio_priv(indio_dev);
> > > - int bit, ret, i = 0;
> > > + int ret;
> > >
> > > mutex_lock(&data->mutex);
> > > - for (bit = 0; bit < AXIS_MAX; bit++) {
> > > - ret = kxcjk1013_get_acc_reg(data, bit);
> > > - if (ret < 0) {
> > > - mutex_unlock(&data->mutex);
> > > - goto err;
> > > - }
> > > - data->buffer[i++] = ret;
> > > - }
> > > + ret = data->read_block_data(data->client, KXCJK1013_REG_XOUT_L,
> > > + AXIS_MAX * 2, (u8 *) data->buffer);
> > > mutex_unlock(&data->mutex);
> > > + if (ret < 0)
> > > + goto err;
> > >
> > > iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> > > data->timestamp);
> > > @@ -1196,6 +1211,11 @@ static int kxcjk1013_probe(struct i2c_client
> > > *client,
> > > const char *name;
> > > int ret;
> > >
> > > + if (!i2c_check_functionality(client->adapter,
> > > + I2C_FUNC_SMBUS_BYTE_DATA |
> > > + I2C_FUNC_SMBUS_READ_WORD_DATA))
> > > + return -ENODEV;
> > > +
> > > indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> > > if (!indio_dev)
> > > return -ENOMEM;
> > > @@ -1204,6 +1224,12 @@ static int kxcjk1013_probe(struct i2c_client
> > > *client,
> > > i2c_set_clientdata(c
[PATCH] genirq: better describe IRQF_NO_SUSPEND semantics
The IRQF_NO_SUSPEND flag is intended to be used for interrupts required
to be enabled during the suspend-resume cycle. This mostly consists of
IPIs and timer interrupts, potentially including chained irqchip
interrupts if these are necessary to handle timers or IPIs. If an
interrupt does not fall into one of the aforementioned categories,
requesting it with IRQF_NO_SUSPEND is likely incorrect.
Using IRQF_NO_SUSPEND does not guarantee that the interrupt can wake the
system from a suspended state. For an interrupt to be able to trigger a
wakeup, it may be necessary to program various components of the system.
In these cases it is necessary to use {enable,disabled}_irq_wake.
Unfortunately, several drivers assume that IRQF_NO_SUSPEND ensures that
an IRQ can wake up the system, and the documentation can be read
ambiguously w.r.t. this property.
This patch updates the documentation regarding IRQF_NO_SUSPEND to make
this caveat explicit, hopefully making future misuse rarer. Cleanup of
existing misuse will occur as part of later patch series.
Cc: Boris Brezillon
Cc: Ian Campbell
Cc: Jonathan Corbet
Cc: Peter Zijlstra
Cc: Rafael J. Wysocki
Cc: Thomas Gleixner
Signed-off-by: Mark Rutland
---
Documentation/power/suspend-and-interrupts.txt | 6 --
include/linux/interrupt.h | 4 +++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/power/suspend-and-interrupts.txt
b/Documentation/power/suspend-and-interrupts.txt
index 2f9c5a5..50493c9 100644
--- a/Documentation/power/suspend-and-interrupts.txt
+++ b/Documentation/power/suspend-and-interrupts.txt
@@ -40,8 +40,10 @@ but also to IPIs and to some other special-purpose
interrupts.
The IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when
requesting a special-purpose interrupt. It causes suspend_device_irqs() to
-leave the corresponding IRQ enabled so as to allow the interrupt to work all
-the time as expected.
+leave the corresponding IRQ enabled so as to allow the interrupt to work as
+expected during the suspend-resume cycle, but does not guarantee that the
+interrupt will wake the system from a suspended state -- for such cases it is
+necessary to use enable_irq_wake().
Note that the IRQF_NO_SUSPEND flag affects the entire IRQ and not just one
user of it. Thus, if the IRQ is shared, all of the interrupt handlers
installed
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index d9b05b5..606771c 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -52,7 +52,9 @@
* IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler
finished.
*Used by threaded interrupts which need to keep the
*irq line disabled until the threaded handler has been run.
- * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
+ * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend. Does not
guarantee
+ * that this interrupt will wake the system from a suspended
+ * state. See Documentation/power/suspend-and-interrupts.txt
* IRQF_FORCE_RESUME - Force enable it on resume even if IRQF_NO_SUSPEND is set
* IRQF_NO_THREAD - Interrupt cannot be threaded
* IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v9 00/10] sched: consolidation of CPU capacity and usage
On 20 February 2015 at 15:35, Morten Rasmussen wrote: > On Fri, Feb 20, 2015 at 02:13:21PM +, Vincent Guittot wrote: >> On 20 February 2015 at 12:52, Morten Rasmussen >> wrote: >> > On Fri, Feb 20, 2015 at 11:34:47AM +, Peter Zijlstra wrote: >> >> On Thu, Feb 19, 2015 at 12:49:40PM +, Morten Rasmussen wrote: >> >> >> >> > Also, it still not clear why patch 10 uses relative capacity reduction >> >> > instead of absolute capacity available to CFS tasks. >> >> >> >> As present in your asymmetric big and small systems? Yes it would be >> >> unfortunate to migrate a task to an idle small core when the big core is >> >> still faster, even if reduced by rt/irq work. >> > >> > Yes, exactly. I don't think it would cause any harm for symmetric cases >> > to use absolute capacity instead. Am I missing something? >> >> If absolute capacity is used, we will trig an active load balance from >> little to big core each time a little has got 1 task and a big core is >> idle whereas we only want to trig an active migration is the src_cpu's >> capacity that is available for the cfs task is significantly reduced >> by rt tasks. >> >> I can mix absolute and relative tests by 1st testing that the capacity >> of the src is reduced and then ensure that the dst_cpu has more >> absolute capacity than src_cpu > > If we use absolute capacity and check if the source cpu is fully > utilized, wouldn't that work? We want to migrate the task if it is we want to trig the migration before the cpu is fully utilized by rt/irq (which almost never occurs) > currently being restricted by the available capacity (due to rt/irq > work, being a little cpu, or both) and if there is a destination cpu > with more absolute capacity available. No? yes, so the relative capacity (cpu_capacity vs cpu_capacity_orig) enables us to know if the cpu is significantly used by irq/rt so it's worth to do an active load balance of the task. Then the absolute comparison of cpu_capacity of src_cpu vs cpu_capacity of dst_cpu checks that the dst_cpu is a better choice something like : if ((check_cpu_capacity(src_rq, sd)) && (capacity_of(src_cpu)*sd->imbalce_pct < capacity_of(dst_cpu)*100)) return 1; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Hi Mark, On Fri, 20 Feb 2015 14:22:08 + Mark Rutland wrote: > Hi Boris, > > On Wed, Feb 11, 2015 at 04:38:23PM +, Boris Brezillon wrote: > > [...] > > > For the list of impacted drivers, you can have a look at this series [1] > > (patches 2 to 5), and I'll take care of the testing part once every one > > has agreed on the solution ;-). > > > > [1]https://lkml.org/lkml/2014/12/15/552 > > Looking at those: > > * The pmc looks like it could be a valid use of the new flag. It also > seems to function as an irqchip. > > Do any of its child IRQs need to be handled during the suspend-resume > cycle? If so using IRQF_NO_SUSPEND would seem to be valid. No they don't, they are used for clock activation only, and thus should be disabled on suspend. > > * atmel_serial seems to be intended to be used as a wakeup device (given > it calls device_set_wakeup_enable). Therefore it needs to call > enable_irq_wake, and when it does so it can share an IRQ with other > interrupts, just not IRQF_NO_SUSPEND interrupts. I'll have a look, but AFAIR serial core already taking care of that. > > None of the approaches thus far can fix the fundamental mismatch > between wakeup interrupts and IRQF_NO_SUSPEND interrupts. > > * Similarly, rtc-at91rm9200 and rtc-at91sam9 are intended to be used as > wakeup devices. They call enable_irq_wake (though don't bother > checking the return value). They can share an IRQ with other > interrupts, just not IRQF_NO_SUSPEND interrupts. Yep. > > * at91sam9_wdt seems to be fundamentally incompatible with suspend. If > the watchdog cannot be disabled, and you need to handle it during > suspend, then it needs to be a wakeup interrupt, not an > IRQF_NO_SUSPEND interrupt. You forgot the PIT timer, which is the one in cause here (no other drivers are specifying this IRQF_NO_SUSPEND flag), and, as you already know, a timer sets the IRQF_NO_SUSPEND flag. > > As far as I can see, the flag or virtual irqchip approaches only help > the PMC case, and even then might not be necessary. All the others seem > to be relying on guarantees the genirq layer don't provide, and fixing > that would mean moving them further from IRQF_NO_SUSPEND. I don't know what you're trying to prove here, but I never said my goal was to set IRQF_NO_SUSPEND flags on existing at91 drivers ? The problem here, is that all those IPs are sharing the irq line with a timer which sets IRQF_NO_SUSPEND. I just want to be able to share an irq line with a timer and other devices that do not set IRQF_NO_SUSPEND. Could we focus on that ? Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
>> Thomas, what is the usual approach for patches like this? Do you take
>> them into your rt tree or should they get integrated to upstream?
>
> Patch 1 is definitely suitable for upstream, that's the reason why we
> have raw_spin_lock vs. raw_spin_unlock.
raw_spin_lock were introduced in c2f21ce2e31286a0a32 ("locking:
Implement new raw_spinlock). They are used in context which runs with
IRQs off - especially on -RT. This includes usually interrupt
controllers and related core-code pieces.
Usually you see "scheduling while atomic" on -RT and convert them to
raw locks if it is appropriate.
Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
not cause a DoS and large latencies in the host. I haven't seen an
answer to my why question. Because if the conversation leads to
large latencies in the host then it does not look right.
Each host PIC has a rawlock and does mostly just mask/unmask and the
raw lock makes sure the value written is not mixed up due to
preemption.
This hardly increase latencies because the "locked" path is very short.
If this conversation leads to higher latencies then the locked path is
too long and hardly suitable to become a rawlock.
> Paolo
>
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] thinkpad_acpi: More Carbon X1 2014 keys
Add support for newly added evdev keycodes. Signed-off-by: Bastien Nocera --- drivers/platform/x86/thinkpad_acpi.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 57130a1..535095d 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -3264,24 +3264,24 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) */ KEY_RESERVED,/* Mute held, 0x103 */ KEY_BRIGHTNESS_MIN, /* Backlight off */ - KEY_RESERVED,/* Clipping tool */ - KEY_RESERVED,/* Cloud */ + KEY_CLIPPING_TOOL, /* Clipping tool */ + KEY_CLOUD, /* Cloud */ KEY_RESERVED, KEY_VOICECOMMAND,/* Voice */ KEY_RESERVED, - KEY_RESERVED,/* Gestures */ + KEY_CAMERA_GESTURES, /* Gestures */ KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_CONFIG, /* Settings */ - KEY_RESERVED,/* New tab */ + KEY_NEW_TAB, /* New tab */ KEY_REFRESH, /* Reload */ KEY_BACK,/* Back */ - KEY_RESERVED,/* Microphone down */ - KEY_RESERVED,/* Microphone up */ - KEY_RESERVED,/* Microphone cancellation */ - KEY_RESERVED,/* Camera mode */ - KEY_RESERVED,/* Rotate display, 0x116 */ + KEY_MICUP, /* Microphone down */ + KEY_MICDOWN, /* Microphone up */ + KEY_MICCANCEL_MODE, /* Microphone cancellation */ + KEY_CAMERA_ZOOM_MODE,/* Camera mode */ + KEY_ROTATE_DISPLAY, /* Rotate display, 0x116 */ }, }; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] thinkpad_acpi: Add adaptive_kbd_mode sysfs attr
Add a sysfs attribute to allow privileged users to change the keyboard
mode. This could be used by desktop environments to change the keyboard
mode depending on the application focused, as the Windows application
does.
Signed-off-by: Bastien Nocera
---
drivers/platform/x86/thinkpad_acpi.c | 69 +++-
1 file changed, 60 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index d395d3f..2030c54 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -2917,6 +2917,57 @@ static void
hotkey_wakeup_hotunplug_complete_notify_change(void)
"wakeup_hotunplug_complete");
}
+/* sysfs adaptive kbd mode - */
+
+static int adaptive_keyboard_get_mode(void);
+static int adaptive_keyboard_set_mode(int new_mode);
+
+enum ADAPTIVE_KEY_MODE {
+ HOME_MODE,
+ WEB_BROWSER_MODE,
+ WEB_CONFERENCE_MODE,
+ FUNCTION_MODE,
+ LAYFLAT_MODE
+};
+
+static ssize_t adaptive_kbd_mode_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ u32 current_mode;
+
+ current_mode = adaptive_keyboard_get_mode();
+ if (current_mode < 0)
+ return current_mode;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", current_mode);
+}
+
+static ssize_t adaptive_kbd_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long t;
+ int res;
+
+ if (parse_strtoul(buf, LAYFLAT_MODE, &t))
+ return -EINVAL;
+
+ res = adaptive_keyboard_set_mode(t);
+ return (res < 0) ? res : count;
+}
+
+static DEVICE_ATTR_RW(adaptive_kbd_mode);
+
+static struct attribute *adaptive_kbd_attributes[] = {
+ &dev_attr_adaptive_kbd_mode.attr,
+ NULL
+};
+
+static const struct attribute_group adaptive_kbd_attr_group = {
+ .attrs = adaptive_kbd_attributes,
+};
+
/* - */
static struct attribute *hotkey_attributes[] __initdata = {
@@ -3232,8 +3283,13 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
* Lenovo Carbon X1 2014 (2nd Gen).
*/
if (acpi_evalf(hkey_handle, &hkeyv, "MHKV", "qd")) {
- if ((hkeyv >> 8) == 2)
+ if ((hkeyv >> 8) == 2) {
tp_features.has_adaptive_kbd = true;
+ res = sysfs_create_group(&tpacpi_pdev->dev.kobj,
+ &adaptive_kbd_attr_group);
+ if (res)
+ goto err_exit;
+ }
}
quirks = tpacpi_check_quirks(tpacpi_hotkey_qtable,
@@ -3446,6 +3502,9 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
err_exit:
delete_attr_set(hotkey_dev_attributes, &tpacpi_pdev->dev.kobj);
+ sysfs_remove_group(&tpacpi_pdev->dev.kobj,
+ &adaptive_kbd_attr_group);
+
hotkey_dev_attributes = NULL;
return (res < 0) ? res : 1;
@@ -3458,14 +3517,6 @@ err_exit:
* Will consider support rest of modes in future.
*
*/
-enum ADAPTIVE_KEY_MODE {
- HOME_MODE,
- WEB_BROWSER_MODE,
- WEB_CONFERENCE_MODE,
- FUNCTION_MODE,
- LAYFLAT_MODE
-};
-
const int adaptive_keyboard_modes[] = {
HOME_MODE,
/* WEB_BROWSER_MODE = 2,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: hide per-cpu lists in output of show_mem()
This makes show_mem() much less verbose at huge machines. Instead of
huge and almost useless dump of counters for each per-zone per-cpu
lists this patch prints sum of these counters for each zone (free_pcp)
and size of per-cpu list for current cpu (local_pcp).
Flag SHOW_MEM_PERCPU_LISTS reverts old verbose mode.
Signed-off-by: Konstantin Khlebnikov
---
include/linux/mm.h |1 +
mm/page_alloc.c| 32 +---
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 028565a..0538de0 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1126,6 +1126,7 @@ extern void pagefault_out_of_memory(void);
* various contexts.
*/
#define SHOW_MEM_FILTER_NODES (0x0001u) /* disallowed nodes */
+#define SHOW_MEM_PERCPU_LISTS (0x0002u) /* per-zone per-cpu */
extern void show_free_areas(unsigned int flags);
extern bool skip_free_areas_node(unsigned int flags, int nid);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a47f0b2..e591f3b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3198,20 +3198,29 @@ static void show_migration_types(unsigned char type)
*/
void show_free_areas(unsigned int filter)
{
+ unsigned long free_pcp = 0;
int cpu;
struct zone *zone;
for_each_populated_zone(zone) {
if (skip_free_areas_node(filter, zone_to_nid(zone)))
continue;
- show_node(zone);
- printk("%s per-cpu:\n", zone->name);
+
+ if (filter & SHOW_MEM_PERCPU_LISTS) {
+ show_node(zone);
+ printk("%s per-cpu:\n", zone->name);
+ }
for_each_online_cpu(cpu) {
struct per_cpu_pageset *pageset;
pageset = per_cpu_ptr(zone->pageset, cpu);
+ free_pcp += pageset->pcp.count;
+
+ if (!(filter & SHOW_MEM_PERCPU_LISTS))
+ continue;
+
printk("CPU %4d: hi:%5d, btch:%4d usd:%4d\n",
cpu, pageset->pcp.high,
pageset->pcp.batch, pageset->pcp.count);
@@ -3220,11 +3229,10 @@ void show_free_areas(unsigned int filter)
printk("active_anon:%lu inactive_anon:%lu isolated_anon:%lu\n"
" active_file:%lu inactive_file:%lu isolated_file:%lu\n"
- " unevictable:%lu"
- " dirty:%lu writeback:%lu unstable:%lu\n"
- " free:%lu slab_reclaimable:%lu slab_unreclaimable:%lu\n"
+ " unevictable:%lu dirty:%lu writeback:%lu unstable:%lu\n"
+ " slab_reclaimable:%lu slab_unreclaimable:%lu\n"
" mapped:%lu shmem:%lu pagetables:%lu bounce:%lu\n"
- " free_cma:%lu\n",
+ " free:%lu free_pcp:%lu free_cma:%lu\n",
global_page_state(NR_ACTIVE_ANON),
global_page_state(NR_INACTIVE_ANON),
global_page_state(NR_ISOLATED_ANON),
@@ -3235,13 +3243,14 @@ void show_free_areas(unsigned int filter)
global_page_state(NR_FILE_DIRTY),
global_page_state(NR_WRITEBACK),
global_page_state(NR_UNSTABLE_NFS),
- global_page_state(NR_FREE_PAGES),
global_page_state(NR_SLAB_RECLAIMABLE),
global_page_state(NR_SLAB_UNRECLAIMABLE),
global_page_state(NR_FILE_MAPPED),
global_page_state(NR_SHMEM),
global_page_state(NR_PAGETABLE),
global_page_state(NR_BOUNCE),
+ global_page_state(NR_FREE_PAGES),
+ free_pcp,
global_page_state(NR_FREE_CMA_PAGES));
for_each_populated_zone(zone) {
@@ -3249,6 +3258,11 @@ void show_free_areas(unsigned int filter)
if (skip_free_areas_node(filter, zone_to_nid(zone)))
continue;
+
+ free_pcp = 0;
+ for_each_online_cpu(cpu)
+ free_pcp += per_cpu_ptr(zone->pageset, cpu)->pcp.count;
+
show_node(zone);
printk("%s"
" free:%lukB"
@@ -3275,6 +3289,8 @@ void show_free_areas(unsigned int filter)
" pagetables:%lukB"
" unstable:%lukB"
" bounce:%lukB"
+ " free_pcp:%lukB"
+ " local_pcp:%ukB"
" free_cma:%lukB"
" writeback_tmp:%lukB"
" pages_scanned:%lu"
@@ -3306,6 +3322,8 @@ void show_free_areas(unsigned int filter)
K(zone_page_state(zone, NR_PAGETABLE)),
K(zone_page_state(zone, NR_UNSTABLE_NFS)),
K(zone_page_state(zone, NR_BOUNCE)),
+ K(free_pcp),
+ K
[RFC v1 3/5] seq_file: Add percpu seq_hlist helpers with locking iterators
Introduce a variant of the seq_hlist helpers for iterating seq_hlist
are protected by perpcu spinlocks.
Signed-off-by: Daniel Wagner
Cc: Jeff Layton
Cc: "J. Bruce Fields"
Cc: Alexander Viro
---
fs/seq_file.c| 83
include/linux/seq_file.h | 13
2 files changed, 96 insertions(+)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 555f821..56adfdb 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -966,3 +966,86 @@ seq_hlist_next_percpu(void *v, struct hlist_head __percpu
*head,
return NULL;
}
EXPORT_SYMBOL(seq_hlist_next_percpu);
+
+/**
+ * seq_hlist_start_precpu_locked - start an iteration of a percpu hlist array
+ * @head: pointer to percpu array of struct hlist_heads
+ * @lock: pointer to percpu spinlock which protects @head
+ * @cpu: pointer to cpu "cursor"
+ * @pos: start position of sequence
+ *
+ * Called at seq_file->op->start().
+ */
+struct hlist_node *
+seq_hlist_start_percpu_locked(struct hlist_head __percpu *head,
+ spinlock_t __percpu *lock, int *cpu, loff_t pos)
+{
+ struct hlist_node *node;
+
+ for_each_possible_cpu(*cpu) {
+ spin_lock(per_cpu_ptr(lock, *cpu));
+ hlist_for_each(node, per_cpu_ptr(head, *cpu)) {
+ if (pos-- == 0)
+ return node;
+ }
+ spin_unlock(per_cpu_ptr(lock, *cpu));
+ }
+ return NULL;
+}
+EXPORT_SYMBOL(seq_hlist_start_percpu_locked);
+
+/**
+ * seq_hlist_next_percpu_locked - move to the next position of the percpu
hlist array
+ * @v:pointer to current hlist_node
+ * @head: pointer to percpu array of struct hlist_heads
+ * @lock: pointer to percpu spinlock which protects @head
+ * @cpu: pointer to cpu "cursor"
+ * @pos: start position of sequence
+ *
+ * Called at seq_file->op->next().
+ */
+struct hlist_node *
+seq_hlist_next_percpu_locked(void *v, struct hlist_head __percpu *head,
+ spinlock_t __percpu *lock,
+ int *cpu, loff_t *pos)
+{
+ struct hlist_node *node = v;
+
+ ++*pos;
+
+ if (node->next)
+ return node->next;
+
+ spin_unlock(per_cpu_ptr(lock, *cpu));
+
+ for (*cpu = cpumask_next(*cpu, cpu_possible_mask); *cpu < nr_cpu_ids;
+*cpu = cpumask_next(*cpu, cpu_possible_mask)) {
+ struct hlist_head *bucket;
+
+ spin_lock(per_cpu_ptr(lock, *cpu));
+ bucket = per_cpu_ptr(head, *cpu);
+
+ if (!hlist_empty(bucket))
+ return bucket->first;
+
+ spin_unlock(per_cpu_ptr(lock, *cpu));
+ }
+ return NULL;
+}
+EXPORT_SYMBOL(seq_hlist_next_percpu_locked);
+
+/**
+ * seq_hlist_stop_percpu_locked - stop iterating over the percpu hlist array
+ * @v:pointer to current hlist_node
+ * @lock: pointer to percpu spinlock which protects @head
+ * @cpu: pointer to cpu "cursor"
+ *
+ * Called at seq_file->op->stop().
+ */
+void
+seq_hlist_stop_percpu_locked(void *v, spinlock_t __percpu *lock, int *cpu)
+{
+ if (v)
+ spin_unlock(per_cpu_ptr(lock, *cpu));
+}
+EXPORT_SYMBOL(seq_hlist_stop_percpu_locked);
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index afbb1fd..6419ac4 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -184,4 +184,17 @@ extern struct hlist_node *seq_hlist_start_percpu(struct
hlist_head __percpu *hea
extern struct hlist_node *seq_hlist_next_percpu(void *v, struct hlist_head
__percpu *head, int *cpu, loff_t *pos);
+extern struct hlist_node *seq_hlist_start_percpu_locked(
+ struct hlist_head __percpu *head,
+ spinlock_t __percpu *lock,
+ int *cpu, loff_t pos);
+
+extern struct hlist_node *seq_hlist_next_percpu_locked(
+ void *v, struct hlist_head __percpu *head,
+ spinlock_t __percpu *lock,
+ int *cpu, loff_t *pos);
+
+extern void seq_hlist_stop_percpu_locked(
+ void *v, spinlock_t __percpu *lock, int *cpu);
+
#endif
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 RFC] page_writeback: cleanup mess around cancel_dirty_page()
This patch replaces cancel_dirty_page() with helper account_page_cleaned()
which only updates counters. It's called from truncate_complete_page()
and from try_to_free_buffers() (hack for ext3). Page is locked in both cases,
page-lock protects against concurrent dirtiers: see commit 2d6d7f982846
("mm: protect set_page_dirty() from ongoing truncation").
Delete_from_page_cache() shouldn't be called for dirty pages, they must be
handled by caller (either written or truncated). This patch treats final
dirty accounting fixup at the end of __delete_from_page_cache() as a debug
check and adds WARN_ON_ONCE() around it. If something removes dirty pages
without proper handling that might be a bug and unwritten data might be lost.
Hugetlbfs has no dirty pages accounting, ClearPageDirty() is enough here.
cancel_dirty_page() in nfs_wb_page_cancel() is redundant. This is helper
for nfs_invalidate_page() and it's called only in case complete invalidation.
The mess was started in v2.6.20 after commits 46d2277c796f ("Clean up and
make try_to_free_buffers() not race with dirty pages") and 3e67c0987d75
("truncate: clear page dirtiness before running try_to_free_buffers()")
first was reverted right in v2.6.20 in commit ecdfc9787fe5 ("Resurrect
'try_to_free_buffers()' VM hackery"), second in v2.6.25 commit a2b345642f53
("Fix dirty page accounting leak with ext3 data=journal").
Custom fixes were introduced between these points. NFS in v2.6.23, commit
1b3b4a1a2deb ("NFS: Fix a write request leak in nfs_invalidate_page()").
Kludge in __delete_from_page_cache() in v2.6.24, commit 3a6927906f1b
("Do dirty page accounting when removing a page from the page cache").
Since v2.6.25 all of them are redundant.
Signed-off-by: Konstantin Khlebnikov
---
.../lustre/include/linux/lustre_patchless_compat.h |4 ++
fs/buffer.c|4 +-
fs/hugetlbfs/inode.c |2 +
fs/nfs/write.c |5 ---
include/linux/mm.h |2 +
include/linux/page-flags.h |2 -
mm/filemap.c | 15
mm/page-writeback.c| 19 ++
mm/truncate.c | 37
9 files changed, 41 insertions(+), 49 deletions(-)
diff --git
a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
index a260e99..d726058 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
@@ -55,7 +55,9 @@ truncate_complete_page(struct address_space *mapping, struct
page *page)
if (PagePrivate(page))
page->mapping->a_ops->invalidatepage(page, 0, PAGE_CACHE_SIZE);
- cancel_dirty_page(page, PAGE_SIZE);
+ if (TestClearPageDirty(page))
+ account_page_cleaned(page, mapping);
+
ClearPageMappedToDisk(page);
ll_delete_from_page_cache(page);
}
diff --git a/fs/buffer.c b/fs/buffer.c
index 20805db..c7a5602 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3243,8 +3243,8 @@ int try_to_free_buffers(struct page *page)
* to synchronise against __set_page_dirty_buffers and prevent the
* dirty bit from being lost.
*/
- if (ret)
- cancel_dirty_page(page, PAGE_CACHE_SIZE);
+ if (ret && TestClearPageDirty(page))
+ account_page_cleaned(page, mapping);
spin_unlock(&mapping->private_lock);
out:
if (buffers_to_free) {
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index c274aca..db76cec 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -319,7 +319,7 @@ static int hugetlbfs_write_end(struct file *file, struct
address_space *mapping,
static void truncate_huge_page(struct page *page)
{
- cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
+ ClearPageDirty(page);
ClearPageUptodate(page);
delete_from_page_cache(page);
}
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 88a6d21..2d4cb36 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1854,11 +1854,6 @@ int nfs_wb_page_cancel(struct inode *inode, struct page
*page)
* request from the inode / page_private pointer and
* release it */
nfs_inode_remove_request(req);
- /*
-* In case nfs_inode_remove_request has marked the
-* page as being dirty
-*/
- cancel_dirty_page(page, PAGE_CACHE_SIZE);
nfs_unlock_and_release_request(req);
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 47a9392..028565a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1294,9 +1294,11 @@ int __set_page_dirty_no_writeback(stru
[PATCH 2/2] drm/msm: Support NV12MT format in mdp4
Using fb modifier flag, support NV12MT format
in MDP4
Change-Id: I3de92b0c3b6d0cb56647aed6e4e35e56eff7adab
Signed-off-by: Beeresh Gopal
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 9 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 5 +
drivers/gpu/drm/msm/msm_drv.c | 2 ++
drivers/gpu/drm/msm/msm_kms.h | 1 +
include/uapi/drm/drm_fourcc.h | 14 ++
6 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index d81e19d..24c38d4 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -157,6 +157,14 @@ static void mdp4_complete_commit(struct msm_kms *kms,
struct drm_atomic_state *s
mdp4_disable(mdp4_kms);
}
+static void mdp4_set_mode_config(struct msm_kms *kms)
+{
+ struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
+ struct drm_device *dev = mdp4_kms->dev;
+
+ dev->mode_config.allow_fb_modifiers = true;
+}
+
static long mdp4_round_pixclk(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder)
{
@@ -197,6 +205,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.complete_commit = mdp4_complete_commit,
.get_format = mdp_get_format,
.round_pixclk= mdp4_round_pixclk,
+ .set_mode_config = mdp4_set_mode_config,
.preclose= mdp4_preclose,
.destroy = mdp4_destroy,
},
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index cde2500..2c2d6a5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -33,6 +33,21 @@ struct mdp4_plane {
};
#define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)
+/* MDP format helper functions */
+static inline
+enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
+{
+ bool is_tile = false;
+
+ if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
+ is_tile = true;
+
+ if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
+ return FRAME_TILE_YCBCR_420;
+
+ return FRAME_LINEAR;
+}
+
static void mdp4_plane_set_scanout(struct drm_plane *plane,
struct drm_framebuffer *fb);
static int mdp4_plane_mode_set(struct drm_plane *plane,
@@ -203,6 +218,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
uint32_t op_mode = 0;
uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
+ enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);
if (!(crtc && fb)) {
DBG("%s: disabled!", mdp4_plane->name);
@@ -302,6 +318,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count
- 1) |
MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type) |
MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample)
|
+ MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
COND(format->unpack_tight,
MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));
mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
@@ -322,6 +339,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);
+ if (frame_type != FRAME_LINEAR)
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
+ MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
+ MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 92b61db..9cb5a5d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -80,6 +80,10 @@ static void mdp5_complete_commit(struct msm_kms *kms, struct
drm_atomic_state *s
mdp5_disable(mdp5_kms);
}
+static void mdp5_set_mode_config(struct msm_kms *kms)
+{
+}
+
static long mdp5_round_pixclk(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder)
{
@@ -131,6 +135,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.complete_commit = mdp5_complete_commit,
.get_format = mdp_get_format,
.round_pixclk= mdp5_round_pixclk,
+ .set_mode_config = mdp5_set_mode_config,
.preclose= mdp5_preclose,
.destroy = mdp5_destroy,
},
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/d
[RFC][PATCH 2/2] perf: Add per event clockid support
While thinking on the whole clock discussion it occured to me we have
two distinct uses of time:
1) the tracking of event/ctx/cgroup enabled/running/stopped times
which includes the self-monitoring support in struct
perf_event_mmap_page.
2) the actual timestamps visible in the data records.
And we've been conflating them.
The first is all about tracking time deltas, nobody should really care
in what time base that happens, its all relative information, as long
as its internally consistent it works.
The second however is what people are worried about when having to
merge their data with external sources. And here we have the
discussion on MONOTONIC vs MONOTONIC_RAW etc..
Where MONOTONIC is good for correlating between machines (static
offset), MONOTNIC_RAW is required for correlating against a fixed rate
hardware clock.
This means configurability; now 1) makes that hard because it needs to
be internally consistent across groups of unrelated events; which is
why we had to have a global perf_clock().
However, for 2) it doesn't really matter, perf itself doesn't care
what it writes into the buffer.
The below patch makes the distinction between these two cases by
adding perf_event_clock() which is used for the second case. It
further makes this configurable on a per-event basis, but adds a few
sanity checks such that we cannot combine events with different clocks
in confusing ways.
And since we then have per-event configurability we might as well
retain the 'legacy' behaviour as a default.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/kernel/cpu/perf_event.c | 14 ++-
include/linux/perf_event.h |2 +
include/linux/timekeeping.h |5 ++
include/uapi/linux/perf_event.h |6 +--
kernel/events/core.c | 74 +--
5 files changed, 93 insertions(+), 8 deletions(-)
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1968,13 +1968,23 @@ void arch_perf_update_userpage(struct pe
data = cyc2ns_read_begin();
+ /*
+* Internal timekeeping for enabled/running/stopped times
+* is always in the local_clock domain.
+*/
userpg->cap_user_time = 1;
userpg->time_mult = data->cyc2ns_mul;
userpg->time_shift = data->cyc2ns_shift;
userpg->time_offset = data->cyc2ns_offset - now;
- userpg->cap_user_time_zero = 1;
- userpg->time_zero = data->cyc2ns_offset;
+ /*
+* cap_user_time_zero doesn't make sense when we're using a different
+* time base for the records.
+*/
+ if (event->clock == &local_clock) {
+ userpg->cap_user_time_zero = 1;
+ userpg->time_zero = data->cyc2ns_offset;
+ }
cyc2ns_read_end(data);
}
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -166,6 +166,7 @@ struct perf_event;
* pmu::capabilities flags
*/
#define PERF_PMU_CAP_NO_INTERRUPT 0x01
+#define PERF_PMU_CAP_NO_NMI0x02
/**
* struct pmu - generic performance monitoring unit
@@ -438,6 +439,7 @@ struct perf_event {
struct pid_namespace*ns;
u64 id;
+ u64 (*clock)(void);
perf_overflow_handler_t overflow_handler;
void*overflow_handler_context;
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -214,6 +214,11 @@ static inline u64 ktime_get_boot_ns(void
return ktime_to_ns(ktime_get_boottime());
}
+static inline u64 ktime_get_tai_ns(void)
+{
+ return ktime_to_ns(ktime_get_clocktai());
+}
+
static inline u64 ktime_get_raw_ns(void)
{
return ktime_to_ns(ktime_get_raw());
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -305,7 +305,8 @@ struct perf_event_attr {
exclude_callchain_user : 1, /* exclude user
callchains */
mmap2 : 1, /* include mmap with inode
data */
comm_exec : 1, /* flag comm events that
are due to an exec */
- __reserved_1 : 39;
+ use_clockid: 1, /* use @clockid for time
fields */
+ __reserved_1 : 38;
union {
__u32 wakeup_events;/* wakeup every n events */
@@ -334,8 +335,7 @@ struct perf_event_attr {
*/
__u32 sample_stack_user;
- /* Align to u64. */
- __u32 __reserved_2;
+ __u32 clockid;
/*
* Defines set of regs to dump for each sample
* state captured on:
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -327,6 +327,11 @@ static inline u64 perf_clock(void)
return local_clock();
}
+static inline u64 perf_event_clock(struct perf_event *event)
+{
+
[RFC v1 1/5] locks: Remove unnecessary IS_POSIX test
Since following change
commit bd61e0a9c852de2d705b6f1bb2cc54c5774db570
Author: Jeff Layton
Date: Fri Jan 16 15:05:55 2015 -0500
locks: convert posix locks to file_lock_context
all Posix locks are kept on their a separate list, so the test is
redudant.
Signed-off-by: Daniel Wagner
Cc: Jeff Layton
Cc: "J. Bruce Fields"
Cc: Alexander Viro
---
fs/locks.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 365c82e..f63aa92 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -964,8 +964,6 @@ static int __posix_lock_file(struct inode *inode, struct
file_lock *request, str
*/
if (request->fl_type != F_UNLCK) {
list_for_each_entry(fl, &ctx->flc_posix, fl_list) {
- if (!IS_POSIX(fl))
- continue;
if (!posix_locks_conflict(request, fl))
continue;
if (conflock)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] phy: add phy-hi6220-usb
Hi,
On Thu, Feb 12, 2015 at 03:37:26PM +0800, Zhangfei Gao wrote:
> Add usb phy controller for hi6220 platform
>
> Signed-off-by: Zhangfei Gao
> ---
> drivers/phy/Kconfig | 9 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-hi6220-usb.c | 306
> +++
> 3 files changed, 316 insertions(+)
> create mode 100644 drivers/phy/phy-hi6220-usb.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index ccad880..40a1ef1 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -162,6 +162,15 @@ config PHY_HIX5HD2_SATA
> help
> Support for SATA PHY on Hisilicon hix5hd2 Soc.
>
> +config PHY_HI6220_USB
> + tristate "hi6220 USB PHY support"
> + select USB_PHY
> + select MFD_SYSCON
> + help
> + Enable this to support the HISILICON HI6220 USB PHY.
> +
> + To compile this driver as a module, choose M here.
> +
> config PHY_SUN4I_USB
> tristate "Allwinner sunxi SoC USB PHY driver"
> depends on ARCH_SUNXI && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index aa74f96..ec43c2d 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_TI_PIPE3) +=
> phy-ti-pipe3.o
> obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
> obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o
> obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
> +obj-$(CONFIG_PHY_HI6220_USB) += phy-hi6220-usb.o
> obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
> obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
> phy-exynos-usb2-y+= phy-samsung-usb2.o
> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
> new file mode 100644
> index 000..0d9f5ac
> --- /dev/null
> +++ b/drivers/phy/phy-hi6220-usb.c
> @@ -0,0 +1,306 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Copyright (c) 2015 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SC_PERIPH_CTRL4 0x00c
> +
> +#define CTRL4_PICO_SIDDQ BIT(6)
> +#define CTRL4_PICO_OGDISABLE BIT(8)
> +#define CTRL4_PICO_VBUSVLDEXTBIT(10)
> +#define CTRL4_PICO_VBUSVLDEXTSEL BIT(11)
> +#define CTRL4_OTG_PHY_SELBIT(21)
> +
> +#define SC_PERIPH_CTRL5 0x010
> +
> +#define CTRL5_USBOTG_RES_SEL BIT(3)
> +#define CTRL5_PICOPHY_ACAENB BIT(4)
> +#define CTRL5_PICOPHY_BC_MODEBIT(5)
> +#define CTRL5_PICOPHY_CHRGSELBIT(6)
> +#define CTRL5_PICOPHY_VDATSRCEND BIT(7)
> +#define CTRL5_PICOPHY_VDATDETENB BIT(8)
> +#define CTRL5_PICOPHY_DCDENB BIT(9)
> +#define CTRL5_PICOPHY_IDDIG BIT(10)
> +
> +#define SC_PERIPH_CTRL8 0x018
> +#define SC_PERIPH_RSTEN0 0x300
> +#define SC_PERIPH_RSTDIS00x304
> +
> +#define RST0_USBOTG_BUS BIT(4)
> +#define RST0_POR_PICOPHY BIT(5)
> +#define RST0_USBOTG BIT(6)
> +#define RST0_USBOTG_32K BIT(7)
> +
> +#define EYE_PATTERN_PARA 0x7053348c
> +
> +struct hi6220_priv {
> + struct usb_phy phy;
> + struct delayed_work work;
> + struct regmap *reg;
> + struct clk *clk;
> + struct regulator *vcc;
> + struct device *dev;
> + int gpio_vbus;
> + int gpio_id;
> + enum usb_otg_state state;
> +};
> +
> +static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> +{
> + struct usb_otg *otg = priv->phy.otg;
> +
> + if (!otg->gadget)
> + return;
> +
> + if (on)
> + usb_gadget_connect(otg->gadget);
> + else
> + usb_gadget_disconnect(otg->gadget);
why is the PHY fiddling with pullups ?
> +}
> +
> +static void hi6220_detect_work(struct work_struct *work)
> +{
> + struct hi6220_priv *priv =
> + container_of(work, struct hi6220_priv, work.work);
> + int gpio_id, gpio_vbus;
> + enum usb_otg_state state;
> +
> + if (!gpio_is_valid(priv->gpio_id) || !gpio_is_valid(priv->gpio_vbus))
> + return;
> +
> + gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> + gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
looks like this should be using extcon
> +
> + if (gpio_vbus == 0) {
> + if (gpio_id == 1)
> + state = OTG_STATE_B_PERIPHERAL;
> + else
> + state = OTG_STATE_A_HOST;
> + } else {
> + state = OTG_STATE_A_HOST;
>
[PATCH 7/7] thinkpad_acpi: use DEVICE_ATTR_* macros
Use the DEVICE_ATTR_RW macro to reduce boiler plate and move the
attribute declaration to get rid of function signatures.
Signed-off-by: Bastien Nocera
---
drivers/platform/x86/thinkpad_acpi.c | 72 ++--
1 file changed, 20 insertions(+), 52 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 535095d..4b31492 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -2668,9 +2668,7 @@ static ssize_t hotkey_enable_store(struct device *dev,
return count;
}
-static struct device_attribute dev_attr_hotkey_enable =
- __ATTR(hotkey_enable, S_IWUSR | S_IRUGO,
- hotkey_enable_show, hotkey_enable_store);
+static DEVICE_ATTR_RW(hotkey_enable);
/* sysfs hotkey mask --- */
static ssize_t hotkey_mask_show(struct device *dev,
@@ -2706,9 +2704,7 @@ static ssize_t hotkey_mask_store(struct device *dev,
return (res) ? res : count;
}
-static struct device_attribute dev_attr_hotkey_mask =
- __ATTR(hotkey_mask, S_IWUSR | S_IRUGO,
- hotkey_mask_show, hotkey_mask_store);
+static DEVICE_ATTR_RW(hotkey_mask);
/* sysfs hotkey bios_enabled --- */
static ssize_t hotkey_bios_enabled_show(struct device *dev,
@@ -2718,8 +2714,7 @@ static ssize_t hotkey_bios_enabled_show(struct device
*dev,
return sprintf(buf, "0\n");
}
-static struct device_attribute dev_attr_hotkey_bios_enabled =
- __ATTR(hotkey_bios_enabled, S_IRUGO, hotkey_bios_enabled_show, NULL);
+static DEVICE_ATTR_RO(hotkey_bios_enabled);
/* sysfs hotkey bios_mask -- */
static ssize_t hotkey_bios_mask_show(struct device *dev,
@@ -2731,8 +2726,7 @@ static ssize_t hotkey_bios_mask_show(struct device *dev,
return snprintf(buf, PAGE_SIZE, "0x%08x\n", hotkey_orig_mask);
}
-static struct device_attribute dev_attr_hotkey_bios_mask =
- __ATTR(hotkey_bios_mask, S_IRUGO, hotkey_bios_mask_show, NULL);
+static DEVICE_ATTR_RO(hotkey_bios_mask);
/* sysfs hotkey all_mask --- */
static ssize_t hotkey_all_mask_show(struct device *dev,
@@ -2743,8 +2737,7 @@ static ssize_t hotkey_all_mask_show(struct device *dev,
hotkey_all_mask | hotkey_source_mask);
}
-static struct device_attribute dev_attr_hotkey_all_mask =
- __ATTR(hotkey_all_mask, S_IRUGO, hotkey_all_mask_show, NULL);
+static DEVICE_ATTR_RO(hotkey_all_mask);
/* sysfs hotkey recommended_mask --- */
static ssize_t hotkey_recommended_mask_show(struct device *dev,
@@ -2756,9 +2749,7 @@ static ssize_t hotkey_recommended_mask_show(struct device
*dev,
& ~hotkey_reserved_mask);
}
-static struct device_attribute dev_attr_hotkey_recommended_mask =
- __ATTR(hotkey_recommended_mask, S_IRUGO,
- hotkey_recommended_mask_show, NULL);
+static DEVICE_ATTR_RO(hotkey_recommended_mask);
#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
@@ -2813,9 +2804,7 @@ static ssize_t hotkey_source_mask_store(struct device
*dev,
return (rc < 0) ? rc : count;
}
-static struct device_attribute dev_attr_hotkey_source_mask =
- __ATTR(hotkey_source_mask, S_IWUSR | S_IRUGO,
- hotkey_source_mask_show, hotkey_source_mask_store);
+static DEVICE_ATTR_RW(hotkey_source_mask);
/* sysfs hotkey hotkey_poll_freq --- */
static ssize_t hotkey_poll_freq_show(struct device *dev,
@@ -2847,9 +2836,7 @@ static ssize_t hotkey_poll_freq_store(struct device *dev,
return count;
}
-static struct device_attribute dev_attr_hotkey_poll_freq =
- __ATTR(hotkey_poll_freq, S_IWUSR | S_IRUGO,
- hotkey_poll_freq_show, hotkey_poll_freq_store);
+static DEVICE_ATTR_RW(hotkey_poll_freq);
#endif /* CONFIG_THINKPAD_ACPI_HOTKEY_POLL */
@@ -2870,8 +2857,7 @@ static ssize_t hotkey_radio_sw_show(struct device *dev,
(res == TPACPI_RFK_RADIO_OFF) ? 0 : 1);
}
-static struct device_attribute dev_attr_hotkey_radio_sw =
- __ATTR(hotkey_radio_sw, S_IRUGO, hotkey_radio_sw_show, NULL);
+static DEVICE_ATTR_RO(hotkey_radio_sw);
static void hotkey_radio_sw_notify_change(void)
{
@@ -2893,8 +2879,7 @@ static ssize_t hotkey_tablet_mode_show(struct device *dev,
return snprintf(buf, PAGE_SIZE, "%d\n", !!s);
}
-static struct device_attribute dev_attr_hotkey_tablet_mode =
- __ATTR(hotkey_tablet_mode, S_IRUGO, hotkey_tablet_mode_show, NULL);
+static DEVICE_ATTR_RO(hotkey_tablet_mode);
static void hotkey_tablet_mode_notify_change(void)
{
@@ -2911,8 +2896,7 @@ static ssize_t hotkey_wakeup_reason_show(struct device
*dev,
return snprintf(buf, PAGE_SIZE, "%d\n", hotkey_wakeup_reason);
}
-static struct device_attribute dev_attr_hotkey_wakeu
[PATCH 2/7] thinkpad_acpi: Factor out get/set adaptive kbd mode
Move the getting/setting of the adaptive keyboard mode to separate
functions, so that we can reuse them later through sysfs attributes.
Signed-off-by: Bastien Nocera
---
drivers/platform/x86/thinkpad_acpi.c | 61 ++--
1 file changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index c1f4daf..d395d3f 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3482,6 +3482,32 @@ const int adaptive_keyboard_modes[] = {
static bool adaptive_keyboard_mode_is_saved;
static int adaptive_keyboard_prev_mode;
+static int adaptive_keyboard_get_mode(void)
+{
+ int mode = 0;
+
+ if (!acpi_evalf(hkey_handle, &mode, "GTRW", "dd", 0)) {
+ pr_err("Cannot read adaptive keyboard mode\n");
+ return -EIO;
+ }
+
+ return mode;
+}
+
+static int adaptive_keyboard_set_mode(int new_mode)
+{
+ if (new_mode < 0 ||
+ new_mode > LAYFLAT_MODE)
+ return -EINVAL;
+
+ if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode)) {
+ pr_err("Cannot set adaptive keyboard mode\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int adaptive_keyboard_get_next_mode(int mode)
{
size_t i;
@@ -3511,39 +3537,28 @@ static bool
adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
new_mode = adaptive_keyboard_prev_mode;
adaptive_keyboard_mode_is_saved = false;
} else {
- if (!acpi_evalf(
- hkey_handle, ¤t_mode,
- "GTRW", "dd", 0)) {
- pr_err("Cannot read adaptive keyboard mode\n");
+ current_mode = adaptive_keyboard_get_mode();
+ if (current_mode < 0)
return false;
- } else {
- new_mode = adaptive_keyboard_get_next_mode(
- current_mode);
- }
+ new_mode = adaptive_keyboard_get_next_mode(
+ current_mode);
}
- if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode)) {
- pr_err("Cannot set adaptive keyboard mode\n");
+ if (adaptive_keyboard_set_mode(new_mode) < 0)
return false;
- }
return true;
case DFR_SHOW_QUICKVIEW_ROW:
- if (!acpi_evalf(hkey_handle,
- &adaptive_keyboard_prev_mode,
- "GTRW", "dd", 0)) {
- pr_err("Cannot read adaptive keyboard mode\n");
+ current_mode = adaptive_keyboard_get_mode();
+ if (current_mode < 0)
return false;
- } else {
- adaptive_keyboard_mode_is_saved = true;
- if (!acpi_evalf(hkey_handle,
- NULL, "STRW", "vd", FUNCTION_MODE)) {
- pr_err("Cannot set adaptive keyboard mode\n");
- return false;
- }
- }
+ adaptive_keyboard_prev_mode = current_mode;
+ adaptive_keyboard_mode_is_saved = true;
+
+ if (adaptive_keyboard_set_mode (FUNCTION_MODE) < 0)
+ return false;
return true;
default:
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] drm/msm: update generated headers
To avoid ambiguity rename FRAME_SIZE to
SSTILE_FRAME_SIZE
Change-Id: I2c1c763cec31acb6c860220c41a8b33bfad430a3
Signed-off-by: Beeresh Gopal
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 36 +
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
index 1d39174..2d0029d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
@@ -8,19 +8,11 @@ http://github.com/freedreno/envytools/
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2014-12-05 15:34:49)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (
1453 bytes, from 2013-03-31 16:51:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(
20908 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml (
2357 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(
27208 bytes, from 2015-01-13 23:56:11)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (
11712 bytes, from 2013-08-17 17:13:43)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (
1686 bytes, from 2014-10-31 16:48:57)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml (
26848 bytes, from 2015-01-13 23:55:57)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (
8253 bytes, from 2014-12-08 16:13:00)
-
-Copyright (C) 2013-2014 by the following authors:
+- /local/mnt/workspace/sandbox/envytools/rnndb/mdp/mdp4.xml(
20915 bytes, from 2015-02-06 15:25:51)
+- /local/mnt/workspace/sandbox/envytools/rnndb/freedreno_copyright.xml (
1453 bytes, from 2015-02-06 15:25:09)
+- /local/mnt/workspace/sandbox/envytools/rnndb/mdp/mdp_common.xml (
2357 bytes, from 2015-02-06 15:25:09)
+
+Copyright (C) 2013-2015 by the following authors:
- Rob Clark (robclark)
Permission is hereby granted, free of charge, to any person obtaining
@@ -680,18 +672,18 @@ static inline uint32_t MDP4_PIPE_SRC_STRIDE_B_P3(uint32_t
val)
return ((val) << MDP4_PIPE_SRC_STRIDE_B_P3__SHIFT) &
MDP4_PIPE_SRC_STRIDE_B_P3__MASK;
}
-static inline uint32_t REG_MDP4_PIPE_FRAME_SIZE(enum mdp4_pipe i0) { return
0x00020048 + 0x1*i0; }
-#define MDP4_PIPE_FRAME_SIZE_HEIGHT__MASK 0x
-#define MDP4_PIPE_FRAME_SIZE_HEIGHT__SHIFT 16
-static inline uint32_t MDP4_PIPE_FRAME_SIZE_HEIGHT(uint32_t val)
+static inline uint32_t REG_MDP4_PIPE_SSTILE_FRAME_SIZE(enum mdp4_pipe i0) {
return 0x00020048 + 0x1*i0; }
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__MASK 0x
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__SHIFT 16
+static inline uint32_t MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(uint32_t val)
{
- return ((val) << MDP4_PIPE_FRAME_SIZE_HEIGHT__SHIFT) &
MDP4_PIPE_FRAME_SIZE_HEIGHT__MASK;
+ return ((val) << MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__SHIFT) &
MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__MASK;
}
-#define MDP4_PIPE_FRAME_SIZE_WIDTH__MASK 0x
-#define MDP4_PIPE_FRAME_SIZE_WIDTH__SHIFT 0
-static inline uint32_t MDP4_PIPE_FRAME_SIZE_WIDTH(uint32_t val)
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__MASK
0x
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__SHIFT 0
+static inline uint32_t MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(uint32_t val)
{
- return ((val) << MDP4_PIPE_FRAME_SIZE_WIDTH__SHIFT) &
MDP4_PIPE_FRAME_SIZE_WIDTH__MASK;
+ return ((val) << MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__SHIFT) &
MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__MASK;
}
static inline uint32_t REG_MDP4_PIPE_SRC_FORMAT(enum mdp4_pipe i0) { return
0x00020050 + 0x1*i0; }
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 0/2] On perf and clocks..
Hai, Changelog for patch 2 has the goodies. Compile tested only.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v1 0/5] fs/locks: Use plain percpu spinlocks instead of lglock to protect file_lock
Hi Jeff, Thanks for the great feedback on version 0. I haven't address all your points yet but will do. Just wanted to post a more readeable version. Still missing things and TODOs (FIXME!!): - adding lockdep assertions - more tests and benchmarks on big machines v1: - rebased on v3.19-8975-g3d88348 - splittet into smaller pieces - fixed a wrong usage of __locks_insert/delete_block() and it's posix version - added seqfile helpers to avoid ugly open coded version Original cover letter: I am looking at how to get rid of lglock. Reason being -rt is not too happy with that lock, especially that it uses arch_spinlock_t and therefore it is not changed into a mutex on -rt. I know no change is accepted only fixing something for -rt alone. So here my attempt to make things faster for mainline and fixing -rt. There are two users of lglock at this point. fs/locks.c and kernel/stop_machine.c I presume the fs/locks is the more interesting one in respect of performance. Let's have a look at that one first. The lglock version of file_lock_lock is used in combination of blocked_lock_lock to protect file_lock's fl_link, fl_block, fl_next, blocked_hash and the percpu file_lock_list. The plan is to reorganize the usage of the locks and what they protect so that the usage of the global blocked_lock_lock is reduced. Whenever we insert a new lock we are going to grab besides the i_lock also the corresponding percpu file_lock_lock. The global blocked_lock_lock is only used when blocked_hash is involved. file_lock_list exists to be being able to produce the content of /proc/locks. For listing the all locks it seems a bit excessive to grab all locks at once. We should be okay just grabbing the corresponding lock when iterating over the percpu file_lock_list. file_lock_lock protects now file_lock_list and fl_link, fl_block and fl_next allone. That means we need to define which file_lock_lock is used for all waiters. Luckely, fl_link_cpu can be reused for fl_block and fl_next. I haven't found a good way around for the open coded seq_ops (locks_start, locks_next, locks_stop). Maybe someone has good idea how to handle with the locks. For performance testing I used git://git.samba.org/jlayton/lockperf.git and for correctness https://github.com/linux-test-project/ltp/tree/master/testcases/network/nfsv4/locks In case you are missing the posix03 results, my machine doesn't like it too much. The load brings it to its knees due to the very high load. Propably I need different parameters. I didn't run excessive tests so far, because I am waiting for getting access on a bigger box compared to my small i7-4850HQ system. I hope to see larger improvements when there are more cores involved. Anyway here are some results based on 3.19. Explanation: 3.19: means unpatched kernel 3.19.0+: patched version -with-reader.data: 'while true; do cat /proc/locks; done > /dev/null' 3.19/flock01.data # NumSamples = 117; Min = 853.77; Max = 1425.62 # Mean = 1387.965754; Variance = 5512.265923; SD = 74.244636; Median 1408.578537 # each ∎ represents a count of 1 853.7746 - 910.9590 [ 1]: ∎ 910.9590 - 968.1435 [ 0]: 968.1435 - 1025.3280 [ 1]: ∎ 1025.3280 - 1082.5124 [ 0]: 1082.5124 - 1139.6969 [ 0]: 1139.6969 - 1196.8813 [ 2]: ∎∎ 1196.8813 - 1254.0658 [ 1]: ∎ 1254.0658 - 1311.2502 [ 1]: ∎ 1311.2502 - 1368.4347 [11]: ∎∎∎ 1368.4347 - 1425.6192 [ 100]: 3.19.0+/flock01.data # NumSamples = 124; Min = 1415.92; Max = 1459.39 # Mean = 1430.258322; Variance = 36.425769; SD = 6.035376; Median 1429.462718 # each ∎ represents a count of 1 1415.9192 - 1420.2667 [ 2]: ∎∎ 1420.2667 - 1424.6142 [19]: ∎∎∎ 1424.6142 - 1428.9617 [36]: 1428.9617 - 1433.3092 [32]: 1433.3092 - 1437.6567 [22]: ∎∎ 1437.6567 - 1442.0042 [10]: ∎∎ 1442.0042 - 1446.3517 [ 2]: ∎∎ 1446.3517 - 1450.6992 [ 0]: 1450.6992 - 1455.0467 [ 0]: 1455.0467 - 1459.3942 [ 1]: ∎ 3.19/flock01-with-reader.data # NumSamples = 97; Min = 1342.97; Max = 1423.54 # Mean = 1410.695019; Variance = 149.115584; SD = 12.211289; Median 1413.260338 # each ∎ represents a count of 1 1342.9675 - 1351.0245 [ 1]: ∎ 1351.0245 - 1359.0815 [ 0]: 1359.0815 - 1367.1384 [ 1]: ∎ 1367.1384 - 1375.1954 [ 1]: ∎ 1375.1954 - 1383.2524 [ 1]: ∎ 1383.2524 - 1391.3093 [ 4]: 1391.3093 - 1399.3663 [ 0]: 1399.3663 - 1407.4233 [10]: ∎∎ 1407.4233 - 1415.4803 [45]: ∎ 1415.4803 - 1423.5372 [34]: ∎∎ 3.19.0+/flock01-with-reader.data # NumSamples = 104; Min = 1331.30; Max = 1349.97 # Mean = 1340.767603; Variance = 16.434314; SD = 4.053926; M
[RFC v1 4/5] locks: Use percpu spinlocks to protect file_lock_list
Replace the lglock with percpu spinlocks. That allows us to iterate in
the seqfile ops without taking all underlyng spinlocks with the
lg_global_lock().
Signed-off-by: Daniel Wagner
Cc: Jeff Layton
Cc: "J. Bruce Fields"
Cc: Alexander Viro
---
fs/locks.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 142e4fd..20ed00a 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -128,7 +128,6 @@
#include
#include
#include
-#include
#define CREATE_TRACE_POINTS
#include
@@ -160,10 +159,10 @@ int lease_break_time = 45;
/*
* The global file_lock_list is only used for displaying /proc/locks, so we
* keep a list on each CPU, with each list protected by its own spinlock via
- * the file_lock_lglock. Note that alterations to the list also require that
+ * the file_lock_lock. Note that alterations to the list also require that
* the relevant flc_lock is held.
*/
-DEFINE_STATIC_LGLOCK(file_lock_lglock);
+static DEFINE_PER_CPU(spinlock_t, file_lock_lock);
static DEFINE_PER_CPU(struct hlist_head, file_lock_list);
/*
@@ -561,10 +560,10 @@ static int posix_same_owner(struct file_lock *fl1, struct
file_lock *fl2)
/* Must be called with the flc_lock held! */
static void locks_insert_global_locks(struct file_lock *fl)
{
- lg_local_lock(&file_lock_lglock);
+ spin_lock(this_cpu_ptr(&file_lock_lock));
fl->fl_link_cpu = smp_processor_id();
hlist_add_head(&fl->fl_link, this_cpu_ptr(&file_lock_list));
- lg_local_unlock(&file_lock_lglock);
+ spin_unlock(this_cpu_ptr(&file_lock_lock));
}
/* Must be called with the flc_lock held! */
@@ -577,9 +576,9 @@ static void locks_delete_global_locks(struct file_lock *fl)
*/
if (hlist_unhashed(&fl->fl_link))
return;
- lg_local_lock_cpu(&file_lock_lglock, fl->fl_link_cpu);
+ spin_lock(per_cpu_ptr(&file_lock_lock, fl->fl_link_cpu));
hlist_del_init(&fl->fl_link);
- lg_local_unlock_cpu(&file_lock_lglock, fl->fl_link_cpu);
+ spin_unlock(per_cpu_ptr(&file_lock_lock, fl->fl_link_cpu));
}
static unsigned long
@@ -2628,9 +2627,9 @@ static void *locks_start(struct seq_file *f, loff_t *pos)
struct locks_iterator *iter = f->private;
iter->li_pos = *pos + 1;
- lg_global_lock(&file_lock_lglock);
spin_lock(&blocked_lock_lock);
- return seq_hlist_start_percpu(&file_lock_list, &iter->li_cpu, *pos);
+ return seq_hlist_start_percpu_locked(&file_lock_list, &file_lock_lock,
+ &iter->li_cpu, *pos);
}
static void *locks_next(struct seq_file *f, void *v, loff_t *pos)
@@ -2638,14 +2637,17 @@ static void *locks_next(struct seq_file *f, void *v,
loff_t *pos)
struct locks_iterator *iter = f->private;
++iter->li_pos;
- return seq_hlist_next_percpu(v, &file_lock_list, &iter->li_cpu, pos);
+ return seq_hlist_next_percpu_locked(v, &file_lock_list, &file_lock_lock,
+ &iter->li_cpu, pos);
}
static void locks_stop(struct seq_file *f, void *v)
__releases(&blocked_lock_lock)
{
+ struct locks_iterator *iter = f->private;
+
+ seq_hlist_stop_percpu_locked(v, &file_lock_lock, &iter->li_cpu);
spin_unlock(&blocked_lock_lock);
- lg_global_unlock(&file_lock_lglock);
}
static const struct seq_operations locks_seq_operations = {
@@ -2686,10 +2688,10 @@ static int __init filelock_init(void)
filelock_cache = kmem_cache_create("file_lock_cache",
sizeof(struct file_lock), 0, SLAB_PANIC, NULL);
- lg_lock_init(&file_lock_lglock, "file_lock_lglock");
-
- for_each_possible_cpu(i)
+ for_each_possible_cpu(i) {
INIT_HLIST_HEAD(per_cpu_ptr(&file_lock_list, i));
+ spin_lock_init(per_cpu_ptr(&file_lock_lock, i));
+ }
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v1 5/5] locks: Use blocked_lock_lock only to protect blocked_hash
blocked_lock_lock and file_lock_lock is used to protect file_lock's
fl_link, fl_block, fl_next, blocked_hash and the percpu
file_lock_list.
The plan is to reorganize the usage of the locks and what they protect
so that the usage of the global blocked_lock_lock is reduced.
Whenever we insert a new lock we are going to grab besides the
flc_lock also the corresponding percpu file_lock_lock. The global
blocked_lock_lock is only used when blocked_hash is involved.
file_lock_lock protects now file_lock_list and fl_link, fl_block and
fl_next allone. That means we need to define which file_lock_lock is
used for all waiters. Luckely, fl_link_cpu can be reused for fl_block
and fl_next.
Signed-off-by: Daniel Wagner
Cc: Jeff Layton
Cc: "J. Bruce Fields"
Cc: Alexander Viro
---
fs/locks.c | 78 ++
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 20ed00a..73b99ac 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -161,6 +161,20 @@ int lease_break_time = 45;
* keep a list on each CPU, with each list protected by its own spinlock via
* the file_lock_lock. Note that alterations to the list also require that
* the relevant flc_lock is held.
+ *
+ * In addition, it also protects the fl->fl_block list, and the fl->fl_next
+ * pointer for file_lock structures that are acting as lock requests (in
+ * contrast to those that are acting as records of acquired locks).
+ *
+ * file_lock structures acting as lock requests (waiters) use the same
+ * spinlock as the those acting as lock holder (blocker). E.g. the
+ * blocker is initially added to the file_lock_list living on CPU 0,
+ * all waiters on that blocker are serialized via CPU 0 (see
+ * fl_link_cpu usage).
+ *
+ * In particular, adding an entry to the fl_block list requires that you hold
+ * both the flc_lock and the blocked_lock_lock (acquired in that order).
+ * Deleting an entry from the list however only requires the file_lock_lock.
*/
static DEFINE_PER_CPU(spinlock_t, file_lock_lock);
static DEFINE_PER_CPU(struct hlist_head, file_lock_list);
@@ -182,19 +196,6 @@ static DEFINE_HASHTABLE(blocked_hash, BLOCKED_HASH_BITS);
/*
* This lock protects the blocked_hash. Generally, if you're accessing it, you
* want to be holding this lock.
- *
- * In addition, it also protects the fl->fl_block list, and the fl->fl_next
- * pointer for file_lock structures that are acting as lock requests (in
- * contrast to those that are acting as records of acquired locks).
- *
- * Note that when we acquire this lock in order to change the above fields,
- * we often hold the flc_lock as well. In certain cases, when reading the
fields
- * protected by this lock, we can skip acquiring it iff we already hold the
- * flc_lock.
- *
- * In particular, adding an entry to the fl_block list requires that you hold
- * both the flc_lock and the blocked_lock_lock (acquired in that order).
- * Deleting an entry from the list however only requires the file_lock_lock.
*/
static DEFINE_SPINLOCK(blocked_lock_lock);
@@ -602,7 +603,7 @@ static void locks_delete_global_blocked(struct file_lock
*waiter)
/* Remove waiter from blocker's block list.
* When blocker ends up pointing to itself then the list is empty.
*
- * Must be called with blocked_lock_lock held.
+ * Must be called with file_lock_lock held.
*/
static void __locks_delete_block(struct file_lock *waiter)
{
@@ -612,7 +613,7 @@ static void __locks_delete_block(struct file_lock *waiter)
/* Posix block variant of __locks_delete_block.
*
- * Must be called with blocked_lock_lock held.
+ * Must be called with file_lock_lock held.
*/
static void __locks_delete_posix_block(struct file_lock *waiter)
{
@@ -622,16 +623,18 @@ static void __locks_delete_posix_block(struct file_lock
*waiter)
static void locks_delete_block(struct file_lock *waiter)
{
- spin_lock(&blocked_lock_lock);
+ spin_lock(per_cpu_ptr(&file_lock_lock, waiter->fl_link_cpu));
__locks_delete_block(waiter);
- spin_unlock(&blocked_lock_lock);
+ spin_unlock(per_cpu_ptr(&file_lock_lock, waiter->fl_link_cpu));
}
static void locks_delete_posix_block(struct file_lock *waiter)
{
+ spin_lock(per_cpu_ptr(&file_lock_lock, waiter->fl_link_cpu));
spin_lock(&blocked_lock_lock);
__locks_delete_posix_block(waiter);
spin_unlock(&blocked_lock_lock);
+ spin_unlock(per_cpu_ptr(&file_lock_lock, waiter->fl_link_cpu));
}
/* Insert waiter into blocker's block list.
@@ -639,22 +642,23 @@ static void locks_delete_posix_block(struct file_lock
*waiter)
* the order they blocked. The documentation doesn't require this but
* it seems like the reasonable thing to do.
*
- * Must be called with both the flc_lock and blocked_lock_lock held. The
- * fl_block list itself is protected by the blocked_lock_lock, but by ensuring
+ * Must be called with both the flc_lock and file_lock_lock held. The
+ * fl_block
Re: [PATCH] mm: hide per-cpu lists in output of show_mem()
On 20.02.2015 17:39, Konstantin Khlebnikov wrote: This makes show_mem() much less verbose at huge machines. Instead of huge and almost useless dump of counters for each per-zone per-cpu lists this patch prints sum of these counters for each zone (free_pcp) and size of per-cpu list for current cpu (local_pcp). Before: [ 14.569103] sysrq: SysRq : Show Memory [ 14.569599] Mem-Info: [ 14.569870] Node 0 DMA per-cpu: [ 14.570375] CPU0: hi:0, btch: 1 usd: 0 [ 14.570913] CPU1: hi:0, btch: 1 usd: 0 [ 14.571449] CPU2: hi:0, btch: 1 usd: 0 [ 14.571978] CPU3: hi:0, btch: 1 usd: 0 [ 14.572507] CPU4: hi:0, btch: 1 usd: 0 [ 14.573090] CPU5: hi:0, btch: 1 usd: 0 [ 14.573914] CPU6: hi:0, btch: 1 usd: 0 [ 14.574869] CPU7: hi:0, btch: 1 usd: 0 [ 14.575413] CPU8: hi:0, btch: 1 usd: 0 [ 14.576233] CPU9: hi:0, btch: 1 usd: 0 [ 14.577054] CPU 10: hi:0, btch: 1 usd: 0 [ 14.577869] CPU 11: hi:0, btch: 1 usd: 0 [ 14.578690] CPU 12: hi:0, btch: 1 usd: 0 [ 14.579510] CPU 13: hi:0, btch: 1 usd: 0 [ 14.580346] CPU 14: hi:0, btch: 1 usd: 0 [ 14.581165] CPU 15: hi:0, btch: 1 usd: 0 [ 14.582044] CPU 16: hi:0, btch: 1 usd: 0 [ 14.582903] CPU 17: hi:0, btch: 1 usd: 0 [ 14.583727] CPU 18: hi:0, btch: 1 usd: 0 [ 14.584544] CPU 19: hi:0, btch: 1 usd: 0 [ 14.585362] CPU 20: hi:0, btch: 1 usd: 0 [ 14.586178] CPU 21: hi:0, btch: 1 usd: 0 [ 14.587103] CPU 22: hi:0, btch: 1 usd: 0 [ 14.588099] CPU 23: hi:0, btch: 1 usd: 0 [ 14.588914] CPU 24: hi:0, btch: 1 usd: 0 [ 14.589735] CPU 25: hi:0, btch: 1 usd: 0 [ 14.590553] CPU 26: hi:0, btch: 1 usd: 0 [ 14.591401] CPU 27: hi:0, btch: 1 usd: 0 [ 14.592215] CPU 28: hi:0, btch: 1 usd: 0 [ 14.604465] CPU 29: hi:0, btch: 1 usd: 0 [ 14.605291] CPU 30: hi:0, btch: 1 usd: 0 [ 14.606113] CPU 31: hi:0, btch: 1 usd: 0 [ 14.606931] Node 0 DMA32 per-cpu: [ 14.607718] CPU0: hi: 186, btch: 31 usd: 84 [ 14.608945] CPU1: hi: 186, btch: 31 usd: 119 [ 14.610359] CPU2: hi: 186, btch: 31 usd: 158 [ 14.611785] CPU3: hi: 186, btch: 31 usd: 35 [ 14.612615] CPU4: hi: 186, btch: 31 usd: 121 [ 14.613463] CPU5: hi: 186, btch: 31 usd: 155 [ 14.614291] CPU6: hi: 186, btch: 31 usd: 130 [ 14.615128] CPU7: hi: 186, btch: 31 usd: 77 [ 14.615944] CPU8: hi: 186, btch: 31 usd: 159 [ 14.616921] CPU9: hi: 186, btch: 31 usd: 119 [ 14.617756] CPU 10: hi: 186, btch: 31 usd: 100 [ 14.618649] CPU 11: hi: 186, btch: 31 usd: 37 [ 14.619483] CPU 12: hi: 186, btch: 31 usd: 66 [ 14.620309] CPU 13: hi: 186, btch: 31 usd: 69 [ 14.621345] CPU 14: hi: 186, btch: 31 usd: 182 [ 14.622295] CPU 15: hi: 186, btch: 31 usd: 127 [ 14.623196] CPU 16: hi: 186, btch: 31 usd: 106 [ 14.624029] CPU 17: hi: 186, btch: 31 usd: 90 [ 14.624848] CPU 18: hi: 186, btch: 31 usd: 161 [ 14.625677] CPU 19: hi: 186, btch: 31 usd: 71 [ 14.626503] CPU 20: hi: 186, btch: 31 usd: 86 [ 14.627328] CPU 21: hi: 186, btch: 31 usd: 159 [ 14.628176] CPU 22: hi: 186, btch: 31 usd: 74 [ 14.633389] CPU 23: hi: 186, btch: 31 usd: 111 [ 14.635477] CPU 24: hi: 186, btch: 31 usd: 156 [ 14.636926] CPU 25: hi: 186, btch: 31 usd: 144 [ 14.638054] CPU 26: hi: 186, btch: 31 usd: 87 [ 14.638903] CPU 27: hi: 186, btch: 31 usd: 50 [ 14.639826] CPU 28: hi: 186, btch: 31 usd: 82 [ 14.640694] CPU 29: hi: 186, btch: 31 usd: 166 [ 14.641607] CPU 30: hi: 186, btch: 31 usd: 85 [ 14.642862] CPU 31: hi: 186, btch: 31 usd: 0 [ 14.644891] Node 1 DMA32 per-cpu: [ 14.646254] CPU0: hi: 186, btch: 31 usd: 126 [ 14.647110] CPU1: hi: 186, btch: 31 usd: 107 [ 14.647942] CPU2: hi: 186, btch: 31 usd: 125 [ 14.648788] CPU3: hi: 186, btch: 31 usd: 42 [ 14.649696] CPU4: hi: 186, btch: 31 usd: 0 [ 14.650522] CPU5: hi: 186, btch: 31 usd: 90 [ 14.651351] CPU6: hi: 186, btch: 31 usd: 132 [ 14.652173] CPU7: hi: 186, btch: 31 usd: 103 [ 14.653000] CPU8: hi: 186, btch: 31 usd: 106 [ 14.654050] CPU9: hi: 186, btch: 31 usd: 133 [ 14.655265] CPU 10: hi: 186, btch: 31 usd: 86 [ 14.656131] CPU 11: hi: 186, btch: 31 usd: 100 [ 14.657017] CPU 12: hi: 186, btch: 31 usd: 131 [ 14.657841] CPU 13: hi: 186, btch: 31 usd: 106 [ 14.659426] CPU 14: hi: 186, btch: 31 usd: 158 [ 14.660518] CPU 15: hi: 186, btch: 31 usd: 172 [ 14.662480] CPU 16: hi: 186, btch: 31 usd: 70 [ 14.663907] CPU 17: hi: 186, btch: 31 usd: 125 [ 14.665075] CPU 18: hi: 186, btch: 31 usd: 99 [ 14.666047] C
[RFC v1 2/5] locks: Split insert/delete block functions into flock/posix parts
The locks_insert/delete_block() functions are used for flock, posix
and leases types. blocked_lock_lock is used to serialize all access to
fl_link, fl_block, fl_next and blocked_hash. Here, we prepare the
stage for using blocked_lock_lock to protect blocked_hash.
Signed-off-by: Daniel Wagner
Cc: Jeff Layton
Cc: "J. Bruce Fields"
Cc: Alexander Viro
---
fs/locks.c | 48
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index f63aa92..142e4fd 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -607,11 +607,20 @@ static void locks_delete_global_blocked(struct file_lock
*waiter)
*/
static void __locks_delete_block(struct file_lock *waiter)
{
- locks_delete_global_blocked(waiter);
list_del_init(&waiter->fl_block);
waiter->fl_next = NULL;
}
+/* Posix block variant of __locks_delete_block.
+ *
+ * Must be called with blocked_lock_lock held.
+ */
+static void __locks_delete_posix_block(struct file_lock *waiter)
+{
+ locks_delete_global_blocked(waiter);
+ __locks_delete_block(waiter);
+}
+
static void locks_delete_block(struct file_lock *waiter)
{
spin_lock(&blocked_lock_lock);
@@ -619,6 +628,13 @@ static void locks_delete_block(struct file_lock *waiter)
spin_unlock(&blocked_lock_lock);
}
+static void locks_delete_posix_block(struct file_lock *waiter)
+{
+ spin_lock(&blocked_lock_lock);
+ __locks_delete_posix_block(waiter);
+ spin_unlock(&blocked_lock_lock);
+}
+
/* Insert waiter into blocker's block list.
* We use a circular list so that processes can be easily woken up in
* the order they blocked. The documentation doesn't require this but
@@ -635,7 +651,17 @@ static void __locks_insert_block(struct file_lock *blocker,
BUG_ON(!list_empty(&waiter->fl_block));
waiter->fl_next = blocker;
list_add_tail(&waiter->fl_block, &blocker->fl_block);
- if (IS_POSIX(blocker) && !IS_OFDLCK(blocker))
+}
+
+/* Posix block variant of __locks_insert_block.
+ *
+ * Must be called with flc_lock and blocked_lock_lock held.
+ */
+static void __locks_insert_posix_block(struct file_lock *blocker,
+ struct file_lock *waiter)
+{
+ __locks_insert_block(blocker, waiter);
+ if (!IS_OFDLCK(blocker))
locks_insert_global_blocked(waiter);
}
@@ -671,7 +697,10 @@ static void locks_wake_up_blocks(struct file_lock *blocker)
waiter = list_first_entry(&blocker->fl_block,
struct file_lock, fl_block);
- __locks_delete_block(waiter);
+ if (IS_POSIX(blocker))
+ __locks_delete_posix_block(waiter);
+ else
+ __locks_delete_block(waiter);
if (waiter->fl_lmops && waiter->fl_lmops->lm_notify)
waiter->fl_lmops->lm_notify(waiter);
else
@@ -979,7 +1008,7 @@ static int __posix_lock_file(struct inode *inode, struct
file_lock *request, str
spin_lock(&blocked_lock_lock);
if (likely(!posix_locks_deadlock(request, fl))) {
error = FILE_LOCK_DEFERRED;
- __locks_insert_block(fl, request);
+ __locks_insert_posix_block(fl, request);
}
spin_unlock(&blocked_lock_lock);
goto out;
@@ -1180,7 +1209,7 @@ int posix_lock_file_wait(struct file *filp, struct
file_lock *fl)
if (!error)
continue;
- locks_delete_block(fl);
+ locks_delete_posix_block(fl);
break;
}
return error;
@@ -1277,7 +1306,7 @@ int locks_mandatory_area(int read_write, struct inode
*inode,
continue;
}
- locks_delete_block(&fl);
+ locks_delete_posix_block(&fl);
break;
}
@@ -2097,7 +2126,10 @@ static int do_lock_file_wait(struct file *filp, unsigned
int cmd,
if (!error)
continue;
- locks_delete_block(fl);
+ if (IS_POSIX(fl))
+ locks_delete_posix_block(fl);
+ else
+ locks_delete_block(fl);
break;
}
@@ -2461,7 +2493,7 @@ posix_unblock_lock(struct file_lock *waiter)
spin_lock(&blocked_lock_lock);
if (waiter->fl_next)
- __locks_delete_block(waiter);
+ __locks_delete_posix_block(waiter);
else
status = -ENOENT;
spin_unlock(&blocked_lock_lock);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordo
Re: [PATCH 4/6] thinkpad_acpi: Add support for more adaptive kbd buttons
On Thu, 2015-02-19 at 21:35 -0800, Darren Hart wrote:
> On Wed, Feb 18, 2015 at 09:53:48PM +0100, Bastien Nocera wrote:
> > This commit adds new elements to the ThinkPad keymaps, and
> > will send key events for keys for which an input.h declaration
> > exists.
> >
> > Signed-off-by: Bastien Nocera
> > ---
> > drivers/platform/x86/thinkpad_acpi.c | 80
> > +++-
> > 1 file changed, 79 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/thinkpad_acpi.c
> > b/drivers/platform/x86/thinkpad_acpi.c
> > index 562d958..a47a56a 100644
> > --- a/drivers/platform/x86/thinkpad_acpi.c
> > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > @@ -1911,6 +1911,27 @@ enum { /* hot key scan codes (derived from
> > ACPI DSDT) */
> > TP_ACPI_HOTKEYSCAN_UNK7,
> > TP_ACPI_HOTKEYSCAN_UNK8,
> >
> > + TP_ACPI_HOTKEYSCAN_MUTE2,
> > + TP_ACPI_HOTKEYSCAN_BRIGHTNESS_ZERO,
> > + TP_ACPI_HOTKEYSCAN_CLIPPING_TOOL,
> > + TP_ACPI_HOTKEYSCAN_CLOUD,
> > + TP_ACPI_HOTKEYSCAN_UNK9,
> > + TP_ACPI_HOTKEYSCAN_VOICE,
> > + TP_ACPI_HOTKEYSCAN_UNK10,
> > + TP_ACPI_HOTKEYSCAN_GESTURES,
> > + TP_ACPI_HOTKEYSCAN_UNK11,
> > + TP_ACPI_HOTKEYSCAN_UNK12,
> > + TP_ACPI_HOTKEYSCAN_UNK13,
> > + TP_ACPI_HOTKEYSCAN_CONFIG,
> > + TP_ACPI_HOTKEYSCAN_NEW_TAB,
> > + TP_ACPI_HOTKEYSCAN_RELOAD,
> > + TP_ACPI_HOTKEYSCAN_BACK,
> > + TP_ACPI_HOTKEYSCAN_MIC_DOWN,
> > + TP_ACPI_HOTKEYSCAN_MIC_UP,
> > + TP_ACPI_HOTKEYSCAN_MIC_CANCELLATION,
> > + TP_ACPI_HOTKEYSCAN_CAMERA_MODE,
> > + TP_ACPI_HOTKEYSCAN_ROTATE_DISPLAY,
> > +
> > /* Hotkey keymap size */
> > TPACPI_HOTKEY_MAP_LEN
> > };
> > @@ -3171,6 +3192,13 @@ static int __init hotkey_init(struct ibm_init_struct
> > *iibm)
> > /* (assignments unknown, please report if found) */
> > KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > +
> > + /* no assignments, only used for Adaptive keyboards */
>
> Sentence formatting please.
Done.
> > + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > + KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
> > },
> >
> > /* Generic keymap for Lenovo ThinkPads */
> > @@ -3227,6 +3255,33 @@ static int __init hotkey_init(struct ibm_init_struct
> > *iibm)
> >
> > /* Extra keys in use since the X240 / T440 / T540 */
> > KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_FILE,
> > +
> > + /* Adaptive keyboard keycodes for Carbon X1 2014,
> > +* The first item in this list is the Mute button
> > +* which is emitted with 0x103 through
> > +* adaptive_keyboard_hotkey_notify_hotkey ()
> > +* when the sound symbol is held
> > +* We'll need to offset those by 0x20 */
>
> Please follow CodingStyle with /* and */ on their own lines. Also, wrapping is
> strange, as is capitalization, etc. Please terminate sentences with periods,
> and only capitalize the beginning of sentences or proper nouns.
Done.
> > + KEY_RESERVED,/* Mute held, 0x103 */
> > + KEY_BRIGHTNESS_MIN, /* Backlight off */
> > + KEY_RESERVED,/* Clipping tool */
> > + KEY_RESERVED,/* Cloud */
> > + KEY_RESERVED,
> > + KEY_VOICECOMMAND,/* Voice */
> > + KEY_RESERVED,
> > + KEY_RESERVED,/* Gestures */
> > + KEY_RESERVED,
> > + KEY_RESERVED,
> > + KEY_RESERVED,
> > + KEY_CONFIG, /* Settings */
> > + KEY_RESERVED,/* New tab */
> > + KEY_REFRESH, /* Reload */
> > + KEY_BACK,/* Back */
> > + KEY_RESERVED,/* Microphone down */
> > + KEY_RESERVED,/* Microphone up */
> > + KEY_RESERVED,/* Microphone cancellation */
> > + KEY_RESERVED,/* Camera mode */
> > + KEY_RESERVED,/* Rotate display, 0x116 */
> > },
> > };
> >
> > @@ -3526,6 +3581,8 @@ const int adaptive_keyboard_modes[] = {
> >
> > #define DFR_CHANGE_ROW 0x101
> > #define DFR_SHOW_QUICKVIEW_ROW 0x102
> > +#define FIRST_ADAPTIVE_KEY 0x103
> > +#define ADAPTIVE_KEY_OFFSET0x020
> >
> > /* press Fn key a while second, it will switch to Function Mode. Then
> > * release Fn key, previous mode be restored.
> > @@ -3581,6 +3638,7 @@ static bool
> > adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
> > {
> > u32 current_mode = 0;
> > int new_mode = 0;
> > + int keycode;
> >
> > switch (scancode) {
> > case DFR_CHANGE_ROW:
> > @@ -3613,7 +367
[PATCH 1/7] thinkpad_acpi: Remember adaptive kbd presence
Rather than checking on each suspend and resume whether the laptop
has an adaptive keyboard, check when the driver is initialised.
Signed-off-by: Bastien Nocera
---
drivers/platform/x86/thinkpad_acpi.c | 37 ++--
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index c3d11fa..c1f4daf 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -318,6 +318,7 @@ static struct {
u32 sensors_pdrv_attrs_registered:1;
u32 sensors_pdev_attrs_registered:1;
u32 hotkey_poll_active:1;
+ u32 has_adaptive_kbd:1;
} tp_features;
static struct {
@@ -3226,6 +3227,15 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
if (!tp_features.hotkey)
return 1;
+ /*
+* Check if we have an adaptive keyboard, like on the
+* Lenovo Carbon X1 2014 (2nd Gen).
+*/
+ if (acpi_evalf(hkey_handle, &hkeyv, "MHKV", "qd")) {
+ if ((hkeyv >> 8) == 2)
+ tp_features.has_adaptive_kbd = true;
+ }
+
quirks = tpacpi_check_quirks(tpacpi_hotkey_qtable,
ARRAY_SIZE(tpacpi_hotkey_qtable));
@@ -3834,28 +3844,21 @@ static void hotkey_notify(struct ibm_struct *ibm, u32
event)
static void hotkey_suspend(void)
{
- int hkeyv;
-
/* Do these on suspend, we get the events on early resume! */
hotkey_wakeup_reason = TP_ACPI_WAKEUP_NONE;
hotkey_autosleep_ack = 0;
/* save previous mode of adaptive keyboard of X1 Carbon */
- if (acpi_evalf(hkey_handle, &hkeyv, "MHKV", "qd")) {
- if ((hkeyv >> 8) == 2) {
- if (!acpi_evalf(hkey_handle,
- &adaptive_keyboard_prev_mode,
- "GTRW", "dd", 0)) {
- pr_err("Cannot read adaptive keyboard mode.\n");
- }
+ if (tp_features.has_adaptive_kbd) {
+ if (!acpi_evalf(hkey_handle, &adaptive_keyboard_prev_mode,
+ "GTRW", "dd", 0)) {
+ pr_err("Cannot read adaptive keyboard mode.\n");
}
}
}
static void hotkey_resume(void)
{
- int hkeyv;
-
tpacpi_disable_brightness_delay();
if (hotkey_status_set(true) < 0 ||
@@ -3870,14 +3873,10 @@ static void hotkey_resume(void)
hotkey_poll_setup_safe(false);
/* restore previous mode of adapive keyboard of X1 Carbon */
- if (acpi_evalf(hkey_handle, &hkeyv, "MHKV", "qd")) {
- if ((hkeyv >> 8) == 2) {
- if (!acpi_evalf(hkey_handle,
- NULL,
- "STRW", "vd",
- adaptive_keyboard_prev_mode)) {
- pr_err("Cannot set adaptive keyboard mode.\n");
- }
+ if (tp_features.has_adaptive_kbd) {
+ if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd",
+ adaptive_keyboard_prev_mode)) {
+ pr_err("Cannot set adaptive keyboard mode.\n");
}
}
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] thinkpad_acpi: Add support for more adaptive kbd buttons
This commit adds new elements to the ThinkPad keymaps, and
will send key events for keys for which an input.h declaration
exists.
Signed-off-by: Bastien Nocera
---
drivers/platform/x86/thinkpad_acpi.c | 80 +++-
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 2030c54..57130a1 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -1911,6 +1911,27 @@ enum { /* hot key scan codes (derived from ACPI DSDT)
*/
TP_ACPI_HOTKEYSCAN_UNK7,
TP_ACPI_HOTKEYSCAN_UNK8,
+ TP_ACPI_HOTKEYSCAN_MUTE2,
+ TP_ACPI_HOTKEYSCAN_BRIGHTNESS_ZERO,
+ TP_ACPI_HOTKEYSCAN_CLIPPING_TOOL,
+ TP_ACPI_HOTKEYSCAN_CLOUD,
+ TP_ACPI_HOTKEYSCAN_UNK9,
+ TP_ACPI_HOTKEYSCAN_VOICE,
+ TP_ACPI_HOTKEYSCAN_UNK10,
+ TP_ACPI_HOTKEYSCAN_GESTURES,
+ TP_ACPI_HOTKEYSCAN_UNK11,
+ TP_ACPI_HOTKEYSCAN_UNK12,
+ TP_ACPI_HOTKEYSCAN_UNK13,
+ TP_ACPI_HOTKEYSCAN_CONFIG,
+ TP_ACPI_HOTKEYSCAN_NEW_TAB,
+ TP_ACPI_HOTKEYSCAN_RELOAD,
+ TP_ACPI_HOTKEYSCAN_BACK,
+ TP_ACPI_HOTKEYSCAN_MIC_DOWN,
+ TP_ACPI_HOTKEYSCAN_MIC_UP,
+ TP_ACPI_HOTKEYSCAN_MIC_CANCELLATION,
+ TP_ACPI_HOTKEYSCAN_CAMERA_MODE,
+ TP_ACPI_HOTKEYSCAN_ROTATE_DISPLAY,
+
/* Hotkey keymap size */
TPACPI_HOTKEY_MAP_LEN
};
@@ -3169,6 +3190,13 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
/* (assignments unknown, please report if found) */
KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+
+ /* No assignments, only used for Adaptive keyboards. */
+ KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+ KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+ KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+ KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
+ KEY_UNKNOWN, KEY_UNKNOWN, KEY_UNKNOWN,
},
/* Generic keymap for Lenovo ThinkPads */
@@ -3225,6 +3253,35 @@ static int __init hotkey_init(struct ibm_init_struct
*iibm)
/* Extra keys in use since the X240 / T440 / T540 */
KEY_CONFIG, KEY_SEARCH, KEY_SCALE, KEY_FILE,
+
+ /*
+* These are the adaptive keyboard keycodes for Carbon X1 2014.
+* The first item in this list is the Mute button which is
+* emitted with 0x103 through
+* adaptive_keyboard_hotkey_notify_hotkey() when the sound
+* symbol is held.
+* We'll need to offset those by 0x20.
+*/
+ KEY_RESERVED,/* Mute held, 0x103 */
+ KEY_BRIGHTNESS_MIN, /* Backlight off */
+ KEY_RESERVED,/* Clipping tool */
+ KEY_RESERVED,/* Cloud */
+ KEY_RESERVED,
+ KEY_VOICECOMMAND,/* Voice */
+ KEY_RESERVED,
+ KEY_RESERVED,/* Gestures */
+ KEY_RESERVED,
+ KEY_RESERVED,
+ KEY_RESERVED,
+ KEY_CONFIG, /* Settings */
+ KEY_RESERVED,/* New tab */
+ KEY_REFRESH, /* Reload */
+ KEY_BACK,/* Back */
+ KEY_RESERVED,/* Microphone down */
+ KEY_RESERVED,/* Microphone up */
+ KEY_RESERVED,/* Microphone cancellation */
+ KEY_RESERVED,/* Camera mode */
+ KEY_RESERVED,/* Rotate display, 0x116 */
},
};
@@ -3526,6 +3583,8 @@ const int adaptive_keyboard_modes[] = {
#define DFR_CHANGE_ROW 0x101
#define DFR_SHOW_QUICKVIEW_ROW 0x102
+#define FIRST_ADAPTIVE_KEY 0x103
+#define ADAPTIVE_KEY_OFFSET0x020
/* press Fn key a while second, it will switch to Function Mode. Then
* release Fn key, previous mode be restored.
@@ -3581,6 +3640,7 @@ static bool
adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
{
u32 current_mode = 0;
int new_mode = 0;
+ int keycode;
switch (scancode) {
case DFR_CHANGE_ROW:
@@ -3613,7 +3673,25 @@ static bool
adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
return true;
default:
- return false;
+ if (scancode < FIRST_ADAPTIVE_KEY || scancode >
FIRST_ADAPTIVE_KEY +
+ TPACPI_HOTKEY_MAP_LEN - ADAPTIVE_KEY_OFFSET) {
+ pr_info("Unhandled adaptive keyboard key: 0x%x\n",
+ scancode);
+ return false;
+ }
+ keycode
[PATCH 5/7] input: Add keycodes used by Lenovo Carbon X1 2014
Signed-off-by: Bastien Nocera
---
include/uapi/linux/input.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index b0a8130..affe40e 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -740,6 +740,16 @@ struct input_keymap_entry {
#define KEY_BRIGHTNESS_MIN 0x250 /* Set Brightness to Minimum */
#define KEY_BRIGHTNESS_MAX 0x251 /* Set Brightness to Maximum */
+#define KEY_CLIPPING_TOOL 0x252 /* Screenshot clipping tool */
+#define KEY_CLOUD 0x253 /* Cloud Settings */
+#define KEY_CAMERA_GESTURES0x254 /* Toggle Camera gestures */
+#define KEY_NEW_TAB0x255 /* Open a new tab */
+#define KEY_MICUP 0x256 /* Microphone Up */
+#define KEY_MICDOWN0x257 /* Microphone Down */
+#define KEY_MICCANCEL_MODE 0x258 /* Toggle Microphone
cancellation mode */
+#define KEY_CAMERA_ZOOM_MODE 0x259 /* Toggle camera zoom mode */
+#define KEY_ROTATE_DISPLAY 0x25a /* Rotate screen by 90 degrees
*/
+
#define KEY_KBDINPUTASSIST_PREV0x260
#define KEY_KBDINPUTASSIST_NEXT0x261
#define KEY_KBDINPUTASSIST_PREVGROUP 0x262
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/2] time: Add ktime_get_mono_raw_fast_ns()
By popular demand, add a MONOTONIC_RAW variant.
The implementation is up for discussion; but given the need for the
dummy thing I thought it was easiest to just always update the
mono_raw clock state in timekeeping_update() for now, even though its
mostly wasted cycles.
I suppose the right place would be a resume callback somewhere.
Cc: Thomas Gleixner
Cc: John Stultz
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/timekeeping.h |1 +
kernel/time/timekeeping.c | 42 +++---
2 files changed, 36 insertions(+), 7 deletions(-)
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -220,6 +220,7 @@ static inline u64 ktime_get_raw_ns(void)
}
extern u64 ktime_get_mono_fast_ns(void);
+extern u64 ktime_get_mono_raw_fast_ns(void);
/*
* Timespec interfaces utilizing the ktime based ones
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -58,7 +58,8 @@ struct tk_fast {
struct tk_read_base base[2];
};
-static struct tk_fast tk_fast_mono cacheline_aligned;
+static struct tk_fast tk_fast_mono cacheline_aligned;
+static struct tk_fast tk_fast_mono_raw cacheline_aligned;
/* flag for if timekeeping is suspended */
int __read_mostly timekeeping_suspended;
@@ -267,18 +268,18 @@ static inline s64 timekeeping_get_ns_raw
* slightly wrong timestamp (a few nanoseconds). See
* @ktime_get_mono_fast_ns.
*/
-static void update_fast_timekeeper(struct tk_read_base *tkr)
+static void update_fast_timekeeper(struct tk_fast *fast, struct tk_read_base
*tkr)
{
- struct tk_read_base *base = tk_fast_mono.base;
+ struct tk_read_base *base = fast->base;
/* Force readers off to base[1] */
- raw_write_seqcount_latch(&tk_fast_mono.seq);
+ raw_write_seqcount_latch(&fast->seq);
/* Update base[0] */
memcpy(base, tkr, sizeof(*base));
/* Force readers back to base[0] */
- raw_write_seqcount_latch(&tk_fast_mono.seq);
+ raw_write_seqcount_latch(&fast->seq);
/* Update base[1] */
memcpy(base + 1, base, sizeof(*base));
@@ -332,6 +333,22 @@ u64 notrace ktime_get_mono_fast_ns(void)
}
EXPORT_SYMBOL_GPL(ktime_get_mono_fast_ns);
+u64 notrace ktime_get_mono_raw_fast_ns(void)
+{
+ struct tk_read_base *tkr;
+ unsigned int seq;
+ u64 now;
+
+ do {
+ seq = raw_read_seqcount(&tk_fast_mono_raw.seq);
+ tkr = tk_fast_mono_raw.base + (seq & 0x01);
+ now = ktime_to_ns(tkr->base_mono) + timekeeping_get_ns(tkr);
+
+ } while (read_seqcount_retry(&tk_fast_mono_raw.seq, seq));
+ return now;
+}
+EXPORT_SYMBOL_GPL(ktime_get_mono_raw_fast_ns);
+
/* Suspend-time cycles value for halted fast timekeeper. */
static cycle_t cycles_at_suspend;
@@ -358,7 +375,11 @@ static void halt_fast_timekeeper(struct
memcpy(&tkr_dummy, tkr, sizeof(tkr_dummy));
cycles_at_suspend = tkr->read(tkr->clock);
tkr_dummy.read = dummy_clock_read;
- update_fast_timekeeper(&tkr_dummy);
+ update_fast_timekeeper(&tk_fast_mono, &tkr_dummy);
+
+ tkr_dummy.mult = tkr->clock->mult;
+ tkr_dummy.shift = tkr->clock->shift;
+ update_fast_timekeeper(&tk_fast_mono_raw, &tkr_dummy);
}
#ifdef CONFIG_GENERIC_TIME_VSYSCALL_OLD
@@ -475,6 +496,8 @@ static inline void tk_update_ktime_data(
/* must hold timekeeper_lock */
static void timekeeping_update(struct timekeeper *tk, unsigned int action)
{
+ static struct tk_read_base tkr;
+
if (action & TK_CLEAR_NTP) {
tk->ntp_error = 0;
ntp_clear();
@@ -489,7 +512,12 @@ static void timekeeping_update(struct ti
memcpy(&shadow_timekeeper, &tk_core.timekeeper,
sizeof(tk_core.timekeeper));
- update_fast_timekeeper(&tk->tkr);
+ update_fast_timekeeper(&tk_fast_mono, &tk->tkr);
+
+ tkr = tk->tkr;
+ tkr.mult = tk->tkr.clock->mult;
+ tkr.shift = tk->tkr.clock->shift;
+ update_fast_timekeeper(&tk_fast_mono_raw, &tkr);
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v0 1/1] fs/locks: Use plain percpu spinlocks instead of lglock to protect file_lock
Hi Jeff, On 02/19/2015 09:49 PM, Jeff Layton wrote: > On Thu, 19 Feb 2015 15:26:14 +0100 > Daniel Wagner wrote: >> Whenever we insert a new lock we are going to grab besides the i_lock >> also the corresponding percpu file_lock_lock. The global >> blocked_lock_lock is only used when blocked_hash is involved. >> > > Ok, good. I like that part -- I hate the blocked_lock_lock, but freezing > the file locking state is the only way I've found to ensure the > correctness of deadlock detection. Bummer. Okay, I'll look into that. >> file_lock_list exists to be being able to produce the content of >> /proc/locks. For listing the all locks it seems a bit excessive to >> grab all locks at once. We should be okay just grabbing the >> corresponding lock when iterating over the percpu file_lock_list. >> > > True, but that's not a terribly common event, which is why I figured > the lg_lock was an acceptable tradeoff there. That said, if you can get > rid of it in favor of something more efficient then that sounds good to > me. If it helps the -rt kernels, then so much the better... Great! I was hoping to hear that :) >> file_lock_lock protects now file_lock_list and fl_link, fl_block and >> fl_next allone. That means we need to define which file_lock_lock is >> used for all waiters. Luckely, fl_link_cpu can be reused for fl_block >> and fl_next. >> > > Ok, so when a lock is blocked, we'll insert the waiter onto the > fl_block list for the blocker, and use the blocker's per-cpu spinlock > to protect that list. Good idea. Let's hope it doesn't explode. So far I am still confident it works. >> Signed-off-by: Daniel Wagner >> Cc: Alexander Viro >> Cc: Jeff Layton >> Cc: "J. Bruce Fields" >> Cc: John Kacur >> Cc: linux-fsde...@vger.kernel.org >> Cc: linux-rt-us...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> > > Thanks for the patch. Some general comments first: > > - fs/locks.c has seen a fair bit of overhaul during the current merge > window, and this patch won't apply directly. I'd suggest cleaning it up > after -rc1 is cut. I just rebased it and splited it a bit up. Couldn't wait... > - the basic idea seems sound, but this is very "fiddly" code. It would > be nice to see if you can break this up into multiple patches. For > instance, maybe convert the lglock to the percpu spinlocks first in a > separate patch, and just keep it protecting the file_lock_list. Once > that's done, start changing other pieces to be protected by the percpu > locks. Small, incremental changes like that are much easier to deal > with if something breaks, since we can at least run a bisect to narrow > down the offending change. They're also easier to review. I complete agree. Sorry to send such a bad initial version. I should have known it better. > - the open-coded seqfile stuff is pretty nasty. When I did the original > change to use lglocks, I ended up adding seq_hlist_*_percpu macros to > support it. Maybe consider doing something like that here too, though > this is a bit more complex obviously since you want to be able to just > hold one spinlock at a time. Ok. > - it would also be good to start thinking about adding lockdep > assertions to this code. I simply didn't realize how wonderful they > were when I did the global spinlock to i_lock conversion a year or two > ago. That can really help catch bugs, and as the (spin)locking gets > more complex in this code, that'd be good to help ensure correctness. I'll give it a try. Many thanks for the quick review. Really appreciated! cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls
On Fri, Feb 20, 2015 at 09:27:51AM +0100, Pavel Machek wrote: > > > > > > > In current state I review all 3 patches as: > > > > > > > > > > > > > > Rejected-by: Pali Rohár > > > > > > > [It breaks booting Nokia N900 device] > > > > > > > > > > > > next step, figure why it's broken. Working just fine here > > > > > > on AM335x which has the same musb IP. > > > > > > > > > > Why is broken? That is easy. You send 3 patches which broke > > > > > it. > > > > > > > > Actually when I reverted only that patch which adds line: > > > > > > > > pm_runtime_irq_safe(musb->controller) > > > > > > > > then early boot crash disappeared. > > > > > > > > But other two patches did not fixed support for external .ko > > > > gadget modules. State is same -- crash after modprobe. > > > > > > Here is crash from qemu when musb is compiled into kernel: > > > > > > [0.641662] Unable to handle kernel NULL pointer dereference at > > > virtual address > > > [0.642211] pgd = c0004000 > ... > > > [0.672882] ---[ end Kernel panic - not syncing: Attempted to kill > > > init! exitcode=0x000b > > > [0.672882] > > > > > > Reason why it crashes is because when function > > > omap2430_runtime_resume() is called pointer to functions > > > musb_readl and musb_writel are both NULL. And so NULL pointer > > > dereference. > > > > https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=1861a2c60351a390272b3395f4d88480cdfd9e58 > > > > So you commit a fix to your internal branch without telling Pali, who > is actively debugging same problem at the same time, and then you just > send him url without at least saying "sorry"? grow up... why do I have to say sorry for fixing a problem ? Why do I have to let you know I committed something to my branch ? It's the middle of the merge window, nothing will happen until -rc1 is out, at which point I'll send this to the mailing list before sending a pull request to Greg. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3] pci: spear: Drop __initdata from spear13xx_pcie_driver
On 02/20/2015 12:13 PM, Matwey V. Kornilov wrote:
> 2015-02-20 13:06 GMT+03:00 Stanimir Varbanov :
>> On 02/19/2015 07:41 PM, Matwey V. Kornilov wrote:
>>> spear13xx_pcie_driver.driver is allocated in text.init section
>>> and then the pointer to it is passed futher. This patch is to avoid
>>> crashes like the following, when freed memory is used.
>>>
>>> Also, __init has been dropped from the probe() function referred from the
>>> struct
>>> and all called functions.
>>>
>>
>>
>>
>>>
>>> Signed-off-by: Matwey V. Kornilov
>>> ---
>>> Changes from v2:
>>> - Drop __init from all probing functions to allow deferred probing.
>>> Changes from v1:
>>> - Use platform_driver_probe instead of platform_driver_register to make
>>> linker happy.
>>>
>>> drivers/pci/host/pcie-designware.c | 2 +-
>>> drivers/pci/host/pcie-spear13xx.c | 6 +++---
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/pci/host/pcie-designware.c
>>> b/drivers/pci/host/pcie-designware.c
>>> index df781cd..5b8a056 100644
>>> --- a/drivers/pci/host/pcie-designware.c
>>> +++ b/drivers/pci/host/pcie-designware.c
>>> @@ -339,7 +339,7 @@ static const struct irq_domain_ops msi_domain_ops = {
>>> .map = dw_pcie_msi_map,
>>> };
>>>
>>> -int __init dw_pcie_host_init(struct pcie_port *pp)
>>> +int dw_pcie_host_init(struct pcie_port *pp)
>>> {
>>
>> we need to fix up the other pci drivers which use dw_pcie_host_init(), too.
>>
>> pci-exynos, pci-imx6, pci-keystone and pci-layerscape.
>>
>> Could you prepare a patch with above drivers included?
>
> What is wrong with them? To call ordinary function from __init section
> is perfectly legal.
I thought in context of probe defer. But this will be subject to another
patch. So ignore my comment.
--
regards,
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] video: fbdev: use msecs_to_jiffies for time conversions
This is only an API consolidation and should make things more readable by
replacing var * HZ / 1000 by msecs_to_jiffies(var).
Signed-off-by: Nicholas Mc Guire
---
v2: fixed missing closing parenthesis in pxafb_disable_controller.
Compile testing was missing part of the patched code due to
the missing CONFIG_FB_PXA_SMARTPANEL=y, so the missing closing
parenthesis reported by Tomi Valkeinen
pxafb_disable_controller went unnoticed.
Patch was only compile tested with viper_defconfig CONFIG_FB_PXA=m,
CONFIG_FB_PXA_SMARTPANEL=y
Patch is against 3.19.0 (localversion-next is -next-20150220)
drivers/video/fbdev/pxafb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index da2431e..d8b4743 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -1285,7 +1285,7 @@ static int pxafb_smart_thread(void *arg)
mutex_unlock(&fbi->ctrlr_lock);
set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(30 * HZ / 1000);
+ schedule_timeout(msecs_to_jiffies(30));
}
pr_debug("%s(): task ending\n", __func__);
@@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct pxafb_info
*fbi)
#ifdef CONFIG_FB_PXA_SMARTPANEL
if (fbi->lccr0 & LCCR0_LCDT) {
wait_for_completion_timeout(&fbi->refresh_done,
- 200 * HZ / 1000);
+ msecs_to_jiffies(200));
return;
}
#endif
@@ -1472,7 +1472,7 @@ static void pxafb_disable_controller(struct pxafb_info
*fbi)
lcd_writel(fbi, LCCR0, lccr0);
lcd_writel(fbi, LCCR0, lccr0 | LCCR0_DIS);
- wait_for_completion_timeout(&fbi->disable_done, 200 * HZ / 1000);
+ wait_for_completion_timeout(&fbi->disable_done, msecs_to_jiffies(200));
/* disable LCD controller clock */
clk_disable_unprepare(fbi->clk);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] of: DT quirks infrastructure
Hi Peter, > On Feb 20, 2015, at 16:21 , Peter Hurley wrote: > > On 02/19/2015 12:38 PM, Pantelis Antoniou wrote: >> >>> On Feb 19, 2015, at 19:30 , Frank Rowand wrote: >>> >>> On 2/19/2015 9:00 AM, Pantelis Antoniou wrote: Hi Frank, > On Feb 19, 2015, at 18:48 , Frank Rowand wrote: > > On 2/19/2015 6:29 AM, Pantelis Antoniou wrote: >> Hi Mark, >> >>> On Feb 18, 2015, at 19:31 , Mark Rutland wrote: >>> >> +While this may in theory work, in practice it is very cumbersome >> +for the following reasons: >> + >> +1. The act of selecting a different boot device tree blob requires >> +a reasonably advanced bootloader with some kind of configuration or >> +scripting capabilities. Sadly this is not the case many times, the >> +bootloader is extremely dumb and can only use a single dt blob. > > You can have several bootloader builds, or even a single build with > something like appended DTB to get an appropriate DTB if the same > binary > will otherwise work across all variants of a board. > No, the same DTB will not work across all the variants of a board. >>> >>> I wasn't on about the DTB. I was on about the loader binary, in the case >>> the FW/bootloader could be common even if the DTB couldn't. >>> >>> To some extent there must be a DTB that will work across all variants >>> (albeit with limited utility) or the quirk approach wouldn't work… >>> >> >> That’s not correct; the only part of the DTB that needs to be common >> is the model property that would allow the quirk detection logic to fire. >> >> So, there is a base DTB that will work on all variants, but that only >> means >> that it will work only up to the point that the quirk detector method >> can work. So while in recommended practice there are common subsets >> of the DTB that might work, they might be unsafe. >> >> For instance on the beaglebone the regulator configuration is different >> between white and black, it is imperative you get them right otherwise >> you risk board damage. >> > So it's not necessarily true that you need a complex bootloader. > >> +2. On many instances boot time is extremely critical; in some cases >> +there are hard requirements like having working video feeds in under >> +2 seconds from power-up. This leaves an extremely small time budget >> for >> +boot-up, as low as 500ms to kernel entry. The sanest way to get >> there >> +is by removing the standard bootloader from the normal boot sequence >> +altogether by having a very small boot shim that loads the kernel >> and >> +immediately jumps to kernel, like falcon-boot mode in u-boot does. > > Given my previous comments above I don't see why this is relevant. > You're already passing _some_ DTB here, so if you can organise for the > board to statically provide a sane DTB that's fine, or you can resort > to > appended DTB if it's not possible to update the board configuration. > You’re missing the point. I can’t use the same DTB for each revision of the board. Each board is similar but it’s not identical. >>> >>> I think you've misunderstood my point. If you program the board with the >>> relevant DTB, or use appended DTB, then you will pass the correct DTB to >>> the kernel without need for quirks. >>> >>> I understand that each variant is somewhat incompatible (and hence needs >>> its own DTB). >> >> In theory it might work, in practice this does not. Ludovic mentioned >> that they >> have 27 different DTBs in use at the moment. At a relatively common 60k >> per DTB >> that’s 27x60k = 1.6MB of DTBs, that need to be installed. > > < snip > > > Or you can install the correct DTB on the board. You trust your > manufacturing line > to install the correct resistors. You trust your manufacturing line to > install the > correct kernel version (eg an updated version to resolve a security > issue). > > I thought the DT blob was supposed to follow the same standard that other > OS's or > bootloaders understood. Are you willing to break that? (This is one of > those > ripples I mentioned in my other emails.) > Trust no-one. This is one of those things that the kernel community doesn’t understand which makes people who push product quite mad. Engineering a product is not only about meeting customer spec, in order to turn a profit the whole endeavor must be engineered as well for manufacturability. Yes, you can always manua
Re: [PATCH 3/6] thinkpad_acpi: Add adaptive_kbd_mode sysfs attr
On Thu, 2015-02-19 at 21:28 -0800, Darren Hart wrote: > On Wed, Feb 18, 2015 at 09:53:44PM +0100, Bastien Nocera wrote: > > Commit message please. Added. > > Signed-off-by: Bastien Nocera > > --- > > drivers/platform/x86/thinkpad_acpi.c | 71 > > +++- > > 1 file changed, 62 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/platform/x86/thinkpad_acpi.c > > b/drivers/platform/x86/thinkpad_acpi.c > > index a6dd017..562d958 100644 > > --- a/drivers/platform/x86/thinkpad_acpi.c > > +++ b/drivers/platform/x86/thinkpad_acpi.c > > ... > > > +static struct device_attribute dev_attr_adaptive_kbd_mode = > > + __ATTR(adaptive_kbd_mode, S_IWUSR | S_IRUGO, > > + adaptive_kbd_mode_show, adaptive_kbd_mode_store); > > + > > Please use DEVICE_ATTR_RW() macros for new sysfs files. Done. > I'd very much like to see a cleanup of the driver to use these as well. > > Henrique, your thoughts / preference? Looks easy enough. I'll post the patch with the new series. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] of: DT quirks infrastructure
On Fri, Feb 20, 2015 at 09:21:38AM -0500, Peter Hurley wrote: > On 02/19/2015 12:38 PM, Pantelis Antoniou wrote: > > > >> On Feb 19, 2015, at 19:30 , Frank Rowand wrote: > >> > >> On 2/19/2015 9:00 AM, Pantelis Antoniou wrote: > >>> Hi Frank, > >>> > On Feb 19, 2015, at 18:48 , Frank Rowand wrote: > > On 2/19/2015 6:29 AM, Pantelis Antoniou wrote: > > Hi Mark, > > > >> On Feb 18, 2015, at 19:31 , Mark Rutland wrote: > >> > > +While this may in theory work, in practice it is very cumbersome > > +for the following reasons: > > + > > +1. The act of selecting a different boot device tree blob requires > > +a reasonably advanced bootloader with some kind of configuration or > > +scripting capabilities. Sadly this is not the case many times, the > > +bootloader is extremely dumb and can only use a single dt blob. > > You can have several bootloader builds, or even a single build with > something like appended DTB to get an appropriate DTB if the same > binary > will otherwise work across all variants of a board. > > >>> > >>> No, the same DTB will not work across all the variants of a board. > >> > >> I wasn't on about the DTB. I was on about the loader binary, in the > >> case > >> the FW/bootloader could be common even if the DTB couldn't. > >> > >> To some extent there must be a DTB that will work across all variants > >> (albeit with limited utility) or the quirk approach wouldn't work… > >> > > > > That’s not correct; the only part of the DTB that needs to be common > > is the model property that would allow the quirk detection logic to > > fire. > > > > So, there is a base DTB that will work on all variants, but that only > > means > > that it will work only up to the point that the quirk detector method > > can work. So while in recommended practice there are common subsets > > of the DTB that might work, they might be unsafe. > > > > For instance on the beaglebone the regulator configuration is different > > between white and black, it is imperative you get them right otherwise > > you risk board damage. > > > So it's not necessarily true that you need a complex bootloader. > > >>> > > +2. On many instances boot time is extremely critical; in some cases > > +there are hard requirements like having working video feeds in > > under > > +2 seconds from power-up. This leaves an extremely small time > > budget for > > +boot-up, as low as 500ms to kernel entry. The sanest way to get > > there > > +is by removing the standard bootloader from the normal boot > > sequence > > +altogether by having a very small boot shim that loads the kernel > > and > > +immediately jumps to kernel, like falcon-boot mode in u-boot does. > > Given my previous comments above I don't see why this is relevant. > You're already passing _some_ DTB here, so if you can organise for > the > board to statically provide a sane DTB that's fine, or you can > resort to > appended DTB if it's not possible to update the board configuration. > > >>> > >>> You’re missing the point. I can’t use the same DTB for each revision > >>> of the > >>> board. Each board is similar but it’s not identical. > >> > >> I think you've misunderstood my point. If you program the board with > >> the > >> relevant DTB, or use appended DTB, then you will pass the correct DTB > >> to > >> the kernel without need for quirks. > >> > >> I understand that each variant is somewhat incompatible (and hence > >> needs > >> its own DTB). > > > > In theory it might work, in practice this does not. Ludovic mentioned > > that they > > have 27 different DTBs in use at the moment. At a relatively common 60k > > per DTB > > that’s 27x60k = 1.6MB of DTBs, that need to be installed. > > < snip > > > Or you can install the correct DTB on the board. You trust your > manufacturing line > to install the correct resistors. You trust your manufacturing line to > install the > correct kernel version (eg an updated version to resolve a security > issue). > > I thought the DT blob was supposed to follow the same standard that > other OS's or > bootloaders understood. Are you willing to break that? (This is one of > those > ripples I mentioned in my other emails.) > > >>> > >>> Trust no-one. > >>> > >>> This is one of those things that the kernel community doesn’t understand > >>> which makes people > >>> who push product quite mad. > >>> > >>> Engineering a product is not only about m
Re: [PATCH RESEND v9 00/10] sched: consolidation of CPU capacity and usage
On Fri, Feb 20, 2015 at 02:13:21PM +, Vincent Guittot wrote: > On 20 February 2015 at 12:52, Morten Rasmussen > wrote: > > On Fri, Feb 20, 2015 at 11:34:47AM +, Peter Zijlstra wrote: > >> On Thu, Feb 19, 2015 at 12:49:40PM +, Morten Rasmussen wrote: > >> > >> > Also, it still not clear why patch 10 uses relative capacity reduction > >> > instead of absolute capacity available to CFS tasks. > >> > >> As present in your asymmetric big and small systems? Yes it would be > >> unfortunate to migrate a task to an idle small core when the big core is > >> still faster, even if reduced by rt/irq work. > > > > Yes, exactly. I don't think it would cause any harm for symmetric cases > > to use absolute capacity instead. Am I missing something? > > If absolute capacity is used, we will trig an active load balance from > little to big core each time a little has got 1 task and a big core is > idle whereas we only want to trig an active migration is the src_cpu's > capacity that is available for the cfs task is significantly reduced > by rt tasks. > > I can mix absolute and relative tests by 1st testing that the capacity > of the src is reduced and then ensure that the dst_cpu has more > absolute capacity than src_cpu If we use absolute capacity and check if the source cpu is fully utilized, wouldn't that work? We want to migrate the task if it is currently being restricted by the available capacity (due to rt/irq work, being a little cpu, or both) and if there is a destination cpu with more absolute capacity available. No? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Hi Boris, On Wed, Feb 11, 2015 at 04:38:23PM +, Boris Brezillon wrote: [...] > For the list of impacted drivers, you can have a look at this series [1] > (patches 2 to 5), and I'll take care of the testing part once every one > has agreed on the solution ;-). > > [1]https://lkml.org/lkml/2014/12/15/552 Looking at those: * The pmc looks like it could be a valid use of the new flag. It also seems to function as an irqchip. Do any of its child IRQs need to be handled during the suspend-resume cycle? If so using IRQF_NO_SUSPEND would seem to be valid. * atmel_serial seems to be intended to be used as a wakeup device (given it calls device_set_wakeup_enable). Therefore it needs to call enable_irq_wake, and when it does so it can share an IRQ with other interrupts, just not IRQF_NO_SUSPEND interrupts. None of the approaches thus far can fix the fundamental mismatch between wakeup interrupts and IRQF_NO_SUSPEND interrupts. * Similarly, rtc-at91rm9200 and rtc-at91sam9 are intended to be used as wakeup devices. They call enable_irq_wake (though don't bother checking the return value). They can share an IRQ with other interrupts, just not IRQF_NO_SUSPEND interrupts. * at91sam9_wdt seems to be fundamentally incompatible with suspend. If the watchdog cannot be disabled, and you need to handle it during suspend, then it needs to be a wakeup interrupt, not an IRQF_NO_SUSPEND interrupt. As far as I can see, the flag or virtual irqchip approaches only help the PMC case, and even then might not be necessary. All the others seem to be relying on guarantees the genirq layer don't provide, and fixing that would mean moving them further from IRQF_NO_SUSPEND. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] of: DT quirks infrastructure
On 02/19/2015 12:38 PM, Pantelis Antoniou wrote: > >> On Feb 19, 2015, at 19:30 , Frank Rowand wrote: >> >> On 2/19/2015 9:00 AM, Pantelis Antoniou wrote: >>> Hi Frank, >>> On Feb 19, 2015, at 18:48 , Frank Rowand wrote: On 2/19/2015 6:29 AM, Pantelis Antoniou wrote: > Hi Mark, > >> On Feb 18, 2015, at 19:31 , Mark Rutland wrote: >> > +While this may in theory work, in practice it is very cumbersome > +for the following reasons: > + > +1. The act of selecting a different boot device tree blob requires > +a reasonably advanced bootloader with some kind of configuration or > +scripting capabilities. Sadly this is not the case many times, the > +bootloader is extremely dumb and can only use a single dt blob. You can have several bootloader builds, or even a single build with something like appended DTB to get an appropriate DTB if the same binary will otherwise work across all variants of a board. >>> >>> No, the same DTB will not work across all the variants of a board. >> >> I wasn't on about the DTB. I was on about the loader binary, in the case >> the FW/bootloader could be common even if the DTB couldn't. >> >> To some extent there must be a DTB that will work across all variants >> (albeit with limited utility) or the quirk approach wouldn't work… >> > > That’s not correct; the only part of the DTB that needs to be common > is the model property that would allow the quirk detection logic to fire. > > So, there is a base DTB that will work on all variants, but that only > means > that it will work only up to the point that the quirk detector method > can work. So while in recommended practice there are common subsets > of the DTB that might work, they might be unsafe. > > For instance on the beaglebone the regulator configuration is different > between white and black, it is imperative you get them right otherwise > you risk board damage. > So it's not necessarily true that you need a complex bootloader. >>> > +2. On many instances boot time is extremely critical; in some cases > +there are hard requirements like having working video feeds in under > +2 seconds from power-up. This leaves an extremely small time budget > for > +boot-up, as low as 500ms to kernel entry. The sanest way to get there > +is by removing the standard bootloader from the normal boot sequence > +altogether by having a very small boot shim that loads the kernel and > +immediately jumps to kernel, like falcon-boot mode in u-boot does. Given my previous comments above I don't see why this is relevant. You're already passing _some_ DTB here, so if you can organise for the board to statically provide a sane DTB that's fine, or you can resort to appended DTB if it's not possible to update the board configuration. >>> >>> You’re missing the point. I can’t use the same DTB for each revision of >>> the >>> board. Each board is similar but it’s not identical. >> >> I think you've misunderstood my point. If you program the board with the >> relevant DTB, or use appended DTB, then you will pass the correct DTB to >> the kernel without need for quirks. >> >> I understand that each variant is somewhat incompatible (and hence needs >> its own DTB). > > In theory it might work, in practice this does not. Ludovic mentioned > that they > have 27 different DTBs in use at the moment. At a relatively common 60k > per DTB > that’s 27x60k = 1.6MB of DTBs, that need to be installed. < snip > Or you can install the correct DTB on the board. You trust your manufacturing line to install the correct resistors. You trust your manufacturing line to install the correct kernel version (eg an updated version to resolve a security issue). I thought the DT blob was supposed to follow the same standard that other OS's or bootloaders understood. Are you willing to break that? (This is one of those ripples I mentioned in my other emails.) >>> >>> Trust no-one. >>> >>> This is one of those things that the kernel community doesn’t understand >>> which makes people >>> who push product quite mad. >>> >>> Engineering a product is not only about meeting customer spec, in order to >>> turn a profit >>> the whole endeavor must be engineered as well for manufacturability. >>> >>> Yes, you can always manually install files in the bootloader. For 1 board >>> no problem. >>> For 10 doable. For 100 I guess you can hire an extra guy. For 1 million? >>> Guess what, >>> instead of turning a profit you’re losing money if you only have a few >>>
Re: [PATCH] video: fbdev: use msecs_to_jiffies for time conversion
On Fri, 20 Feb 2015, Tomi Valkeinen wrote:
> On 20/02/15 16:01, Nicholas Mc Guire wrote:
>
> >>> pr_debug("%s(): task ending\n", __func__);
> >>> @@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct
> >>> pxafb_info *fbi)
> >>> #ifdef CONFIG_FB_PXA_SMARTPANEL
> >>> if (fbi->lccr0 & LCCR0_LCDT) {
> >>> wait_for_completion_timeout(&fbi->refresh_done,
> >>> - 200 * HZ / 1000);
> >>> + msecs_to_jiffies(200);
> >>
> >> That will not compile.
>
> > No compile warning or errors
> >
> > could you send me the compile error message and the toolchain you
> > are using - this change should not really have any noticable impact.
>
> I didn't compile it. It's missing a closing parenthesis.
>
> This is one reason I'm not very fond of cleanups to drivers that the
> patch sender cannot test... They may cause more problems than they help.
>
That was the intent of compile testing the patch but it seems
that it was not covered by the config in use - sorry for that, it was
missing the[*] PXA Smartpanel LCD support so
root@debian:~/linux-next# grep CONFIG_FB_PXA_SMARTPANEL .config
# CONFIG_FB_PXA_SMARTPANEL is not set
The motivation for the cleanup simply was code reasdability - will fix this up
and compile check with a proper config.
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] time, ntp: Do not update time_state in middle of leap second [v3]
On 02/19/2015 12:00 PM, Jiri Bohac wrote:
> Hi,
>
> I'm trying to understand what exactly is going on here...
>
> On Thu, Feb 12, 2015 at 08:58:19AM -0500, Prarit Bhargava wrote:
>> The test did the following in userspace:
>>
>> tx.modes = ADJ_STATUS;
>> tx.status = STA_INS;
>>
>> /* send leap second request */
>> ret = adjtimex(&tx);
>>
>> /* Check adjtimex output every half second */
>> now = tx.time.tv_sec;
>> while (now < next_leap+2) {
>> char buf[26];
>> ret = adjtimex(&tx);
>>
>> ctime_r(&tx.time.tv_sec, buf);
>> buf[strlen(buf)-1] = 0; /*remove trailing\n */
>>
>> printf("%s + %6ld us\t%s\n",
>> buf,
>> tx.time.tv_usec,
>> time_state_str(ret));
>> now = tx.time.tv_sec;
>> /* Sleep for another half second */
>> ts.tv_sec = 0;
>> ts.tv_nsec = NSEC_PER_SEC/2;
>> clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL);
>> }
>>
>> After some investigation it was noted that the test contained a small error:
>> the test does not reinitialize tx.status and reissues the STA_INS every
>> 1/2 second.
>
> Prarit, can you explain who sets the STA_PLL flag, so that
> process_adj_status() detects a STA_PLL->!STA_PLL transition and
> goes to the branch that sets time_state = TIME_OK?
Jiri,
The test being run is:
https://github.com/johnstultz-work/timetests/blob/master/leap-a-day.c
prior to commit
https://github.com/johnstultz-work/timetests/commit/be4526e8b5d48cd108a8d2cf7f5c8fd763acf421
>
> Is that ntpd running in parallel with your test program? If that
No -- ntpd is disabled (chronyd in the case of systemd + current Fedora).
P.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 20.02.15 15:12, Paolo Bonzini wrote: > > > On 20/02/2015 14:45, Alexander Graf wrote: >> >> >> On 18.02.15 10:32, Bogdan Purcareata wrote: >>> This patchset enables running KVM SMP guests with external interrupts on an >>> underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel >>> MPIC >>> emulation could easily panic the kernel due to preemption when delivering >>> IPIs >>> and external interrupts, because of the openpic spinlock becoming a sleeping >>> mutex on PREEMPT_RT_FULL Linux. >>> >>> 0001: converts the openpic spinlock to a raw spinlock, in order to >>> circumvent >>> this behavior. While this change is targeted for a RT enabled Linux, it has >>> no >>> effect on upstream kvm-ppc, so send it upstream for better future >>> maintenance. >>> >>> 0002: introduces a limit on the maximum VCPUs a guest can have, in order to >>> prevent potential DoS attack due to large system latencies. This patch is >>> targeted to RT (due to CONFIG_PREEMPT_RT_FULL), but it can also be applied >>> on >>> upstream Linux, with no effect. Not sure if it's best to send it upstream >>> and >>> have a hanging CONFIG_PREEMPT_RT_FULL check there, with no effect, or send >>> it >>> against linux-stable-rt. Please apply as you consider appropriate. >> >> Thomas, what is the usual approach for patches like this? Do you take >> them into your rt tree or should they get integrated to upstream? > > Patch 1 is definitely suitable for upstream, that's the reason why we > have raw_spin_lock vs. raw_spin_unlock. I see, perfect :). Bogdan, please resend patch 1 with CC to kvm-ppc@vger so that I can pick it up from patchworks. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 20/02/2015 14:45, Alexander Graf wrote: > > > On 18.02.15 10:32, Bogdan Purcareata wrote: >> This patchset enables running KVM SMP guests with external interrupts on an >> underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel >> MPIC >> emulation could easily panic the kernel due to preemption when delivering >> IPIs >> and external interrupts, because of the openpic spinlock becoming a sleeping >> mutex on PREEMPT_RT_FULL Linux. >> >> 0001: converts the openpic spinlock to a raw spinlock, in order to circumvent >> this behavior. While this change is targeted for a RT enabled Linux, it has >> no >> effect on upstream kvm-ppc, so send it upstream for better future >> maintenance. >> >> 0002: introduces a limit on the maximum VCPUs a guest can have, in order to >> prevent potential DoS attack due to large system latencies. This patch is >> targeted to RT (due to CONFIG_PREEMPT_RT_FULL), but it can also be applied on >> upstream Linux, with no effect. Not sure if it's best to send it upstream and >> have a hanging CONFIG_PREEMPT_RT_FULL check there, with no effect, or send it >> against linux-stable-rt. Please apply as you consider appropriate. > > Thomas, what is the usual approach for patches like this? Do you take > them into your rt tree or should they get integrated to upstream? Patch 1 is definitely suitable for upstream, that's the reason why we have raw_spin_lock vs. raw_spin_unlock. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] time, ntp: Do not update time_state in middle of leap second [v3]
On 02/17/2015 06:16 PM, John Stultz wrote: > On Thu, Feb 12, 2015 at 5:58 AM, Prarit Bhargava wrote: >> >> which was intended to mimic the insertion of a leap second. A >> successful run of the test would result in the time_state transitioning >> from TIME_OK to TIME_INS, then to TIME_OOP when the leap second was >> inserted, and then to TIME_WAIT when the leap second was completed. While >> running this code failures were seen in which the time_state remained >> TIME_INS, >> even though the leap second had occurred. >> > > > Ok, thanks for the more verbose explanation. Although this is more a > history of what you've seen rather then the crux of the change. > > To distill this down just a bit, the point is the usual mode for NTP > time_state machine looks like: > > TIME_OK -> TIME_INS -> TIME_OOP > | | > v v > TIME_DEL > TIME_WAIT -(back)-> TIME_OK > > (hopefully the ascii art survives here) > > Now, from any of these states, currently if adjtimex is called w/ the > STA_PLL bit cleared (after STA_PLL was set), we reset back to TIME_OK, > effectively cancelling any transitions. (You'll have to imagine a line > from any of the states back to TIME_OK, since that's going to be too > ugly to do in ascii) > > Your patch is trying to remove the line back from TIME_OOP back to > TIME_OK. Basically stopping the ability to reset the ntp state during > a leapsecond. Correct. > > I do get that the behavior seen was strange due to a bug in the test > code which caused unexpected cancellation of state, but I'm not sure > if we should change the behavior to enforce that cancellation not be > possible. I could imagine some logic which really wants to reset the > state, which just by chance lands during a leap second, and the > application is confused since the state change didn't occur as > expected. I think setting it in the middle of the leap second should be a NOOP. We all know how fragile this code has been in the past and allowing a state transition at that particular time isn't a good idea given the outcome that the state may remain TIME_INS. > > So I guess I'm not seeing that the state machine is actually "broken" > in this case that you've outlined. If you can articulate better why > the OOP -> OK transition is truly invalid, I'd be interested in > hearing, but I'm not sure I want to risk a behavioral change unless > there's wide agreement. I understand -- After thinking about it from your point of view I agree that calling it "broken" is not right. Perhaps a better way of looking at it is, as you also point out, if OOP -> OK is truly valid. P. > > thanks > -john > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v9 00/10] sched: consolidation of CPU capacity and usage
On 20 February 2015 at 12:52, Morten Rasmussen wrote: > On Fri, Feb 20, 2015 at 11:34:47AM +, Peter Zijlstra wrote: >> On Thu, Feb 19, 2015 at 12:49:40PM +, Morten Rasmussen wrote: >> >> > Also, it still not clear why patch 10 uses relative capacity reduction >> > instead of absolute capacity available to CFS tasks. >> >> As present in your asymmetric big and small systems? Yes it would be >> unfortunate to migrate a task to an idle small core when the big core is >> still faster, even if reduced by rt/irq work. > > Yes, exactly. I don't think it would cause any harm for symmetric cases > to use absolute capacity instead. Am I missing something? If absolute capacity is used, we will trig an active load balance from little to big core each time a little has got 1 task and a big core is idle whereas we only want to trig an active migration is the src_cpu's capacity that is available for the cfs task is significantly reduced by rt tasks. I can mix absolute and relative tests by 1st testing that the capacity of the src is reduced and then ensure that the dst_cpu has more absolute capacity than src_cpu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ext4: fix transposition typo in format string
According to C99, %*.s means the same as %*.0s, in other words, print
as many spaces as the field width argument says and effectively ignore
the string argument. That is certainly not what was meant here. The
kernel's printf implementation, however, treats it as if the . was not
there, i.e. as %*s. I don't know if de->name is nul-terminated or not,
but in any case I'm guessing the intention was to use de->name_len as
precision instead of field width.
Signed-off-by: Rasmus Villemoes
---
If de->name is not guaranteed to be nul-terminated, I suppose this is
even -stable material.
fs/ext4/inline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 4b143febf21f..8b64d715e476 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -972,7 +972,7 @@ void ext4_show_inline_dir(struct inode *dir, struct
buffer_head *bh,
offset = 0;
while ((void *)de < dlimit) {
de_len = ext4_rec_len_from_disk(de->rec_len, inline_size);
- trace_printk("de: off %u rlen %u name %*.s nlen %u ino %u\n",
+ trace_printk("de: off %u rlen %u name %.*s nlen %u ino %u\n",
offset, de_len, de->name_len, de->name,
de->name_len, le32_to_cpu(de->inode));
if (ext4_check_dir_entry(dir, NULL, de, bh,
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] kprobes/x86: Check for invalid ftrace location in __recover_probed_insn()
__recover_probed_insn() should always be called from an address where
an instructions starts. The check for ftrace_location() might help to
discover a potential inconsistency.
This patch adds WARN_ON() when the inconsistency is detected. Also
it adds handling of the situation when the original code can not
get recovered.
Suggested-by: Masami Hiramatsu
Signed-off-by: Petr Mladek
---
arch/x86/kernel/kprobes/core.c | 12
arch/x86/kernel/kprobes/opt.c | 2 ++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 70b9b0c12682..a8e8520b953d 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -228,6 +228,13 @@ __recover_probed_insn(kprobe_opcode_t *buf, unsigned long
addr)
kp = get_kprobe((void *)addr);
faddr = ftrace_location(addr);
/*
+* Addresses inside the ftrace location are refused by
+* arch_check_ftrace_location(). Something went terribly wrong
+* if such an address is checked here.
+*/
+ if (WARN_ON(faddr && faddr != addr))
+ return 0UL;
+ /*
* Use the current code if it is not modified by Kprobe
* and it cannot be modified by ftrace.
*/
@@ -265,6 +272,7 @@ __recover_probed_insn(kprobe_opcode_t *buf, unsigned long
addr)
* Recover the probed instruction at addr for further analysis.
* Caller must lock kprobes by kprobe_mutex, or disable preemption
* for preventing to release referencing kprobes.
+ * Returns zero if the instruction can not get recovered.
*/
unsigned long recover_probed_instruction(kprobe_opcode_t *buf, unsigned long
addr)
{
@@ -299,6 +307,8 @@ static int can_probe(unsigned long paddr)
* normally used, we just go through if there is no kprobe.
*/
__addr = recover_probed_instruction(buf, addr);
+ if (!__addr)
+ return 0;
kernel_insn_init(&insn, (void *)__addr, MAX_INSN_SIZE);
insn_get_length(&insn);
@@ -347,6 +357,8 @@ int __copy_instruction(u8 *dest, u8 *src)
unsigned long recovered_insn =
recover_probed_instruction(buf, (unsigned long)src);
+ if (!recovered_insn)
+ return 0;
kernel_insn_init(&insn, (void *)recovered_insn, MAX_INSN_SIZE);
insn_get_length(&insn);
/* Another subsystem puts a breakpoint, failed to recover */
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 0dd8d089c315..7b3b9d15c47a 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -259,6 +259,8 @@ static int can_optimize(unsigned long paddr)
*/
return 0;
recovered_insn = recover_probed_instruction(buf, addr);
+ if (!recovered_insn)
+ return 0;
kernel_insn_init(&insn, (void *)recovered_insn, MAX_INSN_SIZE);
insn_get_length(&insn);
/* Another subsystem puts a breakpoint */
--
1.8.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: use msecs_to_jiffies for time conversion
On 20/02/15 16:01, Nicholas Mc Guire wrote:
>>> pr_debug("%s(): task ending\n", __func__);
>>> @@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct
>>> pxafb_info *fbi)
>>> #ifdef CONFIG_FB_PXA_SMARTPANEL
>>> if (fbi->lccr0 & LCCR0_LCDT) {
>>> wait_for_completion_timeout(&fbi->refresh_done,
>>> - 200 * HZ / 1000);
>>> + msecs_to_jiffies(200);
>>
>> That will not compile.
> No compile warning or errors
>
> could you send me the compile error message and the toolchain you
> are using - this change should not really have any noticable impact.
I didn't compile it. It's missing a closing parenthesis.
This is one reason I'm not very fond of cleanups to drivers that the
patch sender cannot test... They may cause more problems than they help.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH v3 0/2] kprobes/x86: Fix up interaction between kprobes code recovery and ftrace
The code affected by ftrace was not properly recovered in Kprobe checks. Also the address returned by ftrace can be used for a consistency check. This version is based on the feedback for the separate patches, see https://lkml.org/lkml/2015/2/20/91 and https://lkml.org/lkml/2015/2/20/90 Changes against v2: + avoid using MCOUNT_INSN_SIZE that is available only with CONFIG_FUNCTION_TRACER enabled + use WARN_ON() instead of BUG_ON() and correctly handle the situation when Kprobe is not able to recover the code Changes against v1: + always use 5-byte NOP for ftrace location + fix indentation of the touched comment Petr Mladek (2): kprobes/x86: Use 5-byte NOP when the code might be modified by ftrace kprobes/x86: Check for invalid ftrace location in __recover_probed_insn() arch/x86/kernel/kprobes/core.c | 54 +++--- arch/x86/kernel/kprobes/opt.c | 2 ++ 2 files changed, 42 insertions(+), 14 deletions(-) -- 1.8.5.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] kprobes/x86: Use 5-byte NOP when the code might be modified by ftrace
can_probe() checks if the given address points to the beginning of
an instruction. It analyzes all the instructions from the beginning
of the function until the given address. The code might be modified
by another Kprobe. In this case, the current code is read into a buffer,
int3 breakpoint is replaced by the saved opcode in the buffer, and
can_probe() analyzes the buffer instead.
There is a bug that __recover_probed_insn() tries to restore
the original code even for Kprobes using the ftrace framework.
But in this case, the opcode is not stored. See the difference
between arch_prepare_kprobe() and arch_prepare_kprobe_ftrace().
The opcode is stored by arch_copy_kprobe() only from
arch_prepare_kprobe().
This patch makes Kprobe to use the ideal 5-byte NOP when the code
can be modified by ftrace. It is the original instruction, see
ftrace_make_nop() and ftrace_nop_replace().
Note that we always need to use the NOP for ftrace locations. Kprobes
do not block ftrace and the instruction might get modified at anytime.
It might even be in an inconsistent state because it is modified step
by step using the int3 breakpoint.
The patch also fixes indentation of the touched comment.
Note that I found this problem when playing with Kprobes. I did it
on x86_64 with gcc-4.8.3 that supported -mfentry. I modified
samples/kprobes/kprobe_example.c and added offset 5 to put
the probe right after the fentry area:
static struct kprobe kp = {
.symbol_name= "do_fork",
+ .offset = 5,
};
Then I was able to load kprobe_example before jprobe_example
but not the other way around:
$> modprobe jprobe_example
$> modprobe kprobe_example
modprobe: ERROR: could not insert 'kprobe_example': Invalid or incomplete
multibyte or wide character
It did not make much sense and debugging pointed to the bug
described above.
Signed-off-by: Petr Mladek
Acked-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/core.c | 42 --
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 98f654d466e5..70b9b0c12682 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -223,27 +223,41 @@ static unsigned long
__recover_probed_insn(kprobe_opcode_t *buf, unsigned long addr)
{
struct kprobe *kp;
+ unsigned long faddr;
kp = get_kprobe((void *)addr);
- /* There is no probe, return original address */
- if (!kp)
+ faddr = ftrace_location(addr);
+ /*
+* Use the current code if it is not modified by Kprobe
+* and it cannot be modified by ftrace.
+*/
+ if (!kp && !faddr)
return addr;
/*
-* Basically, kp->ainsn.insn has an original instruction.
-* However, RIP-relative instruction can not do single-stepping
-* at different place, __copy_instruction() tweaks the displacement of
-* that instruction. In that case, we can't recover the instruction
-* from the kp->ainsn.insn.
+* Basically, kp->ainsn.insn has an original instruction.
+* However, RIP-relative instruction can not do single-stepping
+* at different place, __copy_instruction() tweaks the displacement of
+* that instruction. In that case, we can't recover the instruction
+* from the kp->ainsn.insn.
*
-* On the other hand, kp->opcode has a copy of the first byte of
-* the probed instruction, which is overwritten by int3. And
-* the instruction at kp->addr is not modified by kprobes except
-* for the first byte, we can recover the original instruction
-* from it and kp->opcode.
+* On the other hand, in case on normal Kprobe, kp->opcode has a copy
+* of the first byte of the probed instruction, which is overwritten
+* by int3. And the instruction at kp->addr is not modified by kprobes
+* except for the first byte, we can recover the original instruction
+* from it and kp->opcode.
+*
+* In case of Kprobes using ftrace, we do not have a copy of
+* the original instruction. In fact, the ftrace location might
+* be modified at anytime and even could be in an inconsistent state.
+* Fortunately, we know that the original code is the ideal 5-byte
+* long NOP.
*/
- memcpy(buf, kp->addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
- buf[0] = kp->opcode;
+ memcpy(buf, (void *)addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
+ if (faddr)
+ memcpy(buf, ideal_nops[NOP_ATOMIC5], 5);
+ else
+ buf[0] = kp->opcode;
return (unsigned long)buf;
}
--
1.8.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Re: [PATCH] clockevents: Add (missing) default case for switch blocks
* Viresh Kumar wrote:
> On 20 February 2015 at 18:52, Ingo Molnar wrote:
> >
> > * Viresh Kumar wrote:
> >> + CLOCK_EVT_DEV_MODE_UNUSED = 0,
> >
> > What is 'unused' - not initialized yet?
>
> Unused. Initially all clockevent devices are supposed to
> be in this mode but later if another device replaces an
> existing one, the existing one is put into this mode.
I'd suggest to rename it to MODE_INIT - at first glance it
gave me the impression that it's some sort of API
placeholder - i.e. an unused flag or so.
Also, I'd suggest to rename all 'modes' to true state
machine naming: STATE_INITIALIZED, STATE_SHUT_DOWN,
STATE_PERIODIC, STATE_RESUMED, etc.: if these are enums for
states and not state transition names, see my later
questions:
> >> + CLOCK_EVT_DEV_MODE_SHUTDOWN,
> >> + CLOCK_EVT_DEV_MODE_PERIODIC,
> >> + CLOCK_EVT_DEV_MODE_ONESHOT,
> >> + CLOCK_EVT_DEV_MODE_RESUME,
> >
> > What is 'resume' mode?
>
> Introduced with: 18de5bc4c1f1 ("clockevents: fix resume
> logic") and is only called during system resume to resume
> the clockevent devices before resuming the tick. Only few
> implementations do meaningful stuff here.
So is it a state that a clockevents device reaches, or a
state transition? The two purposes seem to be mixed up in
the nomenclature.
> >> + CLOCK_EVT_DEV_MODE_ONESHOT_STOPPED, /* This would be the new
> >> mode which I will add later */
> >
> > What does this mode express?
>
> I have added it here to show how things would look like
> eventually, but it wouldn't be present in the patch which
> splits the enum into two parts..
Yeah.
> Its only important for NOHZ_FULL (IDLE ? Maybe). When we
> decide that the tick (LOWRES) or hrtimer interrupt
> (HIGHRES) isn't required for indefinite period of time
> (i.e. no timers/hrtimers are present to serve), we skip
> reprogramming the clockevent device. But its already
> reprogrammed from the tick-handler and so will fire
> atleast once again.
So this new 'mode' appears to be a true state of the
device?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 13/15] cpu-model/s390: Add processor property routines
On 17.02.15 15:24, Michael Mueller wrote: > This patch implements the functions: > > - s390_get_proceccor_props() > - s390_set_proceccor_props() > > They can be used to request or retrieve processor related information from an > accelerator. > That information comprises the cpu identifier, the ICB value and the facility > lists. > > Signed-off-by: Michael Mueller Hrm, I still seem to miss the point of this interface. What do you need it for? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] if_link: Add VF multicast promiscuous control
On 20/02/15 01:00, Hiroshi Shimamoto wrote: > From: Hiroshi Shimamoto > > Add netlink directives and ndo entry to allow VF multicast promiscuous mode. > > The administrator wants to allow dedicatedly multicast promiscuous per VF. If I'm properly understanding, this seems to be an ixgbe-specific option to work around an ixgbe limitation; is it really appropriate to implement as a generic net_device_op? What would this ndo mean to a driver which can support thousands of multicast groups without MC promisc? Is it expected to limit the number of MC groups when this is set to disallow? Or just fulfil the letter of the option but not its spirit? The option doesn't seem to have well-defined semantics outside of ixgbe. I would suggest that the right place for this sort of driver-specific device control is in sysfs. I'm also a little perplexed as to why anyone would need to disallow this; what security, or even administrative convenience, is gained by allowing a VF to join 30 multicast groups but not multicast promiscuous mode? Especially as, afaik, there are no restrictions on which multicast groups are joined, so the VF can receive any particular multicast traffic it cares about. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: use msecs_to_jiffies for time conversion
On Fri, 20 Feb 2015, Tomi Valkeinen wrote:
> On 06/02/15 11:14, Nicholas Mc Guire wrote:
> > This is only an API consolidation and should make things more readable
> > it replaces var * HZ / 1000 by msecs_to_jiffies(var).
> >
> > Signed-off-by: Nicholas Mc Guire
> > ---
> >
> > Patch was only compile tested with viper_defconfig (implies CONFIG_FB_PXA=m)
> >
> > Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
> >
> > drivers/video/fbdev/pxafb.c |6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> > index da2431e..d8b4743 100644
> > --- a/drivers/video/fbdev/pxafb.c
> > +++ b/drivers/video/fbdev/pxafb.c
> > @@ -1285,7 +1285,7 @@ static int pxafb_smart_thread(void *arg)
> > mutex_unlock(&fbi->ctrlr_lock);
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> > - schedule_timeout(30 * HZ / 1000);
> > + schedule_timeout(msecs_to_jiffies(30));
> > }
> >
> > pr_debug("%s(): task ending\n", __func__);
> > @@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct
> > pxafb_info *fbi)
> > #ifdef CONFIG_FB_PXA_SMARTPANEL
> > if (fbi->lccr0 & LCCR0_LCDT) {
> > wait_for_completion_timeout(&fbi->refresh_done,
> > - 200 * HZ / 1000);
> > + msecs_to_jiffies(200);
>
> That will not compile.
>
Just reran it on linux-next 3.19.0 -next-20150220
for viper_defconfig using gcc version 4.9.2 20140904 (prerelease)
(crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09)
root@debian:~/linux-next# patch -p1 <
0001-video-fbdev-use-msecs_to_jiffies-for-time-convrsion.patch
patching file drivers/video/fbdev/pxafb.c
root@debian:~/linux-next# make viper_defconfig ARCH=arm
#
# configuration written to .config
#
root@debian:~/linux-next# LANG=en_US make modules ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf-
...
CC [M] drivers/video/console/softcursor.o
CC [M] drivers/video/fbdev/pxafb.o
CC [M] drivers/video/fbdev/core/cfbfillrect.o
CC [M] drivers/video/fbdev/core/cfbcopyarea.o
CC [M] drivers/video/fbdev/core/cfbimgblt.o
CC [M] sound/sound_core.o
LD [M] sound/soundcore.o
...
CC drivers/video/console/softcursor.mod.o
LDFINAL [M] drivers/video/console/softcursor.ko
CC drivers/video/fbdev/core/cfbcopyarea.mod.o
LDFINAL [M] drivers/video/fbdev/core/cfbcopyarea.ko
CC drivers/video/fbdev/core/cfbfillrect.mod.o
LDFINAL [M] drivers/video/fbdev/core/cfbfillrect.ko
CC drivers/video/fbdev/core/cfbimgblt.mod.o
LDFINAL [M] drivers/video/fbdev/core/cfbimgblt.ko
CC drivers/video/fbdev/pxafb.mod.o
LDFINAL [M] drivers/video/fbdev/pxafb.ko
CC fs/configfs/configfs.mod.o
LDFINAL [M] fs/configfs/configfs.ko
...
No compile warning or errors
could you send me the compile error message and the toolchain you
are using - this change should not really have any noticable impact.
Is this a toolchain issue ?
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC GIT PULL] x86 platform support for Intel Quark SoC systems for v3.20
Linus, If it's not too late for a v3.20 merge yet I'd like you to pull this tree that adds support for Intel Quark X1000 SoC boards, used in the low power 32-bit x86 Intel Galileo microcontroller board intended for the Arduino space: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-platform-for-linus # HEAD: c11a25f443e9bee06fe302b6a78ff44dac554036 x86/intel/quark: Fix simple_return.cocci warnings There's been some preparatory core x86 patches for Quark CPU quirks merged already, but this rounds it all up and adds Kconfig enablement. It's a clean hardware enablement addition tree at this point. out-of-topic modifications in x86-platform-for-linus: --- drivers/platform/x86/Kconfig # 28a375df16c2: x86/intel/quark: Add Isolate Thanks, Ingo --> Bryan O'Donoghue (2): x86/intel/quark: Add Isolated Memory Regions for Quark X1000 x86/intel/quark: Add Intel Quark platform support Fengguang Wu (2): x86/intel/quark: Fix ptr_ret.cocci warnings x86/intel/quark: Fix simple_return.cocci warnings arch/x86/Kconfig | 16 + arch/x86/Kconfig.debug | 13 + arch/x86/include/asm/imr.h | 60 +++ arch/x86/platform/Makefile | 1 + arch/x86/platform/intel-quark/Makefile | 2 + arch/x86/platform/intel-quark/imr.c | 661 +++ arch/x86/platform/intel-quark/imr_selftest.c | 129 ++ drivers/platform/x86/Kconfig | 25 + 8 files changed, 907 insertions(+) create mode 100644 arch/x86/include/asm/imr.h create mode 100644 arch/x86/platform/intel-quark/Makefile create mode 100644 arch/x86/platform/intel-quark/imr.c create mode 100644 arch/x86/platform/intel-quark/imr_selftest.c diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5e28e2be3a41..1f97c7f0d049 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -486,6 +486,22 @@ config X86_INTEL_MID Intel MID platforms are based on an Intel processor and chipset which consume less power than most of the x86 derivatives. +config X86_INTEL_QUARK + bool "Intel Quark platform support" + depends on X86_32 + depends on X86_EXTENDED_PLATFORM + depends on X86_PLATFORM_DEVICES + depends on X86_TSC + depends on PCI + depends on PCI_GOANY + depends on X86_IO_APIC + select IOSF_MBI + select INTEL_IMR + ---help--- + Select to include support for Quark X1000 SoC. + Say Y here if you have a Quark based system such as the Arduino + compatible Intel Galileo. + config X86_INTEL_LPSS bool "Intel Low Power Subsystem Support" depends on ACPI diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index 61bd2ad94281..20028da8ae18 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -313,6 +313,19 @@ config DEBUG_NMI_SELFTEST If unsure, say N. +config DEBUG_IMR_SELFTEST + bool "Isolated Memory Region self test" + default n + depends on INTEL_IMR + ---help--- + This option enables automated sanity testing of the IMR code. + Some simple tests are run to verify IMR bounds checking, alignment + and overlapping. This option is really only useful if you are + debugging an IMR memory map or are modifying the IMR code and want to + test your changes. + + If unsure say N here. + config X86_DEBUG_STATIC_CPU_HAS bool "Debug alternatives" depends on DEBUG_KERNEL diff --git a/arch/x86/include/asm/imr.h b/arch/x86/include/asm/imr.h new file mode 100644 index ..cd2ce4068441 --- /dev/null +++ b/arch/x86/include/asm/imr.h @@ -0,0 +1,60 @@ +/* + * imr.h: Isolated Memory Region API + * + * Copyright(c) 2013 Intel Corporation. + * Copyright(c) 2015 Bryan O'Donoghue + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; version 2 + * of the License. + */ +#ifndef _IMR_H +#define _IMR_H + +#include + +/* + * IMR agent access mask bits + * See section 12.7.4.7 from quark-x1000-datasheet.pdf for register + * definitions. + */ +#define IMR_ESRAM_FLUSHBIT(31) +#define IMR_CPU_SNOOP BIT(30) /* Applicable only to write */ +#define IMR_RMUBIT(29) +#define IMR_VC1_SAI_ID3BIT(15) +#define IMR_VC1_SAI_ID2BIT(14) +#define IMR_VC1_SAI_ID1BIT(13) +#define IMR_VC1_SAI_ID0BIT(12) +#define IMR_VC0_SAI_ID3BIT(11) +#define IMR_VC0_SAI_ID2BIT(10) +#define IMR_VC0_SAI_ID1BIT(9) +#define IMR_VC0_SAI_ID0BIT(8) +#define IMR_CPU_0 BIT(1) /* SMM mode */ +#define IMR
Re: [RFC PATCH v2 09/15] cpu-model/s390: Add KVM VM attribute interface routines
On 17.02.15 15:24, Michael Mueller wrote:
> The patch implements routines to set and retrieve processor configuration
> data and to retrieve machine configuration data. The machine related data
> is used together with the cpu model facility lists to determine the list of
> supported cpu models of this host. The above mentioned routines have QEMU
> trace point instrumentation.
>
> Signed-off-by: Michael Mueller
> ---
> target-s390x/cpu-models.h | 39 ++
> target-s390x/kvm.c| 102
> ++
> trace-events | 3 ++
> 3 files changed, 144 insertions(+)
>
> diff --git a/target-s390x/cpu-models.h b/target-s390x/cpu-models.h
> index 623a7b2..76b3456 100644
> --- a/target-s390x/cpu-models.h
> +++ b/target-s390x/cpu-models.h
> @@ -45,6 +45,45 @@ typedef struct S390CPUAlias {
> char *model;
> } S390CPUAlias;
>
> +typedef struct S390ProcessorProps {
> +uint64_t cpuid;
> +uint16_t ibc;
> +uint8_t pad[6];
> +uint64_t fac_list[S390_ARCH_FAC_LIST_SIZE_UINT64];
> +} S390ProcessorProps;
> +
> +typedef struct S390MachineProps {
> +uint64_t cpuid;
> +uint32_t ibc_range;
> +uint8_t pad[4];
> +uint64_t fac_list_mask[S390_ARCH_FAC_LIST_SIZE_UINT64];
> +uint64_t fac_list[S390_ARCH_FAC_LIST_SIZE_UINT64];
> +} S390MachineProps;
What are those structs there for? To convert between a kvm facing
interface to an internal interface?
I don't think they're necessary. The internal layout is visible from the
KVM code. Just either spawn the class straight from the kvm file or if
you consider that ugly, pass the values of that struct that you need as
function parameters to a function in cpu-models.c.
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clockevents: Add (missing) default case for switch blocks
On 20 February 2015 at 18:52, Ingo Molnar wrote:
>
> * Viresh Kumar wrote:
>> + CLOCK_EVT_DEV_MODE_UNUSED = 0,
>
> What is 'unused' - not initialized yet?
Unused. Initially all clockevent devices are supposed to be in this
mode but later if another device replaces an existing one, the existing
one is put into this mode.
>> + CLOCK_EVT_DEV_MODE_SHUTDOWN,
>> + CLOCK_EVT_DEV_MODE_PERIODIC,
>> + CLOCK_EVT_DEV_MODE_ONESHOT,
>> + CLOCK_EVT_DEV_MODE_RESUME,
>
> What is 'resume' mode?
Introduced with: 18de5bc4c1f1 ("clockevents: fix resume logic") and is only
called during system resume to resume the clockevent devices before resuming
the tick. Only few implementations do meaningful stuff here.
>> + CLOCK_EVT_DEV_MODE_ONESHOT_STOPPED, /* This would be the new
>> mode which I will add later */
>
> What does this mode express?
I have added it here to show how things would look like eventually,
but it wouldn't
be present in the patch which splits the enum into two parts..
Its only important for NOHZ_FULL (IDLE ? Maybe). When we decide that the tick
(LOWRES) or hrtimer interrupt (HIGHRES) isn't required for indefinite
period of time
(i.e. no timers/hrtimers are present to serve), we skip reprogramming
the clockevent
device. But its already reprogrammed from the tick-handler and so will
fire atleast
once again.
The case is worst for implementations where the underlying hardware doesn't have
support for ONESHOT mode. And so they emulate ONESHOT over PERIODIC.
And in those cases, these spurious interrupts come at a rate last programmed for
the clockevent device. And that is mostly tick-rate..
> So for state machines it's important to document the states
> and the transitions between them very clearly - please
> start with that.
Sure.
> Also, this should not be in a generic header, it should be
> somewhere internal in kernel/time/.
Right. But there are some excellent drivers which are comparing things against
dev->mode (i.e. enum clock_event_dev_mode now..). I need to fix them as well
first to push this into some internal header.
>> Ofcourse, we also need to replace 'clock_event_mode' with
>> 'clock_event_dev_mode' and 'CLOCK_EVT_MODE_*' with
>> 'CLOCK_EVT_DEV_MODE_*' in all core code..
>
> Yes.
Thanks for your suggestions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 2/2] arm: socfpga: Set share override bit of the l2 cache controller
On Fri, Feb 20, 2015 at 07:53:50AM -0600, Rob Herring wrote: > On Fri, Feb 20, 2015 at 1:15 AM, Dinh Nguyen wrote: > > Can I ask what is your reasoning for doing this in the bootloader? It's > > seems like this is such a nice mechanism to do it here. > > Primarily, this register is secure only and we try to avoid secure > mode setup in the kernel. > > Russell also has had a patch to do this generically in his patch queue > forever. If we want this in the kernel, then we should apply that. I discarded it. In general, we want boot loaders or firmware to configure the basic properties of the caches, rather than having the kernel do it for exactly the reasons you say above. Yes, there are some cache features which can only be enabled in combination with CPU features, and those the kernel _has_ to know about, but the basic setup should be done outside the kernel. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH 2/2] arm: socfpga: Set share override bit of the l2 cache controller
On Fri, Feb 20, 2015 at 1:15 AM, Dinh Nguyen wrote: > Hi Rob, > > On 2/19/15 12:13 PM, Rob Herring wrote: >> On Thu, Feb 19, 2015 at 11:06 AM, wrote: >>> From: Dinh Nguyen >>> >>> By not having bit 22 set in the PL310 Auxiliary Control register (shared >>> attribute override enable) has the side effect of transforming Normal >>> Shared Non-cacheable reads into Cacheable no-allocate reads. >>> >>> Coherent DMA buffers in Linux always have a Cacheable alias via the >>> kernel linear mapping and the processor can speculatively load cache >>> lines into the PL310 controller. With bit 22 cleared, Non-cacheable >>> reads would unexpectedly hit such cache lines leading to buffer >>> corruption. >> >> You really should be doing this in your bootloader. >> > > Can I ask what is your reasoning for doing this in the bootloader? It's > seems like this is such a nice mechanism to do it here. Primarily, this register is secure only and we try to avoid secure mode setup in the kernel. Russell also has had a patch to do this generically in his patch queue forever. If we want this in the kernel, then we should apply that. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models
On 17.02.15 15:24, Michael Mueller wrote:
> This patch implements the static part of the s390 cpu class definitions.
> It defines s390 cpu models by means of virtual cpu ids (enum) which contain
> information on the cpu generation, the machine class, the GA number and
> the machine type. The cpu id is used to instantiate a cpu class per cpu
> model.
>
> In addition the patch introduces the QMP enumeration AccelId. It is used
> to index certain cpu model poperties per accelerator.
>
> Furthermore it extends the existing S390CPUClass by model related properties.
>
> Signed-off-by: Michael Mueller
> Reviewed-by: Thomas Huth
> ---
> qapi-schema.json | 11 +++
> target-s390x/Makefile.objs | 1 +
> target-s390x/cpu-models.c | 79
> ++
> target-s390x/cpu-models.h | 71 +
> target-s390x/cpu-qom.h | 22 +
> target-s390x/cpu.c | 2 ++
> 6 files changed, 186 insertions(+)
> create mode 100644 target-s390x/cpu-models.c
> create mode 100644 target-s390x/cpu-models.h
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index e16f8eb..4d237c8 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2473,6 +2473,17 @@
> ##
> { 'command': 'query-machines', 'returns': ['MachineInfo'] }
>
> +
> +##
> +# @AccelId
> +#
> +# Defines accelerator ids
> +#
> +# Since: 2.3.0
> +##
> +{ 'enum': 'AccelId',
> + 'data': ['qtest', 'tcg', 'kvm', 'xen' ] }
> +
> ##
> # @CpuDefinitionInfo:
> #
> diff --git a/target-s390x/Makefile.objs b/target-s390x/Makefile.objs
> index 2c57494..9f55140 100644
> --- a/target-s390x/Makefile.objs
> +++ b/target-s390x/Makefile.objs
> @@ -1,5 +1,6 @@
> obj-y += translate.o helper.o cpu.o interrupt.o
> obj-y += int_helper.o fpu_helper.o cc_helper.o mem_helper.o misc_helper.o
> obj-y += gdbstub.o
> +obj-y += cpu-models.o
> obj-$(CONFIG_SOFTMMU) += machine.o ioinst.o arch_dump.o
> obj-$(CONFIG_KVM) += kvm.o
> diff --git a/target-s390x/cpu-models.c b/target-s390x/cpu-models.c
> new file mode 100644
> index 000..4841553
> --- /dev/null
> +++ b/target-s390x/cpu-models.c
> @@ -0,0 +1,79 @@
> +/*
> + * CPU models for s390
> + *
> + * Copyright 2014,2015 IBM Corp.
> + *
> + * Author(s): Michael Mueller
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or (at
> + * your option) any later version. See the COPYING file in the top-level
> + * directory.
> + */
> +
> +#include "qemu-common.h"
> +#include "cpu-models.h"
> +
> +#define S390_PROC_DEF(_name, _cpu_id, _desc)\
> +static void \
> +glue(_cpu_id, _cpu_class_init) \
> +(ObjectClass *oc, void *data) \
> +{ \
> +DeviceClass *dc = DEVICE_CLASS(oc); \
> +S390CPUClass *cc = S390_CPU_CLASS(oc); \
> +\
> +cc->is_active[ACCEL_ID_KVM] = true; \
> +cc->mach= g_malloc0(sizeof(S390CPUMachineProps)); \
> +cc->mach->ga= cpu_ga(_cpu_id); \
> +cc->mach->class = cpu_class(_cpu_id); \
> +cc->mach->order = cpu_order(_cpu_id); \
> +cc->proc= g_malloc0(sizeof(S390CPUProcessorProps)); \
> +cc->proc->gen = cpu_generation(_cpu_id); \
> +cc->proc->ver = S390_DEF_VERSION; \
> +cc->proc->id= S390_DEF_ID; \
> +cc->proc->type = cpu_type(_cpu_id);\
> +cc->proc->ibc = S390_DEF_IBC; \
> +dc->desc= _desc;\
> +} \
> +static const TypeInfo \
> +glue(_cpu_id, _cpu_type_info) = { \
> +.name = _name "-" TYPE_S390_CPU, \
> +.parent = TYPE_S390_CPU,\
> +.class_init = glue(_cpu_id, _cpu_class_init), \
> +}; \
> +static void \
> +glue(_cpu_id, _cpu_register_types)(void)\
> +{ \
> +type_register_static( \
> +&glue(_cpu_id, _cpu_type_info));
Re: [PATCH 2/6] thinkpad_acpi: Factor out get/set adaptive kbd mode
On Thu, 2015-02-19 at 21:22 -0800, Darren Hart wrote:
> On Wed, Feb 18, 2015 at 09:53:35PM +0100, Bastien Nocera wrote:
>
> Please provide a commit message. There is always something to say beyond what
> is
> in the subject. In this case, I suggest the motivation and justification for
> the
> change.
>
> While I appreciate the abstraction, it makes the code at the call site easier
> to
> read, note that you added more code than you removed.
>
> So, please provide a justificaiton.
Sure, done.
> Under no circumstances will I accept a patch without a commit message body.
>
> > Signed-off-by: Bastien Nocera
> > ---
> > drivers/platform/x86/thinkpad_acpi.c | 61
> > ++--
> > 1 file changed, 38 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/platform/x86/thinkpad_acpi.c
> > b/drivers/platform/x86/thinkpad_acpi.c
> > index 80db3ce..a6dd017 100644
> > --- a/drivers/platform/x86/thinkpad_acpi.c
> > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > @@ -3480,6 +3480,32 @@ const int adaptive_keyboard_modes[] = {
> > static bool adaptive_keyboard_mode_is_saved;
> > static int adaptive_keyboard_prev_mode;
> >
> > +static int adaptive_keyboard_get_mode(void)
> > +{
> > + u32 mode = 0;
>
> acpi_evalf second argument takes an "int" and this function returns "int". Is
> there a reason to use u32 for mode?
Used int, done.
> > @@ -3509,39 +3535,28 @@ static bool
> > adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
> > new_mode = adaptive_keyboard_prev_mode;
> > adaptive_keyboard_mode_is_saved = false;
> > } else {
> > - if (!acpi_evalf(
> > - hkey_handle, ¤t_mode,
> > - "GTRW", "dd", 0)) {
> > - pr_err("Cannot read adaptive keyboard mode\n");
> > + current_mode = adaptive_keyboard_get_mode();
> > + if (current_mode < 0)
> > return false;
> > - } else {
> > - new_mode = adaptive_keyboard_get_next_mode(
> > - current_mode);
> > - }
> > + new_mode = adaptive_keyboard_get_next_mode(
> > + current_mode);
>
> This now fits on one line I believe.
Nope, 81 characters. I've kept it as-is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 04/15] cpu-model/s390: Introduce S390 CPU models
On 17.02.15 15:24, Michael Mueller wrote:
> This patch implements the static part of the s390 cpu class definitions.
> It defines s390 cpu models by means of virtual cpu ids (enum) which contain
> information on the cpu generation, the machine class, the GA number and
> the machine type. The cpu id is used to instantiate a cpu class per cpu
> model.
>
> In addition the patch introduces the QMP enumeration AccelId. It is used
> to index certain cpu model poperties per accelerator.
>
> Furthermore it extends the existing S390CPUClass by model related properties.
>
> Signed-off-by: Michael Mueller
> Reviewed-by: Thomas Huth
> ---
> qapi-schema.json | 11 +++
> target-s390x/Makefile.objs | 1 +
> target-s390x/cpu-models.c | 79
> ++
> target-s390x/cpu-models.h | 71 +
> target-s390x/cpu-qom.h | 22 +
> target-s390x/cpu.c | 2 ++
> 6 files changed, 186 insertions(+)
> create mode 100644 target-s390x/cpu-models.c
> create mode 100644 target-s390x/cpu-models.h
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index e16f8eb..4d237c8 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2473,6 +2473,17 @@
> ##
> { 'command': 'query-machines', 'returns': ['MachineInfo'] }
>
> +
> +##
> +# @AccelId
> +#
> +# Defines accelerator ids
> +#
> +# Since: 2.3.0
> +##
> +{ 'enum': 'AccelId',
> + 'data': ['qtest', 'tcg', 'kvm', 'xen' ] }
> +
> ##
> # @CpuDefinitionInfo:
> #
> diff --git a/target-s390x/Makefile.objs b/target-s390x/Makefile.objs
> index 2c57494..9f55140 100644
> --- a/target-s390x/Makefile.objs
> +++ b/target-s390x/Makefile.objs
> @@ -1,5 +1,6 @@
> obj-y += translate.o helper.o cpu.o interrupt.o
> obj-y += int_helper.o fpu_helper.o cc_helper.o mem_helper.o misc_helper.o
> obj-y += gdbstub.o
> +obj-y += cpu-models.o
> obj-$(CONFIG_SOFTMMU) += machine.o ioinst.o arch_dump.o
> obj-$(CONFIG_KVM) += kvm.o
> diff --git a/target-s390x/cpu-models.c b/target-s390x/cpu-models.c
> new file mode 100644
> index 000..4841553
> --- /dev/null
> +++ b/target-s390x/cpu-models.c
> @@ -0,0 +1,79 @@
> +/*
> + * CPU models for s390
> + *
> + * Copyright 2014,2015 IBM Corp.
> + *
> + * Author(s): Michael Mueller
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or (at
> + * your option) any later version. See the COPYING file in the top-level
> + * directory.
> + */
> +
> +#include "qemu-common.h"
> +#include "cpu-models.h"
> +
> +#define S390_PROC_DEF(_name, _cpu_id, _desc)\
> +static void \
> +glue(_cpu_id, _cpu_class_init) \
> +(ObjectClass *oc, void *data) \
> +{ \
> +DeviceClass *dc = DEVICE_CLASS(oc); \
> +S390CPUClass *cc = S390_CPU_CLASS(oc); \
> +\
> +cc->is_active[ACCEL_ID_KVM] = true; \
> +cc->mach= g_malloc0(sizeof(S390CPUMachineProps)); \
> +cc->mach->ga= cpu_ga(_cpu_id); \
> +cc->mach->class = cpu_class(_cpu_id); \
> +cc->mach->order = cpu_order(_cpu_id); \
> +cc->proc= g_malloc0(sizeof(S390CPUProcessorProps)); \
> +cc->proc->gen = cpu_generation(_cpu_id); \
> +cc->proc->ver = S390_DEF_VERSION; \
> +cc->proc->id= S390_DEF_ID; \
> +cc->proc->type = cpu_type(_cpu_id);\
> +cc->proc->ibc = S390_DEF_IBC; \
> +dc->desc= _desc;\
> +} \
> +static const TypeInfo \
> +glue(_cpu_id, _cpu_type_info) = { \
> +.name = _name "-" TYPE_S390_CPU, \
> +.parent = TYPE_S390_CPU,\
> +.class_init = glue(_cpu_id, _cpu_class_init), \
> +}; \
> +static void \
> +glue(_cpu_id, _cpu_register_types)(void)\
> +{ \
> +type_register_static( \
> +&glue(_cpu_id, _cpu_type_info));
Re: [PATCH RESEND v9 10/10] sched: move cfs task on a CPU with higher capacity
On 20 February 2015 at 12:27, Peter Zijlstra wrote:
> On Thu, Jan 15, 2015 at 11:09:30AM +0100, Vincent Guittot wrote:
>> As a sidenote, this will note generate more spurious ilb because we already
>
> s/note/not/
>
>> trig an ilb if there is more than 1 busy cpu. If this cpu is the only one
>> that
>> has a task, we will trig the ilb once for migrating the task.
>
>> +static inline bool nohz_kick_needed(struct rq *rq)
>> {
>> unsigned long now = jiffies;
>> struct sched_domain *sd;
>> struct sched_group_capacity *sgc;
>> int nr_busy, cpu = rq->cpu;
>> + bool kick = false;
>>
>> if (unlikely(rq->idle_balance))
>> + return false;
>>
>> /*
>> * We may be recently in ticked or tickless idle mode. At the first
>> @@ -7472,38 +7498,44 @@ static inline int nohz_kick_needed(struct rq *rq)
>>* balancing.
>>*/
>> if (likely(!atomic_read(&nohz.nr_cpus)))
>> + return false;
>>
>> if (time_before(now, nohz.next_balance))
>> + return false;
>>
>> if (rq->nr_running >= 2)
>> + return true;
>
> So this,
>
>> rcu_read_lock();
>> sd = rcu_dereference(per_cpu(sd_busy, cpu));
>> if (sd) {
>> sgc = sd->groups->sgc;
>> nr_busy = atomic_read(&sgc->nr_busy_cpus);
>>
>> + if (nr_busy > 1) {
>> + kick = true;
>> + goto unlock;
>> + }
>> +
>> }
>>
>> + sd = rcu_dereference(rq->sd);
>> + if (sd) {
>> + if ((rq->cfs.h_nr_running >= 1) &&
>> + check_cpu_capacity(rq, sd)) {
>> + kick = true;
>> + goto unlock;
>> + }
>> + }
>
> vs this: how would we ever get here?
>
> If h_nr_running > 1, must then not nr_running > 1 as well?
you're right,
but the test above can trig a kick with h_nr_running == 1 whereas the
other tests may not
>
>>
>> + sd = rcu_dereference(per_cpu(sd_asym, cpu));
>> if (sd && (cpumask_first_and(nohz.idle_cpus_mask,
>> sched_domain_span(sd)) < cpu))
>> + kick = true;
>
> For consistencies sake I would've added a goto unlock here as well.
i can add the goto
>
>> +unlock:
>> rcu_read_unlock();
>> + return kick;
>> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] nilfs2: fix potential memory overrun on inode
Each inode of nilfs2 stores a root node of a b-tree, and it turned out
to have a memory overrun issue:
Each b-tree node of nilfs2 stores a set of key-value pairs and the
number of them (in "bn_nchildren" member of nilfs_btree_node struct),
as well as a few other "bn_*" members.
Since the value of "bn_nchildren" is used for operations on the
key-values within the b-tree node, it can cause memory access overrun
if a large number is incorrectly set to "bn_nchildren".
For instance, nilfs_btree_node_lookup() function determines the range
of binary search with it, and too large "bn_nchildren" leads
nilfs_btree_node_get_key() in that function to overrun.
As for intermediate b-tree nodes, this is prevented by a sanity check
performed when each node is read from a drive, however, no sanity
check has been done for root nodes stored in inodes.
This patch fixes the issue by adding missing sanity check against
b-tree root nodes so that it's called when on-memory inodes are read
from ifile, inode metadata file.
Signed-off-by: Ryusuke Konishi
---
fs/nilfs2/btree.c | 47 ---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/fs/nilfs2/btree.c b/fs/nilfs2/btree.c
index b2e3ff3..c645d7c 100644
--- a/fs/nilfs2/btree.c
+++ b/fs/nilfs2/btree.c
@@ -31,6 +31,8 @@
#include "alloc.h"
#include "dat.h"
+static void __nilfs_btree_init(struct nilfs_bmap *bmap);
+
static struct nilfs_btree_path *nilfs_btree_alloc_path(void)
{
struct nilfs_btree_path *path;
@@ -368,6 +370,34 @@ static int nilfs_btree_node_broken(const struct
nilfs_btree_node *node,
return ret;
}
+/**
+ * nilfs_btree_root_broken - verify consistency of btree root node
+ * @node: btree root node to be examined
+ * @ino: inode number
+ *
+ * Return Value: If node is broken, 1 is returned. Otherwise, 0 is returned.
+ */
+static int nilfs_btree_root_broken(const struct nilfs_btree_node *node,
+ ino_t ino)
+{
+ int level, flags, nchildren;
+ int ret = 0;
+
+ level = nilfs_btree_node_get_level(node);
+ flags = nilfs_btree_node_get_flags(node);
+ nchildren = nilfs_btree_node_get_nchildren(node);
+
+ if (unlikely(level < NILFS_BTREE_LEVEL_NODE_MIN ||
+level > NILFS_BTREE_LEVEL_MAX ||
+nchildren < 0 ||
+nchildren > NILFS_BTREE_ROOT_NCHILDREN_MAX)) {
+ pr_crit("NILFS: bad btree root (inode number=%lu): level = %d,
flags = 0x%x, nchildren = %d\n",
+ ino, level, flags, nchildren);
+ ret = 1;
+ }
+ return ret;
+}
+
int nilfs_btree_broken_node_block(struct buffer_head *bh)
{
int ret;
@@ -1713,7 +1743,7 @@ nilfs_btree_commit_convert_and_insert(struct nilfs_bmap
*btree,
/* convert and insert */
dat = NILFS_BMAP_USE_VBN(btree) ? nilfs_bmap_get_dat(btree) : NULL;
- nilfs_btree_init(btree);
+ __nilfs_btree_init(btree);
if (nreq != NULL) {
nilfs_bmap_commit_alloc_ptr(btree, dreq, dat);
nilfs_bmap_commit_alloc_ptr(btree, nreq, dat);
@@ -2294,12 +2324,23 @@ static const struct nilfs_bmap_operations
nilfs_btree_ops_gc = {
.bop_gather_data= NULL,
};
-int nilfs_btree_init(struct nilfs_bmap *bmap)
+static void __nilfs_btree_init(struct nilfs_bmap *bmap)
{
bmap->b_ops = &nilfs_btree_ops;
bmap->b_nchildren_per_block =
NILFS_BTREE_NODE_NCHILDREN_MAX(nilfs_btree_node_size(bmap));
- return 0;
+}
+
+int nilfs_btree_init(struct nilfs_bmap *bmap)
+{
+ int ret = 0;
+
+ __nilfs_btree_init(bmap);
+
+ if (nilfs_btree_root_broken(nilfs_btree_get_root(bmap),
+ bmap->b_inode->i_ino))
+ ret = -EIO;
+ return ret;
}
void nilfs_btree_init_gc(struct nilfs_bmap *bmap)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] nilfs2: fix potential memory overrun on inode
Hi Andrew, please queue the following patch as a bug fix. It fixes a memory overrun issue recently I found in the b-tree implementation of nilfs2. Thanks, Ryusuke Konishi -- Ryusuke Konishi (1): nilfs2: fix potential memory overrun on inode fs/nilfs2/btree.c | 47 --- 1 file changed, 44 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] thinkpad_acpi: Remember adaptive kbd presence
On Thu, 2015-02-19 at 21:08 -0800, Darren Hart wrote:
> On Wed, Feb 18, 2015 at 09:53:28PM +0100, Bastien Nocera wrote:
> > Rather than checking on each suspend and resume whether the laptop
> > has an adaptive keyboard, check when the driver is initialised.
>
> Reasonable.
>
> >
> > Signed-off-by: Bastien Nocera
> > ---
> > drivers/platform/x86/thinkpad_acpi.c | 38
> > ++--
> > 1 file changed, 19 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/platform/x86/thinkpad_acpi.c
> > b/drivers/platform/x86/thinkpad_acpi.c
> > index c3d11fa..80db3ce 100644
> > --- a/drivers/platform/x86/thinkpad_acpi.c
> > +++ b/drivers/platform/x86/thinkpad_acpi.c
> ...
> > @@ -3226,6 +3227,13 @@ static int __init hotkey_init(struct ibm_init_struct
> > *iibm)
> > if (!tp_features.hotkey)
> > return 1;
> >
> > + /* does it have an adaptive keyboard, like
> > +* the Lenovo Carbon X1 2014 (2nd gen) */
>
> Please follow CodingStyle here:
>
> /*
> * Sentence formatting.
> * Second line.
> */
>
> The above is a question, just state what you're doing:
>
> /*
> * Check if we have an adaptive keyboard, like on the
> * Lenovo Carbon X1 2014 (2nd Gen).
> */
Done.
> > + if (acpi_evalf(hkey_handle, &hkeyv, "MHKV", "qd")) {
> > + if ((hkeyv >> 8) == 2)
> > + tp_features.has_adaptive_kbd = true;
> > + }
> > +
> > quirks = tpacpi_check_quirks(tpacpi_hotkey_qtable,
> > ARRAY_SIZE(tpacpi_hotkey_qtable));
> >
> > @@ -3834,28 +3842,22 @@ static void hotkey_notify(struct ibm_struct *ibm,
> > u32 event)
> >
> > static void hotkey_suspend(void)
> > {
> > - int hkeyv;
> > -
> > /* Do these on suspend, we get the events on early resume! */
> > hotkey_wakeup_reason = TP_ACPI_WAKEUP_NONE;
> > hotkey_autosleep_ack = 0;
> >
> > /* save previous mode of adaptive keyboard of X1 Carbon */
> > - if (acpi_evalf(hkey_handle, &hkeyv, "MHKV", "qd")) {
> > - if ((hkeyv >> 8) == 2) {
> > - if (!acpi_evalf(hkey_handle,
> > - &adaptive_keyboard_prev_mode,
> > - "GTRW", "dd", 0)) {
> > - pr_err("Cannot read adaptive keyboard mode.\n");
> > - }
> > + if (tp_features.has_adaptive_kbd) {
> > + if (!acpi_evalf(hkey_handle,
> > + &adaptive_keyboard_prev_mode,
> > + "GTRW", "dd", 0)) {
> > + pr_err("Cannot read adaptive keyboard mode.\n");
> > }
> > }
> > }
> >
> > static void hotkey_resume(void)
> > {
> > - int hkeyv;
> > -
> > tpacpi_disable_brightness_delay();
> >
> > if (hotkey_status_set(true) < 0 ||
> > @@ -3870,14 +3872,12 @@ static void hotkey_resume(void)
> > hotkey_poll_setup_safe(false);
> >
> > /* restore previous mode of adapive keyboard of X1 Carbon */
> > - if (acpi_evalf(hkey_handle, &hkeyv, "MHKV", "qd")) {
> > - if ((hkeyv >> 8) == 2) {
> > - if (!acpi_evalf(hkey_handle,
> > - NULL,
> > - "STRW", "vd",
> > - adaptive_keyboard_prev_mode)) {
> > - pr_err("Cannot set adaptive keyboard mode.\n");
> > - }
> > + if (tp_features.has_adaptive_kbd) {
> > + if (!acpi_evalf(hkey_handle,
> > + NULL,
> > + "STRW", "vd",
> > + adaptive_keyboard_prev_mode)) {
>
> You've saved a level of indentation, please group the arguments into fewer
> lines, should be two instead of four.
>
> Otherwise, looks good.
Done.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH V2 1/3] xen: mark pvscsi frontend request consumed only after last read
On 17/02/15 07:02, Juergen Gross wrote: > A request in the ring buffer mustn't be read after it has been marked > as consumed. Otherwise it might already have been reused by the > frontend without violating the ring protocol. > > To avoid inconsistencies in the backend only work on a private copy > of the request. This will ensure a malicious guest not being able to > bypass consistency checks of the backend by modifying an active > request. Applied to stable/for-linus-3.20 and tagged for stable, thanks. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X.509: Fix certificate gathering again
On 2015-02-19 13:26, David Howells wrote: > Michal Marek wrote: > >> +X509_CERTIFICATES-y := $(wildcard *.x509) >> +ifneq ($(objtree),$(srctree)) >> +X509_CERTIFICATES-y += $(wildcard $(srctree)/*.x509) >> +endif >> +X509_CERTIFICATES-$(CONFIG_MODULE_SIG) += signing_key.x509 >> +X509_CERTIFICATES := $(sort $(X509_CERTIFICATES-y)) > > What will happen if there's a "signing_key.x509" in the source tree when O= is > used? It will fail. So the patch needs more work, thanks for the review. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] x86 fixes
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: 570e1aa84c376ff39809442f09c7606ddf62cfd1 x86/mm/ASLR: Avoid
PAGE_SIZE redefinition for UML subarch
This tree contains:
- EFI fixes
- a boot printout fix
- ASLR/kASLR fixes
- intel microcode driver fixes
- other misc fixes
Most of the linecount comes from an EFI revert.
out-of-topic modifications in x86-urgent-for-linus:
-
drivers/firmware/efi/libstub/efi-stub-helper.c# 43a9f69692b2: Revert
"efi/libstub: Call ge
fs/binfmt_elf.c# 4e7c22d447bb: x86, mm/ASLR: Fix stack
rand
Thanks,
Ingo
-->
Alexander Kuleshov (1):
Documentation/x86: Fix path in zero-page.txt
Dave Hansen (1):
x86/mm/init: Fix incorrect page size in init_memory_mapping() printks
Hector Marco-Gisbert (1):
x86, mm/ASLR: Fix stack randomization on 64-bit systems
Jiri Kosina (2):
x86/mm/ASLR: Propagate base load address calculation
x86/mm/ASLR: Avoid PAGE_SIZE redefinition for UML subarch
Matt Fleming (2):
x86/efi: Avoid triple faults during EFI mixed mode calls
Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes"
Quentin Casasnovas (2):
x86/microcode/intel: Guard against stack overflow in the loader
x86/microcode/intel: Handle truncated microcode images more robustly
Ricardo Ribalda Delgado (1):
x86/apic: Fix the devicetree build in certain configs
Documentation/x86/zero-page.txt| 2 +-
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/boot/compressed/aslr.c| 34 -
arch/x86/boot/compressed/efi_stub_64.S | 25
arch/x86/boot/compressed/efi_thunk_64.S| 196 +
arch/x86/boot/compressed/misc.c| 3 +-
arch/x86/boot/compressed/misc.h| 6 +-
arch/x86/include/asm/apic.h| 8 +
arch/x86/include/asm/page_types.h | 2 +
arch/x86/include/uapi/asm/bootparam.h | 1 +
arch/x86/kernel/cpu/microcode/intel.c | 5 +
arch/x86/kernel/cpu/microcode/intel_early.c| 6 +-
arch/x86/kernel/module.c | 10 +-
arch/x86/kernel/setup.c| 22 ++-
arch/x86/mm/init.c | 28 +++-
arch/x86/mm/mmap.c | 6 +-
arch/x86/platform/efi/efi_stub_64.S| 161
arch/x86/platform/efi/efi_thunk_64.S | 121 ---
drivers/firmware/efi/libstub/efi-stub-helper.c | 16 +-
fs/binfmt_elf.c| 5 +-
20 files changed, 419 insertions(+), 239 deletions(-)
create mode 100644 arch/x86/boot/compressed/efi_thunk_64.S
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index 199f453cb4de..82fbdbc1e0b0 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -3,7 +3,7 @@ protocol of kernel. These should be filled by bootloader or
16-bit
real-mode setup code of the kernel. References/settings to it mainly
are in:
- arch/x86/include/asm/bootparam.h
+ arch/x86/include/uapi/asm/bootparam.h
Offset Proto NameMeaning
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index ad754b4411f7..8bd44e8ee6e2 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -49,6 +49,7 @@ $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
vmlinux-objs-$(CONFIG_EFI_STUB) += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o \
$(objtree)/drivers/firmware/efi/libstub/lib.a
+vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
$(obj)/vmlinux: $(vmlinux-objs-y) FORCE
$(call if_changed,ld)
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index bb1376381985..7083c16cccba 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -14,6 +14,13 @@
static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+struct kaslr_setup_data {
+ __u64 next;
+ __u32 type;
+ __u32 len;
+ __u8 data[1];
+} kaslr_setup_data;
+
#define I8254_PORT_CONTROL 0x43
#define I8254_PORT_COUNTER00x40
#define I8254_CMD_READBACK 0xC0
@@ -295,7 +302,29 @@ static unsigned long find_random_addr(unsigned long
minimum,
return slots_fetch_random();
}
-unsigned char *choose_kernel_location(unsigned char *input,
+static void add_kaslr_setup_data(struct boot_params *params, __u8 enabled)
+{
+ struct setup_data *data;
+
+ kaslr_setup_data.type = SETUP_KASLR;
+ kaslr_setup_data.len = 1;
+ kaslr_setup_data.next = 0;
+ kaslr_setup_data.data[0
[PATCH] rtc: mc13xxx: fix obfuscated and wrong format string
According to C99, %2.s means 'print two spaces' (a precision of . without following digits or * means 0). The kernel's printf implementation, however, treats that case as if no precision was given, but relying on that quirk is rather silly. Also, since no - (aka left-justify) flag is given, the field with of 2 would then cause the alarm->enabled case to come out as "o n". Deobfuscate it. Signed-off-by: Rasmus Villemoes --- drivers/rtc/rtc-mc13xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-mc13xxx.c b/drivers/rtc/rtc-mc13xxx.c index 5bce904b7ee6..c8e78a560de7 100644 --- a/drivers/rtc/rtc-mc13xxx.c +++ b/drivers/rtc/rtc-mc13xxx.c @@ -219,7 +219,7 @@ static int mc13xxx_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm) if (unlikely(ret)) goto out; - dev_dbg(dev, "%s: o%2.s %lu\n", __func__, alarm->enabled ? "n" : "ff", + dev_dbg(dev, "%s: %s %lu\n", __func__, alarm->enabled ? "on" : "off", s1970); ret = mc13xxx_rtc_irq_enable_unlocked(dev, alarm->enabled, -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 18.02.15 10:32, Bogdan Purcareata wrote: > This patchset enables running KVM SMP guests with external interrupts on an > underlying RT-enabled Linux. Previous to this patch, a guest with in-kernel > MPIC > emulation could easily panic the kernel due to preemption when delivering IPIs > and external interrupts, because of the openpic spinlock becoming a sleeping > mutex on PREEMPT_RT_FULL Linux. > > 0001: converts the openpic spinlock to a raw spinlock, in order to circumvent > this behavior. While this change is targeted for a RT enabled Linux, it has no > effect on upstream kvm-ppc, so send it upstream for better future maintenance. > > 0002: introduces a limit on the maximum VCPUs a guest can have, in order to > prevent potential DoS attack due to large system latencies. This patch is > targeted to RT (due to CONFIG_PREEMPT_RT_FULL), but it can also be applied on > upstream Linux, with no effect. Not sure if it's best to send it upstream and > have a hanging CONFIG_PREEMPT_RT_FULL check there, with no effect, or send it > against linux-stable-rt. Please apply as you consider appropriate. Thomas, what is the usual approach for patches like this? Do you take them into your rt tree or should they get integrated to upstream? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux
On 18.02.15 10:32, Bogdan Purcareata wrote: > Due to the introduction of the raw_spinlock for the KVM openpic, guests with a > high number of VCPUs may induce great latencies on the underlying RT Linux > system (e.g. cyclictest reports latencies of ~15ms for guests with 24 VCPUs). > This can be further aggravated by sending a lot of external interrupts to the > guest. > > A malicious app can abuse this scenario, causing a DoS of the host Linux. > Until the KVM openpic code is refactored to use finer lock granularity, impose > a limitation on the number of VCPUs a guest can have when running on a > PREEMPT_RT_FULL system with KVM_MPIC emulation. > > Signed-off-by: Mihai Caraman > Signed-off-by: Bogdan Purcareata > Reviewed-by: Scott Wood I don't think this patch is reasonable to take upstream. If we have a latency issue, whoever spawned KVM VMs made a decision to spawn such big VMs. I'd say let's leave it at MAX_VCPUS == NR_CPUS for now and rather get someone to resolve any locking problems for real ;). Alex > --- > arch/powerpc/include/asm/kvm_host.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/powerpc/include/asm/kvm_host.h > b/arch/powerpc/include/asm/kvm_host.h > index 8ef0512..6f6b928 100644 > --- a/arch/powerpc/include/asm/kvm_host.h > +++ b/arch/powerpc/include/asm/kvm_host.h > @@ -36,8 +36,14 @@ > #include > #include > > +#if defined(CONFIG_PREEMPT_RT_FULL) && defined(CONFIG_KVM_MPIC) > +/* Limit the number of vcpus due to in-kernel mpic concurrency */ > +#define KVM_MAX_VCPUS4 > +#define KVM_MAX_VCORES 4 > +#else > #define KVM_MAX_VCPUSNR_CPUS > #define KVM_MAX_VCORES NR_CPUS > +#endif > #define KVM_USER_MEM_SLOTS 32 > #define KVM_MEM_SLOTS_NUM KVM_USER_MEM_SLOTS > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] ARM: DTS: omap3: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap3.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7bd55..f4f78c40b564 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -155,8 +155,8 @@
<14>,
<15>;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <96>;
+ dma-channels = <32>;
+ dma-requests = <96>;
};
omap3_pmx_core: pinmux@48002030 {
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] ARM: DTS: OMAP/DRA7: dma property name correction
Hi, While working on the DMA crossbar support for DRA7 typo of devices I have noticed that the dma-channels and dma-requests properties of sdma wrongly has # at the beginning. According to the documentation, it should not have: Documentation/devicetree/bindings/dma/dma.txt Since these properties are not in use at the moment, but it is going to be needed for the crossbar driver it is better to fix it right now so we do not need to patch .dtsi and .c files at the same time later. Tony: I would really appreciate if this could go in within the current merge window. Thanks, Peter Peter Ujfalusi (5): ARM: DTS: omap2: Correct the dma controller's property names ARM: DTS: omap3: Correct the dma controller's property names ARM: DTS: omap4: Correct the dma controller's property names ARM: DTS: omap5: Correct the dma controller's property names ARM: DTS: dra7: Correct the dma controller's property names arch/arm/boot/dts/dra7.dtsi | 4 ++-- arch/arm/boot/dts/omap2.dtsi | 4 ++-- arch/arm/boot/dts/omap3.dtsi | 4 ++-- arch/arm/boot/dts/omap4.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] time/ntp fix
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: 29183a70b0b828500816bd794b3fe192fce89f73 ntp: Fixup adjtimex freq
validation on 32-bit systems
An adjtimex interface regression fix for 32-bit systems.
Thanks,
Ingo
-->
John Stultz (1):
ntp: Fixup adjtimex freq validation on 32-bit systems
kernel/time/ntp.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 4b585e0fdd22..0f60b08a4f07 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -633,10 +633,14 @@ int ntp_validate_timex(struct timex *txc)
if ((txc->modes & ADJ_SETOFFSET) && (!capable(CAP_SYS_TIME)))
return -EPERM;
- if (txc->modes & ADJ_FREQUENCY) {
- if (LONG_MIN / PPM_SCALE > txc->freq)
+ /*
+* Check for potential multiplication overflows that can
+* only happen on 64-bit systems:
+*/
+ if ((txc->modes & ADJ_FREQUENCY) && (BITS_PER_LONG == 64)) {
+ if (LLONG_MIN / PPM_SCALE > txc->freq)
return -EINVAL;
- if (LONG_MAX / PPM_SCALE < txc->freq)
+ if (LLONG_MAX / PPM_SCALE < txc->freq)
return -EINVAL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] ARM: DTS: omap2: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 59d1c297bb30..578fa2a54dce 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -87,8 +87,8 @@
<14>,
<15>;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <64>;
+ dma-channels = <32>;
+ dma-requests = <64>;
};
i2c1: i2c@4807 {
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] ARM: DTS: omap5: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b321fdf42c9f..eb6653cbe3f8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -238,8 +238,8 @@
,
;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <127>;
+ dma-channels = <32>;
+ dma-requests = <127>;
};
gpio1: gpio@4ae1 {
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] scheduler fixes
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 2636ed5f8d15ff9395731593537b4b3fdf2af24d sched/rt: Avoid obvious
configuration fail
This tree contains misc fixes: preempt_schedule_common()
and io_schedule() recursion fixes, sched/dl fixes, a
completion_done() revert, two sched/rt fixes and a comment
update patch.
Thanks,
Ingo
-->
Frederic Weisbecker (1):
sched: Fix preempt_schedule_common() triggering tracing recursion
Kirill Tkhai (2):
sched/dl: Prevent enqueue of a sleeping task in dl_task_timer()
sched/dl: Do update_rq_clock() in yield_task_dl()
NeilBrown (1):
sched: Prevent recursion in io_schedule()
Oleg Nesterov (1):
sched/completion: Serialize completion_done() with complete()
Peter Zijlstra (4):
sched: Clarify ordering between task_rq_lock() and move_queued_task()
sched: Make dl_task_time() use task_rq_lock()
sched/autogroup: Fix failure to set cpu.rt_runtime_us
sched/rt: Avoid obvious configuration fail
include/linux/sched.h | 10 ++--
kernel/sched/auto_group.c | 6 +--
kernel/sched/completion.c | 19 +++-
kernel/sched/core.c | 113 --
kernel/sched/deadline.c | 33 ++
kernel/sched/sched.h | 76 +++
6 files changed, 155 insertions(+), 102 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8db31ef98d2f..cb5cdc777c8a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -363,9 +363,6 @@ extern void show_regs(struct pt_regs *);
*/
extern void show_stack(struct task_struct *task, unsigned long *sp);
-void io_schedule(void);
-long io_schedule_timeout(long timeout);
-
extern void cpu_init (void);
extern void trap_init(void);
extern void update_process_times(int user);
@@ -422,6 +419,13 @@ extern signed long schedule_timeout_uninterruptible(signed
long timeout);
asmlinkage void schedule(void);
extern void schedule_preempt_disabled(void);
+extern long io_schedule_timeout(long timeout);
+
+static inline void io_schedule(void)
+{
+ io_schedule_timeout(MAX_SCHEDULE_TIMEOUT);
+}
+
struct nsproxy;
struct user_namespace;
diff --git a/kernel/sched/auto_group.c b/kernel/sched/auto_group.c
index 8a2e230fb86a..eae160dd669d 100644
--- a/kernel/sched/auto_group.c
+++ b/kernel/sched/auto_group.c
@@ -87,8 +87,7 @@ static inline struct autogroup *autogroup_create(void)
* so we don't have to move tasks around upon policy change,
* or flail around trying to allocate bandwidth on the fly.
* A bandwidth exception in __sched_setscheduler() allows
-* the policy change to proceed. Thereafter, task_group()
-* returns &root_task_group, so zero bandwidth is required.
+* the policy change to proceed.
*/
free_rt_sched_group(tg);
tg->rt_se = root_task_group.rt_se;
@@ -115,9 +114,6 @@ bool task_wants_autogroup(struct task_struct *p, struct
task_group *tg)
if (tg != &root_task_group)
return false;
- if (p->sched_class != &fair_sched_class)
- return false;
-
/*
* We can only assume the task group can't go away on us if
* autogroup_move_group() can see us on ->thread_group list.
diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index 7052d3fd4e7b..8d0f35debf35 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -274,7 +274,7 @@ bool try_wait_for_completion(struct completion *x)
* first without taking the lock so we can
* return early in the blocking case.
*/
- if (!ACCESS_ONCE(x->done))
+ if (!READ_ONCE(x->done))
return 0;
spin_lock_irqsave(&x->wait.lock, flags);
@@ -297,6 +297,21 @@ EXPORT_SYMBOL(try_wait_for_completion);
*/
bool completion_done(struct completion *x)
{
- return !!ACCESS_ONCE(x->done);
+ if (!READ_ONCE(x->done))
+ return false;
+
+ /*
+* If ->done, we need to wait for complete() to release ->wait.lock
+* otherwise we can end up freeing the completion before complete()
+* is done referencing it.
+*
+* The RMB pairs with complete()'s RELEASE of ->wait.lock and orders
+* the loads of ->done and ->wait.lock such that we cannot observe
+* the lock before complete() acquires it while observing the ->done
+* after it's acquired the lock.
+*/
+ smp_rmb();
+ spin_unlock_wait(&x->wait.lock);
+ return true;
}
EXPORT_SYMBOL(completion_done);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1f37fe7f77a4..a4869bd426ca 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -307,66 +307,6 @@ __read_mostly int scheduler_running;
int sysctl_sched_rt_runtime = 95000
[PATCH 3/5] ARM: DTS: omap4: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 074147cebae4..87401d9f4d8b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -223,8 +223,8 @@
,
;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <127>;
+ dma-channels = <32>;
+ dma-requests = <127>;
};
gpio1: gpio@4a31 {
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] ARM: DTS: dra7: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fedafd43..aefa4192533a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -249,8 +249,8 @@
,
;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <127>;
+ dma-channels = <32>;
+ dma-requests = <127>;
};
gpio1: gpio@4ae1 {
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
