Auxtrace records might have up to 7 bytes of padding appended. Adjust the
overlap accordingly.
Signed-off-by: Adrian Hunter
Cc: sta...@vger.kernel.org
---
.../util/intel-pt-decoder/intel-pt-decoder.c | 36 +--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/tools/
CYC packet timestamp calculation depends upon CBR which was being
cleared upon overflow (OVF). That can cause errors due to failing to
synchronize with sideband events. Even if a CBR change has been lost,
the old CBR is still a better estimate than zero. So remove the clearing
of CBR.
Signed-off-b
On Mon, Jan 28, 2019 at 10:02 PM Axel Lin wrote:
>
> Fix copy-paste mistake while converting to use defines for masks.
>
> Fixes: db4a555f7c4cf ("regulator: axp20x: use defines for masks")
> Signed-off-by: Axel Lin
Reviewed-by: Chen-Yu Tsai
Though I believe the latter three have already been f
On Thu, 24 Jan 2019 16:07:24 -0700
Keith Busch wrote:
> Platforms may provide system memory where some physical address ranges
> perform differently than others, or is side cached by the system.
>
> Add documentation describing a high level overview of such systems and the
> perforamnce and cach
On Sat, Feb 02, 2019 at 03:42:27PM +0100, Borislav Petkov wrote:
> On Sat, Feb 02, 2019 at 10:48:00PM +0900, Masahiro Yamada wrote:
> > '?=' is the same as '=' here.
>
> Sure but if the slowdown disappears, then make does something else for
> '?=' apparently vs for '='.
Ok, let me ask a different
From: Heyi Guo
1. In current implementation, every VLPI will temporarily be mapped to
the first CPU in system (normally CPU0) and then moved to the real
scheduled CPU later.
2. So there is a time window and a VLPI may be sent to CPU0 instead of
the real scheduled vCPU, in a multi-CPU virtual mac
From: Lubomir Rintel
Resetting bit 4 disables the interrupt delivery to the "secure
processor" core. This breaks the keyboard on a OLPC XO 1.75 laptop,
where the firmware running on the "secure processor" bit-bangs the
PS/2 protocol over the GPIO lines.
It is not clear what the rest of the bits
In the unlikely event that we cannot find any available LPI in the
system, we should gracefully return an error instead of carrying
on with no LPI allocated at all.
Fixes: 38dd7c494cf6 ("irqchip/gic-v3-its: Drop chunk allocation compatibility")
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq
Hi Thomas,
This is the final set of 5.0 updates from the irqchip department. This
time, an embarassingly large number of GICv3/GICv4 buglets (VLPI drop,
MSI allocation race on device sharing the same DevID, LPI pool
exhaustion and other cleanups), as well as a fix for PJ4-based systems
that appare
On Wed, Jan 30, 2019 at 1:44 PM Uwe Kleine-König
wrote:
>
> On Tue, Jan 29, 2019 at 05:13:18PM +0530, Yash Shah wrote:
> > DT documentation for PWM controller added.
> >
> > Signed-off-by: Wesley W. Terpstra
> > [Atish: Compatible string update]
> > Signed-off-by: Atish Patra
> > Signed-off-by:
On systems or VMs where multiple devices share a single DevID
(because they sit behind a PCI bridge, or because the HW is
broken in funky ways), we reuse the save its_device structure
in order to reflect this.
It turns out that there is a distinct lack of locking when looking
up the its_device, an
From: Zenghui Yu
According to ARM IHI 0069C (ID070116), we should use GITS_TYPER's
bits [7:4] as ITT_entry_size instead of [8:4]. Although this is
pretty annoying, it only results in a potential over-allocation
of memory, and nothing bad happens.
Fixes: 3dfa576bfb45 ("irqchip/gic-v3-its: Add pro
From: Xiang Chen
If sending IOs to many disks from single queue, it is possible that the
queue may be full. To avoid the situation, change queue depth from 512
to 4096 which is the max number of IOs for v3 hw.
Signed-off-by: Xiang Chen
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_
Do some very minor tidy-up, for things like needlessly initing
variable and not leaving whitespace before quote endings.
Originally-from: Xiang Chen
Originally-from: Luo Jiaxing
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 10 +-
drivers/scsi/hisi_sas/hisi_sas
This patchset introduces the following:
- DIX support for v3 hw
- Optimisation based on mapping CPUs to queues, much the same as other
SCSI drivers do today, without exposing > 1 queue to upper layer.
It is disabled by default and marked as experimental, due to ongoing
discussion here:
ht
From: Luo Jiaxing
Add an interface to manually trigger a debugfs dump.
Signed-off-by: Luo Jiaxing
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 34 +++
1 file changed, 34 insertions(+)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drive
To support queue mapped to a CPU, it needs to be ensured that issuing an
internal abort is safe, in that it is guaranteed that an internal abort
is processed for a single IO or a device after all the relevant
command(s) which it is attempting to abort have been processed by
the controller.
Current
From: Xiang Chen
This patch adds support for DIX to v3 hw driver.
For this, we build upon support for DIF, most significantly
is adding new DMA map and unmap paths.
Some pre-existing macro precedence issues are also tidied. They
were detected by checkpatch --strict.
Signed-off-by: Xiang Chen
From: Xiang Chen
For auto-control irq affinity mode, choose the dq to deliver IO according
to the current CPU.
Then it decreases the performance regression that fio and CQ interrupts
are processed on different node.
For user control irq affinity mode, keep it as before.
To realize it, also nee
Hi,
Nicolas Saenz Julienne writes:
>> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> > index 005e65922608..dec62f7f5dc8 100644
>> > --- a/drivers/usb/host/xhci.c
>> > +++ b/drivers/usb/host/xhci.c
>> > @@ -1238,6 +1238,21 @@ EXPORT_SYMBOL_GPL(xhci_resume);
>> >
>> >
>> >
Hi Frédéric,
On 2/5/19 11:47 AM, Frédéric Mathieu wrote:
Hi,
on an X86_64 architecture (Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz), I use
the linux kernel 4.9.146 with patch rt 125.
uname -a: Linux 4.9.146-rt125 #1 SMP PREEMPT RT Tue Jan 29 14:17:55 CET 2019
x86_64 GNU/Linux
I observed a strang
Commit-ID: 82f9ed3a93307089242ff8a5c694e82c8c93f522
Gitweb: https://git.kernel.org/tip/82f9ed3a93307089242ff8a5c694e82c8c93f522
Author: Borislav Petkov
AuthorDate: Tue, 5 Feb 2019 12:05:45 +0100
Committer: Borislav Petkov
CommitDate: Wed, 6 Feb 2019 11:41:21 +0100
x86/boot: Fix cmdline
Commit-ID: 82df8261c6a9523511d83ac367c7d64375ebabf4
Gitweb: https://git.kernel.org/tip/82df8261c6a9523511d83ac367c7d64375ebabf4
Author: Borislav Petkov
AuthorDate: Tue, 5 Feb 2019 14:04:01 +0100
Committer: Borislav Petkov
CommitDate: Wed, 6 Feb 2019 11:48:42 +0100
x86/boot: Fix randcon
On Wed, 06 Feb 2019 10:48:43 +,
Marc Zyngier wrote:
>
> Hi Thomas,
>
> This is the final set of 5.0 updates from the irqchip department. This
> time, an embarassingly large number of GICv3/GICv4 buglets (VLPI drop,
> MSI allocation race on device sharing the same DevID, LPI pool
> exhaustion
Lorenzo,
On Tue, Feb 5, 2019 at 11:13 PM Lorenzo Pieralisi
wrote:
>
> On Tue, Feb 05, 2019 at 11:09:19AM +0530, Subrahmanya Lingappa wrote:
> > Reviewed-by: Subrahmanya Lingappa
>
> I have a feeling you do not read what I write.
My apologies, I do read. I am new to reviewing process and trying
On 04/02/2019 18:36, Marc Gonzalez wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> index 6f4f4b79853b..831af20143da 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> @@ -711,6 +711,69 @@
>
On Wed, 6 Feb 2019 14:53:10 +0900
Masahiro Yamada wrote:
> I do not see any consistency about headers_install of
> and .
>
> According to my analysis of Linux 5.0-rc5, there are 3 groups:
>
> [1] Both and are exported
>
> alpha, arm, hexagon, mips, powerpc, s390, sparc, x86
>
> [2]
This patch renames active_banks (member of tpm_chip) to allocated_banks,
stores the number of allocated PCR banks in nr_allocated_banks (new member
of tpm_chip), and replaces the static array with a pointer to a dynamically
allocated array.
tpm2_get_pcr_allocation() determines if a PCR bank is all
Update
This version of the patch set includes three additional patches (5-7/7)
that allow users of the TPM driver to provide a digest for each PCR bank to
tpm_pcr_extend(). The new patches have been included to facilitate the
review of all the changes to support TPM 2.0 crypto agility for reading
Rename tpm2_* to tpm_* and move the definitions to include/linux/tpm.h so
that these can be used by other kernel subsystems (e.g. IMA).
Also, set the length of the digest array in tpm_digest to a new constant
named TPM_MAX_DIGEST_SIZE, equal to SHA512_DIGEST_SIZE.
Signed-off-by: Roberto Sassu
Re
On Wed, Feb 06, 2019 at 11:22:33AM +0100, Krzysztof Kozlowski wrote:
> On Wed, 6 Feb 2019 at 11:05, Charles Keepax
> wrote:
> >
> > DAIs linked to the dummy will not have an associated playback/capture
> > widget, so we need to skip the update in that case.
> >
> > Fixes: 078a85f2806f ("ASoC: dapm
Currently, the TPM driver retrieves the digest size from a table mapping
TPM algorithms identifiers to identifiers defined by the crypto subsystem.
If the algorithm is not defined by the latter, the digest size can be
retrieved from the output of the PCR read command.
The patch modifies the defini
The tpm_chip structure contains the list of PCR banks currently allocated
in the TPM. When support for crypto agility will be added to the TPM
driver, users of the driver have to provide a digest for each allocated
bank to tpm_pcr_extend(). With this patch, they can obtain the PCR bank
algorithms d
When crypto agility support will be added to the TPM driver, users of the
driver have to retrieve the allocated banks from chip->allocated_banks and
use this information to prepare the array of tpm_digest structures to be
passed to tpm_pcr_extend().
This patch retrieves a tpm_chip pointer from tpm
* Roger Quadros [2019-02-06 10:41]:
Hi,
On 21/01/19 16:02, Jochen Sprickerhof wrote:
[..]
I'm not sure why this it only works with the driver compiled into the
kernel nor why it needs a hard reset or why it was the line was dropped
when the patch was accepted. Would be great to get some feedb
Currently, tpm_pcr_extend() accepts as an input only a SHA1 digest.
This patch replaces the hash parameter of tpm_pcr_extend() with an array of
tpm_digest structures, so that the caller can provide a digest for each PCR
bank currently allocated in the TPM.
tpm_pcr_extend() will not extend banks f
On Wed, Feb 06, 2019 at 11:11:03AM +0100, Sylwester Nawrocki wrote:
> On 2/6/19 10:46, Sylwester Nawrocki wrote:
> > On 2/5/19 22:16, Krzysztof Kozlowski wrote:
> >> Bisect pointed to commit:
> >> commit 078a85f2806f0ffd11289009462a6a390f9adb5c
> >> Author: Charles Keepax
> >> Date:
On Wed, Feb 06, 2019 at 04:18:47PM +0530, Yash Shah wrote:
> On Wed, Jan 30, 2019 at 1:44 PM Uwe Kleine-König
> wrote:
> >
> > On Tue, Jan 29, 2019 at 05:13:18PM +0530, Yash Shah wrote:
> > > DT documentation for PWM controller added.
> > >
> > > Signed-off-by: Wesley W. Terpstra
> > > [Atish: Co
Add a new SERDES driver for TI's AM654x SoC which configures
the SERDES only for PCIe. Support fo USB3 will be added later.
SERDES in am654x has three input clocks (left input, externel reference
clock and right input) and two output clocks (left output and right
output) in addition to a PLL mux c
This patch series
*) adds support for SERDES module in am654
*) modifies phy_reset API to invoke pm_runtime_get/pm_runtime_put since
the reset callback can access registers.
*) Add *release* phy_ops to be invoked when the consumer relinquishes
PHY
Changes from v1:
*) Add *release* phy ops
AM654x has two SERDES instances. Each instance has three input clocks
(left input, externel reference clock and right input) and two output
clocks (left output and right output) in addition to a PLL mux clock
which the SERDES uses for Clock Multiplier Unit (CMU refclock).
The PLL mux clock can sele
PHY drivers may try to access PHY registers in the ->reset() callback.
Invoke phy_pm_runtime_get_sync() before invoking the ->reset() callback
so that the PHY drivers don't have to enable clocks by themselves before
accessing PHY registers.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/p
Add a new phy_ops *release* invoked when the consumer relinquishes the
PHY using phy_put/devm_phy_put. The initializations done by the PHY
driver in of_xlate call back can be can be cleaned up here.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/phy/phy-core.c | 5 +
include/linux/phy/ph
Hi Miquel,
On mar., janv. 08 2019, Miquel Raynal wrote:
> One pin can be muxed as PCIe endpoint card reset.
>
> Signed-off-by: Miquel Raynal
Applied to mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> dif
Hi Miquel,
On mar., janv. 08 2019, Miquel Raynal wrote:
> Ensure the PCIe endpoint card reset that is toggled by the PCIe
> controller itself is muxed correctly on the EspressoBin.
>
> Signed-off-by: Miquel Raynal
Applied to mvebu/dt64
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/
On Wed, 6 Feb 2019 at 12:00, Charles Keepax
wrote:
>
> On Wed, Feb 06, 2019 at 11:22:33AM +0100, Krzysztof Kozlowski wrote:
> > On Wed, 6 Feb 2019 at 11:05, Charles Keepax
> > wrote:
> > >
> > > DAIs linked to the dummy will not have an associated playback/capture
> > > widget, so we need to skip
Hi,
On 06/02/19 2:27 PM, Miquel Raynal wrote:
> Hi Kishon,
>
> Miquel Raynal wrote on Tue, 8 Jan 2019
> 17:31:17 +0100:
>
>> Hello,
>>
>> This series adds a new driver to support Armada 3700 COMPHY IP.
>> The series has been tested on an ESPRESSObin with SATA, PCIe
>> and USB3 host. For this p
Alex,
On 2/6/19 1:34 AM, Alex Williamson wrote:
> On Mon, 4 Feb 2019 14:42:32 +
> "Suthikulpanit, Suravee" wrote:
>
>> Once the IRQ ack notifier for in-kernel PIT is no longer required
>> and run-time AVIC activate/deactivate is supported, we can remove
>> the kernel irqchip split mode requi
On Wed, 6 Feb 2019 at 10:56, Rafael J. Wysocki wrote:
>
> On Tue, Feb 5, 2019 at 12:27 PM Rafael J. Wysocki wrote:
> >
> > On Tuesday, February 5, 2019 9:15:49 AM CET Ulf Hansson wrote:
> > > On Mon, 4 Feb 2019 at 12:45, Rafael J. Wysocki wrote:
> > > >
> > > > On Mon, Feb 4, 2019 at 12:40 PM Ra
Hi,
I hit use-after-free issues in UIO in 4.14.x, and discovered that it's
already fixed in later kernel versions:
commit a93e7b331568227500186a465fee3c2cb5dffd1f
Author: Hamish Martin
Date: Mon May 14 13:32:23 2018 +1200
uio: Prevent device destruction while fds are open
Can we have thi
In MMC, the discard arg is a read-only ext_csd parameter - set it once
on card init. To be consistent, do that for SD as well even though its
discard arg is always 0x0.
Signed-off-by: Avri Altman
---
drivers/mmc/core/block.c | 12 +++-
drivers/mmc/core/core.c | 4 ++--
drivers/mmc/core
SD specs version 4.x and 5.x have a dedicated slices in the SCR register.
Higher versions will rely on a combination of the existing fields.
Signed-off-by: Avri Altman
---
drivers/mmc/core/sd.c| 5 +
include/linux/mmc/card.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/
SD spec v5.1 adds discard support. The flows and commands matches those
in eMMC, Which leaves to set the appropriate discard arg in CMD38 if
DISCARD_SUPPORT (b313) is set in the SD_STATUS register.
We set this arg on card init: not in mmc_init_erase as one might expect
but arbitrarily once the car
SD spec v5.1 adds discard support. The flows and commands are similar to
mmc, so just set the discard arg in CMD38.
Actually, there is no need to check for the spec version like we are
doing, as it is assured that the reserved bits in earlier versions are
null. Do that anyway to document the spec
Accordingly to the documentation
---cut---
The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
fields can be cleared by either a reset or by writing the current
value of GCR_ERROR_CAUSE.ERR_TYPE to the
GCR_ERROR_CAUSE.ERR_TYPE register.
---cut---
Do exactly this
Fixes: 3885c2b463f6
Masahiro Yamada writes:
> On Tue, Feb 5, 2019 at 7:33 PM Michael Ellerman wrote:
>>
>> Masahiro Yamada writes:
>>
>> > It is fragile to rely on the compiler's optimization to avoid the
>> > section mismatch. Some functions may not be necessarily inlined
>> > when the compiler's inlining heuristi
Hi Yizhuo,
On 06/02/19 9:00 AM, Yizhuo wrote:
> In function miphy_osc_is_ready(), local variable "val"
> could be uninitalized. if function regmap_read() returns
> -EINVAL. However, this value is used in if statement.
> This is potentially unsafe.
>
> Signed-off-by: Yizhuo
Can you send all your
On Wed, Feb 06, 2019 at 11:28:05AM +0100, Philipp Zabel wrote:
> On Tue, 2019-02-05 at 23:13 +0100, Thierry Reding wrote:
> [...]
> > > Drivers that never call _acquire()/_release() must continue to work as
> > > they are, so exclusive reset controls have to be acquired by default.
> >
> > I don't
On 06/02/19 12:29 AM, Evan Green wrote:
> Expose a reset controller that the phy will later use to control its
> own PHY reset in the UFS controller. This will enable the combining
> of PHY init functionality into a single function.
>
> Signed-off-by: Evan Green
I'd like to get ACK from scsi/
From: Vladimir Kondratiev
Accordingly to the documentation
---cut---
The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
fields can be cleared by either a reset or by writing the current
value of GCR_ERROR_CAUSE.ERR_TYPE to the
GCR_ERROR_CAUSE.ERR_TYPE register.
---cut---
Do exactl
Hi stable maintainers,
Can you consider including these "random" patches in 4.14.y?
These are very useful in fixing esp. first-bootup delays of VMs due to
entropy starvation.
commit 39a8883a2b989d1d21bd8dd99f5557f0c5e89694
Author: Theodore Ts'o
Date: Tue Jul 17 18:24:27 2018 -0400
rando
Accordingly to the documentation
---cut---
The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
fields can be cleared by either a reset or by writing the current
value of GCR_ERROR_CAUSE.ERR_TYPE to the
GCR_ERROR_CAUSE.ERR_TYPE register.
---cut---
Do exactly this. Original value of cm
On Wed, Feb 06, 2019 at 12:14:56PM +0100, Krzysztof Kozlowski wrote:
> On Wed, 6 Feb 2019 at 12:00, Charles Keepax
> wrote:
> >
> > On Wed, Feb 06, 2019 at 11:22:33AM +0100, Krzysztof Kozlowski wrote:
> > > On Wed, 6 Feb 2019 at 11:05, Charles Keepax
> > > wrote:
> > > >
> > > > DAIs linked to th
From: Mathieu Desnoyers
> Sent: 04 February 2019 19:15
> I notice this commit as a possible culprit of the illegal instructions my
> lttng
> users are noticing on arm32 when using kprobes on a v4.19.13 Linux kernel
> in a Yocto environment [1]. They were able to reproduce the issue with perf
> as
Hi,
Can you pick this tiny one-liner patch to 4.4.y?
Fixes unexpected null byte in RCU "expedited stall" message.
commit ec3833ed02ae6ef2a933ece9de7cbab0c64c699e
Author: Paul E. McKenney
Date: Mon Jan 11 16:29:29 2016 -0800
rcu: Force boolean subscript for expedited stall warnings
-Tom
Verify the notification relevance by checking if the
device is a ethsw one.
Signed-off-by: Ioana Ciornei
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index f17
This patch set contains various small cleanup patches
for the DPAA2 ethsw driver.
Ioana Ciornei (1):
staging: fsl-dpaa2/ethsw: Check notification relevance
Razvan Stefanescu (6):
staging: fsl-dpaa2/ethsw: Fix setting port learning/flooding flags
staging: fsl-dpaa2/ethsw: Add network interfa
From: Razvan Stefanescu
Allocate MC portal with atomic context for I/O and enable network interface
statistics for hardware counters.
Signed-off-by: Razvan Stefanescu
Signed-off-by: Ioana Ciornei
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
From: Razvan Stefanescu
ethsw_set_learning()/ethsw_set_flood() use flags parameter as an
enable/disable (1/0) indicator. Previous usage sent incorrect values.
Signed-off-by: Razvan Stefanescu
Signed-off-by: Ioana Ciornei
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 5 +++--
1 file changed, 3
From: Razvan Stefanescu
Add the ndo_get_phys_port_name callback to the ethsw driver.
Signed-off-by: Razvan Stefanescu
Signed-off-by: Ioana Ciornei
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/et
From: Razvan Stefanescu
If the ethsw_port_init() call failed, the netdevice remains registered in
the system.
Use labels to ensure that netdevice is unregistered and freed in this case.
Signed-off-by: Razvan Stefanescu
Signed-off-by: Ioana Ciornei
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c
On Mon, Feb 04, 2019 at 10:32:39PM +0200, Oded Gabbay wrote:
> Hello,
> This is v3 of the Habana Labs kernel driver patch-set. It contains minor fixes
> according to reviews done on v2. In addition, it is rebased on v5.0-rc5.
>
> Link to v2 cover letter: https://lkml.org/lkml/2019/1/30/1003
>
> L
From: Razvan Stefanescu
Document each ETHSW_VLAN flag with the appropriate comment.
Signed-off-by: Razvan Stefanescu
Signed-off-by: Ioana Ciornei
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.h
b/driv
From: Razvan Stefanescu
Add a switch driver entry in the dpaa2 overview documentation.
Signed-off-by: Razvan Stefanescu
Signed-off-by: Ioana Ciornei
---
.../networking/device_drivers/freescale/dpaa2/overview.rst | 6 ++
MAINTAINERS
RDMSR in the trampoline code overrides EDX, but we use the register to
indicate if 5-level paging has to enabled. It leads to failure to boot
on a 5-level paging machine.
Preserve EDX on the stack while we are dealing with EFER.
Signed-off-by: Kirill A. Shutemov
Fixes: b677dfae5aa1 ("x86/boot/co
On 06/02/2019 12:42, Kishon Vijay Abraham I wrote:
> On 06/02/19 12:29 AM, Evan Green wrote:
>
>> Expose a reset controller that the phy will later use to control its
>> own PHY reset in the UFS controller. This will enable the combining
>> of PHY init functionality into a single function.
>>
>>
06.02.2019 1:46, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
On 14/01/2019 09:41, Christoph Hellwig wrote:
For entirely dma coherent architectures there is no good reason to ever
remap dma coherent allocation.
Yes there is, namely assembling large buffers without the need for
massive CMA areas and compaction overhead under memory fragmentation.
That ha
Deepa Dinamani writes:
> Add new socket timeout options that are y2038 safe.
>
> Signed-off-by: Deepa Dinamani
> Acked-by: Willem de Bruijn
> Cc: ccaul...@redhat.com
> Cc: da...@davemloft.net
> Cc: del...@gmx.de
> Cc: pau...@samba.org
> Cc: r...@linux-mips.org
> Cc: r...@twiddle.net
> Cc: clust
On 14/01/2019 09:41, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Acked-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 13 +
include/linux/dma-iommu.h | 13 +
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
Deepa Dinamani writes:
> SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
> as the time format. struct timeval is not y2038 safe.
> The subsequent patches in the series add support for new socket
> timeout options with _NEW suffix that will use y2038 safe
> data structures. Although
Hi Brian!
I found a second bug in this patch:
On Fri, Jan 25, 2019 at 5:23 PM Brian Masney wrote:
> - npins = platform_irq_count(pdev);
(...)
> - pctrl->npins = npins;
Do not lose this assignment of pctrl->npins.
pctrl->npins is used further down in the code and the gpiochip
does
Hey there.
Sorry to nag, but it seems we came to the conclusion that there's
indeed a problem with the current code, and then collectively decided
that we're done. Can I do something to expedite this? Are there any
issues with my proposed patch? If there are, what can I do to fix
those? Alternativ
On Wed, Feb 06, 2019 at 12:47:07AM +0200, Jarkko Sakkinen wrote:
> Make the changes necessary to detach TPM space code and TPM activation
> code out of the tpm_transmit() flow because of both of these can cause
> nested tpm_transmit() calls. The nesteds calls make the whole flow hard
> to maintain,
On Tue, Feb 05, 2019 at 11:55:06PM +0200, Jarkko Sakkinen wrote:
> Remove @flags from tpm_transmit() API. It is no longer used for
> anything.
>
> Signed-off-by: Jarkko Sakkinen
> Reviewed-by: Stefan Berger
> Tested-by: Stefan Berger
> ---
> v4:
> * Fix typos in comments.
> v3:
> * Fix typo i.e
On 02/05/19 at 09:15am, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 03:30:16PM -0700, Jerry Hoemann wrote:
> > Is your objection only to the second fallback of allocating
> > memory above >= 4GB? Or are you objecting to allocating from
> > (896 .. 4GB) as well?
>
> My problem is why should
The __next_mem_range() and __next_mem_range_rev() duplucate the code that
checks whether a region should be skipped because of node or flags
incompatibility.
Split this code into a helper function.
Signed-off-by: Mike Rapoport
---
mm/memblock.c | 53 +
On Tue, Feb 5, 2019 at 4:26 PM Eric W. Biederman wrote:
>
>
> Recently syzkaller was able to create unkillablle processes by
> creating a timer that is delivered as a thread local signal on SIGHUP,
> and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop
> failing to deliver SIGHUP but alwa
Hi,
These patches perform some minor cleanups in memblock.
Generated vs mmotm-2019-02-04-17-47.
Mike Rapoport (2):
memblock: remove memblock_{set,clear}_region_flags
memblock: split checks whether a region should be skipped to a helper
function
include/linux/memblock.h | 12 --
On Wed, Feb 6, 2019 at 12:24 PM Ulf Hansson wrote:
>
> On Wed, 6 Feb 2019 at 10:56, Rafael J. Wysocki wrote:
> >
> > On Tue, Feb 5, 2019 at 12:27 PM Rafael J. Wysocki
> > wrote:
> > >
> > > On Tuesday, February 5, 2019 9:15:49 AM CET Ulf Hansson wrote:
> > > > On Mon, 4 Feb 2019 at 12:45, Rafae
Hi Marc,
On 06/02/19 5:24 PM, Marc Gonzalez wrote:
> On 06/02/2019 12:42, Kishon Vijay Abraham I wrote:
>
>> On 06/02/19 12:29 AM, Evan Green wrote:
>>
>>> Expose a reset controller that the phy will later use to control its
>>> own PHY reset in the UFS controller. This will enable the combining
Hi,
On 05/02/19 2:16 PM, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote:
>>
>>
>> On 21/01/19 9:15 PM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Here is a set of patches to allow the phy framework consumers to test and
>>> apply runtime configurations.
>>>
On 05/02/19 12:51 AM, Scott Branden wrote:
> Looks good.
>
> On 2019-02-04 11:07 a.m., Ray Jui wrote:
>> From: Qingmin Liu
>>
>> When PIPEMIX=1, change the operation from 2x8 EP to 1x8 EP + 1x8 RC.
>>
>> Signed-off-by: Qingmin Liu
>> Signed-off-by: Ray Jui
> Acked-by: Scott Branden
merged,
On Wed, Feb 06, 2019 at 11:32:31AM +0800, Chen-Yu Tsai wrote:
> The A80 SoC has configuration registers for I/O bias voltage. Incorrect
> settings would make the affected peripherals inoperable in some cases,
> such as Ethernet RGMII signals biased at 2.5V with the settings still
> at 3.3V. However
On Wed, Feb 06, 2019 at 11:32:30AM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> On the Allwinner A80, the PIO pin controller includes configuration
> registers to set the I/O voltage. These must match the actual voltage
> provided externally. A mismatch results in signals not being passed
> throu
On Thu, 24 Jan 2019 16:07:23 -0700
Keith Busch wrote:
> Register memory side cache attributes with the memory's node if HMAT
> provides the side cache iniformation table.
>
> Signed-off-by: Keith Busch
Trivial suggestion inline.
> ---
> drivers/acpi/hmat/hmat.c | 32 +++
On 14/01/2019 09:41, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Acked-by: Robin Murphy
---
arch/arm64/mm/dma-mapping.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index fffba9
On Tue, Feb 05, 2019 at 11:00:40PM +0800, Chen-Yu Tsai wrote:
> On these A64 devices, the DC input jacks are wired to the ACIN pins of
> the PMIC, which is represented by the AC power supply. With the
> exception of the Nanopi A64, all devices include LiPo batteries or have
> connectors for them, w
Anurag,
On 23/01/19 9:40 PM, Anurag Kumar Vulisha wrote:
> Hi Kishon,
>
>> -Original Message-
>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
>> Sent: Monday, January 21, 2019 11:16 AM
>> To: Anurag Kumar Vulisha ; robh...@kernel.org; Mark
>> Rutland ; vivek.gau...@codeaurora.org
>
On Tue, Feb 05, 2019 at 11:42:25PM +0800, Chen-Yu Tsai wrote:
> The Libre Computer ALL-H3-CC H5 is one of the few boards that can have
> its eMMC run at HS-DDR speed mode. Mark it as such.
>
> Signed-off-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kern
101 - 200 of 994 matches
Mail list logo
