On Tue, Jun 26, 2018 at 2:06 AM, Shakeel Butt wrote:
> A lot of memory can be consumed by the events generated for the huge or
> unlimited queues if there is either no or slow listener. This can cause
> system level memory pressure or OOMs. So, it's better to account the
> fsnotify kmem caches
On Tue, Jun 26, 2018 at 2:06 AM, Shakeel Butt wrote:
> A lot of memory can be consumed by the events generated for the huge or
> unlimited queues if there is either no or slow listener. This can cause
> system level memory pressure or OOMs. So, it's better to account the
> fsnotify kmem caches
this for awhile and then determining I REALLY did not
want to think about it as my brain was getting tied into a gordian knot.
{^_^}
On 20180625 19:23, Michael Schmitz wrote:
Joanne,
Martin's boot log (including your patch) says:
Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512
this for awhile and then determining I REALLY did not
want to think about it as my brain was getting tied into a gordian knot.
{^_^}
On 20180625 19:23, Michael Schmitz wrote:
Joanne,
Martin's boot log (including your patch) says:
Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512
Hi Matthias,
On 2018-06-26 05:35, Matthias Kaehlcke wrote:
On Mon, Jun 25, 2018 at 04:43:54PM -0700, Matthias Kaehlcke wrote:
This is a nice improvement, a few remaining questions inline.
On Mon, Jun 25, 2018 at 07:10:10PM +0530, Balakrishna Godavarthi
wrote:
> In function qca_setup, we set
Hi Matthias,
On 2018-06-26 05:35, Matthias Kaehlcke wrote:
On Mon, Jun 25, 2018 at 04:43:54PM -0700, Matthias Kaehlcke wrote:
This is a nice improvement, a few remaining questions inline.
On Mon, Jun 25, 2018 at 07:10:10PM +0530, Balakrishna Godavarthi
wrote:
> In function qca_setup, we set
Hi Pavel,
On 25 June 2018 at 20:18, Pavel Machek wrote:
> On Mon 2018-06-25 13:03:19, Baolin Wang wrote:
>> From: Bjorn Andersson
>>
>> Some LED controllers have support for autonomously controlling
>> brightness over time, according to some preprogrammed pattern or
>> function.
>>
>> This adds
On (06/26/18 07:03), Dmitry Vyukov wrote:
> > I don't think this is a printk() issue per se, so I think Option B is
> > the only option. You should not get stuck in an infinite loop if we run
> > short on memory. Perhaps we could have an Option C which would exit
> > this loop gracefully with some
Hi Pavel,
On 25 June 2018 at 20:18, Pavel Machek wrote:
> On Mon 2018-06-25 13:03:19, Baolin Wang wrote:
>> From: Bjorn Andersson
>>
>> Some LED controllers have support for autonomously controlling
>> brightness over time, according to some preprogrammed pattern or
>> function.
>>
>> This adds
On (06/26/18 07:03), Dmitry Vyukov wrote:
> > I don't think this is a printk() issue per se, so I think Option B is
> > the only option. You should not get stuck in an infinite loop if we run
> > short on memory. Perhaps we could have an Option C which would exit
> > this loop gracefully with some
> Subject: Re: [Patch v2 14/15] CIFS: Add support for direct I/O write
>
> On 5/30/2018 3:48 PM, Long Li wrote:
> > From: Long Li
> >
> > Implement the function for direct I/O write. It doesn't support AIO,
> > which will be implemented in a follow up patch.
> >
> > Signed-off-by: Long Li
> >
> Subject: Re: [Patch v2 14/15] CIFS: Add support for direct I/O write
>
> On 5/30/2018 3:48 PM, Long Li wrote:
> > From: Long Li
> >
> > Implement the function for direct I/O write. It doesn't support AIO,
> > which will be implemented in a follow up patch.
> >
> > Signed-off-by: Long Li
> >
> Subject: Re: [Patch v2 13/15] CIFS: Add support for direct I/O read
>
>
>
> On 5/30/2018 3:48 PM, Long Li wrote:
> > From: Long Li
> >
> > Implement the function for direct I/O read. It doesn't support AIO,
> > which will be implemented in a follow up patch.
> >
> > Signed-off-by: Long Li
>
> Subject: Re: [Patch v2 13/15] CIFS: Add support for direct I/O read
>
>
>
> On 5/30/2018 3:48 PM, Long Li wrote:
> > From: Long Li
> >
> > Implement the function for direct I/O read. It doesn't support AIO,
> > which will be implemented in a follow up patch.
> >
> > Signed-off-by: Long Li
>
Hi all,
Changes since 20180625:
The cifs tree lost its build failure.
The drm tree still had its build failure for which I disabled some
sample code.
The nvdimm tree gained a conflict against the tip tree.
Non-merge commits (relative to Linus' tree): 2240
2288 files changed, 72718 insertions
Hi all,
Changes since 20180625:
The cifs tree lost its build failure.
The drm tree still had its build failure for which I disabled some
sample code.
The nvdimm tree gained a conflict against the tip tree.
Non-merge commits (relative to Linus' tree): 2240
2288 files changed, 72718 insertions
> Subject: Re: [Patch v2 11/15] CIFS: Pass page offset for calculating signature
>
> On 5/30/2018 3:48 PM, Long Li wrote:
> > From: Long Li
> >
> > When calculating signature for the packet, it needs to read into the
> > correct page offset for the data.
> >
> > Signed-off-by: Long Li
> > ---
>
> Subject: Re: [Patch v2 11/15] CIFS: Pass page offset for calculating signature
>
> On 5/30/2018 3:48 PM, Long Li wrote:
> > From: Long Li
> >
> > When calculating signature for the packet, it needs to read into the
> > correct page offset for the data.
> >
> > Signed-off-by: Long Li
> > ---
>
On Tue, Jun 26, 2018 at 11:46:35AM +0800, Wei Wang wrote:
> On 06/26/2018 09:37 AM, Michael S. Tsirkin wrote:
> > On Mon, Jun 25, 2018 at 08:05:10PM +0800, Wei Wang wrote:
> >
> > > @@ -326,17 +353,6 @@ static void stats_handle_request(struct
> > > virtio_balloon *vb)
> > >
On Tue, Jun 26, 2018 at 11:46:35AM +0800, Wei Wang wrote:
> On 06/26/2018 09:37 AM, Michael S. Tsirkin wrote:
> > On Mon, Jun 25, 2018 at 08:05:10PM +0800, Wei Wang wrote:
> >
> > > @@ -326,17 +353,6 @@ static void stats_handle_request(struct
> > > virtio_balloon *vb)
> > >
On Mon, Jun 25, 2018 at 08:50:26PM +0100, John Whitmore wrote:
> On Mon, Jun 25, 2018 at 02:05:04PM +0100, Justin Skists wrote:
> >
> > > On 25 June 2018 at 13:36 John Whitmore wrote:
> > >
> > >
> > > On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote:
> > > > On Sun, Jun 24,
On Mon, Jun 25, 2018 at 08:50:26PM +0100, John Whitmore wrote:
> On Mon, Jun 25, 2018 at 02:05:04PM +0100, Justin Skists wrote:
> >
> > > On 25 June 2018 at 13:36 John Whitmore wrote:
> > >
> > >
> > > On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote:
> > > > On Sun, Jun 24,
On Sun, Jun 24, 2018 at 04:34:51PM +0100, John Whitmore wrote:
> Changed a number of hard coded function names to use %s and __func__
>
> Mailing list response suggest that there is a better method for debugging
> using netdev_dbg(). I can't argue with that, but for the moment this change
> will
On Sun, Jun 24, 2018 at 04:34:51PM +0100, John Whitmore wrote:
> Changed a number of hard coded function names to use %s and __func__
>
> Mailing list response suggest that there is a better method for debugging
> using netdev_dbg(). I can't argue with that, but for the moment this change
> will
We are taking a look at this - Ronnie had some ideas. Probably simply
not implemented - hopefully not too hard to fix.
On Mon, Jun 25, 2018 at 6:58 PM Laura Abbott wrote:
>
> Hi,
>
> A while back, someone reported a failure on Fedora when trying to boot
> a QEMU image off of a CIFS share. The
We are taking a look at this - Ronnie had some ideas. Probably simply
not implemented - hopefully not too hard to fix.
On Mon, Jun 25, 2018 at 6:58 PM Laura Abbott wrote:
>
> Hi,
>
> A while back, someone reported a failure on Fedora when trying to boot
> a QEMU image off of a CIFS share. The
KVM is supposed to update some guest VM's CPUID bits (e.g. OSXSAVE) when
CR4 is changed. A bug was found in KVM recently and it was fixed by
Commit c4d2188206ba ("KVM: x86: Update cpuid properly when CR4.OSXAVE or
CR4.PKE is changed"). This patch adds a test to verify the synchronization
between
KVM is supposed to update some guest VM's CPUID bits (e.g. OSXSAVE) when
CR4 is changed. A bug was found in KVM recently and it was fixed by
Commit c4d2188206ba ("KVM: x86: Update cpuid properly when CR4.OSXAVE or
CR4.PKE is changed"). This patch adds a test to verify the synchronization
between
HI folks,
I've come across a strange problem recently when doing some MPI
based CPU+IO load test simulations recently. I've been running them
on the same machine I use to host all my filesystem test VMs
(16p/32t, 64GB RAM) which is currently running 4.16.12. Both the
MPI job context and the qemu
HI folks,
I've come across a strange problem recently when doing some MPI
based CPU+IO load test simulations recently. I've been running them
on the same machine I use to host all my filesystem test VMs
(16p/32t, 64GB RAM) which is currently running 4.16.12. Both the
MPI job context and the qemu
On 6/14/2018 12:26 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 6:45 PM, Stuart Hayes
> wrote:
>>
>> If the WSMT ACPI table is present and indicates that a fixed communication
>> buffer should be used, use the firmware-specified buffer instead of
>> allocating a buffer in memory for
On 6/14/2018 12:26 PM, Andy Shevchenko wrote:
> On Thu, Jun 14, 2018 at 6:45 PM, Stuart Hayes
> wrote:
>>
>> If the WSMT ACPI table is present and indicates that a fixed communication
>> buffer should be used, use the firmware-specified buffer instead of
>> allocating a buffer in memory for
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit
Acked-by: Michael Ellerman
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc:
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit
Acked-by: Michael Ellerman
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc:
Remove the dance around old and new attributes. Just don't modify the
previous breakpoint at all until we have verified everything.
Reported-by: Linus Torvalds
Original-patch-by: Andy Lutomirski
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc:
This field seem to be unused, perhaps a leftover from old code...
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Mark Rutland
Cc: Max Filippov
Cc: Chris Zankel
Cc:
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will
We soon won't be able to rely on bp->attr anymore to get the new
type of the modifying breakpoint because the new attributes are going
to be copied only once we successfully modified the breakpoint slot.
This will fix the current misdesigned layout where the new attr are
copied to the modifying
Remove the dance around old and new attributes. Just don't modify the
previous breakpoint at all until we have verified everything.
Reported-by: Linus Torvalds
Original-patch-by: Andy Lutomirski
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc:
This field seem to be unused, perhaps a leftover from old code...
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Mark Rutland
Cc: Max Filippov
Cc: Chris Zankel
Cc:
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will
We soon won't be able to rely on bp->attr anymore to get the new
type of the modifying breakpoint because the new attributes are going
to be copied only once we successfully modified the breakpoint slot.
This will fix the current misdesigned layout where the new attr are
copied to the modifying
All architectures have implemented it, we can now remove the poor weak
version.
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Mark Rutland
Cc: Max Filippov
Cc: Chris
All architectures have implemented it, we can now remove the poor weak
version.
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: Mark Rutland
Cc: Max Filippov
Cc: Chris
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit.
Acked-by: Will Deacon
Acked-by: Mark Rutland
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc:
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit.
Acked-by: Will Deacon
Acked-by: Mark Rutland
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc:
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Will
arch_validate_hwbkpt_settings() mixes up attribute check and commit into
a single code entity. Therefore the validation may return an error due to
incorrect atributes while still leaving halfway modified architecture
breakpoint data.
This is harmless when we deal with a new breakpoint but it
We can't pass the breakpoint directly on arch_check_bp_in_kernelspace()
anymore because its architecture internal datas (struct arch_hw_breakpoint)
are not yet filled by the time we call the function, and most
implementation need this backend to be up to date. So arrange the
function to take the
arch_validate_hwbkpt_settings() mixes up attribute check and commit into
a single code entity. Therefore the validation may return an error due to
incorrect atributes while still leaving halfway modified architecture
breakpoint data.
This is harmless when we deal with a new breakpoint but it
We can't pass the breakpoint directly on arch_check_bp_in_kernelspace()
anymore because its architecture internal datas (struct arch_hw_breakpoint)
are not yet filled by the time we call the function, and most
implementation need this backend to be up to date. So arrange the
function to take the
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit.
Acked-by: Mark Rutland
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc:
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit.
Acked-by: Mark Rutland
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo Molnar
Cc:
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit.
Original-patch-by: Andy Lutomirski
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo
Migrate to the new API in order to remove arch_validate_hwbkpt_settings()
that clumsily mixes up architecture validation and commit.
Original-patch-by: Andy Lutomirski
Signed-off-by: Frederic Weisbecker
Cc: Linus Torvalds
Cc: Andy Lutomirski
Cc: Yoshinori Sato
Cc: Rich Felker
Cc: Ingo
Ingo,
Please pull the perf/breakpoint-v4 branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
perf/breakpoint-v4
HEAD: ba25ee9c7b3ef1543c2a24a7ca6a621433803ee4
Only change since v3 is a rebase against latest tip:perf/core
---
When we
Ingo,
Please pull the perf/breakpoint-v4 branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
perf/breakpoint-v4
HEAD: ba25ee9c7b3ef1543c2a24a7ca6a621433803ee4
Only change since v3 is a rebase against latest tip:perf/core
---
When we
2018-06-25 23:55 GMT+09:00 Boris Brezillon :
> On Mon, 25 Jun 2018 09:50:18 -0500
> Dinh Nguyen wrote:
>
>> On 06/22/2018 10:58 AM, Richard Weinberger wrote:
>> > Masahiro,
>> >
>> > Am Freitag, 22. Juni 2018, 16:37:21 CEST schrieb Masahiro Yamada:
>> >> Hi Richard,
>> >>
>> >>
>> >> 2018-06-19
On Wed, Jun 13, 2018 at 02:36:12PM -0500, Eddie James wrote:
> This series adds an algorithm for an I2C master physically located on an FSI
> slave device. The I2C master has multiple ports, each of which may be
> connected
> to an I2C slave. Access to the I2C master registers is achieved over
2018-06-25 23:55 GMT+09:00 Boris Brezillon :
> On Mon, 25 Jun 2018 09:50:18 -0500
> Dinh Nguyen wrote:
>
>> On 06/22/2018 10:58 AM, Richard Weinberger wrote:
>> > Masahiro,
>> >
>> > Am Freitag, 22. Juni 2018, 16:37:21 CEST schrieb Masahiro Yamada:
>> >> Hi Richard,
>> >>
>> >>
>> >> 2018-06-19
On Wed, Jun 13, 2018 at 02:36:12PM -0500, Eddie James wrote:
> This series adds an algorithm for an I2C master physically located on an FSI
> slave device. The I2C master has multiple ports, each of which may be
> connected
> to an I2C slave. Access to the I2C master registers is achieved over
On Wed, Jun 13, 2018 at 02:36:13PM -0500, Eddie James wrote:
> Document the bindings.
>
> Signed-off-by: Eddie James >
Broken email address here. checkpatch warns about it.
On Wed, Jun 13, 2018 at 02:36:13PM -0500, Eddie James wrote:
> Document the bindings.
>
> Signed-off-by: Eddie James >
Broken email address here. checkpatch warns about it.
On Wed, Jun 13, 2018 at 02:36:16PM -0500, Eddie James wrote:
> Add abort procedure for failed transfers. Add engine and bus reset
> procedures to recover from as many faults as possible.
I think this is a way too aggressive recovery. Your are doing the 9
pulse toggles basically on any error while
On Wed, Jun 13, 2018 at 02:36:16PM -0500, Eddie James wrote:
> Add abort procedure for failed transfers. Add engine and bus reset
> procedures to recover from as many faults as possible.
I think this is a way too aggressive recovery. Your are doing the 9
pulse toggles basically on any error while
On Wed, Jun 13, 2018 at 02:36:19PM -0500, Eddie James wrote:
> Bus recovery should reset the engine and force clock the bus 9 times
> to recover most situations.
>
> Signed-off-by: Eddie James
> ---
> drivers/i2c/busses/i2c-fsi.c | 19 +++
> 1 file changed, 19 insertions(+)
>
>
On Wed, Jun 13, 2018 at 02:36:19PM -0500, Eddie James wrote:
> Bus recovery should reset the engine and force clock the bus 9 times
> to recover most situations.
>
> Signed-off-by: Eddie James
> ---
> drivers/i2c/busses/i2c-fsi.c | 19 +++
> 1 file changed, 19 insertions(+)
>
>
On Wed, Jun 13, 2018 at 02:36:17PM -0500, Eddie James wrote:
> Execute I2C transfers from the FSI-attached I2C master. Use polling
> instead of interrupts as we have no hardware IRQ over FSI.
>
> Signed-off-by: Eddie James
> ---
> drivers/i2c/busses/i2c-fsi.c | 195
>
On Wed, Jun 20, 2018 at 07:17:53AM +0200, Peter Rosin wrote:
> Hi!
>
> With the introduction of mux-locked I2C muxes, the concept of
> locking only a segment of the I2C adapter tree was added. At the
> time, I did not want to cause a lot of extra churn, so left most
> users of i2c_lock_adapter
> This is not perfectly equivalent, since i2c_smbus_xfer was callable from
> atomic/irq context if you happened to end up emulating SMBus with an I2C
> transfer, and that is no longer the case with this patch. It is unknown
> (to me) if anything depends on that quirk, but it seems fragile enough
On Wed, Jun 13, 2018 at 02:36:17PM -0500, Eddie James wrote:
> Execute I2C transfers from the FSI-attached I2C master. Use polling
> instead of interrupts as we have no hardware IRQ over FSI.
>
> Signed-off-by: Eddie James
> ---
> drivers/i2c/busses/i2c-fsi.c | 195
>
On Wed, Jun 20, 2018 at 07:17:53AM +0200, Peter Rosin wrote:
> Hi!
>
> With the introduction of mux-locked I2C muxes, the concept of
> locking only a segment of the I2C adapter tree was added. At the
> time, I did not want to cause a lot of extra churn, so left most
> users of i2c_lock_adapter
> This is not perfectly equivalent, since i2c_smbus_xfer was callable from
> atomic/irq context if you happened to end up emulating SMBus with an I2C
> transfer, and that is no longer the case with this patch. It is unknown
> (to me) if anything depends on that quirk, but it seems fragile enough
On Wed, Jun 20, 2018 at 11:43:23AM +0200, Peter Rosin wrote:
> If DMA safe memory was allocated, but the subsequent I2C transfer
> fails the memory is leaked. Plug this leak.
>
> Fixes: 8a77821e74d6 ("i2c: smbus: use DMA safe buffers for emulated SMBus
> transactions")
> Signed-off-by: Peter
On Wed, Jun 20, 2018 at 11:43:23AM +0200, Peter Rosin wrote:
> If DMA safe memory was allocated, but the subsequent I2C transfer
> fails the memory is leaked. Plug this leak.
>
> Fixes: 8a77821e74d6 ("i2c: smbus: use DMA safe buffers for emulated SMBus
> transactions")
> Signed-off-by: Peter
Joanne,
Martin's boot log (including your patch) says:
Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512) sdb1
(LNX^@)(res 2 spb 1) sdb2 (JXF^D)(res 2 spb 1) sdb3 (DOS^C)(res 2 spb
4)
Jun 19 21:19:09 merkaba kernel: [ 7891.844055] sd 7:0:0:0: [sdb]
Attached SCSI disk
so it's indeed
Joanne,
Martin's boot log (including your patch) says:
Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512) sdb1
(LNX^@)(res 2 spb 1) sdb2 (JXF^D)(res 2 spb 1) sdb3 (DOS^C)(res 2 spb
4)
Jun 19 21:19:09 merkaba kernel: [ 7891.844055] sd 7:0:0:0: [sdb]
Attached SCSI disk
so it's indeed
On Mon 25 Jun 18:34 PDT 2018, Alex Elder wrote:
> From: Bjorn Andersson
>
> "start" and "stop" are more suitable names for how these two operations
> are used, and they fit better with the upcoming introduction of two
> additional operations in the struct.
>
> [el...@linaro.org: minor comment
On Mon 25 Jun 18:34 PDT 2018, Alex Elder wrote:
> From: Bjorn Andersson
>
> "start" and "stop" are more suitable names for how these two operations
> are used, and they fit better with the upcoming introduction of two
> additional operations in the struct.
>
> [el...@linaro.org: minor comment
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
arch/x86/kernel/cpu/mcheck/mce.c
between commit:
d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
from the tip tree and commit:
f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
from
Hi all,
Today's linux-next merge of the nvdimm tree got a conflict in:
arch/x86/kernel/cpu/mcheck/mce.c
between commit:
d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
from the tip tree and commit:
f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
from
On Mon 25 Jun 18:32 PDT 2018, Alex Elder wrote:
> On 05/29/2018 06:53 AM, Alex Elder wrote:
> > On 05/29/2018 04:12 AM, Arnaud Pouliquen wrote:
> >> Hello Alex
> >>
> >>
> >> We have the same needs (prepare unprepare steps) on our platform. We
> >> tested you core patches and they answers to our
On Mon 25 Jun 18:32 PDT 2018, Alex Elder wrote:
> On 05/29/2018 06:53 AM, Alex Elder wrote:
> > On 05/29/2018 04:12 AM, Arnaud Pouliquen wrote:
> >> Hello Alex
> >>
> >>
> >> We have the same needs (prepare unprepare steps) on our platform. We
> >> tested you core patches and they answers to our
Hi John,
On 26 June 2018 at 01:23, John Stultz wrote:
> On Sat, Jun 23, 2018 at 5:14 PM, Thomas Gleixner wrote:
>> On Wed, 13 Jun 2018, Baolin Wang wrote:
>>> Moreover we can register the clocksource with CLOCK_SOURCE_SUSPEND_NONSTOP
>>> to be one persistent clock, then we can simplify the
Hi John,
On 26 June 2018 at 01:23, John Stultz wrote:
> On Sat, Jun 23, 2018 at 5:14 PM, Thomas Gleixner wrote:
>> On Wed, 13 Jun 2018, Baolin Wang wrote:
>>> Moreover we can register the clocksource with CLOCK_SOURCE_SUSPEND_NONSTOP
>>> to be one persistent clock, then we can simplify the
Hi Thomas,
On 24 June 2018 at 08:14, Thomas Gleixner wrote:
> On Wed, 13 Jun 2018, Baolin Wang wrote:
>> Moreover we can register the clocksource with CLOCK_SOURCE_SUSPEND_NONSTOP
>> to be one persistent clock, then we can simplify the suspend/resume
>> accounting by removing
Hi Thomas,
On 24 June 2018 at 08:14, Thomas Gleixner wrote:
> On Wed, 13 Jun 2018, Baolin Wang wrote:
>> Moreover we can register the clocksource with CLOCK_SOURCE_SUSPEND_NONSTOP
>> to be one persistent clock, then we can simplify the suspend/resume
>> accounting by removing
This adds dt-binding documentation for Mediatek MT6765. Only
include very basic items, gic, uart timer and cpu.
Signed-off-by: Mars Cheng
---
Documentation/devicetree/bindings/arm/mediatek.txt |4
.../interrupt-controller/mediatek,sysirq.txt |1 +
This adds dt-binding documentation for Mediatek MT6765. Only
include very basic items, gic, uart timer and cpu.
Signed-off-by: Mars Cheng
---
Documentation/devicetree/bindings/arm/mediatek.txt |4
.../interrupt-controller/mediatek,sysirq.txt |1 +
This adds basic chip support for MT6765 SoC.
Signed-off-by: Mars Cheng
---
arch/arm64/boot/dts/mediatek/Makefile |1 +
arch/arm64/boot/dts/mediatek/mt6765-evb.dts | 33 ++
arch/arm64/boot/dts/mediatek/mt6765.dtsi| 158 +++
3 files changed, 192
This patch adds basic SoC support for Mediatek's new 8-core SoC,
MT6765, which is mainly for smartphone application.
Change in V2:
1. fix clk properties in uart dts node
2. fix typo in submit title
3. add simple-bus in mt6765.dtsi
4. use correct SPDX license format
Mars Cheng (2):
This adds basic chip support for MT6765 SoC.
Signed-off-by: Mars Cheng
---
arch/arm64/boot/dts/mediatek/Makefile |1 +
arch/arm64/boot/dts/mediatek/mt6765-evb.dts | 33 ++
arch/arm64/boot/dts/mediatek/mt6765.dtsi| 158 +++
3 files changed, 192
This patch adds basic SoC support for Mediatek's new 8-core SoC,
MT6765, which is mainly for smartphone application.
Change in V2:
1. fix clk properties in uart dts node
2. fix typo in submit title
3. add simple-bus in mt6765.dtsi
4. use correct SPDX license format
Mars Cheng (2):
> On Jun 25, 2018, at 6:32 PM, Tycho Andersen wrote:
>
>> On Sat, Jun 23, 2018 at 12:27:43AM +0200, Jann Horn wrote:
>>> On Fri, Jun 22, 2018 at 11:51 PM Kees Cook wrote:
>>>
On Fri, Jun 22, 2018 at 11:09 AM, Andy Lutomirski
wrote:
One possible extra issue: IIRC
> On Jun 25, 2018, at 6:32 PM, Tycho Andersen wrote:
>
>> On Sat, Jun 23, 2018 at 12:27:43AM +0200, Jann Horn wrote:
>>> On Fri, Jun 22, 2018 at 11:51 PM Kees Cook wrote:
>>>
On Fri, Jun 22, 2018 at 11:09 AM, Andy Lutomirski
wrote:
One possible extra issue: IIRC
The SDCLK was named SDCLKCLK, and no one has used this yet.
Fix it.
Signed-off-by: Lei YU
---
drivers/clk/clk-aspeed.c | 2 +-
include/dt-bindings/clock/aspeed-clock.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-aspeed.c
The SDCLK was named SDCLKCLK, and no one has used this yet.
Fix it.
Signed-off-by: Lei YU
---
drivers/clk/clk-aspeed.c | 2 +-
include/dt-bindings/clock/aspeed-clock.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-aspeed.c
From: Bjorn Andersson
"start" and "stop" are more suitable names for how these two operations
are used, and they fit better with the upcoming introduction of two
additional operations in the struct.
[el...@linaro.org: minor comment edits]
Signed-off-by: Bjorn Andersson
Acked-by: Alex Elder
From: Bjorn Andersson
"start" and "stop" are more suitable names for how these two operations
are used, and they fit better with the upcoming introduction of two
additional operations in the struct.
[el...@linaro.org: minor comment edits]
Signed-off-by: Bjorn Andersson
Acked-by: Alex Elder
1 - 100 of 1596 matches
Mail list logo
