Re: [PATCH perf/core v13 06/15] perf buildid-cache: Scan and import user SDT events to probe cache

Em Fri, Jul 01, 2016 at 05:04:10PM +0900, Masami Hiramatsu escreveu: > From: Masami Hiramatsu > > perf buildid-cache --add scans given binary and add > the SDT events to probe cache. "sdt_" prefix is appended for > all SDT providers to avoid event-name clash

Re: [PATCH perf/core v13 06/15] perf buildid-cache: Scan and import user SDT events to probe cache

Em Fri, Jul 01, 2016 at 05:04:10PM +0900, Masami Hiramatsu escreveu: > From: Masami Hiramatsu > > perf buildid-cache --add scans given binary and add > the SDT events to probe cache. "sdt_" prefix is appended for > all SDT providers to avoid event-name clash with other pre-defined > events. It

Re: Portable Device Tree Connector -- conceptual

On 07/01/16 09:56, Pantelis Antoniou wrote: > Hi Frank, > >> On Jul 1, 2016, at 19:31 , Frank Rowand wrote: >> >> On 07/01/16 03:59, Pantelis Antoniou wrote: >>> Hi Frank, >>> >>> Comments inline. >>> On Jul 1, 2016, at 03:02 , Frank Rowand

Re: Portable Device Tree Connector -- conceptual

On 07/01/16 09:56, Pantelis Antoniou wrote: > Hi Frank, > >> On Jul 1, 2016, at 19:31 , Frank Rowand wrote: >> >> On 07/01/16 03:59, Pantelis Antoniou wrote: >>> Hi Frank, >>> >>> Comments inline. >>> On Jul 1, 2016, at 03:02 , Frank Rowand wrote: Hi All, I've been

Re: [PATCH] doc: flat-table directive

Em Fri, 01 Jul 2016 20:24:48 +0300 Jani Nikula escreveu: > On Fri, 01 Jul 2016, Markus Heiser wrote: > > Am 01.07.2016 um 14:58 schrieb Jonathan Corbet : > > > >> On Fri, 01 Jul 2016 13:44:17 +0300 > >> Jani Nikula

Re: [PATCH] doc: flat-table directive

Em Fri, 01 Jul 2016 20:24:48 +0300 Jani Nikula escreveu: > On Fri, 01 Jul 2016, Markus Heiser wrote: > > Am 01.07.2016 um 14:58 schrieb Jonathan Corbet : > > > >> On Fri, 01 Jul 2016 13:44:17 +0300 > >> Jani Nikula wrote: > >> > >>> This is also one of the reasons why I so much want to

Re: strange Mac OSX RST behavior

> yes, we do in fact see a POLLRDHUP from the FIN in this case and > read of zero, but we still have more data to write to the socket, and > b/c the RST is dropped here, the socket stays in TIME_WAIT until > things eventually time out... After the FIN when you send/retransmit your next segment do

Re: strange Mac OSX RST behavior

> yes, we do in fact see a POLLRDHUP from the FIN in this case and > read of zero, but we still have more data to write to the socket, and > b/c the RST is dropped here, the socket stays in TIME_WAIT until > things eventually time out... After the FIN when you send/retransmit your next segment do

Re: [PATCH v1 10/11] KVM: x86: add KVM_CAP_X2APIC_API

On Thu, Jun 30, 2016 at 1:54 PM, Radim Krčmář wrote: > KVM_CAP_X2APIC_API can be enabled to extend APIC ID in get/set ioctl and MSI > addresses to 32 bits. Both are needed to support x2APIC. > > The capability has to be toggleable and disabled by default, because get/set >

Re: [PATCH v1 10/11] KVM: x86: add KVM_CAP_X2APIC_API

On Thu, Jun 30, 2016 at 1:54 PM, Radim Krčmář wrote: > KVM_CAP_X2APIC_API can be enabled to extend APIC ID in get/set ioctl and MSI > addresses to 32 bits. Both are needed to support x2APIC. > > The capability has to be toggleable and disabled by default, because get/set > ioctl shifted and

RE: [PATCH] cacheinfo: Introduce cache id

> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 10:28 AM > To: Luck, Tony > Cc: Yu, Fenghua ; Thomas Gleixner > ; Ingo Molnar ; Anvin, H Peter > ; Peter Zijlstra

RE: [PATCH] cacheinfo: Introduce cache id

> From: Borislav Petkov [mailto:b...@suse.de] > Sent: Friday, July 01, 2016 10:28 AM > To: Luck, Tony > Cc: Yu, Fenghua ; Thomas Gleixner > ; Ingo Molnar ; Anvin, H Peter > ; Peter Zijlstra ; > Stephane Eranian ; Shankar, Ravi V > ; Vikas Shivappa > ; linux-kernel ker...@vger.kernel.org>; x86 >

Re: [PATCH] cacheinfo: Introduce cache id

> Basically all cache indices carry the APIC ID of the core, so L1D on > CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same > ID. > > How does that look on a CAT system? Do all the different cache levels > get different IDs? For CAT we only need the IDs to be unique at each

Re: [PATCH v3 2/4] drm/rockchip: add an common abstracted PSR driver

On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang wrote: > The PSR driver have exported four symbols for specific device driver: > - rockchip_drm_psr_register() > - rockchip_drm_psr_unregister() > - rockchip_drm_psr_enable() > - rockchip_drm_psr_disable() > -

Re: [PATCH] cacheinfo: Introduce cache id

> Basically all cache indices carry the APIC ID of the core, so L1D on > CPU0 has ID 0 and then L1I has ID 0 too and then L2 has also the same > ID. > > How does that look on a CAT system? Do all the different cache levels > get different IDs? For CAT we only need the IDs to be unique at each

Re: [PATCH v3 2/4] drm/rockchip: add an common abstracted PSR driver

On Fri, Jul 1, 2016 at 5:19 AM, Yakir Yang wrote: > The PSR driver have exported four symbols for specific device driver: > - rockchip_drm_psr_register() > - rockchip_drm_psr_unregister() > - rockchip_drm_psr_enable() > - rockchip_drm_psr_disable() > - rockchip_drm_psr_flush() > > Encoder driver

Re: [PATCH v3] kasan/quarantine: fix bugs on qlist_move_cache()

On 07/01/2016 05:15 PM, Dmitry Vyukov wrote: > On Fri, Jul 1, 2016 at 4:09 PM, Joonsoo Kim wrote: >> 2016-07-01 23:03 GMT+09:00 Dmitry Vyukov : + + if (obj_cache == cache) + qlist_put(to, qlink,

Re: [PATCH v3] kasan/quarantine: fix bugs on qlist_move_cache()

On 07/01/2016 05:15 PM, Dmitry Vyukov wrote: > On Fri, Jul 1, 2016 at 4:09 PM, Joonsoo Kim wrote: >> 2016-07-01 23:03 GMT+09:00 Dmitry Vyukov : + + if (obj_cache == cache) + qlist_put(to, qlink, cache->size); + else +

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

Am Donnerstag, 30 Juni 2016, 17:43:57 schrieb Dave Young: > On 06/30/16 at 01:42pm, Thiago Jung Bauermann wrote: > > Am Donnerstag, 30 Juni 2016, 12:49:44 schrieb Thiago Jung Bauermann: > > > To be honest I think struct kexec_buf is an implementation detail > > > inside > > >

Re: [PATCH v3 2/9] kexec_file: Generalize kexec_add_buffer.

Am Donnerstag, 30 Juni 2016, 17:43:57 schrieb Dave Young: > On 06/30/16 at 01:42pm, Thiago Jung Bauermann wrote: > > Am Donnerstag, 30 Juni 2016, 12:49:44 schrieb Thiago Jung Bauermann: > > > To be honest I think struct kexec_buf is an implementation detail > > > inside > > >

[PATCH] Fix race condition in enc28j60 driver

From: Sergio Valverde The interrupt worker code for the enc28j60 relies only on the TXIF flag to determinate if the packet transmission was completed. However the datasheet specifies in section 12.1.3 that TXERIF will clear the TXRTS after a transmit abort. Also in

[PATCH] Fix race condition in enc28j60 driver

From: Sergio Valverde The interrupt worker code for the enc28j60 relies only on the TXIF flag to determinate if the packet transmission was completed. However the datasheet specifies in section 12.1.3 that TXERIF will clear the TXRTS after a transmit abort. Also in section 12.1.4 that TXIF will

[PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum

This is very lightly tested. I haven't even run it on the affected hardware. Just sending it quickly in case someone can easily see something fatally wrong with it. This seems a lot less fragile than the previous patches that relied on TLB flushing. Those seemed like it would be easy to add

[PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none()

The erratum we are fixing here can lead to stray setting of the A and D bits. That means that a pte that we cleared might suddenly have A/D set. So, stop considering those bits when determining if a pte is pte_none(). The same goes for the other pmd_none() and pud_none(). pgd_none() can be

[PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum

This is very lightly tested. I haven't even run it on the affected hardware. Just sending it quickly in case someone can easily see something fatally wrong with it. This seems a lot less fragile than the previous patches that relied on TLB flushing. Those seemed like it would be easy to add

[PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none()

The erratum we are fixing here can lead to stray setting of the A and D bits. That means that a pte that we cleared might suddenly have A/D set. So, stop considering those bits when determining if a pte is pte_none(). The same goes for the other pmd_none() and pud_none(). pgd_none() can be

[PATCH 3/4] x86: disallow running with 32-bit PTEs to work around erratum

The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights Landing) has an erratum where a processor thread setting the Accessed or Dirty bits may not do so atomically against its checks for the Present bit. This may cause a thread (which is about to page fault) to set A and/or D, even

[PATCH 1/4] x86, swap: move swap offset/type up in PTE to work around erratum

This erratum can result in Accessed/Dirty getting set by the hardware when we do not expect them to be (on !Present PTEs). Instead of trying to fix them up after this happens, we just allow the bits to get set and try to ignore them. We do this by shifting the layout of the bits we use for swap

[PATCH 3/4] x86: disallow running with 32-bit PTEs to work around erratum

The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights Landing) has an erratum where a processor thread setting the Accessed or Dirty bits may not do so atomically against its checks for the Present bit. This may cause a thread (which is about to page fault) to set A and/or D, even

[PATCH 1/4] x86, swap: move swap offset/type up in PTE to work around erratum

This erratum can result in Accessed/Dirty getting set by the hardware when we do not expect them to be (on !Present PTEs). Instead of trying to fix them up after this happens, we just allow the bits to get set and try to ignore them. We do this by shifting the layout of the bits we use for swap

[PATCH 4/4] x86: use pte_none() to test for empty PTE

The page table manipulation code seems to have grown a couple of sites that are looking for empty PTEs. Just in case one of these entries got a stray bit set, use pte_none() instead of checking for a zero pte_val(). The use pte_same() makes me a bit nervous. If we were doing a pte_same() check

[PATCH 4/4] x86: use pte_none() to test for empty PTE

The page table manipulation code seems to have grown a couple of sites that are looking for empty PTEs. Just in case one of these entries got a stray bit set, use pte_none() instead of checking for a zero pte_val(). The use pte_same() makes me a bit nervous. If we were doing a pte_same() check

Re: [PATCH] mwifiex: mask PCIe interrupts before removal

Hi, On Thu, Jun 30, 2016 at 3:21 PM, Brian Norris wrote: > The PCIe driver didn't mask the host interrupts before trying to tear > down. This causes lockups at reboot or rmmod when using MSI-X on 8997, > since the MSI handler gets confused and locks up the system. > >

Re: [PATCH] mwifiex: mask PCIe interrupts before removal

Hi, On Thu, Jun 30, 2016 at 3:21 PM, Brian Norris wrote: > The PCIe driver didn't mask the host interrupts before trying to tear > down. This causes lockups at reboot or rmmod when using MSI-X on 8997, > since the MSI handler gets confused and locks up the system. > > Also tested on 8897, which

[PATCH] kasan: make depot_fetch_stack more robust

I've hit a GPF in depot_fetch_stack when it was given bogus stack handle. I think it was caused by a distant out-of-bounds that hit a different object, as the result we treated uninit garbage as stack handle. Maybe there is something to fix in KASAN logic, but I think it makes sense to make

[PATCH] kasan: make depot_fetch_stack more robust

I've hit a GPF in depot_fetch_stack when it was given bogus stack handle. I think it was caused by a distant out-of-bounds that hit a different object, as the result we treated uninit garbage as stack handle. Maybe there is something to fix in KASAN logic, but I think it makes sense to make

Re: GPF in __mark_inode_dirty due to locked_inode_to_wb_and_lock_list returning NULL

On Fri, Jul 01, 2016 at 12:00:50PM +0200, Jan Kara wrote: > Hello, > > On Thu 30-06-16 14:18:14, Nikolay Borisov wrote: > > In light of the discussion in https://patchwork.kernel.org/patch/9187411/ > > and > > the discussion at > > https://groups.google.com/forum/#!topic/syzkaller/XvxH3cBQ134

Re: GPF in __mark_inode_dirty due to locked_inode_to_wb_and_lock_list returning NULL

On Fri, Jul 01, 2016 at 12:00:50PM +0200, Jan Kara wrote: > Hello, > > On Thu 30-06-16 14:18:14, Nikolay Borisov wrote: > > In light of the discussion in https://patchwork.kernel.org/patch/9187411/ > > and > > the discussion at > > https://groups.google.com/forum/#!topic/syzkaller/XvxH3cBQ134

[PATCH v4] mfd: dm355evm_msp: Refactoring for add_child()

From: Markus Elfring Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring --- v4: Further feedback was integrated

Re: [Query] Preemption (hogging) of the work handler

Thanks for the quick reply Tejun, really appreciate it. On 01-07-16, 12:22, Tejun Heo wrote: > Hello, Viresh. > > On Fri, Jul 01, 2016 at 09:59:59AM -0700, Viresh Kumar wrote: > > The system watchdog uses a delayed-work (1 second) for petting the > > watchdog (resetting its counter) and if the

[PATCH v4] mfd: dm355evm_msp: Refactoring for add_child()

From: Markus Elfring Adjust jump targets according to the Linux coding style convention. Another check for the variable "status" can be omitted then at the end. Signed-off-by: Markus Elfring --- v4: Further feedback was integrated into this message. v3: Deletion of another blank line v2:

Re: [Query] Preemption (hogging) of the work handler

Thanks for the quick reply Tejun, really appreciate it. On 01-07-16, 12:22, Tejun Heo wrote: > Hello, Viresh. > > On Fri, Jul 01, 2016 at 09:59:59AM -0700, Viresh Kumar wrote: > > The system watchdog uses a delayed-work (1 second) for petting the > > watchdog (resetting its counter) and if the

Re: [PATCH] pinctrl: qcom: add support for EBI2

On Fri 01 Jul 08:52 PDT 2016, Linus Walleij wrote: > Add support to mux in the second external bus interface as > function 1 on pins 123 thru 158. This external bus is used on > the APQ8060 Dragonboard to connect an external SMSC9211 ethernet > adapter. > > Cc: Stephen Boyd

Re: [PATCH] pinctrl: qcom: add support for EBI2

On Fri 01 Jul 08:52 PDT 2016, Linus Walleij wrote: > Add support to mux in the second external bus interface as > function 1 on pins 123 thru 158. This external bus is used on > the APQ8060 Dragonboard to connect an external SMSC9211 ethernet > adapter. > > Cc: Stephen Boyd > Cc: Bjorn

Re: [PATCH] ARM: brcmstb: Add earlyprintk support using run-time checks

On 06/30/2016 05:42 PM, Florian Fainelli wrote: > SUN_TOP_CTRL_FAMILY_ID is at a fixed absolute address for all of our supported > chips, so utilize its value to determine what the UARTA base address should > be. > > Since the code is called both during decompressor when the MMU is off, and >

Re: [PATCH 1/6] lib: string: add function strtolower()

On Fri, 01 Jul 2016, Markus Mayer wrote: > On 1 July 2016 at 03:52, Jani Nikula wrote: >> On Fri, 01 Jul 2016, Markus Mayer wrote: >>> Add a function called strtolower() to convert strings to lower case >>> in-place,

Re: [PATCH] ARM: brcmstb: Add earlyprintk support using run-time checks

On 06/30/2016 05:42 PM, Florian Fainelli wrote: > SUN_TOP_CTRL_FAMILY_ID is at a fixed absolute address for all of our supported > chips, so utilize its value to determine what the UARTA base address should > be. > > Since the code is called both during decompressor when the MMU is off, and >

Re: [PATCH 1/6] lib: string: add function strtolower()

On Fri, 01 Jul 2016, Markus Mayer wrote: > On 1 July 2016 at 03:52, Jani Nikula wrote: >> On Fri, 01 Jul 2016, Markus Mayer wrote: >>> Add a function called strtolower() to convert strings to lower case >>> in-place, overwriting the original string. >>> >>> This seems to be a recurring

Re: [PATCH] [media] cec: add missing inline stubs

On 07/01/2016 05:37 PM, Arnd Bergmann wrote: > On Friday, July 1, 2016 5:22:32 PM CEST Hans Verkuil wrote: >>> diff --git a/drivers/media/platform/vivid/Kconfig >>> b/drivers/media/platform/vivid/Kconfig >>> index 8e6918c5c87c..8e31146d079a 100644 >>> --- a/drivers/media/platform/vivid/Kconfig

Re: [PATCH] [media] cec: add missing inline stubs

On 07/01/2016 05:37 PM, Arnd Bergmann wrote: > On Friday, July 1, 2016 5:22:32 PM CEST Hans Verkuil wrote: >>> diff --git a/drivers/media/platform/vivid/Kconfig >>> b/drivers/media/platform/vivid/Kconfig >>> index 8e6918c5c87c..8e31146d079a 100644 >>> --- a/drivers/media/platform/vivid/Kconfig

Re: [PATCH] cacheinfo: Introduce cache id

On Fri, Jul 01, 2016 at 09:50:41AM -0700, Luck, Tony wrote: > Here's the situation. We have lots of (mostly) independent caches on a > system. > The L3 cache (also called LLC - Last Level Cache - in some documentation) is > usually shared by all cpus on a physical socket. The L1 and L2 caches

Re: [PATCH] cacheinfo: Introduce cache id

On Fri, Jul 01, 2016 at 09:50:41AM -0700, Luck, Tony wrote: > Here's the situation. We have lots of (mostly) independent caches on a > system. > The L3 cache (also called LLC - Last Level Cache - in some documentation) is > usually shared by all cpus on a physical socket. The L1 and L2 caches

Re: sysfs topology for arm64 cluster_id

On 07/01/2016 11:54 AM, Stuart Yoder wrote: Re-opening a thread from back in early 2015... -Original Message- From: Jon Masters Date: Wed, Jan 14, 2015 at 11:18 AM Subject: Re: sysfs topology for arm64 cluster_id To: Mark Rutland Cc:

Re: sysfs topology for arm64 cluster_id

On 07/01/2016 11:54 AM, Stuart Yoder wrote: Re-opening a thread from back in early 2015... -Original Message- From: Jon Masters Date: Wed, Jan 14, 2015 at 11:18 AM Subject: Re: sysfs topology for arm64 cluster_id To: Mark Rutland Cc: "linux-arm-ker...@lists.infradead.org" ,

Re: [PATCH] doc: flat-table directive

On Fri, 01 Jul 2016, Markus Heiser wrote: > Am 01.07.2016 um 14:58 schrieb Jonathan Corbet : > >> On Fri, 01 Jul 2016 13:44:17 +0300 >> Jani Nikula wrote: >> >>> This is also one of the reasons why I so much want to keep

Re: [PATCH] doc: flat-table directive

On Fri, 01 Jul 2016, Markus Heiser wrote: > Am 01.07.2016 um 14:58 schrieb Jonathan Corbet : > >> On Fri, 01 Jul 2016 13:44:17 +0300 >> Jani Nikula wrote: >> >>> This is also one of the reasons why I so much want to keep everything >>> behind one configuration file, and build everything in the

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

Hello Caesar, On Fri, Jul 1, 2016 at 12:32 AM, Caesar Wang wrote: > From: Elaine Zhang > > In order to meet low power requirements, a power management unit (PMU) is > designed for controlling power resources in RK3399. The RK3399 PMU is > dedicated

Re: [Query] Preemption (hogging) of the work handler

Hello, Viresh. On Fri, Jul 01, 2016 at 09:59:59AM -0700, Viresh Kumar wrote: > The system watchdog uses a delayed-work (1 second) for petting the > watchdog (resetting its counter) and if the work doesn't reset the > counters in time (another 1 second), the watchdog resets the system. > >

Re: [Query] Preemption (hogging) of the work handler

Hello, Viresh. On Fri, Jul 01, 2016 at 09:59:59AM -0700, Viresh Kumar wrote: > The system watchdog uses a delayed-work (1 second) for petting the > watchdog (resetting its counter) and if the work doesn't reset the > counters in time (another 1 second), the watchdog resets the system. > >

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

Hello Caesar, On Fri, Jul 1, 2016 at 12:32 AM, Caesar Wang wrote: > From: Elaine Zhang > > In order to meet low power requirements, a power management unit (PMU) is > designed for controlling power resources in RK3399. The RK3399 PMU is > dedicated for managing the power of the whole chip. > >

Re: Portable Device Tree Connector -- conceptual

On 07/01/16 09:44, Frank Rowand wrote: > On 06/30/16 17:02, Frank Rowand wrote: >> Hi All, >> >> I've been trying to wrap my head around what Pantelis and Rob have written >> on the subject of a device tree representation of a connector for a >> daughter board to connect to (eg a cape or a shield)

Re: Portable Device Tree Connector -- conceptual

On 07/01/16 09:44, Frank Rowand wrote: > On 06/30/16 17:02, Frank Rowand wrote: >> Hi All, >> >> I've been trying to wrap my head around what Pantelis and Rob have written >> on the subject of a device tree representation of a connector for a >> daughter board to connect to (eg a cape or a shield)

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

Am Freitag, 1. Juli 2016, 09:56:31 schrieb Doug Anderson: > Caesar > > On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang wrote: > > From: Elaine Zhang > > > > In order to meet low power requirements, a power management unit (PMU) > > is > > designed

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

Am Freitag, 1. Juli 2016, 09:56:31 schrieb Doug Anderson: > Caesar > > On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang wrote: > > From: Elaine Zhang > > > > In order to meet low power requirements, a power management unit (PMU) > > is > > designed for controlling power resources in RK3399. The

Re: strange Mac OSX RST behavior

On 07/01/2016 01:08 PM, Rick Jones wrote: > On 07/01/2016 08:10 AM, Jason Baron wrote: >> I'm wondering if anybody else has run into this... >> >> On Mac OSX 10.11.5 (latest version), we have found that when tcp >> connections are abruptly terminated (via ^C), a FIN is sent followed >> by an RST

Re: strange Mac OSX RST behavior

On 07/01/2016 01:08 PM, Rick Jones wrote: > On 07/01/2016 08:10 AM, Jason Baron wrote: >> I'm wondering if anybody else has run into this... >> >> On Mac OSX 10.11.5 (latest version), we have found that when tcp >> connections are abruptly terminated (via ^C), a FIN is sent followed >> by an RST

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

On Fri, Jul 01, 2016 at 10:05:50AM -0700, Doug Anderson wrote: > I'm curious why you you need a timer at all. Can't you just keep > track of the jiffies that you last sent and do subtraction? ...or you > could get even more accurate and use a ktime_t. That avoids a whole > lot of

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

On Fri, Jul 01, 2016 at 10:05:50AM -0700, Doug Anderson wrote: > I'm curious why you you need a timer at all. Can't you just keep > track of the jiffies that you last sent and do subtraction? ...or you > could get even more accurate and use a ktime_t. That avoids a whole > lot of

Re: strange Mac OSX RST behavior

On 07/01/2016 08:10 AM, Jason Baron wrote: I'm wondering if anybody else has run into this... On Mac OSX 10.11.5 (latest version), we have found that when tcp connections are abruptly terminated (via ^C), a FIN is sent followed by an RST packet. That just seems, well, silly. If the client

Re: strange Mac OSX RST behavior

On 07/01/2016 08:10 AM, Jason Baron wrote: I'm wondering if anybody else has run into this... On Mac OSX 10.11.5 (latest version), we have found that when tcp connections are abruptly terminated (via ^C), a FIN is sent followed by an RST packet. That just seems, well, silly. If the client

Re: [PATCH 1/6] lib: string: add function strtolower()

On 1 July 2016 at 03:52, Jani Nikula wrote: > On Fri, 01 Jul 2016, Markus Mayer wrote: >> Add a function called strtolower() to convert strings to lower case >> in-place, overwriting the original string. >> >> This seems to be a recurring

Re: [PATCH 1/6] lib: string: add function strtolower()

On 1 July 2016 at 03:52, Jani Nikula wrote: > On Fri, 01 Jul 2016, Markus Mayer wrote: >> Add a function called strtolower() to convert strings to lower case >> in-place, overwriting the original string. >> >> This seems to be a recurring requirement in the kernel that is >> currently being

Asus screenDUO

Hello. I'm posting here because someone asked (a long time ago) for a driver or app that would drive a little usb gadget (mini vga display) called the screenDUO that comes with Asus motherboards. I recently put a bunch of work into it (multiline support, color text, pixel drawing, etc.) And

Asus screenDUO

Hello. I'm posting here because someone asked (a long time ago) for a driver or app that would drive a little usb gadget (mini vga display) called the screenDUO that comes with Asus motherboards. I recently put a bunch of work into it (multiline support, color text, pixel drawing, etc.) And

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

Hi, On Fri, Jul 1, 2016 at 1:21 AM, Mark Brown wrote: > On Thu, Jun 30, 2016 at 09:23:26PM -0700, Doug Anderson wrote: > >> Also, something doesn't seem terribly robust about this, buy maybe I'm >> being paranoid. If something happens where the timer hasn't fired >> quickly

Re: Portable Device Tree Connector -- conceptual

Hi Frank, > On Jul 1, 2016, at 19:31 , Frank Rowand wrote: > > On 07/01/16 03:59, Pantelis Antoniou wrote: >> Hi Frank, >> >> Comments inline. >> >>> On Jul 1, 2016, at 03:02 , Frank Rowand wrote: >>> >>> Hi All, >>> >>> I've been trying to

Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS

Hi, On Fri, Jul 1, 2016 at 1:21 AM, Mark Brown wrote: > On Thu, Jun 30, 2016 at 09:23:26PM -0700, Doug Anderson wrote: > >> Also, something doesn't seem terribly robust about this, buy maybe I'm >> being paranoid. If something happens where the timer hasn't fired >> quickly enough then you

Re: Portable Device Tree Connector -- conceptual

Hi Frank, > On Jul 1, 2016, at 19:31 , Frank Rowand wrote: > > On 07/01/16 03:59, Pantelis Antoniou wrote: >> Hi Frank, >> >> Comments inline. >> >>> On Jul 1, 2016, at 03:02 , Frank Rowand wrote: >>> >>> Hi All, >>> >>> I've been trying to wrap my head around what Pantelis and Rob have

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

Caesar On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang wrote: > From: Elaine Zhang > > In order to meet low power requirements, a power management unit (PMU) is > designed for controlling power resources in RK3399. The RK3399 PMU is > dedicated for

Re: [PATCH v2] arm64: dts: rockchip: add the power domain node for rk3399

Caesar On Thu, Jun 30, 2016 at 9:32 PM, Caesar Wang wrote: > From: Elaine Zhang > > In order to meet low power requirements, a power management unit (PMU) is > designed for controlling power resources in RK3399. The RK3399 PMU is > dedicated for managing the power of the whole chip. > > 1. add

[Query] Preemption (hogging) of the work handler

Hi Tejun, we are stuck with a typical issue on our octa-core ARM platform and wanted to make sure that we aren't abusing the workqueue API by using it for the wrong usecase. Setup: The system watchdog uses a delayed-work (1 second) for petting the watchdog (resetting its counter) and if the

[Query] Preemption (hogging) of the work handler

Hi Tejun, we are stuck with a typical issue on our octa-core ARM platform and wanted to make sure that we aren't abusing the workqueue API by using it for the wrong usecase. Setup: The system watchdog uses a delayed-work (1 second) for petting the watchdog (resetting its counter) and if the

Re: [PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

On Thu, 30 Jun 2016, Manfred Spraul wrote: On 06/28/2016 07:27 AM, Davidlohr Bueso wrote: If I understand it right, it means that spin_lock() is both an acquire and a release - for qspinlocks. I wouldn't say that: the _Q_LOCKED_VAL stores are still unordered inside the acquire region but

Re: [PATCH 1/2] ipc/sem.c: Fix complex_count vs. simple op race

On Thu, 30 Jun 2016, Manfred Spraul wrote: On 06/28/2016 07:27 AM, Davidlohr Bueso wrote: If I understand it right, it means that spin_lock() is both an acquire and a release - for qspinlocks. I wouldn't say that: the _Q_LOCKED_VAL stores are still unordered inside the acquire region but

Re: [PATCH] cacheinfo: Introduce cache id

On Fri, Jul 01, 2016 at 12:21:43PM +0200, Borislav Petkov wrote: > On Wed, Jun 29, 2016 at 06:56:10PM -0700, Fenghua Yu wrote: > > From: Fenghua Yu > > > > Each cache node is described by cacheinfo and is a unique node across > > What is a cache node? Clearly not a good

Re: [PATCH] cacheinfo: Introduce cache id

On Fri, Jul 01, 2016 at 12:21:43PM +0200, Borislav Petkov wrote: > On Wed, Jun 29, 2016 at 06:56:10PM -0700, Fenghua Yu wrote: > > From: Fenghua Yu > > > > Each cache node is described by cacheinfo and is a unique node across > > What is a cache node? Clearly not a good name for the concept we

Re: [RFC PATCH 0/2] KVM: x86: guest exit microoptimization

On 16/06/2016 10:21, Paolo Bonzini wrote: > This saves about 20 clock cycles per vmexit by avoiding a > local_irq_save/restore pair. The price is that nested VMX will break > with KVM hosts < 3.16, because the "acknowledge interrupt on exit" > feature becomes mandatory. What do you think? I'm

Re: [RFC PATCH 0/2] KVM: x86: guest exit microoptimization

On 16/06/2016 10:21, Paolo Bonzini wrote: > This saves about 20 clock cycles per vmexit by avoiding a > local_irq_save/restore pair. The price is that nested VMX will break > with KVM hosts < 3.16, because the "acknowledge interrupt on exit" > feature becomes mandatory. What do you think? I'm

Re: [PATCH 1/6] x86: fix duplicated X86_BUG(9) macro

On Fri, Jul 01, 2016 at 09:30:37AM -0700, Andy Lutomirski wrote: > I put the ifdef there to prevent anyone from accidentally using it in > a 64-bit code path, not to save a bit. We could put in the middle of > the list to make the mistake much less likely to be repeated, I > suppose. Well, if

Re: [PATCH 1/6] x86: fix duplicated X86_BUG(9) macro

On Fri, Jul 01, 2016 at 09:30:37AM -0700, Andy Lutomirski wrote: > I put the ifdef there to prevent anyone from accidentally using it in > a 64-bit code path, not to save a bit. We could put in the middle of > the list to make the mistake much less likely to be repeated, I > suppose. Well, if

Re: Portable Device Tree Connector -- conceptual

On 06/30/16 17:02, Frank Rowand wrote: > Hi All, > > I've been trying to wrap my head around what Pantelis and Rob have written > on the subject of a device tree representation of a connector for a > daughter board to connect to (eg a cape or a shield) and the representation > of the daughter

Re: Portable Device Tree Connector -- conceptual

On 06/30/16 17:02, Frank Rowand wrote: > Hi All, > > I've been trying to wrap my head around what Pantelis and Rob have written > on the subject of a device tree representation of a connector for a > daughter board to connect to (eg a cape or a shield) and the representation > of the daughter

Re: [PATCH v1 06/11] KVM: x86: use hardware-compatible format for APIC ID register

On 01/07/2016 17:53, Radim Krčmář wrote: >> >> enable_xapic() >> >> id = apic_id() >> >> set_apic_id(id+1) // ? >> >> enable_x2apic() >> >> id == apic_id() & 0xff >> >> disable_apic() >> >> enable_xapic() >> >> id == apic_id() >> >> > > > > Yes, plus checking that it "moves"

Re: [PATCH v1 06/11] KVM: x86: use hardware-compatible format for APIC ID register

On 01/07/2016 17:53, Radim Krčmář wrote: >> >> enable_xapic() >> >> id = apic_id() >> >> set_apic_id(id+1) // ? >> >> enable_x2apic() >> >> id == apic_id() & 0xff >> >> disable_apic() >> >> enable_xapic() >> >> id == apic_id() >> >> > > > > Yes, plus checking that it "moves"

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

On 01/07/2016 17:43, Radim Krčmář wrote: > > Forgot to reply about this: letting SET_LAPIC change x2APIC IDs is nonsense. > > > > In x2APIC mode + new capability disabled SET_LAPIC should ignore the id > > register altogether for backwards compatibility. > > I'd still shift SET_LAPIC APIC ID

Re: [PATCH v1 03/11] KVM: x86: dynamic kvm_apic_map

On 01/07/2016 17:43, Radim Krčmář wrote: > > Forgot to reply about this: letting SET_LAPIC change x2APIC IDs is nonsense. > > > > In x2APIC mode + new capability disabled SET_LAPIC should ignore the id > > register altogether for backwards compatibility. > > I'd still shift SET_LAPIC APIC ID

Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

On Jun 30, 2016 2:25 PM, "Dave Hansen" wrote: > > On 06/30/2016 10:36 AM, Andy Lutomirski wrote: > >>> We make baseline_pkru a process-wide baseline and store it in > >>> mm->context. That way, no matter which thread gets interrupted for a > >>> signal, they see

Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

On Jun 30, 2016 2:25 PM, "Dave Hansen" wrote: > > On 06/30/2016 10:36 AM, Andy Lutomirski wrote: > >>> We make baseline_pkru a process-wide baseline and store it in > >>> mm->context. That way, no matter which thread gets interrupted for a > >>> signal, they see consistent values. We only write

Re: Portable Device Tree Connector -- conceptual

On 07/01/16 03:59, Pantelis Antoniou wrote: > Hi Frank, > > Comments inline. > >> On Jul 1, 2016, at 03:02 , Frank Rowand wrote: >> >> Hi All, >> >> I've been trying to wrap my head around what Pantelis and Rob have written >> on the subject of a device tree

Re: Portable Device Tree Connector -- conceptual

On 07/01/16 03:59, Pantelis Antoniou wrote: > Hi Frank, > > Comments inline. > >> On Jul 1, 2016, at 03:02 , Frank Rowand wrote: >> >> Hi All, >> >> I've been trying to wrap my head around what Pantelis and Rob have written >> on the subject of a device tree representation of a connector for a

<    1   2   3   4   5   6   7   8   9   10   >