On Tue, Sep 04, 2018 at 06:14:31PM +0200, Michal Hocko wrote:
> On Tue 04-09-18 08:34:49, Roman Gushchin wrote:
> > On Tue, Sep 04, 2018 at 09:00:05AM +0200, Michal Hocko wrote:
> > > On Mon 03-09-18 13:28:06, Roman Gushchin wrote:
> > > > On Mon, Sep 03, 2018 at 08:29:56PM +0200, Michal Hocko
On Tue, Sep 04, 2018 at 06:14:31PM +0200, Michal Hocko wrote:
> On Tue 04-09-18 08:34:49, Roman Gushchin wrote:
> > On Tue, Sep 04, 2018 at 09:00:05AM +0200, Michal Hocko wrote:
> > > On Mon 03-09-18 13:28:06, Roman Gushchin wrote:
> > > > On Mon, Sep 03, 2018 at 08:29:56PM +0200, Michal Hocko
This patch adds the device ID for the AMPAK AP6335 combo module used
in the 1st generation WeTek Hub Android/LibreELEC HTPC box. The WiFI
chip identifies itself as BCM4339, while Bluetooth identifies itself
as BCM4335 (rev C0):
```
[4.864248] Bluetooth: hci0: BCM: chip id 86
[4.866388]
This patch adds the device ID for the AMPAK AP6335 combo module used
in the 1st generation WeTek Hub Android/LibreELEC HTPC box. The WiFI
chip identifies itself as BCM4339, while Bluetooth identifies itself
as BCM4335 (rev C0):
```
[4.864248] Bluetooth: hci0: BCM: chip id 86
[4.866388]
On Mon, Aug 27 2018 at 16:35 -0600, Matthias Kaehlcke wrote:
Hi Lina,
On Fri, Aug 24, 2018 at 02:01:53PM -0600, Lina Iyer wrote:
QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
domain can wakeup the SoC, when interrupts and GPIOs are routed to the
its interrupt
On Mon, Aug 27 2018 at 16:35 -0600, Matthias Kaehlcke wrote:
Hi Lina,
On Fri, Aug 24, 2018 at 02:01:53PM -0600, Lina Iyer wrote:
QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on
domain can wakeup the SoC, when interrupts and GPIOs are routed to the
its interrupt
On Mon, 2018-09-03 at 23:53 -0700, Francisco Jerez wrote:
> Eero Tamminen writes:
>
> > Hi,
> >
> > On 31.08.2018 20:28, Srinivas Pandruvada wrote:
> > ...
> > > As per testing Eero Tamminen, the results are comparable to the
> > > patchset
> > > https://patchwork.kernel.org/patch/10312259/
> >
On Mon, 2018-09-03 at 23:53 -0700, Francisco Jerez wrote:
> Eero Tamminen writes:
>
> > Hi,
> >
> > On 31.08.2018 20:28, Srinivas Pandruvada wrote:
> > ...
> > > As per testing Eero Tamminen, the results are comparable to the
> > > patchset
> > > https://patchwork.kernel.org/patch/10312259/
> >
Hi,
On 04.09.2018 20:34, Andi Kleen wrote:
>> .sample = process_sample_event,
>> @@ -1678,6 +1680,8 @@ static struct option __record_options[] = {
>>"signal"),
>> OPT_BOOLEAN(0, "dry-run", _run,
>> "Parse options then exit"),
>> +
Hi,
On 04.09.2018 20:34, Andi Kleen wrote:
>> .sample = process_sample_event,
>> @@ -1678,6 +1680,8 @@ static struct option __record_options[] = {
>>"signal"),
>> OPT_BOOLEAN(0, "dry-run", _run,
>> "Parse options then exit"),
>> +
On Mon, Sep 03, 2018 at 05:41:53PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 27, 2018 at 9:58 PM Jarkko Sakkinen
> wrote:
>
> > + va = ioremap_cache(addr, size);
> > + if (!va)
> > + return -ENOMEM;
>
> I'm not sure this is a right API. Do we operate with memory?
On Mon, Sep 03, 2018 at 05:41:53PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 27, 2018 at 9:58 PM Jarkko Sakkinen
> wrote:
>
> > + va = ioremap_cache(addr, size);
> > + if (!va)
> > + return -ENOMEM;
>
> I'm not sure this is a right API. Do we operate with memory?
On Mon, Aug 27 2018 at 16:57 -0600, Matthias Kaehlcke wrote:
Hi Lina,
On Fri, Aug 24, 2018 at 02:01:55PM -0600, Lina Iyer wrote:
During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be
On Mon, Aug 27 2018 at 16:57 -0600, Matthias Kaehlcke wrote:
Hi Lina,
On Fri, Aug 24, 2018 at 02:01:55PM -0600, Lina Iyer wrote:
During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be
Stephen Rothwell writes:
> [ Unknown signature status ]
> Hi Eric,
>
> Fetching the bcm2835 tree (git://github.com/anholt/linux.git#for-next)
> produces this error:
>
> fatal: Couldn't find remote ref refs/heads/for-next
I'd passed responsibility for the git tree off to Stefan while I'm
Stephen Rothwell writes:
> [ Unknown signature status ]
> Hi Eric,
>
> Fetching the bcm2835 tree (git://github.com/anholt/linux.git#for-next)
> produces this error:
>
> fatal: Couldn't find remote ref refs/heads/for-next
I'd passed responsibility for the git tree off to Stefan while I'm
On a platform with MB resource enabled, a divided-by-zero
exception is triggered when accessing 'size':
[ 151.193447] divide error: [#1] SMP PTI
[ 151.197743] CPU: 93 PID: 1929 Comm: cat Not tainted 4.19.0-rc2-debug-rdt+ #25
[ 151.205070] Hardware name: Dell Inc. PowerEdge R640/0CRT1G,
On a platform with MB resource enabled, a divided-by-zero
exception is triggered when accessing 'size':
[ 151.193447] divide error: [#1] SMP PTI
[ 151.197743] CPU: 93 PID: 1929 Comm: cat Not tainted 4.19.0-rc2-debug-rdt+ #25
[ 151.205070] Hardware name: Dell Inc. PowerEdge R640/0CRT1G,
On Tue, 4 Sep 2018, Tim Chen wrote:
> > Current ptrace_may_access() implementation assumes that the 'source' task is
> > always the caller (current).
> >
> > Expose ___ptrace_may_access() that can be used to apply the check on
> > arbitrary
> > tasks.
>
> Casey recently has proposed putting
On Tue, 4 Sep 2018, Tim Chen wrote:
> > Current ptrace_may_access() implementation assumes that the 'source' task is
> > always the caller (current).
> >
> > Expose ___ptrace_may_access() that can be used to apply the check on
> > arbitrary
> > tasks.
>
> Casey recently has proposed putting
> .sample = process_sample_event,
> @@ -1678,6 +1680,8 @@ static struct option __record_options[] = {
> "signal"),
> OPT_BOOLEAN(0, "dry-run", _run,
> "Parse options then exit"),
> + OPT_INTEGER(0, "aio", _cblocks,
> +
> .sample = process_sample_event,
> @@ -1678,6 +1680,8 @@ static struct option __record_options[] = {
> "signal"),
> OPT_BOOLEAN(0, "dry-run", _run,
> "Parse options then exit"),
> + OPT_INTEGER(0, "aio", _cblocks,
> +
On Tue, Sep 4, 2018 at 3:13 AM, Grant Likely wrote:
> Hey folks. More comments below, but the short answer is I really don't
> see what the problem is. Distros cannot easily support platforms that
> require a dtb= parameter, and so they probably won't. They may or may
> not disable 'dtb=',
On Tue, Sep 4, 2018 at 3:13 AM, Grant Likely wrote:
> Hey folks. More comments below, but the short answer is I really don't
> see what the problem is. Distros cannot easily support platforms that
> require a dtb= parameter, and so they probably won't. They may or may
> not disable 'dtb=',
On 09/04/2018 07:40 AM, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Current ptrace_may_access() implementation assumes that the 'source' task is
> always the caller (current).
>
> Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
> tasks.
Casey recently has proposed
On 09/04/2018 07:40 AM, Jiri Kosina wrote:
> From: Jiri Kosina
>
> Current ptrace_may_access() implementation assumes that the 'source' task is
> always the caller (current).
>
> Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
> tasks.
Casey recently has proposed
Hi RT folks!
The call for proposals (CfP) is now open for the RT Microconference at
Linux Plumbers in Vancouver, Canada. The topics we are looking at this
year are:
- How will PREEMPT_RT be maintained (is it a subsystem?)
- Who will maintain it?
- How do we teach the rest of the kernel
Hi RT folks!
The call for proposals (CfP) is now open for the RT Microconference at
Linux Plumbers in Vancouver, Canada. The topics we are looking at this
year are:
- How will PREEMPT_RT be maintained (is it a subsystem?)
- Who will maintain it?
- How do we teach the rest of the kernel
On Tue, Sep 04, 2018 at 10:12:13AM -0700, Linus Torvalds wrote:
> On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
> wrote:
> >
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> > Sep 3 20:19:38
On Tue, Sep 04, 2018 at 10:12:13AM -0700, Linus Torvalds wrote:
> On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
> wrote:
> >
> > Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> > Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> > Sep 3 20:19:38
On 18-09-04 03:13 AM, Grant Likely wrote:
Hey folks. More comments below, but the short answer is I really don't
see what the problem is. Distros cannot easily support platforms that
require a dtb= parameter, and so they probably won't. They may or may
not disable 'dtb=', depending on whether
On 18-09-04 03:13 AM, Grant Likely wrote:
Hey folks. More comments below, but the short answer is I really don't
see what the problem is. Distros cannot easily support platforms that
require a dtb= parameter, and so they probably won't. They may or may
not disable 'dtb=', depending on whether
On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
wrote:
>
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> ..a few hundred times..
> Sep
On Mon, Sep 3, 2018 at 11:39 AM Holger Hoffstätte
wrote:
>
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x76/0xc0
> Sep 3 20:19:38 ragnarok kernel: tlb_table_flush.part.13+0xe/0x30
> Sep 3 20:19:38 ragnarok kernel: tlb_flush_mmu_tlbonly+0x54/0xc0
> ..a few hundred times..
> Sep
On Mon, Sep 3, 2018 at 1:34 PM Miguel Ojeda
wrote:
>
> Cc: Rasmus Villemoes
> Cc: Luc Van Oostenryck
> Cc: Eli Friedman
> Cc: Christopher Li
> Cc: Kees Cook
> Cc: Ingo Molnar
> Cc: Geert Uytterhoeven
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Masahiro Yamada
> Cc: Joe Perches
>
On Mon, Sep 3, 2018 at 1:34 PM Miguel Ojeda
wrote:
>
> Cc: Rasmus Villemoes
> Cc: Luc Van Oostenryck
> Cc: Eli Friedman
> Cc: Christopher Li
> Cc: Kees Cook
> Cc: Ingo Molnar
> Cc: Geert Uytterhoeven
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Cc: Masahiro Yamada
> Cc: Joe Perches
>
On Fri, Aug 31, 2018 at 06:57:47PM +0530, Manish Narani wrote:
> Add platform specific structures, so that we can add different IP
> support later using quirks.
>
> Signed-off-by: Manish Narani
> ---
> drivers/edac/synopsys_edac.c | 78
> +---
> 1 file
On Fri, Aug 31, 2018 at 06:57:47PM +0530, Manish Narani wrote:
> Add platform specific structures, so that we can add different IP
> support later using quirks.
>
> Signed-off-by: Manish Narani
> ---
> drivers/edac/synopsys_edac.c | 78
> +---
> 1 file
On Mon, Sep 03, 2018 at 12:45:45PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix kernel-doc warnings for missing parameter descriptions:
>
> ../include/linux/srcu.h:175: warning: Function parameter or member 'p' not
> described in 'srcu_dereference_notrace'
>
On Mon, Sep 03, 2018 at 12:45:45PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix kernel-doc warnings for missing parameter descriptions:
>
> ../include/linux/srcu.h:175: warning: Function parameter or member 'p' not
> described in 'srcu_dereference_notrace'
>
On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Yang, Bin wrote:
> > On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> > > On Tue, 21 Aug 2018, Bin Yang wrote:
> > > > @@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long
> > > > address,
> > > >
> >
On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Yang, Bin wrote:
> > On Tue, 2018-09-04 at 00:27 +0200, Thomas Gleixner wrote:
> > > On Tue, 21 Aug 2018, Bin Yang wrote:
> > > > @@ -625,6 +625,7 @@ try_preserve_large_page(pte_t *kpte, unsigned long
> > > > address,
> > > >
> >
Dear Maintainers,
This series is still needed to complete the initial cache pseudo-locking
implementation and still applies cleanly to both x86/cache of tip.git as
well as v4.19-rc2.
At this time users are unable to measure the success of their cache
pseudo-locked regions and either need to
Dear Maintainers,
This series is still needed to complete the initial cache pseudo-locking
implementation and still applies cleanly to both x86/cache of tip.git as
well as v4.19-rc2.
At this time users are unable to measure the success of their cache
pseudo-locked regions and either need to
On Sun, 2 Sep 2018 13:03:43 +
Sasha Levin wrote:
> [
> Note, this only fixes the symptom. The real fix was not to call
> this function when tracing_on was already one. But this still makes
> the code more robust, so we'll add it.
> ]
This patch really didn't need to be backported (which
On Sun, 2 Sep 2018 13:03:43 +
Sasha Levin wrote:
> [
> Note, this only fixes the symptom. The real fix was not to call
> this function when tracing_on was already one. But this still makes
> the code more robust, so we'll add it.
> ]
This patch really didn't need to be backported (which
On Tue, Sep 04, 2018 at 06:30:21PM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 04, 2018 at 07:54:51AM -0700, Sean Christopherson wrote:
> > I don't see any value in trying to rule out specific causes of
> > INVALID_TOKEN, but we should only retry EINIT if ret==INVALID_TOKEN
> > and RDMSR(HASH0) !=
On Tue, Sep 04, 2018 at 06:30:21PM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 04, 2018 at 07:54:51AM -0700, Sean Christopherson wrote:
> > I don't see any value in trying to rule out specific causes of
> > INVALID_TOKEN, but we should only retry EINIT if ret==INVALID_TOKEN
> > and RDMSR(HASH0) !=
The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
times while operating on one of the client's ion_handles. This creates
windows where userspace can call ION_IOC_FREE on the same client with
the same handle, and effectively make the kernel drop its own reference.
For example:
The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several
times while operating on one of the client's ion_handles. This creates
windows where userspace can call ION_IOC_FREE on the same client with
the same handle, and effectively make the kernel drop its own reference.
For example:
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.6 release.
> There are 123 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Mon, Sep 03, 2018 at 06:55:44PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.6 release.
> There are 123 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On 09/04/2018 01:10 PM, Andrey Ryabinin wrote:
>
>
> On 09/04/2018 09:59 AM, Kyeongdon Kim wrote:
>
+#undef strncmp
+int strncmp(const char *cs, const char *ct, size_t len)
+{
+ check_memory_region((unsigned long)cs, len, false, _RET_IP_);
+
On 09/04/2018 01:10 PM, Andrey Ryabinin wrote:
>
>
> On 09/04/2018 09:59 AM, Kyeongdon Kim wrote:
>
+#undef strncmp
+int strncmp(const char *cs, const char *ct, size_t len)
+{
+ check_memory_region((unsigned long)cs, len, false, _RET_IP_);
+
On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
>
> Well, I think the point was that in the above examples you'd prefer that
> the read just fail--no need to keep the data. A bit marking the file
> (or even the entire filesystem) unreadable would satisfy posix, I guess.
>
On Tue, Sep 04, 2018 at 12:12:03PM -0400, J. Bruce Fields wrote:
>
> Well, I think the point was that in the above examples you'd prefer that
> the read just fail--no need to keep the data. A bit marking the file
> (or even the entire filesystem) unreadable would satisfy posix, I guess.
>
The patch
spi: spidev_test: Improve decoded text part of hex dump
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
spi: spidev_test: Improve decoded text part of hex dump
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
regulator: fix kernel-doc for regulator_suspend()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: fix kernel-doc for regulator_suspend()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Jiri Kosina wrote:
> > +/**
> > + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> > + * between two arbitrary tasks
> > + * @curr: source task
>
> That's a pretty shitty name, really. If @curr is supposed to
On Tue, 4 Sep 2018, Thomas Gleixner wrote:
> On Tue, 4 Sep 2018, Jiri Kosina wrote:
> > +/**
> > + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> > + * between two arbitrary tasks
> > + * @curr: source task
>
> That's a pretty shitty name, really. If @curr is supposed to
On Tue, Sep 04, 2018 at 11:02:14AM -0500, Andrew F. Davis wrote:
> On 09/04/2018 10:56 AM, Mark Brown wrote:
> > I'm really having a lot of trouble seeing MICBIAS_OFF as a useful
> > voltage to specify in DT in the first place.
> I don't see the usefulness in specifying any bias voltage in DT at
On Tue, Sep 04, 2018 at 11:02:14AM -0500, Andrew F. Davis wrote:
> On 09/04/2018 10:56 AM, Mark Brown wrote:
> > I'm really having a lot of trouble seeing MICBIAS_OFF as a useful
> > voltage to specify in DT in the first place.
> I don't see the usefulness in specifying any bias voltage in DT at
On 4 September 2018 15:05:38 BST, Srinivas Kandagatla
wrote:
>Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor.
>Its been more than 2 years of wait for this to be fixed, which has
>no hopes to be fixed. This change was introduced for the "lead device"
>on msm8996 platform. It
On 4 September 2018 15:05:38 BST, Srinivas Kandagatla
wrote:
>Access to GICR_WAKER is restricted on msm8996 SoC in Hypervisor.
>Its been more than 2 years of wait for this to be fixed, which has
>no hopes to be fixed. This change was introduced for the "lead device"
>on msm8996 platform. It
On Tue, 4 Sep 2018, Jiri Kosina wrote:
> if (tsk && tsk->mm &&
> tsk->mm->context.ctx_id != last_ctx_id &&
> - get_dumpable(tsk->mm) != SUID_DUMP_USER)
> + ___ptrace_may_access(current, tsk, PTRACE_MODE_IBPB))
Uurgh. If
On Tue, 4 Sep 2018, Jiri Kosina wrote:
> if (tsk && tsk->mm &&
> tsk->mm->context.ctx_id != last_ctx_id &&
> - get_dumpable(tsk->mm) != SUID_DUMP_USER)
> + ___ptrace_may_access(current, tsk, PTRACE_MODE_IBPB))
Uurgh. If
On Tue, Sep 4, 2018 at 6:16 PM Andrew Lunn wrote:
>
> On Tue, Sep 04, 2018 at 05:24:35PM +0530, sunil.kovv...@gmail.com wrote:
> > From: Sunil Goutham
> >
> > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports
> > multiple PCIe SRIOV physical functions (PFs) and virtual
On Tue 04-09-18 08:34:49, Roman Gushchin wrote:
> On Tue, Sep 04, 2018 at 09:00:05AM +0200, Michal Hocko wrote:
> > On Mon 03-09-18 13:28:06, Roman Gushchin wrote:
> > > On Mon, Sep 03, 2018 at 08:29:56PM +0200, Michal Hocko wrote:
> > > > On Fri 31-08-18 14:31:41, Roman Gushchin wrote:
> > > > >
On Tue, Sep 4, 2018 at 6:16 PM Andrew Lunn wrote:
>
> On Tue, Sep 04, 2018 at 05:24:35PM +0530, sunil.kovv...@gmail.com wrote:
> > From: Sunil Goutham
> >
> > Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports
> > multiple PCIe SRIOV physical functions (PFs) and virtual
On Tue 04-09-18 08:34:49, Roman Gushchin wrote:
> On Tue, Sep 04, 2018 at 09:00:05AM +0200, Michal Hocko wrote:
> > On Mon 03-09-18 13:28:06, Roman Gushchin wrote:
> > > On Mon, Sep 03, 2018 at 08:29:56PM +0200, Michal Hocko wrote:
> > > > On Fri 31-08-18 14:31:41, Roman Gushchin wrote:
> > > > >
On Tue, 4 Sep 2018, Jiri Kosina wrote:
> +/**
> + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> + * between two arbitrary tasks
> + * @curr: source task
That's a pretty shitty name, really. If @curr is supposed to be an
arbitrary task, then please rename it in a way
On Tue, Sep 04, 2018 at 11:44:20AM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> > A practical and concrete example may be,
> > A disk cleaner program that first searches for garbage files that won't be
> > used
> > anymore and save the list in a file
On Tue, 4 Sep 2018, Jiri Kosina wrote:
> +/**
> + * ___ptrace_may_access - variant of ptrace_may_access that can be used
> + * between two arbitrary tasks
> + * @curr: source task
That's a pretty shitty name, really. If @curr is supposed to be an
arbitrary task, then please rename it in a way
On Tue, Sep 04, 2018 at 11:44:20AM -0400, Jeff Layton wrote:
> On Tue, 2018-09-04 at 22:56 +0800, 焦晓冬 wrote:
> > A practical and concrete example may be,
> > A disk cleaner program that first searches for garbage files that won't be
> > used
> > anymore and save the list in a file
On Mon, Sep 03, 2018 at 03:11:11PM +0530, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> Disable interrupts while configuring the transfer and enable them back.
>
> We have below as the programming sequence
> 1. start and slave address
> 2. byte count and stop
>
> In some
On Mon, Sep 03, 2018 at 03:11:11PM +0530, shubhrajyoti.da...@gmail.com wrote:
> From: Shubhrajyoti Datta
>
> Disable interrupts while configuring the transfer and enable them back.
>
> We have below as the programming sequence
> 1. start and slave address
> 2. byte count and stop
>
> In some
On Tue, Sep 4, 2018 at 7:04 PM Dave Hansen wrote:
>
> On 09/03/2018 06:16 AM, Andy Shevchenko wrote:
> >> + EBLOCK = 0x9,
> >> + EPA = 0xA,
> >> + EWB = 0xB,
> >> + ETRACK = 0xC,
> >> + EAUG= 0xD,
> >> + EMODPR = 0xE,
> >> + EMODT = 0xF,
On Tue, Sep 4, 2018 at 7:04 PM Dave Hansen wrote:
>
> On 09/03/2018 06:16 AM, Andy Shevchenko wrote:
> >> + EBLOCK = 0x9,
> >> + EPA = 0xA,
> >> + EWB = 0xB,
> >> + ETRACK = 0xC,
> >> + EAUG= 0xD,
> >> + EMODPR = 0xE,
> >> + EMODT = 0xF,
On Tue, Sep 04, 2018 at 08:50:07AM -0700, Stephane Eranian wrote:
> > > When we get an exact IP (using PEBS) and were sampling a data related
> > > event (say L1 misses), we can get the data type from the instruction
> > > itself; that is, through DWARF. We _know_ what type (structure::member)
> >
On Tue, Sep 04, 2018 at 08:50:07AM -0700, Stephane Eranian wrote:
> > > When we get an exact IP (using PEBS) and were sampling a data related
> > > event (say L1 misses), we can get the data type from the instruction
> > > itself; that is, through DWARF. We _know_ what type (structure::member)
> >
On Mon, Aug 27, 2018 at 9:58 PM Jarkko Sakkinen
wrote:
>
> From: Sean Christopherson
>
> Add a function to perform ENCLS(EINIT), which initializes an enclave,
> which can be used by a driver for running enclaves and VMMs.
>
> Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x
On Mon, Aug 27, 2018 at 9:58 PM Jarkko Sakkinen
wrote:
>
> From: Sean Christopherson
>
> Add a function to perform ENCLS(EINIT), which initializes an enclave,
> which can be used by a driver for running enclaves and VMMs.
>
> Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x
On 09/03/2018 06:16 AM, Andy Shevchenko wrote:
>> + EBLOCK = 0x9,
>> + EPA = 0xA,
>> + EWB = 0xB,
>> + ETRACK = 0xC,
>> + EAUG= 0xD,
>> + EMODPR = 0xE,
>> + EMODT = 0xF,
>> +};
> Hmm... This E prefix confuses me with (system wide) error
On 09/03/2018 06:16 AM, Andy Shevchenko wrote:
>> + EBLOCK = 0x9,
>> + EPA = 0xA,
>> + EWB = 0xB,
>> + ETRACK = 0xC,
>> + EAUG= 0xD,
>> + EMODPR = 0xE,
>> + EMODT = 0xF,
>> +};
> Hmm... This E prefix confuses me with (system wide) error
'error' variable is left uninitialized in case we see an unknown operation.
As we don't immediately return and proceed to pwrite() we need to set it
to something, HV_E_FAIL sounds good enough.
Signed-off-by: Vitaly Kuznetsov
---
tools/hv/hv_fcopy_daemon.c | 1 +
1 file changed, 1 insertion(+)
'error' variable is left uninitialized in case we see an unknown operation.
As we don't immediately return and proceed to pwrite() we need to set it
to something, HV_E_FAIL sounds good enough.
Signed-off-by: Vitaly Kuznetsov
---
tools/hv/hv_fcopy_daemon.c | 1 +
1 file changed, 1 insertion(+)
On Tue, Sep 04, 2018 at 11:45:02PM +0800, Pu Wen wrote:
> I add these definitions to indicate that there are Hygon PCI device IDs.
> You are right, I can just use the AMD f17h ones here.
Right, if this is a small piece where they're all together in a single
compilation unit - like in this case -
On Tue, Sep 04, 2018 at 11:45:02PM +0800, Pu Wen wrote:
> I add these definitions to indicate that there are Hygon PCI device IDs.
> You are right, I can just use the AMD f17h ones here.
Right, if this is a small piece where they're all together in a single
compilation unit - like in this case -
On 09/04/2018 10:56 AM, Mark Brown wrote:
> On Tue, Sep 04, 2018 at 10:10:24AM -0500, Andrew F. Davis wrote:
>> On 09/04/2018 09:55 AM, Mark Brown wrote:
>
>>> you get to keep the pieces" territory. If we really want to have a way
>>> of explicitly specifying that some widgets should never be
On 09/04/2018 10:56 AM, Mark Brown wrote:
> On Tue, Sep 04, 2018 at 10:10:24AM -0500, Andrew F. Davis wrote:
>> On 09/04/2018 09:55 AM, Mark Brown wrote:
>
>>> you get to keep the pieces" territory. If we really want to have a way
>>> of explicitly specifying that some widgets should never be
Hi,
since I had an opportunity to play with RPi3B+ recently, I took a look
at the existing bcm2835-audio driver code and was amused very much :)
So here is the result, a cleanup and fix patch series.
Most of the patches are trivial cleanups, just brushing up, removing
many redundant and buggy
Hi,
since I had an opportunity to play with RPi3B+ recently, I took a look
at the existing bcm2835-audio driver code and was amused very much :)
So here is the result, a cleanup and fix patch series.
Most of the patches are trivial cleanups, just brushing up, removing
many redundant and buggy
The "IEC958 Playback Stream" control does basically the very same
thing as "IEC958 Playback Default" redundantly. The former should
have been stream-specific and restored after closing the stream, but
we don't do in that way.
Since it's nothing but confusion, remove this fake.
Signed-off-by:
The "IEC958 Playback Stream" control does basically the very same
thing as "IEC958 Playback Default" redundantly. The former should
have been stream-specific and restored after closing the stream, but
we don't do in that way.
Since it's nothing but confusion, remove this fake.
Signed-off-by:
Only a few of them are really needed.
Signed-off-by: Takashi Iwai
---
.../vc04_services/bcm2835-audio/bcm2835-ctl.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
The handling of SNDRV_PCM_TRIGGER_STOP at the trigger callback is
incorrect: when the STOP is issued, the driver is supposed to drop the
stream immediately. Meanwhile bcm2835 driver checks the DRAINING
state and tries to issue some different command.
This patch straightens things a bit, dropping
snd-bcm2835 driver takes the lock with mutex_lock_interruptible() in
all places, which don't make sense. Replace them with the simple
mutex_lock().
Also taking a mutex lock right after creating it for each PCM object
is nonsense, too. It cannot be racy at that point. We can get rid of
it.
Only a few of them are really needed.
Signed-off-by: Takashi Iwai
---
.../vc04_services/bcm2835-audio/bcm2835-ctl.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
401 - 500 of 1168 matches
Mail list logo
