On Thu, Feb 14, 2019 at 04:59:04PM -0800, Andrey Smirnov wrote:
[...]
> Lorenzo, can you apply the dwc specific patches that are already
> reviewed by Gustavo Pimentel from this series, to keep things moving
> while we are waiting on Lucas? I can also spin them out into a
> separate series if tha
On 19-02-19, 17:49, Baolin Wang wrote:
> Hi Geert,
>
> On Tue, 19 Feb 2019 at 17:30, Geert Uytterhoeven wrote:
> >
> > Hi Baolin,
> >
> > On Tue, Feb 19, 2019 at 4:15 AM Baolin Wang wrote:
> > > On Mon, 18 Feb 2019 at 20:23, Arnd Bergmann wrote:
> > > > On Mon, Feb 18, 2019 at 11:52 AM Baolin W
On Tue, Feb 19, 2019 at 08:59:45AM +0800, Wei Yang wrote:
> On Mon, Feb 18, 2019 at 03:54:42PM +0800, kernel test robot wrote:
> >Greeting,
> >
> >FYI, we noticed a -12.2% regression of will-it-scale.per_thread_ops due to
> >commit:
> >
> >
> >commit: 570d0200123fb4f809aa2f6226e93a458d664d70 ("dri
BCM63XX (MIPS) does not use device tree, so there cannot be any
of_device_id, causing the driver to fail on probe:
[0.904564] bcm2835-rng: probe of bcm63xx-rng failed with error -22
Fix this by checking for match data only if we are probing from device
tree.
Fixes: 8705f24f7b57 ("hwrng: bcm2
The result of the bisection is
[88dbcbb3a4847f5e6dfeae952d3105497700c128] blkdev: avoid migration stalls for
blkdev pages
Is that result relevant for the problem or should I continue bisecting between
4.20.0 and the so far first bad commit?
Can you try reverting the commit and see if it makes
On 14-02-19, 10:44, Long Cheng wrote:
> On Mon, 2019-02-04 at 12:51 +0530, Vinod Koul wrote:
> > > +static int mtk_uart_apdma_device_pause(struct dma_chan *chan)
> > > +{
> > > + /* just for check caps pass */
> > > + return 0;
> > > +}
> >
> > please remove, this is not a mandatory fn
>
> Can't
From: Colin Ian King
Currently when the call to of_get_drm_display_mode fails the error return
path does not free an earlier allocated struct drm_display_mode, causing
a memory leak. Fix this by kfree'ing mode before returning.
Fixes: 76ecd9c9fb24 ("drm/imx: parallel-display: check return code f
On Mon, 18 Feb 2019 at 23:09, Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> Commit 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage
> counter imbalance") introduced a regression that causes suppliers
> to be suspended prematurely for device links added during consumer
> drive
On Tue, Feb 19, 2019 at 12:38:42PM +0100, Thomas Gleixner wrote:
> On Tue, 19 Feb 2019, Peter Zijlstra wrote:
>
> > On Tue, Feb 19, 2019 at 10:04:09AM +0100, Peter Zijlstra wrote:
> > > > Does that make more sense?
> > >
> > > It appears to me you're going about it backwards.
> >
> > So how abou
In ACPI, and now also in DT, the USB connectors usually have
their own device nodes. In case of USB Type-C, those
connector (port) nodes are child nodes of the controller or
PHY device, in our case the fusb302. The software fwnodes
allow us to create a similar child node for fusb302 that
represents
On 2019/2/19 18:35, Jarkko Sakkinen wrote:
> On Tue, Feb 19, 2019 at 05:15:47PM +0800, YueHaibing wrote:
>> On 2019/2/19 16:59, Jarkko Sakkinen wrote:
>>> On Tue, Feb 19, 2019 at 03:26:18PM +0800, YueHaibing wrote:
calc_tpm2_event_size return size of the event which type is
size_t, If it
On Mon, 18 Feb 2019 at 17:01, Kamil Konieczny
wrote:
>
> Fix bug "s5p-sss crypto driver doesn't set next AES-CBC IV". This should
> also fix AES-CTR mode. Tested on Odroid U3 with Eric Biggers branch
> "iv-out-testing".
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/crypto/s5p-sss.c | 8
Replace hard coded AES block size with define.
Signed-off-by: Krzysztof Kozlowski
---
drivers/crypto/s5p-sss.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 0064be0e3941..39fc6942364b 100644
--- a/drivers/crypt
On Mon, Feb 18, 2019 at 11:49:18AM +1100, Michael Ellerman wrote:
> Balbir Singh writes:
> > On Sun, Feb 17, 2019 at 07:34:20PM +1100, Michael Ellerman wrote:
> >> Balbir Singh writes:
> >> > On Sat, Feb 16, 2019 at 08:22:12AM -0600, Segher Boessenkool wrote:
> >> >> On Sat, Feb 16, 2019 at 09:55
Hi guys,
The software nodes support node hierarchy. By using them with fusb302
we can add a separate fwnode also for the USB connector as a child of
fusb302. We can then use the "standard" USB connector device
properties with the connector node, and stop using the deprecated
fusb302 specific prope
Creating a software node for max17047 when ACPI tables don't
have a device node for it.
While here, moving max17047 handling to its own function.
Signed-off-by: Heikki Krogerus
---
drivers/platform/x86/intel_cht_int33fe.c | 86 +++-
1 file changed, 53 insertions(+), 33 delet
On Tue, Feb 19, 2019 at 11:35:08AM +0100, Jiri Pirko wrote:
> >- some features provided by ethtool would rather belong to devlink (and
> > some are already superseded by devlink); however, only few drivers
> > provide devlink interface at the moment and as recent discussion on
> > flashing revea
pstore_blk is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_blk?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fact, there is already a sample
The document, at Documentation/admin-guide/pstore-block.rst,
tells user how to use pstore_blk and the attentions about panic
read/write
Signed-off-by: liaoweixiong
---
Documentation/admin-guide/pstore-block.rst | 233 +
MAINTAINERS| 1
To enable pmsg, just set pmsg_size when block device register blkzone.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 21
fs/pstore/blkoops.c| 11 ++
fs/pstore/blkzone.c| 254 +
include/linux/pstore_blk.h | 1 +
4
blkoops is a sample for pstore/blk. It can only record oops, excluding
panics as no read/write apis for panic registered. It support settings
on Kconfg/device tree/module parameters. It can record oops log even
power failure if "PSTORE_BLKOOPS_BLKDEV" on Kconfig or "block-device"
on dts or "blkdev"
Create DT binding document for blkoops.
Signed-off-by: liaoweixiong
---
.../devicetree/bindings/pstore/blkoops.txt | 53 ++
MAINTAINERS| 1 +
2 files changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindin
Why should we need pstore_block?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have b
The patch
regulator: stpmic1: Add active discharge support
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 hours)
The patch
regulator: stpmic1: Use regulator mode definition from bindings
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
The patch
dt-bindings: regulator: Add active discharge support for stpmic1
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 th
The patch
dt-bindings: regulator: remove interrupt-parent description on stpmic1
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
The patch
regulator: stpmic1: Simplify regulators registration
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 ho
The patch
regulator: stpmic1: Change buck1 voltage range
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 hours) a
The patch
SoC: imx-sgtl5000: add missing put_device()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to L
The patch
dt-bindings: regulator: remove regulator pull-down support for stpmic1
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
The patch
regulator: stpmic1: Remove support for regulator pull down
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
The patch
regulator: core: Drop lockdep annotation in drms_uA_update()
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 ne
On Mon, 18 Feb 2019 23:07:23 +0100
Jann Horn wrote:
> The first version of this method was missing the check for
> `ret == PATH_MAX`; then such a check was added, but it didn't call kfree()
> on error, so there was still a small memory leak in the error case.
> Fix it by using strndup_user() inst
> Avri,
>
> > Is there any reason why this sires is not applied for 5.1?
>
> I haven't had time to review it yet. I'll get there...
A kind reminder.
Thanks,
Avri
>
> --
> Martin K. PetersenOracle Linux Engineering
From: Colin Ian King
There is a null check on the pointer bh to avoid a null pointer dereference
on bh->b_data however later bh is passed to mark_buffer_dirty that can also
cause a null pointer dereference on bh. Avoid this potential null pointer
dereference by moving the call to mark_buffer_dir
DT documentation for SPI controller added.
Signed-off-by: Palmer Dabbelt
Signed-off-by: Emil Renner Berthing
Signed-off-by: Yash Shah
---
.../devicetree/bindings/spi/spi-sifive.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetre
Add driver for the SiFive SPI controller
on the HiFive Unleashed board.
Signed-off-by: Palmer Dabbelt
Signed-off-by: Emil Renner Berthing
Signed-off-by: Yash Shah
---
drivers/spi/Kconfig | 6 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-sifive.c | 450
This patch series adds a SPI driver and DT documentation
for HiFive Unleashed board.
Yash Shah (2):
spi: sifive: Add DT documentation for SiFive SPI controller
spi: sifive: Add driver for the SiFive SPI controller
.../devicetree/bindings/spi/spi-sifive.txt | 37 ++
drivers/spi/Kconf
On Tue, 19 Feb 2019, Peter Zijlstra wrote:
> On Tue, Feb 19, 2019 at 10:04:09AM +0100, Peter Zijlstra wrote:
> > > Does that make more sense?
> >
> > It appears to me you're going about it backwards.
>
> So how about you do a GCC plugin that verifies limits on code-gen
> between user_access_begi
On Tue, Feb 19, 2019 at 12:31:50PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni
> wrote:
> > On Mon, 18 Feb 2019 21:37:25 +0100
> > Arnd Bergmann wrote:
> >
> > > Ah, it seems we actually do that on 32-bit ARM, at least on one platform,
> > > see 6a02734d420f ("
On Tue, Feb 19, 2019 at 11:24:00AM +0100, Jiri Pirko wrote:
> Mon, Feb 18, 2019 at 07:22:24PM CET, mkube...@suse.cz wrote:
> >Add information about permanent hadware address of a device (as provided by
> >ETHTOOL_GPERMADDR ioctl command) in GET_INFO reply if ETH_INFO_IM_PERMADDR
> >flag is set in t
On Tue, 19 Feb 2019 at 12:19, Greg KH wrote:
>
> On Tue, Feb 19, 2019 at 11:35:12AM +0100, Ard Biesheuvel wrote:
> > On Fri, 15 Feb 2019 at 20:45, Ard Biesheuvel
> > wrote:
> > >
> > > On Fri, 15 Feb 2019 at 20:43, Nick Desaulniers
> > > wrote:
> > > >
> > > > On Fri, Feb 15, 2019 at 11:28 AM
Hi Thomas,
On Tue, Feb 19, 2019 at 11:27:47AM +0100, Thomas Petazzoni wrote:
> On Mon, 18 Feb 2019 21:37:25 +0100
> Arnd Bergmann wrote:
>
> > > > I would say we should strengthen the behavior of outX() where possible.
> > > > I don't know if arm64 actually has a way of doing that, my understand
On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni
wrote:
> On Mon, 18 Feb 2019 21:37:25 +0100
> Arnd Bergmann wrote:
>
> > Ah, it seems we actually do that on 32-bit ARM, at least on one platform,
> > see 6a02734d420f ("ARM: mvebu: map PCI I/O regions strongly ordered")
> > and prior commits.
>
>
On 19/02/2019 01:34, Chen Yu wrote:
[...]
> This patch set based on Heikki Krogerus's patches.
> Have you applied https://do-db2.lkml.org/lkml/2019/2/13/106 first?
> And these configs should be set to y:
> CONFIG_TYPEC
> CONFIG_TYPEC_TCPM
> CONFIG_TYPEC_TCPCI
> CONFIG_TYPEC_
On Tue, Jan 22, 2019 at 02:33:27PM +0800, Xiaowei Bao wrote:
> Add the PCIe EP mode support for layerscape platform.
>
> Signed-off-by: Xiaowei Bao
> Reviewed-by: Minghuan Lian
> Reviewed-by: Zhiqiang Hou
> Reviewed-by: Kishon Vijay Abraham I
> ---
> depends on: https://patchwork.kernel.org/pr
Hi David,
On Mon, Feb 18, 2019 at 03:33:10PM -0800, David Miller wrote:
> From: Vadim Lomovtsev
> Date: Mon, 18 Feb 2019 09:52:14 +
>
> > @@ -169,6 +169,20 @@ static int nicvf_check_pf_ready(struct nicvf *nic)
> > return 1;
> > }
> >
> > +static int nicvf_send_cfg_done(struct nicvf *n
On Tue, Feb 19, 2019 at 11:35:12AM +0100, Ard Biesheuvel wrote:
> On Fri, 15 Feb 2019 at 20:45, Ard Biesheuvel
> wrote:
> >
> > On Fri, 15 Feb 2019 at 20:43, Nick Desaulniers
> > wrote:
> > >
> > > On Fri, Feb 15, 2019 at 11:28 AM Ard Biesheuvel
> > > wrote:
> > > >
> > > > On Fri, 15 Feb 2019
> I'm not sending a pull request for this if it breaks any architectures,
> so I think we need to fix them all, and I suppose we also have to
> change all architectures in the same patch that changes the architecture
> independent declaration, so it doesn't break intermittently.
>
> At this point,
On Mon, Feb 18, 2019 at 09:16:03PM -0800, Bjorn Andersson wrote:
> On Wed 13 Feb 07:23 PST 2019, Lorenzo Pieralisi wrote:
>
> > On Fri, Jan 25, 2019 at 03:26:16PM -0800, Bjorn Andersson wrote:
> > > Acquiring the reset GPIO low means that reset is being deasserted, this
> > > is followed almost im
On Mon, Feb 18, 2019 at 05:01:59PM +, Robin Murphy wrote:
> On 18/02/2019 14:37, Stanislaw Gruszka wrote:
> [...]
> >Another issue is that dma_map_sg() & dma_map_page() may require some
> >constraints. I'm not sure about that and I want to clarify that with
> >CCed mm maintainers. I think DMA d
On Tue, Feb 19, 2019 at 5:07 AM Sergey Senozhatsky
wrote:
> Suppose, in my driver I want to sprintf() IPv4 address. The longest
> possible address is 3 * 4 (%d%d%d) + 3 bytes (dots) + terminating NULL.
> E.g. 111.111.111.111
>
> So I can allocate a 16-bytes buffer (stack or slab) and accidentally
Hi Marc,
A gentle reminder on this one...
Thanks,
Shameer
> -Original Message-
> From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of Shameer
> Kolothum
> Sent: 14 January 2019 09:50
> To: marc.zyng...@arm.com; linux-kernel@vger.kernel.org
> Cc: gkulka...@marvell.com; suzuki.
On Mon, Jan 28, 2019 at 04:34:16PM -0800, Rick Edgecombe wrote:
> For architectures with CONFIG_ARCH_HAS_SET_ALIAS, pages can be unmapped
> briefly on the directmap, even when CONFIG_DEBUG_PAGEALLOC is not
> configured. So this changes kernel_map_pages and kernel_page_present to be
s/this changes/
On Tue, Feb 19, 2019 at 5:35 AM Sergey Senozhatsky
wrote:
> On (02/08/19 16:23), Petr Mladek wrote:
> Hmm... So the assumption here is that the target buffer always has
> at least strlen("(efault)") bytes and, thus, we always can write the
> error message to it.
Same assumption as for pointers,
My Acer Nitro 5 AN515-42 laptop with a Ryzen 2700U hangs on boot because
of spurious interrupts from pinctrl-amd.
This seems to happen because the touchpad interrupt is enabled on boot
in "level" mode and there is no way to clear it until a touchpad driver
probes.
Fix by disabling all gpio interr
On Tue, Feb 19, 2019 at 4:44 AM Tobin C. Harding wrote:
>
> Currently we have a test module but it is not tied into the kselftest
> infrastructure. In preparation for adding string manipulation functions
> and testing we should enable kselftest to utilize the test module.
>
> Enable string testin
Signed-off-by: Eugeniy Paltsev
---
NOTE:
Even if this patch have no logical dependency with gpu-enabling-patch
(http://patchwork.ozlabs.org/patch/1034722/)
gpu-enabling-patch should be applied first to avoid rebasing.
arch/arc/boot/dts/hsdk.dts | 27 +++
arch/a
In function do_write_buffer(), in the for loop, there is a case
chip_ready() returns 1 while chip_good() returns 0, so it never
break the loop.
To fix this, chip_good() is enough and it should timeout if it stay
bad for a while.
Fixes: dfeae1073583 ("mtd: cfi_cmdset_0002: Change write buffer to ch
Hi TeJun
I've built the 5.0.0-rc6 kernel with psi option, but I cannot find any
cgroup.controllers when I mounted cgroup2.
[root@bogon /]# uname -r
[root@bogon /]# 5.0.0-rc6+
[root@bogon /]# mount -t cgroup2 none cgroup2/
[root@bogon /]# cat cgroup2/cgroup.controllers
[root@bogon /]
[root@bogon /]
Mon, Feb 18, 2019 at 07:21:24PM CET, mkube...@suse.cz wrote:
>Note: this is marked as RFC because it's rather late in the cycle; the plan
>is to make a regular submission (with changes based on review) once
>net-next reopens after the 5.1 merge window. The full (work in progress)
>series, together
When reading the "See below" here, I'd expect to find some further
description of "Odd Fixes" a little bit later in the file. However,
as far as I can see, there is no further description available. Thus
let's simply remove these deceptive two words.
Signed-off-by: Thomas Huth
---
Please double-
On Tue, Feb 19, 2019 at 10:04:34AM +, Pascal PAILLET-LME wrote:
> Change buck1 voltage range to be conform with the data-sheet.
This is a bug fix so it should've gone at the start of the series to
make it easier to apply and send to Linus as a fix.
signature.asc
Description: PGP signature
On Fri, 15 Feb 2019 at 20:45, Ard Biesheuvel wrote:
>
> On Fri, 15 Feb 2019 at 20:43, Nick Desaulniers
> wrote:
> >
> > On Fri, Feb 15, 2019 at 11:28 AM Ard Biesheuvel
> > wrote:
> > >
> > > On Fri, 15 Feb 2019 at 20:25, Nick Desaulniers
> > > wrote:
> > > >
> > > > On Fri, Feb 15, 2019 at 11
On Tue, Feb 19, 2019 at 05:15:47PM +0800, YueHaibing wrote:
> On 2019/2/19 16:59, Jarkko Sakkinen wrote:
> > On Tue, Feb 19, 2019 at 03:26:18PM +0800, YueHaibing wrote:
> >> calc_tpm2_event_size return size of the event which type is
> >> size_t, If it is an invalid event, returns 0. And all the
>
There are no external users of this API (nor should there be); remove it.
Acked-by: Will Deacon
Signed-off-by: Peter Zijlstra (Intel)
---
include/asm-generic/tlb.h |1 -
mm/mmu_gather.c | 34 +-
2 files changed, 17 insertions(+), 18 deletions(-)
Generic mmu_gather provides everything SH needs (range tracking and
cache coherency).
Cc: Will Deacon
Cc: "Aneesh Kumar K.V"
Cc: Andrew Morton
Cc: Nick Piggin
Cc: Yoshinori Sato
Cc: Rich Felker
Signed-off-by: Peter Zijlstra (Intel)
---
arch/sh/include/asm/pgalloc.h |7 ++
arch/sh/inclu
Add the Kconfig option HAVE_MMU_GATHER_NO_GATHER to the generic
mmu_gather code. If the option is set the mmu_gather will not
track individual pages for delayed page free anymore. A platform
that enables the option needs to provide its own implementation
of the __tlb_remove_page_size function to fr
Provide a generic tlb_flush() implementation that relies on
flush_tlb_range(). This is a little awkward because flush_tlb_range()
assumes a VMA for range invalidation, but we no longer have one.
Audit of all flush_tlb_range() implementations shows only vma->vm_mm
and vma->vm_flags are used, and of
Generic mmu_gather provides the simple flush_tlb_range() based range
tracking mmu_gather UM needs.
Cc: Will Deacon
Cc: "Aneesh Kumar K.V"
Cc: Andrew Morton
Cc: Nick Piggin
Cc: Richard Weinberger
Signed-off-by: Peter Zijlstra (Intel)
---
arch/um/include/asm/tlb.h | 156 -
As the comment notes; it is a potentially dangerous operation. Just
use tlb_flush_mmu(), that will skip the (double) TLB invalidate if
it really isn't needed anyway.
Acked-by: Will Deacon
Signed-off-by: Peter Zijlstra (Intel)
---
include/asm-generic/tlb.h | 10 +++---
mm/memory.c
For the architectures that do not implement their own tlb_flush() but
do already use the generic mmu_gather, there are two options:
1) the platform has an efficient flush_tlb_range() and
asm-generic/tlb.h doesn't need any overrides at all.
2) the platform lacks an efficient flush_tlb_range(
Generic mmu_gather provides everything ia64 needs (range tracking).
Cc: Will Deacon
Cc: "Aneesh Kumar K.V"
Cc: Andrew Morton
Cc: Nick Piggin
Cc: Tony Luck
Signed-off-by: Peter Zijlstra (Intel)
---
arch/ia64/include/asm/tlb.h | 256 ---
arch/ia64/inc
Write a comment explaining some of this..
Cc: Nick Piggin
Cc: Andrew Morton
Cc: "Aneesh Kumar K.V"
Acked-by: Will Deacon
Signed-off-by: Peter Zijlstra (Intel)
---
include/asm-generic/tlb.h | 119 --
1 file changed, 116 insertions(+), 3 deletions(-
Now that all architectures are converted to the generic code, remove
the arch hooks.
Acked-by: Will Deacon
Signed-off-by: Peter Zijlstra (Intel)
---
mm/mmu_gather.c | 93 +---
1 file changed, 42 insertions(+), 51 deletions(-)
--- a/mm/mmu_g
Mon, Feb 18, 2019 at 07:22:24PM CET, mkube...@suse.cz wrote:
>Add information about permanent hadware address of a device (as provided by
>ETHTOOL_GPERMADDR ioctl command) in GET_INFO reply if ETH_INFO_IM_PERMADDR
>flag is set in the request.
>
>There is no separate attribute for hardware address l
Cc: heiko.carst...@de.ibm.com
Cc: npig...@gmail.com
Cc: a...@linux-foundation.org
Cc: aneesh.ku...@linux.vnet.ibm.com
Cc: will.dea...@arm.com
Cc: Linus Torvalds
Cc: li...@armlinux.org.uk
Signed-off-by: Martin Schwidefsky
Signed-off-by: Peter Zijlstra (Intel)
Link: http://lkml.kernel.org/r/2018
When an architecture does not have (an efficient) flush_tlb_range(),
but instead always uses full TLB invalidates, the current generic
tlb_flush() is sub-optimal, for it will generate extra flushes in
order to keep the range small.
But if we cannot do range flushes, that is a moot concern. Optiona
The one obvious thing SH and ARM want is a sensible default for
tlb_start_vma(). (also: https://lkml.org/lkml/2004/1/15/6 )
Avoid all VIPT architectures providing their own tlb_start_vma()
implementation and rely on architectures to provide a no-op
flush_cache_range() when it is not relevant.
The
Hi all,
Sorry I haven't posted these in a while, I sorta forgot about them for a little.
Not much changed since last time; one change to the ARM patch as suggested by
Will and a fresh Changelog for patch 12 as requested by Vineet. And some
trivial rebasing of the s390 bits.
They've sat in my que
Since all architectures are now using it, it is redundant.
Acked-by: Will Deacon
Signed-off-by: Peter Zijlstra (Intel)
---
include/asm-generic/tlb.h |1 -
mm/mmu_gather.c |4
2 files changed, 5 deletions(-)
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
Make issuing a TLB invalidate for page-table pages the normal case.
The reason is twofold:
- too many invalidates is safer than too few,
- most architectures use the linux page-tables natively
and would thus require this.
Make it an opt-out, instead of an opt-in.
Acked-by: Will Deacon
Sig
Needed for ia64 -- alternatively we drop the entire hook.
Cc: Will Deacon
Cc: "Aneesh Kumar K.V"
Cc: Andrew Morton
Cc: Nick Piggin
Signed-off-by: Peter Zijlstra (Intel)
---
include/asm-generic/tlb.h |2 ++
1 file changed, 2 insertions(+)
--- a/include/asm-generic/tlb.h
+++ b/include/asm
On 02/19/2019 08:27 AM, Jason Yan wrote:
If we remove the scsi disk when running io with fio, oops occured with
the following condition.
[scsi_eh_0] [fio]
scsi_end_request
->blk_update_request
->end_bio(io returned to userspace)
Move the mmu_gather::page_size things into the generic code instead of
powerpc specific bits.
Cc: Nick Piggin
Cc: "Aneesh Kumar K.V"
Cc: Andrew Morton
Acked-by: Will Deacon
Signed-off-by: Peter Zijlstra (Intel)
---
arch/Kconfig |3 +++
arch/arm/include/asm/tlb.h |
Generic mmu_gather provides everything that ARM needs:
- range tracking
- RCU table free
- VM_EXEC tracking
- VIPT cache flushing
The one notable curiosity is the 'funny' range tracking for classical
ARM in __pte_free_tlb().
Cc: Nick Piggin
Cc: "Aneesh Kumar K.V"
Cc: Andrew Morton
Cc: Rus
Hallo Schatz, ich hoffe, es ist alles gut mit dir
und deine Familie? Ich habe eine wichtige Vereinbarung mit Ihnen zu besprechen
Bitte antworten Sie mir umgehend.
Danke dir
Michelle
Hello,
On Mon, 18 Feb 2019 21:37:25 +0100
Arnd Bergmann wrote:
> > > I would say we should strengthen the behavior of outX() where possible.
> > > I don't know if arm64 actually has a way of doing that, my understanding
> > > earlier was that the AXI bus was already posted, so there is not much
On Tuesday, February 12, 2019 12:06:04 PM CET Viresh Kumar wrote:
> The cpufreq core doesn't remove the cpufreq policy anymore on CPU
> offline operation, rather that happens when the CPU device gets
> unregistered from the kernel. This allows faster recovery when the CPU
> comes back online. This
On Thursday, February 14, 2019 12:15:43 PM CET Harry Pan wrote:
> This patch gives the reader an intuitive metric of the time cost by
> the kernel issuing a filesystem sync during suspend; although developer
> can guess by the timestamp of next log or enable the ftrace power event
> for manual calc
On 18/02/2019 22:08, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Commit 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage
> counter imbalance") introduced a regression that causes suppliers
> to be suspended prematurely for device links added during consumer
> driver probe i
On Thursday, February 14, 2019 11:46:21 AM CET Viresh Kumar wrote:
> Double NOT (!!) operation is normally done to convert a non-zero value
> to 1 and keep zero as is, but that isn't the requirement in this case.
> All we wanted was to make sure that only one of the two routines isn't
> set, i.e. e
On Monday, February 18, 2019 5:53:30 AM CET Viresh Kumar wrote:
> On 16-02-19, 11:31, Yangtao Li wrote:
> > This issue was detected with the help of Coccinelle. So
> > change the order of function calls to fix it.
> >
> > Fixes: 1690d8bb91e37 (cpufreq: scpi/scmi: Fix freeing of dynamic OPPs)
> >
Hi,
I am observing huge fsync latencies for a small file under the below
test scenario -
process A -
Issue async write of 4GB using dd command (say large_file) on /data
mounted
with ext4:
dd if=/dev/zero of=/data/testfile bs=1M count=4096
process B -
In parallel another process wrote a smal
On Thursday, February 14, 2019 7:12:48 PM CET Douglas Anderson wrote:
> The genpd_dev_pm_attach_by_name() simply takes the name and passes it
> to of_property_match_string() where the argument is "const char *".
> Adding a const here allows a later patch to add a const to
> dev_pm_domain_attach_by_
On Wed, Feb 13, 2019 at 08:40:35PM +0100, Marcin Ciupak wrote:
> This patch adds driver for Nordic Semiconductor nRF24L01+ radio
> transceiver.
>
> Signed-off-by: Marcin Ciupak
> ---
> Changes in v2:
> - add terminating newlines to all logging formats
> Changes in v3:
> - patch subject
> -
Goodix CTP controllers require AVDD28, VDDIO regulators for power-on
sequence.
The delay between these regualtor operations as per Power-on Timing
from datasheet[1] is 0 (T1 >= 0 usec).
So, enable and disable these regulators in proper order using normal
regulator functions without any delay in b
GT5663 is capacitive touch controller with customized smart
wakeup gestures, it support chipdata which is similar to
existing GT1151 and require AVDD28 supply for some boards.
Document the compatible for the same.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Documentation/devicetree/
801 - 900 of 1032 matches
Mail list logo
