On 2019-02-26, Petr Mladek wrote:
>> When new consoles register, they currently print how many messages
>> they have missed. However, many (or all) of those messages may still
>> be in the ring buffer. Add functionality to print as much of the
>> history as available. This is a clean replacement o
On Fri, Feb 22, 2019 at 11:27:05AM -0800, Alexei Starovoitov wrote:
> On Fri, Feb 22, 2019 at 09:43:14AM -0800, Linus Torvalds wrote:
> >
> > Then we should still probably fix up "__probe_kernel_read()" to not
> > allow user accesses. The easiest way to do that is actually likely to
> > use the "u
[ Drop codeaurora.org devs ]
On 26/02/2019 15:52, Martin K. Petersen wrote:
Revert the original patch, and clean up loose ends in the next patch.
>>>
>>> This commit isn't a revert. Why not?
>>
>> What do you mean?
>
> Your commit states it reverts the original patch but the submission is
>
On 02/26, Jiri Slaby wrote:
>
> On 10. 01. 19, 18:52, Andrei Vagin wrote:
> > --- a/kernel/exit.c
> > +++ b/kernel/exit.c
> > @@ -558,12 +558,14 @@ static struct task_struct *find_alive_thread(struct
> > task_struct *p)
> > return NULL;
> > }
> >
> > -static struct task_struct *find_child_rea
On 25/02/2019 at 22:25, Alexandre Belloni wrote:
> Make the driver OF only as since AVR32 has been removed from the kernel,
> there are only OF enabled platform using it.
>
> Signed-off-by: Alexandre Belloni
It looks good to me:
Acked-by: Nicolas Ferre
Thanks Alexandre.
Best regards,
Nicola
On 2/25/19 7:03 AM, Roman Gushchin wrote:
> On Fri, Feb 22, 2019 at 08:58:25PM +0300, Andrey Ryabinin wrote:
>> In a presence of more than 1 memory cgroup in the system our reclaim
>> logic is just suck. When we hit memory limit (global or a limit on
>> cgroup with subgroups) we reclaim some mem
On Tue 2019-02-12 15:29:54, John Ogness wrote:
> If the CON_PRINTBUFFER flag is not set, do not replay the history
> for that console.
This patch fixes a regression caused by previous patches.
We need to do it a way that does not cause the regression
and do not break bisection.
> diff --git a/ker
On 2/25/19 2:11 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.104 release.
There are 71 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On Tue, Feb 26, 2019 at 03:47:30PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 26, 2019 at 06:28:45AM -0800, Paul E. McKenney wrote:
> > I must confess to not being all that sympathetic to code that takes
> > advantage of happenstance stack-frame layout. Is there some reason
> > we need that?
>
>
EMC1444 is compatible with EMC1404. Add it to device ID table.
Reviewed-by: David Thompson
Signed-off-by: Shravan Kumar Ramani
---
drivers/hwmon/emc1403.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwmon/emc1403.c b/drivers/hwmon/emc1403.c
index bdab47a..88f6a40 100644
--- a/dr
On 2/26/19 2:02 AM, Marc Kleine-Budde wrote:
> On 1/29/19 7:06 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>> drivers/net/can/peak_canfd/peak_pc
On 2/26/2019 3:41 PM, Greg Kroah-Hartman wrote:
The dev_links_info structure has 4 bytes of padding at the end of it
when embedded in struct device (which is the only place it lives). To
help reduce the size of struct device pack this structure so we can take
advantage of the hole with later str
26.02.2019 18:21, Greg Kroah-Hartman пишет:
> On Tue, Feb 26, 2019 at 06:08:17PM +0300, Dmitry Osipenko wrote:
>> 26.02.2019 17:58, Greg Kroah-Hartman пишет:
>>> On Tue, Feb 26, 2019 at 05:33:05PM +0300, Dmitry Osipenko wrote:
26.02.2019 13:56, Greg Kroah-Hartman пишет:
> On Mon, Feb 25, 2
On 2/25/19 2:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.26 release.
There are 152 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 2/26/19 6:47 AM, Pierre Morel wrote:
On 25/02/2019 19:36, Tony Krowiak wrote:
On 2/22/19 10:29 AM, Pierre Morel wrote:
We prepare the interception of the PQAP/AQIC instruction for
the case the AQIC facility is enabled in the guest.
We add a callback inside the KVM arch structure for s390 fo
* Axel Lin [190226 05:52]:
> This driver uses regulator_get/set_voltage_sel_regmap so it does not use
> vsel_shift. Actually, vsel_shift can be calculated by vsel_mask setting.
Thanks for doing this, still works for me:
Tested-by: Tony Lindgren
On 2/25/19 2:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.20.13 release.
There are 183 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
* Axel Lin [190226 05:52]:
> They should never change, make them const.
Acked-by: Tony Lindgren
When hypercalls is used for sending IPIs, kexec will fail with a kernel
panic like this:
kexec_core: Starting new kernel
BUG: unable to handle kernel NULL pointer dereference at
PGD 800057995067 P4D 800057995067 PUD 57990067 PMD 0
Oops: 0002 [#1] SMP PTI
CPU: 0 PID: 1016 C
On 01/02/2019 09:30, Weiyi Lu wrote:
> From: Owen Chen
>
> PLLs with tuner_en bit, such as APLL1, need to disable
> tuner_en before apply new frequency settings, or the new frequency
> settings (pcw) will not be applied.
> The tuner_en bit will be disabled during changing PLL rate
> and be res
On 2019-02-12 17:28:57 [+0100], To linux-kernel@vger.kernel.org wrote:
> The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> timer callback requires this flag at all. Its sole purpose is to ensure
> synchronisation in the workqueue code.
>
> Remove TIMER_IRQSAFE flag because
On Sun, Feb 24, 2019 at 3:58 PM Ken Milmore wrote:
> Setting charge thresholds seems to basically work, but one thing worth
> mentioning is that charge_start_threshold and charge_stop_threshold
> appear to be tied together; AFAICT setting one also sets the other to
> the same value. The battery do
Hi,
On Tue, Feb 26, 2019 at 01:52:29PM +0800, Axel Lin wrote:
> This driver uses regulator_get/set_voltage_sel_regmap so it does not use
> vsel_shift. Actually, vsel_shift can be calculated by vsel_mask setting.
>
> Signed-off-by: Axel Lin
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Tue, Feb 26, 2019 at 01:52:30PM +0800, Axel Lin wrote:
> They should never change, make them const.
>
> Signed-off-by: Axel Lin
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/regulator/cpcap-regulator.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> dif
On Tue, Feb 26, 2019 at 03:31:59PM +0800, Wei Yang wrote:
> Leverage __ATTR_RO_MODE to define rev sysfs instead of using open code
> to define the attribute.
>
> Signed-off-by: Wei Yang
> ---
> drivers/firmware/qemu_fw_cfg.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
On 2/22/19 10:29 AM, Pierre Morel wrote:
The AP interruptions are assigned on a queue basis and
the GISA structure is handled on a VM basis, so that
we need to add a structure we can retrieve from both side
holding the information we need to handle PQAP/AQIC interception
and setup the GISA.
Sinc
hi,
David reported a crash related to return kprobes.
The change below tries to explain it and fix it,
but I'm sending it as RFC because I don't follow
kprobes code that much, so I might have missed
something.
thanks,
jirka
---
We can call recycle_rp_inst from both task and irq contexts,
so we s
MP2 controllers have two separate busses, so may accommodate up to two I2C
adapters. Those adapters are listed in the ACPI namespace with the
"AMDI0011" HID, and probed by a platform driver.
Communication with the MP2 takes place through MMIO registers, or through
DMA for more than 32 bytes transf
commit 5b0d62108b46 ("mmc: sdhci-omap: Add platform specific reset
callback") skips data resets during tuning operation. Because of this,
a data error or data finish interrupt might still arrive after a command
error has been handled and the mrq ended. This ends up with a "mmc0: Got
data interrupt
Some platforms might need a custom method for handling command error
interrupts. Add a callback to sdhci_ops to facilitate the same. Move
default command error handling to its own non-static function so it can
be called from platform drivers. Also make sdhci_finish_command()
non-static.
Fixes: 5b0
These patches fix the following error message in dra7xx boards:
[4.833198] mmc1: Got data interrupt 0x0002 even though no data
operation was in progress.
Tested with 100 times boot tests on dra71x-evm, dra72x-evm and
dra7xx-evm.
Faiz Abbas (2):
mmc: sdhci: Add platform_cmd_err() to sdhci_o
On 2019-02-26 2:34 a.m., Joerg Roedel wrote:
> On Wed, Feb 13, 2019 at 10:54:42AM -0700, Logan Gunthorpe wrote:
>> iommu/vt-d: Add helper to set an IRTE to verify only the bus number
>> iommu/vt-d: Allow interrupts from the entire bus for aliased devices
>
> Applied these two to the iommu t
Dear RT folks!
I'm pleased to announce the v4.19.25-rt16 patch set.
Changes since v4.19.25-rt15:
- The "preserve task state" change in cpu_chill() in the previous
release is responsible for missing a wake up. Reported by Mike
Galbraith.
- The x86-32 lazy preempt code was broken. Re
From: Ayan Kumar Halder
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal
This patchset aims to add support for AFBC in mali display driver with
the help of format modifiers. AFBC modifiers add some constraints to
framebuffer size, alignment, pitch, formats, etc
In the initial patchset ie
https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html
I had illu
From: Ayan Kumar Halder
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported mo
From: Brian Starkey
As we look to enable AFBC using DRM format modifiers, we run into
problems which we've historically handled via vendor-private details
(i.e. gralloc, on Android).
AFBC (as an encoding) is fully flexible, and for example YUV data can
be encoded into 1, 2 or 3 encoded "planes",
From: Ayan Kumar Halder
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp
On 2/23/19 1:29 AM, Arnd Bergmann wrote:
> Building an arm64 allmodconfig kernel with clang results in over 140 warnings
> about overly large stack frames, the worst ones being:
>
> drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame
> size of 20224 bytes in function 'st7
From: Ayan Kumar Halder
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits p
From: Ayan Kumar Halder
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if th
From: Ayan Kumar Halder
We need to define a common list of format modifiers supported by each of
the Mali display processors.
The following are the constraints with AFBC:-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported
From: Ayan Kumar Halder
We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane Y
On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote:
>
> Hi Ard,
>
> On 25/02/2019 12:45, Ard Biesheuvel wrote:
> > On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote:
> >>
> >> For quite some time, I wondered why the PCI mwifiex device built in my
> >> Chromebook was unable to use the good old legacy
From: Ayan Kumar Halder
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom croppi
On 2/26/19 12:08 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190225:
>
on i386:
ld: net/sched/sch_pie.o: in function `pie_timer':
sch_pie.c:(.text+0x604): undefined reference to `__udivdi3'
--
~Randy
On 02/26, Ravi Bangoria wrote:
>
> On 2/8/19 2:03 PM, Ravi Bangoria wrote:
> >
> >
> > On 2/6/19 7:06 PM, Oleg Nesterov wrote:
> >> Ravi, I am on vacation till the end of this week, can't read your patch
> >> carefully.
> >>
> >> I am not sure I fully understand the problem, but shouldn't we change
From: Ayan Kumar Halder
This new format is supported by DP550 and DP650
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers
The patch
ASoC: stm32: i2s: fix stream count management
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
The patch
ASoC: stm32: i2s: fix 16 bit format support
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
ASoC: stm32: i2s: fix dma configuration
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 Linus
The patch
ASoC: stm32: i2s: fix IRQ clearing
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 Linus duri
The patch
ASoC: stm32: i2s: remove useless callback
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 Lin
The patch
ASoC: stm32: i2s: skip useless write in slave mode
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 se
The patch
ASoC: stm32: i2s: fix race condition in irq handler
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 s
My apologies for the time it took to apply those changes.
I will also start working on an alternate (v17?) version with only one
module and replacing the platform driver by an ACPI lookup as
requested by Bjorn Helgaas, unless Nehal clarifies how AMD plans to
expand the platform driver.
Elie Moris
On 02/26/2019 03:58 PM, zerons wrote:
> On 2/26/19 22:44, Daniel Borkmann wrote:
>> On 02/26/2019 03:15 PM, zerons wrote:
>>> [ Upstream commit c91951f15978f1a0c6b65f063d30f7ea7bc6fb42 ]
>>
>> Thanks for the fix! What do you mean by "upstream commit" above in this
>> context?
>
> This patch is ba
Hi Marc,
> I indeed started off from 'git revert'
>
> $ git revert 60f0187031c0
> warning: inexact rename detection was skipped due to too many files.
> warning: you may want to set your merge.renamelimit variable to at
> least 18258 and retry the command.
> error: could not revert 60f0187031c0.
On 2019-02-26, Petr Mladek wrote:
> The warning about dropped messages gets lost when the current
> message is above console_loglevel and suppressed.
Here you are reporting a bug. (More on this below.)
> The suppressed messages allow even slow consoles to caught up
> with a flood of messages. Th
On Tue, Feb 26, 2019 at 03:15:50PM +, Christopher Lameter wrote:
> On Mon, 25 Feb 2019, den...@kernel.org wrote:
>
> > > @@ -67,7 +67,7 @@ static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp)
> > > pcpu_set_page_chunk(nth_page(pages, i), chunk);
> > >
> > > chunk->data = pages;
>
On Tue, Feb 26, 2019 at 08:51:17AM -0700, shuah wrote:
> On 2/25/19 2:09 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.13 release.
> > There are 183 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with
On Tue, Feb 26, 2019 at 07:23:53PM +0530, Naresh Kamboju wrote:
> On Tue, 26 Feb 2019 at 02:59, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 4.20.13 release.
> > There are 183 patches in this series, all will be posted as a response
> > to this one. If
On Wed 27-02-19 00:07:27, Liu Song wrote:
> In jbd2_get_transaction, a new transaction is initialized,
> and set to the j_running_transaction. No need for a return
> value, so remove it.
> Also, adjust some comments to match the actual operation
> of this function.
>
> Signed-off-by: Liu Song
Lo
Hi Sebastian,
Sorry, I just noticed your email...
On 02/05, Sebastian Andrzej Siewior wrote:
>
> On 2019-01-21 12:21:17 [+0100], Oleg Nesterov wrote:
> > > This is part of our ABI for *sure*. Inspecting that state is how
> > > userspace makes sense of MPX or protection keys faults. We even use
Kairui Song writes:
> When hypercalls is used for sending IPIs, kexec will fail with a kernel
> panic like this:
>
> kexec_core: Starting new kernel
> BUG: unable to handle kernel NULL pointer dereference at
> PGD 800057995067 P4D 800057995067 PUD 57990067 PMD 0
> Oops: 0
On Tue, 26 Feb 2019 06:59:21 +, Ran Wang wrote:
> When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
> (or its control signal) will turn on immediately on related Root Hub
> ports. Then the VBUS will be de-asserted for a little while during xhci
> reset (conducted by xhci dri
On Fri, Feb 08, 2019 at 05:04:25PM +, Julien Grall wrote:
> TIF_USEDFPU is not defined as thread flags for Arm64. So drop it from
> the documentation.
>
> Signed-off-by: Julien Grall
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infradead.org
Queued for 5.1. Thanks.
On Tue, Feb 26, 2019 at 09:10:57PM +0800, Qii Wang wrote:
> Add MT8183 i2c binding to binding file. Compare to MT2712 i2c
> controller, MT8183 has different registers, offsets, and clock.
>
> Signed-off-by: Qii Wang
> ---
> Documentation/devicetree/bindings/i2c/i2c-mtk.txt |4 +++-
> 1 file
undefined!
Signed-off-by: Randy Dunlap
Cc: Oded Gabbay
---
drivers/misc/habanalabs/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-next-20190226.orig/drivers/misc/habanalabs/Kconfig
+++ linux-next-20190226/drivers/misc/habanalabs/Kconfig
@@ -6,6 +6,7 @@ config HABANA_AI
The patch
regulator: cpcap: Constify omap4_regulators and xoom_regulators
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
regulator: cpcap: Remove unused vsel_shift from struct cpcap_regulator
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: 88pm8607: Remove unused fields from struct pm8607_regulator_info
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 som
The patch
regulator: 88pm8607: Simplify pm8607_list_voltage implementation
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
Hi Elie,
> My apologies for the time it took to apply those changes.
No worries. I am super happy that you are still around and willing to
continue the work!
> I will also start working on an alternate (v17?) version with only one
> module and replacing the platform driver by an ACPI lookup as
>
26.02.2019 12:13, Russell King - ARM Linux admin пишет:
> On Tue, Feb 26, 2019 at 01:55:37PM +0530, Sameer Pujar wrote:
>> The requirement for this came while adding runtime PM support for HDA
>> driver. There were concerns about driver explicitly handling !PM case.
>> In general, drivers need to h
From: Colin Ian King
Don't populate the const array ti_sn_bridge_supply_names on the
stack but instead make it static.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86
On Fri, Feb 22, 2019 at 5:10 PM Szabolcs Nagy wrote:
>
> On 22/02/2019 15:40, Andrey Konovalov wrote:
> > On Fri, Feb 22, 2019 at 4:35 PM Szabolcs Nagy wrote:
> >>
> >> On 22/02/2019 12:53, Andrey Konovalov wrote:
> >>> This patchset is meant to be merged together with "arm64 relaxed ABI" [1].
>
On Tue, Feb 26, 2019 at 03:16:44PM +, Christopher Lameter wrote:
> On Mon, 25 Feb 2019, Dennis Zhou wrote:
>
> > > @@ -27,7 +27,7 @@
> > > * chunk size is not aligned. percpu-km code will whine about it.
> > > */
> > >
> > > -#if defined(CONFIG_SMP) && defined(CONFIG_NEED_PER_CPU_PAGE_F
On 26/02/2019 17:26, Martin K. Petersen wrote:
>> I indeed started off from 'git revert'
>>
>> $ git revert 60f0187031c0
>> warning: inexact rename detection was skipped due to too many files.
>> warning: you may want to set your merge.renamelimit variable to at
>> least 18258 and retry the comman
The SIMCom SIM5218 and compatible devices have 5 USB interfaces, only 4
of which are serial ports. The fifth is a network interface supported
by the qmi-wwan driver. Furthermore, the serial ports do not support
modem control signals. Add driver_info flags to reflect this.
Signed-off-by: Mans Ru
From: YueHaibing
Date: Mon, 25 Feb 2019 02:03:28 +
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
> 'mlxsw_sp_port_get_link_ksettings':
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3062:5: warning:
> variable 'autoneg_st
Hi Jon,
On Tue, Feb 26, 2019 at 2:26 AM Jonathan Corbet wrote:
>
> On Sun, 24 Feb 2019 23:45:23 +0800
> Zenghui Yu wrote:
>
> > As linux-5.0 is coming up soon, the howto.rst document can be
> > updated for the new kernel version. Change all 4.x references
> > to 5.x now.
> >
> > Signed-off-by: Z
From:
Date: Tue, 26 Feb 2019 09:23:04 +
> This patch series seem pretty intrusive, so I would like that you wait
> for my explicit ACK before applying even next versions of it.
Ok.
On 26/02/2019 16:21, Ard Biesheuvel wrote:
> On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote:
>>
>> Hi Ard,
>>
>> On 25/02/2019 12:45, Ard Biesheuvel wrote:
>>> On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote:
For quite some time, I wondered why the PCI mwifiex device built in my
On Thu, Feb 14, 2019 at 03:00:53PM -0800, Bart Van Assche wrote:
> +/* hash_entry is used to keep track of dynamically allocated keys. */
> struct lock_class_key {
> + struct hlist_node hash_entry;
> struct lockdep_subclass_key subkeys[MAX_LOCKDEP_SUBCLASSES];
> };
I
On Fri, Feb 22, 2019 at 11:55 PM Dave Hansen wrote:
>
> On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> > The following testing approaches has been taken to find potential issues
> > with user pointer untagging:
> >
> > 1. Static testing (with sparse [3] and separately with a custom static
> >an
On Mon, Feb 11, 2019 at 5:36 AM Marc Gonzalez wrote:
>
> The UFSHC driver defines a few quirks that are not used anywhere:
>
> UFS_DEVICE_QUIRK_BROKEN_LCC
> UFS_DEVICE_NO_VCCQ
> UFS_DEVICE_QUIRK_NO_LINK_OFF
> UFS_DEVICE_NO_FASTAUTO
>
> Let's remove them.
>
> Signed-off-by: Marc Gonzalez
Whoops,
On 26-02-19, 15:24, Stephen Rothwell wrote:
> Hi Vinod,
>
> Today's linux-next merge of the slave-dma tree got a conflict in:
>
> drivers/dma/dmatest.c
>
> between commit:
>
> 6454368a804c ("dmaengine: dmatest: Abort test in case of mapping error")
>
> from Linus' tree and commit:
>
> 3
On Thu, Feb 14, 2019 at 10:00 AM Evan Green wrote:
>
> On Wed, Feb 13, 2019 at 6:40 PM Martin K. Petersen
> wrote:
> >
> >
> > Evan,
> >
> > > If the backing device for a loop device is a block device, then mirror
> > > the discard properties of the underlying block device into the loop
> > > dev
On Thu, Feb 14, 2019 at 03:00:56PM -0800, Bart Van Assche wrote:
> @@ -472,7 +473,8 @@ struct blk_flush_queue *blk_alloc_flush_queue(struct
> request_queue *q,
> if (!fq)
> goto fail;
>
> - spin_lock_init(&fq->mq_flush_lock);
> + lockdep_register_key(&fq->key);
> +
From: Yazen Ghannam
AMD systems may support Chip Select interleaving. However, on Fam17h+
this was not taken into account when printing the Chip Select sizes.
Add support to detect if Chip Selects are interleaved on Fam17h+, and
adjust the sizes accordingly.
Signed-off-by: Yazen Ghannam
---
Li
From: Yazen Ghannam
Future AMD systems may support x16 symbol sizes.
Recognize if a system is using x16 symbol size. Also, simplify the print
statement.
Note that a x16 syndrome vector table is not necessary like with x4 or
x8. This is because systems that support x16 symbol sizes will be SMCA
From: Yazen Ghannam
The first few models of Family 17h all had 2 Unified Memory Controllers
per Die, so this was treated as a fixed value. However, future systems
may have more Unified Memory Controllers per Die.
Related to this, the channel number and base address of a Unified Memory
Controller
From: Yazen Ghannam
Add the new Family 17h Model 30h PCI IDs to the AMD64 EDAC module.
This also fixes a probe failure that appeared when some other PCI IDs
for Family 17h Model 30h were added to the AMD NB code.
Fixes: be3518a16ef2 (x86/amd_nb: Add PCI device IDs for family 17h, model 30h)
Sig
From: Yazen Ghannam
The struct chip_select array that's used for saving Chip Select bases
and masks is fixed at length of two. There should be one struct
chip_select for each controller, so this array should be increased to
support systems that may have more than two controllers.
Increase the si
From: Yazen Ghannam
Define and use a macro for looping over the number of Unified Memory
Controllers.
No functional change.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20190219202536.15462-2-yazen.ghan...@amd.com
v1->v2:
* New in V2. Please see comment on Patch 2 V1 at li
On Mon, Feb 25, 2019 at 10:09:33PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.20.13 release.
> There are 183 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
On Tue, Feb 26, 2019 at 12:17 AM Huang, Ying wrote:
>
> As for fixing. Should we care about the cache line alignment of struct
> inode? Or its size is considered more important because there may be a
> huge number of struct inode in the system?
Thanks for the great analysis.
I suspect we _woul
On 25/02/2019 18:02, Szabolcs Nagy wrote:
On 25/02/2019 16:57, Catalin Marinas wrote:
On Tue, Feb 19, 2019 at 06:38:31PM +, Szabolcs Nagy wrote:
i think these rules work for the cases i care about, a more
tricky question is when/how to check for the new syscall abi
and when/how the TCR_EL1.
On Tue, Feb 26, 2019 at 12:09:28AM +, Peng Fan wrote:
> Hi Dennis,
>
> > -Original Message-
> > From: den...@kernel.org [mailto:den...@kernel.org]
> > Sent: 2019年2月25日 23:24
> > To: Peng Fan
> > Cc: t...@kernel.org; c...@linux.com; linux...@kvack.org;
> > linux-kernel@vger.kernel.org;
401 - 500 of 929 matches
Mail list logo
