The touchpads on both T25 and T480 are accessible over SMBUS/RMI.
Signed-off-by: kitsunyan
---
drivers/input/mouse/synaptics.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 55d33500d55e..be934a082424 100644
---
The touchpads on both T25 and T480 are accessible over SMBUS/RMI.
Signed-off-by: kitsunyan
---
drivers/input/mouse/synaptics.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 55d33500d55e..be934a082424 100644
---
On Fri, Jul 06, 2018 at 06:06:10PM -0400, Steven Rostedt wrote:
>
> Peter,
>
> Want to ack this? It touches Lockdep.
>
> Joel,
>
> I got to this patch and I'm still reviewing it. I'll hopefully have my
> full review done by next week. I'll make it a priority. But I still
> would like Peter's
On Fri, Jul 06, 2018 at 06:06:10PM -0400, Steven Rostedt wrote:
>
> Peter,
>
> Want to ack this? It touches Lockdep.
>
> Joel,
>
> I got to this patch and I'm still reviewing it. I'll hopefully have my
> full review done by next week. I'll make it a priority. But I still
> would like Peter's
On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> Hi,
> We're seeing a regression triggered by the stress-ng[*] "chdir" test
> that I've bisected to:
>
> 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
>
> So far we've only seen failures on servers based on
On Fri, Jul 06, 2018 at 11:43:24AM -0600, dann frazier wrote:
> Hi,
> We're seeing a regression triggered by the stress-ng[*] "chdir" test
> that I've bisected to:
>
> 044e6e3d74a3 ext4: don't update checksum of new initialized bitmaps
>
> So far we've only seen failures on servers based on
: Azael Avalos
Cc: platform-driver-...@vger.kernel.org
Cc: Darren Hart
Cc: Andy Shevchenko
---
drivers/platform/x86/toshiba_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-next-20180706.orig/drivers/platform/x86/toshiba_acpi.c
+++ linux-next-20180706/drivers/platform
: Azael Avalos
Cc: platform-driver-...@vger.kernel.org
Cc: Darren Hart
Cc: Andy Shevchenko
---
drivers/platform/x86/toshiba_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-next-20180706.orig/drivers/platform/x86/toshiba_acpi.c
+++ linux-next-20180706/drivers/platform
>I strongly advocate for vendors to have more control over their drivers,
>but this scenario really frustrates me. I don't think I can justify this
>to Linus as a fix. But before we just say "no" (because hey, I want
>these fixes available as early as possible too), let's ask Rafael if he
>has an
>I strongly advocate for vendors to have more control over their drivers,
>but this scenario really frustrates me. I don't think I can justify this
>to Linus as a fix. But before we just say "no" (because hey, I want
>these fixes available as early as possible too), let's ask Rafael if he
>has an
The first checks in mtdchar_read() and mtdchar_write() attempt to limit
`count` such that `*ppos + count <= mtd->size`. However, they ignore the
possibility of `*ppos > mtd->size`, allowing the calculation of `count` to
wrap around. `mtdchar_lseek()` prevents seeking beyond mtd->size, but the
The first checks in mtdchar_read() and mtdchar_write() attempt to limit
`count` such that `*ppos + count <= mtd->size`. However, they ignore the
possibility of `*ppos > mtd->size`, allowing the calculation of `count` to
wrap around. `mtdchar_lseek()` prevents seeking beyond mtd->size, but the
Hi,
Kindly pull the new firmware from the following URL.
git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
Thanks
Ganesh
The following changes since commit d1147327232ec4616a66ab898df84f9700c816c1:
Merge branch 'for-upstreaming-v1.7.2-vsw' of
Hi,
Kindly pull the new firmware from the following URL.
git://git.chelsio.net/pub/git/linux-firmware.git for-upstream
Thanks
Ganesh
The following changes since commit d1147327232ec4616a66ab898df84f9700c816c1:
Merge branch 'for-upstreaming-v1.7.2-vsw' of
ASAN
> CPU: 0 PID: 4429 Comm: syz-executor697 Not tainted 4.18.0-rc3-next-20180706+
> #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:shmem_undo_range+0xdaa/0x29a0 mm/shmem.c:815
Pretty sure this one's mine. At least I s
ASAN
> CPU: 0 PID: 4429 Comm: syz-executor697 Not tainted 4.18.0-rc3-next-20180706+
> #1
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:shmem_undo_range+0xdaa/0x29a0 mm/shmem.c:815
Pretty sure this one's mine. At least I s
From: Jun Gao
DMA mode will always be used in i2c transactions, try to allocate
a DMA safe buffer if the buf of struct i2c_msg used is not DMA safe.
Signed-off-by: Jun Gao
---
drivers/i2c/busses/i2c-mt65xx.c | 62 -
1 file changed, 55 insertions(+), 7
This patch series based on v4.18-rc1, include i2c adapter driver register time
modification, DMA safe buffer free function and DMA safe buffers used for i2c
transactions.
Jun Gao (3):
i2c: mediatek: Register i2c adapter driver earlier
i2c: Add helper to ease DMA handling
i2c: mediatek: Use
From: Jun Gao
DMA mode will always be used in i2c transactions, try to allocate
a DMA safe buffer if the buf of struct i2c_msg used is not DMA safe.
Signed-off-by: Jun Gao
---
drivers/i2c/busses/i2c-mt65xx.c | 62 -
1 file changed, 55 insertions(+), 7
This patch series based on v4.18-rc1, include i2c adapter driver register time
modification, DMA safe buffer free function and DMA safe buffers used for i2c
transactions.
Jun Gao (3):
i2c: mediatek: Register i2c adapter driver earlier
i2c: Add helper to ease DMA handling
i2c: mediatek: Use
Add support for the Zodiac Inflight Innovations SCU2 Mezz
board (i.MX51-based).
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc:
Add support for the Zodiac Inflight Innovations SCU2 Mezz
board (i.MX51-based).
Cc: Fabio Estevam
Cc: Nikita Yushchenko
Cc: Lucas Stach
Cc: cphe...@gmail.com
Cc: Shawn Guo
Cc: Rob Herring
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc:
From: Jun Gao
This function is needed by i2c_get_dma_safe_msg_buf() potentially.
It is used to free DMA safe buffer when DMA operation fails.
Signed-off-by: Jun Gao
---
drivers/i2c/i2c-core-base.c | 14 ++
include/linux/i2c.h | 1 +
2 files changed, 15 insertions(+)
diff
From: Jun Gao
As i2c adapter, i2c slave devices will depend on it. In order not to
block the initializations of i2c slave devices, register i2c adapter
driver at appropriate time.
Signed-off-by: Jun Gao
---
drivers/i2c/busses/i2c-mt65xx.c | 12 +++-
1 file changed, 11 insertions(+), 1
From: Jun Gao
As i2c adapter, i2c slave devices will depend on it. In order not to
block the initializations of i2c slave devices, register i2c adapter
driver at appropriate time.
Signed-off-by: Jun Gao
---
drivers/i2c/busses/i2c-mt65xx.c | 12 +++-
1 file changed, 11 insertions(+), 1
From: Jun Gao
This function is needed by i2c_get_dma_safe_msg_buf() potentially.
It is used to free DMA safe buffer when DMA operation fails.
Signed-off-by: Jun Gao
---
drivers/i2c/i2c-core-base.c | 14 ++
include/linux/i2c.h | 1 +
2 files changed, 15 insertions(+)
diff
Relying on serial port defaults for flow control and parity can result
in complete breakdown of communication with RAVE SP on some platforms
where defaults are not what we need them to be. One such case is
VF610-base ZII SPU3 board (not supported upstream). To avoid this
problem in the future, add
RAVE SP firmware covered by "legacy" variant uses 16-bit CCITT
checksum algorithm. Change the code to correctly reflect that.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 2
Relying on serial port defaults for flow control and parity can result
in complete breakdown of communication with RAVE SP on some platforms
where defaults are not what we need them to be. One such case is
VF610-base ZII SPU3 board (not supported upstream). To avoid this
problem in the future, add
RAVE SP firmware covered by "legacy" variant uses 16-bit CCITT
checksum algorithm. Change the code to correctly reflect that.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 2
CMD_GET_STATUS is not supported by some devices implementing
RDU2-compatible ICD as well as "legacy" devices. To account for that
fact, add code that obtains the same information (app/bootloader FW
version) using several different commands.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Lee:
This series is a number of small fixes the resulted from using RAVE SP
driver on wider selection of ZII devices that initial driver was
tested on. In addition to RDU1 and RDU2, the driver is now known to
work reasonably well on SCU2 Mezz (being upstreamed currently) as well
as SPU3 (not
CMD_GET_STATUS is not supported by some devices implementing
RDU2-compatible ICD as well as "legacy" devices. To account for that
fact, add code that obtains the same information (app/bootloader FW
version) using several different commands.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Lee:
This series is a number of small fixes the resulted from using RAVE SP
driver on wider selection of ZII devices that initial driver was
tested on. In addition to RDU1 and RDU2, the driver is now known to
work reasonably well on SCU2 Mezz (being upstreamed currently) as well
as SPU3 (not
This is needed to make rave-sp-wdt driver to properly ping the
watchdog on "legacy" firmware.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 2 ++
1 file changed, 2
This is needed to make rave-sp-wdt driver to properly ping the
watchdog on "legacy" firmware.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 2 ++
1 file changed, 2
Remove unusded defines that are a leftover from earlier iterations of
the driver.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 10 --
1 file changed, 10
This is needed to make rave-sp-eeprom driver work on "legacy"
firmware.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 2 ++
include/linux/mfd/rave-sp.h | 1 +
2 files
Remove unusded defines that are a leftover from earlier iterations of
the driver.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 10 --
1 file changed, 10
This is needed to make rave-sp-eeprom driver work on "legacy"
firmware.
Cc: linux-kernel@vger.kernel.org
Cc: cphe...@gmail.com
Cc: Lucas Stach
Cc: Nikita Yushchenko
Cc: Lee Jones
Signed-off-by: Andrey Smirnov
---
drivers/mfd/rave-sp.c | 2 ++
include/linux/mfd/rave-sp.h | 1 +
2 files
This read handler had a lot of custom logic and wrote outside the bounds of
the provided buffer. This could lead to kernel and userspace memory
corruption. Just use simple_read_from_buffer() with a stack buffer.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
Signed-off-by:
This read handler had a lot of custom logic and wrote outside the bounds of
the provided buffer. This could lead to kernel and userspace memory
corruption. Just use simple_read_from_buffer() with a stack buffer.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
Signed-off-by:
From: Xiubo Li
Prepraing for changing to use mutex lock.
Signed-off-by: Xiubo Li
---
drivers/uio/uio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index e8f4ac9..b4b2ae1 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
From: Xiubo Li
Prepraing for changing to use mutex lock.
Signed-off-by: Xiubo Li
---
drivers/uio/uio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index e8f4ac9..b4b2ae1 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
From: Xiubo Li
We are hitting a regression with the following commit:
commit a93e7b331568227500186a465fee3c2cb5dffd1f
Author: Hamish Martin
Date: Mon May 14 13:32:23 2018 +1200
uio: Prevent device destruction while fds are open
The problem is the addition of spin_lock_irqsave in
From: Xiubo Li
For the target_core_user use case, after the device is unregistered
it maybe still opened in user space, then the kernel will crash, like:
[ 251.163692] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 251.163820] IP: [] show_name+0x23/0x40 [uio]
[
From: Xiubo Li
We are hitting a regression with the following commit:
commit a93e7b331568227500186a465fee3c2cb5dffd1f
Author: Hamish Martin
Date: Mon May 14 13:32:23 2018 +1200
uio: Prevent device destruction while fds are open
The problem is the addition of spin_lock_irqsave in
From: Xiubo Li
For the target_core_user use case, after the device is unregistered
it maybe still opened in user space, then the kernel will crash, like:
[ 251.163692] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 251.163820] IP: [] show_name+0x23/0x40 [uio]
[
From: Xiubo Li
V2:
- resend it with some small fix
V3:
- switch to use request_threaded_irq
V4:
- remove useless checking code, Thanks Mike.
- Thanks very much for the review from Hamish and Mike.
Xiubo Li (3):
uio: use request_threaded_irq instead
uio: change to use the mutex lock
From: Xiubo Li
V2:
- resend it with some small fix
V3:
- switch to use request_threaded_irq
V4:
- remove useless checking code, Thanks Mike.
- Thanks very much for the review from Hamish and Mike.
Xiubo Li (3):
uio: use request_threaded_irq instead
uio: change to use the mutex lock
BPF_SYNCHRONIZE waits for any BPF programs active at the time of
BPF_SYNCHRONIZE to complete, allowing userspace to ensure atomicity of
RCU data structure operations with respect to active programs. For
example, userspace can update a map->map entry to point to a new map,
use BPF_SYNCHRONIZE to
BPF_SYNCHRONIZE waits for any BPF programs active at the time of
BPF_SYNCHRONIZE to complete, allowing userspace to ensure atomicity of
RCU data structure operations with respect to active programs. For
example, userspace can update a map->map entry to point to a new map,
use BPF_SYNCHRONIZE to
If softsynthx_read() is called with `count < 3`, `count - 3` wraps, causing
the loop to copy as much data as available to the provided buffer. If
softsynthx_read() is invoked through sys_splice(), this causes an
unbounded kernel write; but even when userspace just reads from it
normally, a small
If softsynthx_read() is called with `count < 3`, `count - 3` wraps, causing
the loop to copy as much data as available to the provided buffer. If
softsynthx_read() is invoked through sys_splice(), this causes an
unbounded kernel write; but even when userspace just reads from it
normally, a small
On Sat, Jul 07, 2018 at 03:41:30AM +0200, Tomas Bortoli wrote:
> I don't have a background on usage or internals of the driver at issue
> but I hope these clues will help in finding the proper fix.
I think anything is useful, thanks..
The truth is that nobody is left that seems to really
On Sat, Jul 07, 2018 at 03:41:30AM +0200, Tomas Bortoli wrote:
> I don't have a background on usage or internals of the driver at issue
> but I hope these clues will help in finding the proper fix.
I think anything is useful, thanks..
The truth is that nobody is left that seems to really
On Thu, 2018-07-05 at 10:08 -0600, Rob Herring wrote:
>
> > It's not really a SOC block from a vendor, it's a pseudo-device in a
> > way. The current one that doesn't use the coldfire offload is just
> > compatible "fsi-master-gpio".
> >
> > I can add a vendor but what should it be ? aspeed
On Thu, 2018-07-05 at 10:08 -0600, Rob Herring wrote:
>
> > It's not really a SOC block from a vendor, it's a pseudo-device in a
> > way. The current one that doesn't use the coldfire offload is just
> > compatible "fsi-master-gpio".
> >
> > I can add a vendor but what should it be ? aspeed
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
- struct uio_device *idev = info->uio_dev;
+ struct uio_device *idev;
+
+ if (!info)
+ return;
+
+ idev =
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
- struct uio_device *idev = info->uio_dev;
+ struct uio_device *idev;
+
+ if (!info)
+ return;
+
+ idev =
Hi,
I spent some time debugging the Syzkaller's found issue at subject:
https://syzkaller.appspot.com/bug?id=b8febdb3c7c8c1f1b606fb903cee66b21b2fd02f
And I've backtracked the UAF to the fact that the cma_listen_on_all()
function adds "id_priv->list" to the global var "listen_any_list" but
then
Hi,
I spent some time debugging the Syzkaller's found issue at subject:
https://syzkaller.appspot.com/bug?id=b8febdb3c7c8c1f1b606fb903cee66b21b2fd02f
And I've backtracked the UAF to the fact that the cma_listen_on_all()
function adds "id_priv->list" to the global var "listen_any_list" but
then
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id;
- irqreturn_t ret = idev->info->handler(irq, idev->info);
+
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id;
- irqreturn_t ret = idev->info->handler(irq, idev->info);
+
2018-07-07 1:29 GMT+09:00 Kirill A. Shutemov :
> On Fri, Jul 06, 2018 at 11:13:02PM +0900, Masahiro Yamada wrote:
>> >> LDFLAGS is for internal-use.
>> >> Please do not override it from the command line.
>> >
>> > Can we generate a build error if a user try to override LDFLAGS, CFLAGS or
>> >
2018-07-07 1:29 GMT+09:00 Kirill A. Shutemov :
> On Fri, Jul 06, 2018 at 11:13:02PM +0900, Masahiro Yamada wrote:
>> >> LDFLAGS is for internal-use.
>> >> Please do not override it from the command line.
>> >
>> > Can we generate a build error if a user try to override LDFLAGS, CFLAGS or
>> >
Hello,
syzbot found the following crash on:
HEAD commit:526674536360 Add linux-next specific files for 20180706
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=116d16fc40
kernel config: https://syzkaller.appspot.com/x/.config?x=c8d1cfc0cb798e48
Hello,
syzbot found the following crash on:
HEAD commit:526674536360 Add linux-next specific files for 20180706
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=116d16fc40
kernel config: https://syzkaller.appspot.com/x/.config?x=c8d1cfc0cb798e48
Hi,
This is a follow up from
lkml.kernel.org/r/<20180329004805.7278-1-labb...@redhat.com> . I was
pointed to a previous suggestion (https://lkml.org/lkml/2018/2/28/178)
to rename the variables for better namespacing. I hadn't seen anyone
follow up so this is a series to do just that. I split up
Hi,
This is a follow up from
lkml.kernel.org/r/<20180329004805.7278-1-labb...@redhat.com> . I was
pointed to a previous suggestion (https://lkml.org/lkml/2018/2/28/178)
to rename the variables for better namespacing. I hadn't seen anyone
follow up so this is a series to do just that. I split up
In preparation for enabling command line CFLAGS, re-name HOSTCFLAGS to
KBUILD_HOSTCFLAGS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
arch/alpha/boot/Makefile | 2 +-
arch/s390/tools/Makefile
In preparation for enabling command line LDFLAGS, re-name HOSTLDFLAGS to
KBUILD_HOSTLDFLAGS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
net/bpfilter/Makefile | 2 +-
scripts/Makefile.host | 10
On 07/07, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2018/7/7 6:45, Jaegeuk Kim wrote:
> > On 07/04, Chao Yu wrote:
> >> From: Chao Yu
> >>
> >> Some devices has small max_{hw,}discard_sectors, so that in
> >> __blkdev_issue_discard(), one big size discard bio can be split
> >> into multiple small size
In preparation for enabling command line CFLAGS, re-name HOSTCFLAGS to
KBUILD_HOSTCFLAGS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
arch/alpha/boot/Makefile | 2 +-
arch/s390/tools/Makefile
In preparation for enabling command line LDFLAGS, re-name HOSTLDFLAGS to
KBUILD_HOSTLDFLAGS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
net/bpfilter/Makefile | 2 +-
scripts/Makefile.host | 10
On 07/07, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2018/7/7 6:45, Jaegeuk Kim wrote:
> > On 07/04, Chao Yu wrote:
> >> From: Chao Yu
> >>
> >> Some devices has small max_{hw,}discard_sectors, so that in
> >> __blkdev_issue_discard(), one big size discard bio can be split
> >> into multiple small size
Commit 0c3b7e42616f ("tools build: Add support for host programs format")
introduced host_c_flags which referenced CHOSTFLAGS. The actual name of the
variable is HOSTCFLAGS. Fix this up.
Fixes: 0c3b7e42616f ("tools build: Add support for host programs format")
Signed-off-by: Laura Abbott
---
Commit 0c3b7e42616f ("tools build: Add support for host programs format")
introduced host_c_flags which referenced CHOSTFLAGS. The actual name of the
variable is HOSTCFLAGS. Fix this up.
Fixes: 0c3b7e42616f ("tools build: Add support for host programs format")
Signed-off-by: Laura Abbott
---
In preparation for enabling command line CXXFLAGS, re-name HOSTCXXFLAGS to
KBUILD_HOSTCXXFLAGS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
scripts/Makefile.host| 4 ++--
Now that we have the rename in place, reuse the HOST*FLAGS options as
something that can be set from the command line and included with the
rest of the flags.
Signed-off-by: Laura Abbott
---
Makefile | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile
In preparation for enabling command line CXXFLAGS, re-name HOSTCXXFLAGS to
KBUILD_HOSTCXXFLAGS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
scripts/Makefile.host| 4 ++--
Now that we have the rename in place, reuse the HOST*FLAGS options as
something that can be set from the command line and included with the
rest of the flags.
Signed-off-by: Laura Abbott
---
Makefile | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile
The final link of fixdep uses LDFLAGS but not the existing HOSTLDFLAGS.
Fix this.
Signed-off-by: Laura Abbott
---
This was another one where I couldn't tell of the use of LDFLAGS was a
typo or intentional, hence keeping both.
---
tools/build/Makefile | 2 +-
1 file changed, 1 insertion(+), 1
In preparation for enabling command line LDLIBS, re-name HOST_LOADLIBES to
KBUILD_HOSTLDLIBS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
samples/bpf/Makefile | 2 +-
scripts/Makefile.host | 10
The final link of fixdep uses LDFLAGS but not the existing HOSTLDFLAGS.
Fix this.
Signed-off-by: Laura Abbott
---
This was another one where I couldn't tell of the use of LDFLAGS was a
typo or intentional, hence keeping both.
---
tools/build/Makefile | 2 +-
1 file changed, 1 insertion(+), 1
In preparation for enabling command line LDLIBS, re-name HOST_LOADLIBES to
KBUILD_HOSTLDLIBS as the internal use only flags. This should not have any
visible effects.
Signed-off-by: Laura Abbott
---
Makefile | 4 ++--
samples/bpf/Makefile | 2 +-
scripts/Makefile.host | 10
2018-07-06 23:39 GMT+09:00 Gabriel C :
> 2018-07-06 16:13 GMT+02:00 Masahiro Yamada :
>> Hi.
>>
>> 2018-07-06 19:41 GMT+09:00 Kirill A. Shutemov :
>>> On Fri, Jul 06, 2018 at 03:37:58PM +0900, Masahiro Yamada wrote:
>> > > Also see https://bugzilla.kernel.org/show_bug.cgi?id=200385 ,
>>
2018-07-06 23:39 GMT+09:00 Gabriel C :
> 2018-07-06 16:13 GMT+02:00 Masahiro Yamada :
>> Hi.
>>
>> 2018-07-06 19:41 GMT+09:00 Kirill A. Shutemov :
>>> On Fri, Jul 06, 2018 at 03:37:58PM +0900, Masahiro Yamada wrote:
>> > > Also see https://bugzilla.kernel.org/show_bug.cgi?id=200385 ,
>>
This changes the behavior of the KASLR logic for allocating memory for the text
sections of loadable modules. It randomizes the location of each module text
section with about 17 bits of entropy in typical use. This is enabled on X86_64
only. For 32 bit, the behavior is unchanged.
The algorithm
This changes the behavior of the KASLR logic for allocating memory for the text
sections of loadable modules. It randomizes the location of each module text
section with about 17 bits of entropy in typical use. This is enabled on X86_64
only. For 32 bit, the behavior is unchanged.
The algorithm
Add debugfs file "modfraginfo" for providing info on module space
fragmentation. This can be used for determining if loadable module
randomization is causing any problems for extreme module loading situations,
like huge numbers of modules or extremely large modules.
Sample output when
Create __vmalloc_node_try_addr function that tries to allocate at a specific
address and supports caller specified behavior for whether any lazy purging
happens if there is a collision.
Signed-off-by: Rick Edgecombe
---
include/linux/vmalloc.h | 3 +
mm/vmalloc.c| 174
Add debugfs file "modfraginfo" for providing info on module space
fragmentation. This can be used for determining if loadable module
randomization is causing any problems for extreme module loading situations,
like huge numbers of modules or extremely large modules.
Sample output when
Create __vmalloc_node_try_addr function that tries to allocate at a specific
address and supports caller specified behavior for whether any lazy purging
happens if there is a collision.
Signed-off-by: Rick Edgecombe
---
include/linux/vmalloc.h | 3 +
mm/vmalloc.c| 174
Hi,
This is v2 of the "KASLR feature to randomize each loadable module" patchset.
The purpose is to increase the randomization and makes the modules randomized
in relation to each other instead of just the base, so that if one module leaks,
the location of the others can't be inferred.
This code
Hi,
This is v2 of the "KASLR feature to randomize each loadable module" patchset.
The purpose is to increase the randomization and makes the modules randomized
in relation to each other instead of just the base, so that if one module leaks,
the location of the others can't be inferred.
This code
On Tue, 19 Jun 2018 13:53:08 +0100 Will Deacon wrote:
> In preparation for implementing the asm-generic atomic bitops in terms
> of atomic_long_*, we need to prevent asm/atomic.h implementations from
> pulling in linux/bitops.h. A common reason for this include is for the
> BITS_PER_BYTE
On Tue, 19 Jun 2018 13:53:08 +0100 Will Deacon wrote:
> In preparation for implementing the asm-generic atomic bitops in terms
> of atomic_long_*, we need to prevent asm/atomic.h implementations from
> pulling in linux/bitops.h. A common reason for this include is for the
> BITS_PER_BYTE
Add binding document for Stingray PCIe PHYs for both PAXB and PAXC based
root complex
Signed-off-by: Ray Jui
Reviewed-by: Rob Herring
---
.../devicetree/bindings/phy/brcm,sr-pcie-phy.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Add Stingray PCIe PHY driver for both PAXB and PAXC root complex
Signed-off-by: Ray Jui
---
drivers/phy/broadcom/Kconfig | 10 ++
drivers/phy/broadcom/Makefile | 2 +
drivers/phy/broadcom/phy-bcm-sr-pcie.c | 305 +
3 files changed, 317
1 - 100 of 1266 matches
Mail list logo
