On 2019/9/13 1:45, Kalle Valo wrote:
> zhong jiang writes:
>
>> il4965_set_tkip_dynamic_key_info do not need return value to
>> cope with different ases. And change functon return type to void.
>>
>> Signed-off-by: zhong jiang
>> ---
>> drivers/net/wireless/intel/iwlegacy/4965-mac.c | 8
On Sat, Sep 14, 2019 at 08:17:44PM +0300, ivan.laz...@gmail.com wrote:
> + struct list_head acpi_resources, crb_resources;
Please do not create crb_resources. I said this already last time.
/Jarkko
In add_memory_resource() the memory range to be hot added first gets into
the memblock via memblock_add() before arch_add_memory() is called on it.
Reverse sequence should be followed during memory hot removal which already
is being followed in add_memory_resource() error path. This now ensures
On Wed, 2019-09-11 at 11:44 -0700, Guenter Roeck wrote:
> On Fri, Aug 30, 2019 at 03:40:50PM +0800, Chunfeng Yun wrote:
> > Support USB wakeup by ip-sleep mode for MT8183, it's similar to
> > MT8173
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > v3: changes micros define
> >
> > v2: no changes
>
> On Fri, Sep 13, 2019 at 03:00:06PM +0100, Jarkko Sakkinen wrote:
> > On Wed, Sep 11, 2019 at 02:17:48PM +0900, Seunghun Han wrote:
> > > Vanya,
> > > I also made a patch series to solve AMD's fTPM. My patch link is here,
> > > https://lkml.org/lkml/2019/9/9/132 .
> > >
> > > The maintainer,
On Sat, Sep 14, 2019 at 08:17:44PM +0300, ivan.laz...@gmail.com wrote:
> From: Ivan Lazeev
>
> Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=195657
>
> cmd/rsp buffers are expected to be in the same ACPI region.
> For Zen+ CPUs BIOS's might report two different regions, some of
> them
On Sat, Sep 14, 2019 at 08:32:38AM -0700, Dave Hansen wrote:
> On 9/14/19 6:41 AM, Jarkko Sakkinen wrote:
> >
> > The proposed LSM hooks give the granularity to make yes/no decision
> > based on the
> >
> > * The origin of the source of the source for the enclave.
> > * The requested permissions
On 11.09.2019 12:58, Codrin Ciubotariu wrote:
> External E-Mail
>
>
> After a transfer timeout, some faulty I2C slave devices might hold down
> the SCL or the SDA pins. We can generate a bus clear command, hoping that
> the slave might release the pins.
>
> Signed-off-by: Codrin Ciubotariu
Hi Alan,
I spend some time reading this, really helpful! Thanks.
Please see comments below:
On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
[...]
> If two memory accesses aren't concurrent then one must execute before
> the other. Therefore the LKMM decides two accesses aren't
On 15:00 Sun 15 Sep 2019, Linus Torvalds wrote:
So we've had a fairly quiet last week, but I think it was good that we
ended up having that extra week and the final rc8.
Even if the reason for that extra week was my travel schedule rather
than any pending issues, we ended up having a few good
On 16 September 2019 2:37:27 am GMT+01:00, Mark Brown
wrote:
>On Thu, Sep 05, 2019 at 04:02:37PM +1000, Stephen Rothwell wrote:
>
>> As I said yesterday, there will be no release today, or any day until
>> September 30.
>
>I'm going to try to provide some builds for this week (16th-20th).
>There
On Sun, Sep 15, 2019 at 9:30 PM Willy Tarreau wrote:
>
> I'd be in favor of adding in the man page something like "this
> random source is only suitable for applications which will not be
> harmed by getting a predictable value on output, and as such it is
> not suitable for generation of system
On Sun, Sep 15, 2019 at 09:21:06PM -0700, Linus Torvalds wrote:
> The timer interrupt could be somewhat interesting if you are also
> CPU-bound on a non-trivial load, because then "what program counter
> got interrupted" ends up being possibly unpredictable - even with a
> very stable timer
Fixes: 95f3b3d20e9b ("mm, slab_common: Make kmalloc_caches[] start at size
KMALLOC_MIN_SIZE")
Signed-off-by: kbuild test robot
---
slab_common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 2aed30deb0714..bf1cf4ba35f86 100644
Hi Pengfei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3 next-20190915]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
The following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d:
Linux 5.3-rc3 (2019-08-04 18:40:12 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fscrypt-for-linus
for you to fetch changes up to
Hi Ted,
On Sun, Sep 15, 2019 at 10:49:04PM -0400, Theodore Y. Ts'o wrote:
> No matter *what* we do, it's going to either (a) make some
> systems insecure, or (b) make some systems more likely hang while
> booting.
I continue to strongly disagree with opposing these two. (b) is
caused precisely
On 2019/09/13 22:26, John Ogness wrote:
> 6. A new may-sleep function pr_flush() will be made available to wait
> for all previously printk'd messages to be output on all consoles before
> proceeding. For example:
>
> pr_cont("Running test ABC... ");
> pr_flush();
>
> do_test();
>
>
On Sun, Sep 15, 2019 at 8:52 PM Herbert Xu wrote:
>
> Can we perhaps artifically increase the interrupt rate while the
> CRNG is not initialised?
Long term (or even medium term in some areas), the problem really is
that device interrupts during boot really are going away, rather than
becoming
On Thu, 12 Sep 2019 at 20:37, Paolo Bonzini wrote:
>
> On 12/09/19 02:34, Wanpeng Li wrote:
> >>> -timer_advance_ns -= min((u32)ns,
> >>> -timer_advance_ns / LAPIC_TIMER_ADVANCE_ADJUST_STEP);
> >>> +timer_advance_ns -= ns;
>
> Looking more closely, this assignment...
>
Hi Linus,
the following is the bulk of GPIO changes for v5.4. The
main information chunk about the updates is in the signed
tag as always. This cycle has been pretty lively.
You will notice that I merged in v5.3-rc7 at a late point.
This was because the conflicts were really hairy between
the
On Sun, Sep 15, 2019 at 8:40 PM Linus Torvalds
wrote:
>
> If you want secure keys, you can't rely on a blocking model, because
> it ends up not working. Blocking leads to problems.
Side note: I'd argue that (despite my earlier mis-understanding) the
only really valid use of "block until there is
Theodore Y. Ts'o wrote:
>
> Ultimately, though, we need to find *some* way to fix userspace's
> assumptions that they can always get high quality entropy in early
> boot, or we need to get over people's distrust of Intel and RDRAND.
> Otherwise, future performance improvements in any part of the
When skb_shinfo(skb) is not able to cache extra fragment (that is,
skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS), xennet_fill_frags() assumes
the sk_buff_head list is already empty. As a result, cons is increased only
by 1 and returns to error handling path in xennet_poll().
However, if the
On Sun, Sep 15, 2019 at 8:23 PM Theodore Y. Ts'o wrote:
>
> But not blocking is *precisely* what lead us to weak keys in network
> devices that were sold by the millions to users in their printers,
> wifi routers, etc.
Ted, just admit that you are wrong on this, instead of writing the
above kind
On Sun, Sep 15, 2019 at 8:26 PM Nicolas Boichat wrote:
>
> On Sat, Sep 14, 2019 at 6:03 AM Dmitry Torokhov wrote:
> >
> > The USB interface may get detected before the platform/EC one, so let's
> > note the state of the base (if we receive event) and use it to correctly
> > initialize the tablet
On Sun, Sep 15, 2019 at 6:41 PM Ahmed S. Darwish wrote:
>
> Yes, the systemd-random-seed(8) process blocks, but this is an
> isolated process, and it's only there as a synchronization point and
> to load/restore random seeds from disk across reboots.
>
> What blocked the system boot was
On Sat, Sep 14, 2019 at 6:03 AM Dmitry Torokhov wrote:
>
> The USB interface may get detected before the platform/EC one, so let's
> note the state of the base (if we receive event) and use it to correctly
> initialize the tablet mode switch state.
>
> Also let's start the HID interface
On Sat, 2019-09-14 at 09:46 +0200, Christophe Leroy wrote:
>
> Le 03/09/2019 à 07:23, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > When calling flush_icache_range with a size >4GB, we were masking
> > off the upper 32 bits, so we would incorrectly flush a range
> > smaller
> >
On Sun, Sep 15, 2019 at 10:02:18AM -0700, Linus Torvalds wrote:
> But on a PC, we can _almost_ guarantee entropy. Even with a golden
> image, we do mix in:
>
> - timestamp counter on every device interrupt (but "device interrupt"
> doesn't include things like the local CPU timer, so it really
Hi Pengfei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi all,
Non-merge commits (relative to Linus' tree): 11835
11503 files changed, 777542 insertions(+), 373473 deletions(-)
I have created today's linux-next tree at
On 9/13/2019 6:12 PM, andriy.shevche...@intel.com wrote:
On Fri, Sep 13, 2019 at 05:20:26PM +0800, Dilip Kota wrote:
On 9/12/2019 6:49 PM, Gustavo Pimentel wrote:
On Thu, Sep 12, 2019 at 10:23:31, Dilip Kota
wrote:
Hi, I just return from parental leave, therefore I still trying to get
the
On 9/15/19 7:06 PM, Hillf Danton wrote:
>
> On Sun, 15 Sep 2019 09:34:37 -0700
>>
>> Kernel is 5.3-rc8 on x86_64.
>>
>> Loading and removing the pci-epf-test module causes a BUG.
>>
>>
>> [40928.435755] calling pci_epf_test_init+0x0/0x1000 [pci_epf_test] @ 12132
>> [40928.436717] initcall
Hi, Leonard
> On 2019-09-12 5:57 AM, Anson Huang wrote:
> > The 800MHz opp speed grading fuse mask should be 0xd instead of 0xf
> > according to fuse map definition:
> >
> > SPEED_GRADING[1:0] MHz
> > 00 800
> > 01 500
> > 10 1000
> > 11
Add scu key node for i.MX8QXP, disabled by default as it
depends on board design.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and scu key event etc. management, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key event, add binding doc for
Enable scu key for i.MX8QXP MEK board.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and scu key etc..
Adds i.MX system controller key driver support, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu
Select CONFIG_KEYBOARD_IMX_SC_KEY as module by default to
support i.MX8QXP scu key driver.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index
On 2019/9/12 18:06, Jan Kara wrote:
> On Wed 11-09-19 17:36:50, Chao Yu wrote:
>> Quoted from
>> commit 3da40c7b0898 ("ext4: only call ext4_truncate when size <= isize")
>>
>> " At LSF we decided that if we truncate up from isize we shouldn't trim
>> fallocated blocks that were fallocated with
On Sun, Sep 15, 2019 at 06:48:34PM -0700, Vito Caputo wrote:
> > A small note here, especially after I've just read the commit log of
> > 72dbcf721566 ('Revert ext4: "make __ext4_get_inode_loc plug"'), which
> > unfairly blames systemd there.
...
> > What blocked the system boot was
On Sun, Sep 15, 2019 at 11:59:41AM -0700, Linus Torvalds wrote:
> On Sun, Sep 15, 2019 at 11:32 AM Willy Tarreau wrote:
> >
> > I think that the exponential decay will either not be used or
> > be totally used, so in practice you'll always end up with 0 or
> > 30s depending on the entropy
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm/include/asm/xen/page-coherent.h
between commits:
bef4d2037d2143a ("xen/arm: consolidate page-coherent.h")
60d8cd572f655aa ("arm64/xen: fix xen-swiotlb cache flushing")
from the dma-mapping tree and
Hi, Dmitry
> On Tue, Sep 03, 2019 at 05:36:37PM -0400, Anson Huang wrote:
> > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> > inside, the system controller is in charge of controlling power, clock
> > and scu key etc..
> >
> > Adds i.MX system controller key driver support,
On Thu, 2019-09-12 at 12:04 -0700, Vijay Khemka wrote:
> Disabling multicast filtering from NCSI if it is supported. As it
> should not filter any multicast packets. In current code, multicast
> filter is enabled and with an exception of optional field supported
> by device are disabled filtering.
On 19/9/12 18:56, Will Deacon wrote:
> [Adding the ocfs2 maintainers and mailing list]
>
> On Mon, Sep 09, 2019 at 09:52:26AM +0800, kernel test robot wrote:
>> FYI, we noticed the following commit (built with gcc-7):
>>
>> commit: 26d2e0d5df5b9aab517d8327743e66fcb38e8136 ("refcount:
Errata: unsupported request error on inbound posted write
transaction, PCIe controller reports advisory error instead
of uncorrectable error message to RC.
Signed-off-by: Xiaowei Bao
---
drivers/pci/controller/mobiveil/pcie-layerscape-gen4-ep.c | 13 +
Add the layerscape PCIE GEN4 EP device support in pci_endpoint_test driver.
Signed-off-by: Xiaowei Bao
---
drivers/misc/pci_endpoint_test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 6e208a0..8b145a7 100644
---
Add the documentation for the Device Tree binding of the layerscape
PCIe GEN4 controller with EP mode.
Signed-off-by: Xiaowei Bao
---
.../bindings/pci/layerscape-pcie-gen4.txt | 28 +-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git
Add the LX2160A PCIe EP node.
Signed-off-by: Xiaowei Bao
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 56 ++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index
Add the EP driver support for Mobiveil base on endpoint framework.
Signed-off-by: Xiaowei Bao
---
MAINTAINERS| 1 +
drivers/pci/controller/mobiveil/Kconfig| 5 +
drivers/pci/controller/mobiveil/Makefile | 1 +
This patch set are for adding Mobiveil EP driver and adding PCIe Gen4
EP driver of NXP Layerscape platform.
This patch set depends on:
https://patchwork.kernel.org/project/linux-pci/list/?series=159139
Xiaowei Bao (6):
PCI: mobiveil: Add the EP driver support
dt-bindings: Add DT binding for
This PCIe controller is based on the Mobiveil GPEX IP, it work in EP
mode if select this config opteration.
Signed-off-by: Xiaowei Bao
---
MAINTAINERS| 2 +
drivers/pci/controller/mobiveil/Kconfig| 17 ++-
On Tue, Sep 10, 2019 at 6:26 PM Paul Burton wrote:
>
> Hi Jiaxun & Huacai,
>
> On Thu, Sep 05, 2019 at 10:42:59PM +0800, Jiaxun Yang wrote:
> > As later model of GSx64 family processors including 2-series-soc have
> > similar design with initial loongson3a while loongson2e/f seems less
> >
On Mon, Sep 16, 2019 at 03:40:50AM +0200, Ahmed S. Darwish wrote:
> On Sun, Sep 15, 2019 at 09:29:55AM -0700, Linus Torvalds wrote:
> > On Sat, Sep 14, 2019 at 11:51 PM Lennart Poettering
> > wrote:
> > >
> > > Oh man. Just spend 5min to understand the situation, before claiming
> > > this was
Hi Pengfei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi all,
Today's linux-next merge of the kselftest tree got a conflict in:
tools/testing/selftests/tpm2/Makefile
between commit:
3fb2179b0f3553a ("selftests/tpm2: Add the missing TEST_FILES assignment")
from the tpmdd tree and commit:
d04e26067d13f01 ("selftests: tpm2: install python
On 3/9/19 7:45 pm, Anshuman Khandual wrote:
> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs
I could not find this path in the code, the only called for get_nid_for_pfn()
was register_mem_sect_under_node() when the system is under boot.
> entries between memory block
On Sun, Sep 15, 2019 at 09:29:55AM -0700, Linus Torvalds wrote:
> On Sat, Sep 14, 2019 at 11:51 PM Lennart Poettering
> wrote:
> >
> > Oh man. Just spend 5min to understand the situation, before claiming
> > this was garbage or that was garbage. The code above does not block
> > boot.
>
> Yes it
On Thu, Sep 05, 2019 at 04:02:37PM +1000, Stephen Rothwell wrote:
> As I said yesterday, there will be no release today, or any day until
> September 30.
I'm going to try to provide some builds for this week (16th-20th).
There may also be a build for the 15th depending on how much rebuilding
the
From: Frank Shi
Add tas2770 smart PA kernel driver
Signed-off-by: Frank Shi
---
sound/soc/codecs/Kconfig | 5 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tas2770.c | 932 +
sound/soc/codecs/tas2770.h | 166
4 files changed,
From: Frank Shi
Add tas2770 smart PA dt bindings
Signed-off-by: Frank Shi
---
.../devicetree/bindings/sound/tas2770.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tas2770.txt
diff --git
On 7/20/2019 1:18 AM, Paolo Bonzini wrote:
On 19/07/19 08:31, Tao Xu wrote:
Ping for comments :)
Hi, I'll look at it for 5.4, right after the merge window.
Paolo
Hi paolo,
Linux 5.3 has released, could you review these patches. Thank you very much!
Tao
On 7/16/2019 2:55 PM, Tao Xu
Hi all,
Today's linux-next merge of the char-misc tree got a conflict in:
drivers/android/binderfs.c
between commit:
e7d8840d4b626 ("vfs: Convert binderfs to use the new mount API")
from the vfs tree and commit:
f00834518ed31 ("binder: add a mount option to show global stats")
from
在 2019/9/16 6:00, Richard Weinberger 写道:
> On Fri, Aug 16, 2019 at 10:01 AM chengzhihao wrote:
>>
>>> ubifs_assert(c, p < c->gap_lebs + c->lst.idx_lebs);
>>
>> I've done 50 problem reproduces on different flash devices and made sure
>> that the assertion was not triggered. See record.txt for
On 9/15/19 1:25 PM, Helen Koike wrote:
Hi Shuah,
Thanks for the patch.
On 9/6/19 11:42 PM, Shuah Khan wrote:
vimc uses Component API to split the driver into functional components.
The real hardware resembles a monolith structure than component and
component structure added a level of
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/ia64/Kconfig
between commits:
fc5bad03709f9 ("ia64: remove the hpsim platform")
cf07cb1ff4ea0 ("ia64: remove support for the SGI SN2 platform")
from the ia64 tree and commit:
a2cbfd46559e8 ("arch, ia64: Make
On 9/15/19 1:25 PM, Helen Koike wrote:
Hi Shuah,
On 9/6/19 11:42 PM, Shuah Khan wrote:
Move duplicated IS_SRC and IS_SINK dfines to common header. Rename
them to VIMC_IS_SRC and VIM_IS_SINK.
Signed-off-by: Shuah Khan
---
drivers/media/platform/vimc/vimc-common.h | 4
On Sun, 15 Sep 2019 11:20:40 PDT (-0700), m...@kernel.org wrote:
On Sun, 15 Sep 2019 18:31:33 +0100,
Palmer Dabbelt wrote:
Hi Palmer,
On Sun, 15 Sep 2019 07:24:20 PDT (-0700), m...@kernel.org wrote:
> On Thu, 12 Sep 2019 22:40:34 +0100,
> Darius Rad wrote:
>
> Hi Darius,
>
>>
>> As per the
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.4
for you to fetch changes up to
On Fri, Sep 13, 2019 at 03:13:26PM -0400, Alan Stern wrote:
> On Thu, 12 Sep 2019, Paul E. McKenney wrote:
>
> > On Fri, Sep 06, 2019 at 02:11:29PM -0400, Alan Stern wrote:
>
> > > To this end, the LKMM imposes three extra restrictions, together
> > > called the "plain-coherence" axiom because
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
tags/regulator-v5.4
for you to fetch changes up to
Hi Alexandre, thanks for the thoughts.
On Thu, Sep 12, 2019 at 9:09 AM Alexandre Belloni
wrote:
>
> Hi Nick,
>
> On 10/09/2019 16:19:29+0100, Nick Crews wrote:
> > Check that the time received from the RTC HW is valid,
> > otherwise the computation of rtc_year_days() in the next
> > line could,
Hi all,
Today's linux-next merge of the block tree got a conflict in:
block/blk-settings.c
include/linux/blkdev.h
between commit:
45147fb522bb459e7 ("block: add a helper function to merge the segments")
from the dma-mapping tree and commit:
68c43f133a754cbf5 ("block: Introduce
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4 (2019-08-11 13:26:41 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
tags/regmap-v5.4
for you to fetch changes up to
Hi all,
Today's linux-next merge of the modules tree got a conflict in:
include/linux/export.h
between at least commit:
69a94abb82eed ("export.h, genksyms: do not make genksyms calculate CRC of
trimmed symbols")
from the compiler-attributes tree and commit:
cb9b55d21fe06 ("module: add
Hello, Maintainer(Russell King)...
Would you please update the feedback for this patch?
2019년 9월 11일 (수) 오후 11:16, Austin Kim 님이 작성:
>
> Since rel->r_offset is declared as Elf32_Addr,
> this value is always non-negative.
> typedef struct elf32_rel {
> Elf32_Addrr_offset;
> Elf32_Word
Hi Linus,
Please pull hwmon updates for Linux v5.4 from signed tag:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-for-v5.4
Thanks,
Guenter
--
The following changes since commit a55aa89aab90fae7c815b0551b07be37db359d76:
Linux 5.3-rc6 (2019-08-25
Hi all,
Today's linux-next merge of the modules tree got a conflict in:
scripts/Makefile.modpost
between commit:
9b9a3f20cbe0ba ("kbuild: split final module linking out into
Makefile.modfinal")
from the kbuild tree and commit:
eb8305aecb958e ("cripts: Coccinelle script for namespace
On Fri, Aug 16, 2019 at 10:01 AM chengzhihao wrote:
>
> > ubifs_assert(c, p < c->gap_lebs + c->lst.idx_lebs);
>
> I've done 50 problem reproduces on different flash devices and made sure that
> the assertion was not triggered. See record.txt for details.
Thanks for letting me know. :)
I need
So we've had a fairly quiet last week, but I think it was good that we
ended up having that extra week and the final rc8.
Even if the reason for that extra week was my travel schedule rather
than any pending issues, we ended up having a few good fixes come in,
including some for some bad btrfs
On Thu, Aug 29, 2019 at 2:50 AM Gustavo A. R. Silva
wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/dml/Makefile
between commit:
54b8ae66ae1a345 ("kbuild: change *FLAGS_.o to take the path
relative to $(obj)")
from the kbuild tree and commits:
0f0727d971f6fdf ("drm/amd/display: readd
zswap_writeback_entry() maps a handle to read swpentry first, and
then in the most common case it would map the same handle again.
This is ok when zbud is the backend since its mapping callback is
plain and simple, but it slows things down for z3fold.
Since there's hardly a point in unmapping a
On Mon, 16 Sep 2019, Pengfei Li wrote:
> KMALLOC_NORMAL is the most frequently accessed, and kmalloc_caches[]
> is initialized by different types of the same size.
>
> So modifying kmalloc_caches[type][idx] to kmalloc_caches[idx][type]
> will benefit performance.
>
> $ ./scripts/bloat-o-meter
On Mon, 16 Sep 2019, Pengfei Li wrote:
> This is a preparation patch, just replace 0 with ZERO_SIZE_ALLOC
> as the return value of zero sized requests.
>
> Signed-off-by: Pengfei Li
Acked-by: David Rientjes
On Mon, 16 Sep 2019, Pengfei Li wrote:
> Currently, kmalloc_cache[] is not sorted by size, kmalloc_cache[0]
> is kmalloc-96, kmalloc_cache[1] is kmalloc-192 (when ARCH_DMA_MINALIGN
> is not defined).
>
> As suggested by Vlastimil Babka,
>
> "Since you're doing these cleanups, have you
On Mon, 16 Sep 2019, Pengfei Li wrote:
> The type of local variable *type* of new_kmalloc_cache() should
> be enum kmalloc_cache_type instead of int, so correct it.
>
> Signed-off-by: Pengfei Li
> Acked-by: Vlastimil Babka
> Acked-by: Roman Gushchin
Acked-by: David Rientjes
On Mon, 16 Sep 2019, Pengfei Li wrote:
> The size of kmalloc can be obtained from kmalloc_info[],
> so remove kmalloc_size() that will not be used anymore.
>
> Signed-off-by: Pengfei Li
> Acked-by: Vlastimil Babka
> Acked-by: Roman Gushchin
Acked-by: David Rientjes
On Mon, 16 Sep 2019, Pengfei Li wrote:
> There are three types of kmalloc, KMALLOC_NORMAL, KMALLOC_RECLAIM
> and KMALLOC_DMA.
>
> The name of KMALLOC_NORMAL is contained in kmalloc_info[].name,
> but the names of KMALLOC_RECLAIM and KMALLOC_DMA are dynamically
> generated by
On Mon, 16 Sep 2019, Pengfei Li wrote:
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 2aed30deb071..e7903bd28b1f 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1165,12 +1165,9 @@ void __init setup_kmalloc_cache_index_table(void)
>
Modify the scaler subdevice to accept setting the resolution of the source
pad (previously the source resolution would always be 3 times the sink for
both dimensions). Now any resolution can be set at src (even smaller ones)
and the sink video will be scaled to match it.
Test example: With the
Could someone please review this?
On 2019-09-04 03:15, Jethro Beekman wrote:
> Some flash controllers don't have a software sequencer. Avoid
> configuring the register addresses for it, and double check
> everywhere that its not accidentally trying to be used.
>
> Every use of `sregs` is now
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
between commit:
bf280c0387ebbf8ee ("ixgbe: fix double clean of Tx descriptors with xdp")
from Linus' tree and commit:
5c129241e2de79f09 ("ixgbe: add support for AF_XDP
Lad, Prabhakar wrote on Sat [2019-Sep-14 11:33:42
+0100]:
> Hi Benoit,
>
> On Thu, Sep 12, 2019 at 1:58 PM Benoit Parrot wrote:
> >
> > On some board it is possible that the sensor 'powerdown'
> > pin might be controlled with a gpio instead of being
> > tied to always powered.
> >
> > This
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/bluetooth/btusb.c
between commit:
1ffdb51f28e8ec ("Revert "Bluetooth: btusb: driver to enable the usb-wakeup
feature"")
from Linus' tree and commit:
9e45524a011107 ("Bluetooth: btusb: Fix suspend issue
On Sun, Sep 15, 2019 at 09:01:30PM +0200, Pavel Machek wrote:
On Fri 2019-09-13 14:04:58, Greg Kroah-Hartman wrote:
[ Upstream commit 72bbf9358c3676bd89dc4bd8fb0b1f2a11c288fc ]
The state related to the VP assist page is still managed by the LAPIC
code in the pv_eoi field.
I don't get it.
Lad, Prabhakar wrote on Sat [2019-Sep-14 11:11:02
+0100]:
> Hi Benoit,
>
> Thank you for the patch.
>
> On Thu, Sep 12, 2019 at 1:58 PM Benoit Parrot wrote:
> >
> > Add powerdown-gpios to the list of optional properties for the OV2659
> > camera sensor.
> >
> > Signed-off-by: Benoit Parrot
>
We have an interrupt handler for the wake-up GPIO pin, but we're missing
the code to wake-up the system. This can cause timeouts receiving data
for the UART that shares the wake-up GPIO pin with the USB PHY.
All we need to do is just wake the system and kick the autosuspend
timeout to fix the
1 - 100 of 281 matches
Mail list logo
