On Tue, Feb 05, 2019 at 07:59:22AM +, Thomas Hellstrom wrote:
> On Mon, 2019-02-04 at 13:11 +0100, Thomas Hellström wrote:
> > On Mon, 2019-02-04 at 09:19 +0100, Christoph Hellwig wrote:
> > > On Fri, Jan 25, 2019 at 09:12:13AM +0100, Thomas Hellstrom wrote:
> > > > -#if !defined(CONFIG_SWIOTLB
On Mon, Feb 4, 2019 at 4:24 AM Rasmus Villemoes
wrote:
>
> BUILD_BUG_ON() is a little annoying, since it cannot be used outside
> function scope. So one cannot put assertions about the sizeof() a
> struct next to the struct definition, but has to hide that in some
> more or less arbitrary function
On Tue, Feb 05, 2019 at 08:34:09AM +0100, Jiri Slaby wrote:
> I also suggest noticing the size 0 -> 8 change ;).
Ha!
And one would think that binutils would've seen the ".quad 0" in the
previous definition and do a proper size but that wouldn't have worked
most likely, because before it was a sim
On 2/5/2019 12:40 AM, Jarkko Sakkinen wrote:
On Tue, Feb 05, 2019 at 01:31:17AM +0200, Jarkko Sakkinen wrote:
On Mon, Feb 04, 2019 at 02:49:54PM +0100, Roberto Sassu wrote:
On 2/4/2019 2:37 PM, Jarkko Sakkinen wrote:
Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
ST33ZP2
On Mon, 4 Feb 2019 at 17:25, Vincent Guittot wrote:
>
> Similarly to what happened whith autosuspend, a deadlock has been raised
> with runtime accounting in the sequence:
>
> change_clocksource
> ...
> write_seqcount_begin
> ...
> timekeeping_update
> ...
> sh_cmt_
On Mon, 4 Feb 2019 at 17:26, Vincent Guittot wrote:
>
> Update accounting_timestamp field only when PM runtime is enable
> and don't forget to account the last state before disabling it.
>
> Suggested-by: Ulf Hansson
> Signed-off-by: Vincent Guittot
Reviewed-by: Ulf Hansson
Kind regards
Uffe
/commits/Jarkko-Sakkinen/tpm-st33zp24-Fix-the-name-collisions-in-tpm_st33zp24_spi-and-tpm_i2c_infineon/20190205-150003
base: git://git.infradead.org/users/jjs/linux-tpmdd next
config: x86_64-randconfig-x013-201905 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
# save
H Greg
>
>On Thu, Jan 31, 2019 at 11:52:29AM +, Pawel Laszczak wrote:
>> Patch moves some decoding functions from driver/usb/dwc3/debug.h driver
>> to driver/usb/common/debug.c file. These moved functions include:
>> dwc3_decode_get_status
>> dwc3_decode_set_clear_feature
>> dwc3_de
On Sun, Feb 3, 2019 at 5:50 PM Vladimir Kondratiev
wrote:
>
> From: Vladimir Kondratiev
>
> When compiling into output directory using O=, many files
> created under KBUILD_OUTPUT that git considers
> as new ones; git clients, ex. "git gui" lists it, and it clutters
> file list making it difficul
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 user need to specify high or low allocation
explicitly
On Mon, 4 Feb 2019 at 12:45, Rafael J. Wysocki wrote:
>
> On Mon, Feb 4, 2019 at 12:40 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Feb 1, 2019 at 4:18 PM Ulf Hansson wrote:
> > >
> > > On Fri, 1 Feb 2019 at 02:04, Rafael J. Wysocki wrote:
> > > >
> > > > Hi Greg at al,
> > > >
> > > > This is a
Hi Sven,
On Mon, Feb 04, 2019 at 05:09:52PM -0500, Sven Van Asbroeck wrote:
> The work which is scheduled by led_classdev->brightness_set() is
> potentially left pending or running until after the driver module
> is unloaded.
>
> Fix by using resource-controlled version of INIT_WORK().
I believe
On 2/4/19 5:41 PM, Tom Talpey wrote:
On 2/4/2019 12:21 AM, john.hubb...@gmail.com wrote:
From: John Hubbard
Performance: here is an fio run on an NVMe drive, using this for the fio
configuration file:
[reader]
direct=1
ioengine=libaio
blocksize=4096
size=1g
numj
Hi Yash,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pwm/for-next]
[also build test ERROR on v5.0-rc4 next-20190204]
[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/comm
Hi,
Pawel Laszczak writes:
>>On Thu, Jan 31, 2019 at 11:52:29AM +, Pawel Laszczak wrote:
>>> Patch moves some decoding functions from driver/usb/dwc3/debug.h driver
>>> to driver/usb/common/debug.c file. These moved functions include:
>>> dwc3_decode_get_status
>>> dwc3_decode_set_cl
On Sat, Feb 2, 2019 at 6:10 AM wrote:
>
> From: Jon Flatley
>
> gcc produces format warnings that clang suppresses. To keep behavior
> consistent between gcc and clang, don't suppress format warnings in
> clang.
>
> Signed-off-by: Jon Flatley
> ---
Applied to linux-kbuild.
Thanks.
> script
On Mon, Feb 04, 2019 at 05:09:51PM -0500, Sven Van Asbroeck wrote:
> The work which is scheduled on a POR boot is potentially left
> pending or running until after the driver module is unloaded.
>
> Fix by using resource-controlled version of INIT_WORK().
>
> Signed-off-by: Sven Van Asbroeck
> -
We have now a HSDK device in our kernelci lab, but kernel builded via
the hsdk_defconfig ignore bootargs, so it cannot boot kernelci jobs yet.
Furthermore, I think the probability is that devices will be booted more via
uboot than by a debugger.
So this patch enable CONFIG_ARC_UBOOT_SUPPORT in hsd
We have now a HSDK device in our kernelci lab, but kernel builded via
the hsdk_defconfig lacks ramfs supports, so it cannot boot kernelci jobs
yet.
So this patch enable CONFIG_BLK_DEV_RAM in hsdk_defconfig.
Signed-off-by: Corentin Labbe
---
arch/arc/configs/hsdk_defconfig | 1 +
1 file changed,
Hello
In our kernelci lab, we have one hsdk device and since it is the only
ARC device at our disposal, it is important to made it availlable for
kernelci boot jobs.
Since kernelci build only defconfig without hacking it, it is important
that defconfig are bootable by default.
And so for hsdk_def
Hi,
>On Thu, Jan 31, 2019 at 11:52:32AM +, Pawel Laszczak wrote:
>> This patch introduce new Cadence USBSS DRD driver
>> to linux kernel.
>>
>> The Cadence USBSS DRD Driver is a highly
>> configurable IP Core which can be
>> instantiated as Dual-Role Device (DRD),
>> Peripheral Only and Host O
On Tue, Feb 05, 2019 at 12:18:46AM -0800, Dmitry Torokhov wrote:
> Hi Sven,
>
> On Mon, Feb 04, 2019 at 05:09:52PM -0500, Sven Van Asbroeck wrote:
> > The work which is scheduled by led_classdev->brightness_set() is
> > potentially left pending or running until after the driver module
> > is unloa
On Tue, Feb 05, 2019 at 09:08:33AM +0100, Roberto Sassu wrote:
> On 2/5/2019 12:40 AM, Jarkko Sakkinen wrote:
> > On Tue, Feb 05, 2019 at 01:31:17AM +0200, Jarkko Sakkinen wrote:
> > > On Mon, Feb 04, 2019 at 02:49:54PM +0100, Roberto Sassu wrote:
> > > > On 2/4/2019 2:37 PM, Jarkko Sakkinen wrote:
From: Borislav Petkov
Add James to the list of reviewers of the firmware-assisted RAS glue.
Signed-off-by: Borislav Petkov
Cc: James Morse
Cc: "Rafael J. Wysocki"
Cc: Tony Luck
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cd5f8ea1e08b..
On Tue, 5 Feb 2019 at 09:10, Ulf Hansson wrote:
>
> On Mon, 4 Feb 2019 at 17:25, Vincent Guittot
> wrote:
> >
> > Similarly to what happened whith autosuspend, a deadlock has been raised
> > with runtime accounting in the sequence:
> >
> > change_clocksource
> > ...
> > write_seqcount_be
On Mon, Feb 4, 2019 at 9:41 PM Maxime Ripard wrote:
>
> On Mon, Feb 04, 2019 at 06:16:24PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Feb 4, 2019 at 5:34 PM Maxime Ripard
> > wrote:
> > >
> > > On Sun, Feb 03, 2019 at 11:56:27PM +0800, Chen-Yu Tsai wrote:
> > > > The MMC device tree bindings include
On Mon, Feb 04, 2019 at 01:44:44PM -0800, Guenter Roeck wrote:
> On Mon, Feb 04, 2019 at 11:36:15AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.134 release.
> > There are 31 patches in this series, all will be posted as a response
> > to this one.
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.
> >
> > This is needed to support more phy classes
On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote:
> So, the compromise we reached in this case is that Intel will fully
> document the future silicon architecture, and then write the kernel
> implementation to _that_. Then, for the weirdo deployments where this
> feature is not enumerat
> On Feb 1, 2019, at 4:05 PM, Edward Cree wrote:
>
> This series introduces 'dynamic_calls', branch trees of static calls (updated
> at runtime using text patching), to avoid making indirect calls to common
> targets. The basic mechanism is
>if (func == static_key_1.target)
>call_sta
On Mon, Feb 04, 2019 at 01:09:12PM -0800, Fenghua Yu wrote:
> Intel SDM published TODAY does have IA32_CORE_CAPABILITY MSR enumerateion
> bit CPUID.0x7.0:EDX[30] now. Please check today's SDM for the bit:
> https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-vol
+Rob
Andrew,
On 04/02/19 17:33, Roger Quadros wrote:
> On 04/02/19 17:11, Andrew F. Davis wrote:
>> On 2/4/19 8:22 AM, Roger Quadros wrote:
>>> From: "Andrew F. Davis"
>>>
>>
>> [...]
>>
>>> +static const struct pruss_intc_match_data am437x_pruss_intc_data = {
>>> + .no_host7_intr = true,
>>
>
On Mon, Jan 28, 2019 at 04:34:06PM -0800, Rick Edgecombe wrote:
> From: Nadav Amit
>
> Provide a function for copying init_mm. This function will be later used
> for setting a temporary mm.
>
> Cc: Andy Lutomirski
> Cc: Kees Cook
> Cc: Dave Hansen
> Acked-by: Peter Zijlstra (Intel)
> Reviewe
Hi Chen-Yu,
On Fri, Jan 18, 2019 at 04:52:06PM +0800, Chen-Yu Tsai wrote:
> The register value lists for all the supported resolution settings all
> include a register address/value pair for setting the JPEG compression
> mode. With the exception of 1080p (which sets mode 2), all resolutions
> use
This patch adds I2C interface timing registers support for
proper bus rate configuration along with meeting the i2c spec
setup and hold times based on the tuning performed on Tegra210,
Tegra186 and Tegra194 platforms.
I2C_INTERFACE_TIMING_0 register contains TLOW and THIGH field
and Tegra I2C cont
Bus clear feature of Tegra I2C controller helps to recover from
bus hang when I2C master loses the bus arbitration due to the
slave device holding SDA LOW continuously for some unknown reasons.
Per I2C specification, the device that held the bus LOW should
release it within 9 clock pulses.
During
This patch sorts all the include headers alphabetically for the
I2C Tegra driver.
Acked-by: Thierry Reding
Reviewed-by: Dmitry Osipenko
Signed-off-by: Sowjanya Komatineni
---
[V9/V10/V11] : Rebased to 5.0-rc4
[V3/V4/V5/V7/V8] : Removed unsued headers in tegra I2C
[V2] : Added this in V2 to s
Tegra194 allows max of 64K bytes and Tegra186 and prior allows
max of 4K bytes of transfer per packet.
one sec timeout is not enough for transfers more than 10K bytes
at STD bus rate.
This patch updates I2C transfer timeout based on the transfer size
and I2C bus rate to allow enough time during m
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 needs full intervention of CPU to fill or empty FIFO's
an
On 31.01.2019 18:47, Cornelia Huck wrote:
> On Thu, 31 Jan 2019 09:52:46 +0100
> Michael Mueller wrote:
>
>> Assure a GISA is in use before accessing the IPM to avoid a
>> null pointer dereference issue.
>
> This series can hopefully make it into the next merge window;
> otherwise, queuing a
On Mon, Feb 04, 2019 at 03:24:23PM -0800, Dave Hansen wrote:
> Actually, there's one part of all this that I forgot. Will split lock
> detection be enumerated _widely_? IOW, will my laptop in 5 years
> enumerate support for it?
I would bloody hope so. Just for giggles, create an little program
On 2/5/19 7:26 AM, Tomasz Figa wrote:
> On Fri, Feb 1, 2019 at 12:18 AM Nicolas Dufresne wrote:
>>
>> Le jeudi 31 janvier 2019 à 22:34 +0900, Tomasz Figa a écrit :
>>> On Thu, Jan 31, 2019 at 9:42 PM Philipp Zabel
>>> wrote:
Hi Nicolas,
On Wed, 2019-01-30 at 10:32 -0500, Nicolas D
On Mon, Feb 04, 2019 at 12:01:31PM +0100, Gerd Hoffmann wrote:
> Commit "f4bd542bca drm/fb-helper: Scale back depth to supported maximum"
> uncovered a bug in the cirrus driver. It must create its own primary
> plane, using the correct format list, depending on the bpp module
> parameter, so it is
On Mon, Feb 04, 2019 at 07:38:58PM +0100, Gerd Hoffmann wrote:
> ttm_fbdev_mmap() just doesn't work. It appears to work fine, mmap()
> returns success, but any attempt to actually access the mapping causes a
> SIGBUS.
>
> We can just use drm_gem_prime_mmap() instead. Almost. We have to copy
> o
On Tue, Feb 05, 2019 at 06:06:50AM +0800, Tom Li wrote:
> > Since you care about this driver, considered converting it to a drm
> > display driver? You can still have all the acceleration and stuff, the
> > fbdev compat mode in drm is rather flexible.
> > -Daniel
>
> Yes, I know fbdev is now in ma
> On Feb 5, 2019, at 12:53 AM, Borislav Petkov wrote:
>
> On Mon, Jan 28, 2019 at 04:34:06PM -0800, Rick Edgecombe wrote:
>> From: Nadav Amit
>>
>> - * Allocate a new mm structure and copy contents from the
>> - * mm structure of the passed in task structure.
>> +/**
>> + * dup_mm() - duplicate
Patch series introducing support for ROHM BD70528 PMIC
Please note that patch 1 breaks compilation without patches 2 and 3
Knowing the bd718x7 driver is already in upstream, it might be good
if this change went through single tree, right?
ROHM BD70528 is a programmable Power Management IC for bat
Header rohm-bd718x7.h was split to generic and component specific
parts. This changed the struct bd718x7. Adapt the regulator driver to
these changes.
Signed-off-by: Matti Vaittinen
Acked-by: Mark Brown
---
drivers/regulator/bd718x7-regulator.c | 22 +++---
1 file changed, 11 in
Split the bd718x7.h to ROHM common and bd718x7 specific parts
so that we do not need to add same things in every new ROHM
PMIC header. Please note that this change requires changes also
in bd718x7 sub-device drivers for regulators and clk.
Signed-off-by: Matti Vaittinen
---
drivers/mfd/rohm-bd71
ROHM BD70528MWV is an ultra-low quiescent current general
purpose single-chip power management IC for battery-powered
portable devices.
Add MFD core which enables chip access for following subdevices:
- regulators/LED drivers
- battery-charger
- gpios
- 32.768kHz cl
ROHM BD70528 is an ultra low power PMIC with similar 32K clk as
bd718x7. Only difference (from clk perspective) is register address.
Add support for controlling BD70528 clk using bd718x7 driver.
Signed-off-by: Matti Vaittinen
---
drivers/clk/Kconfig | 6 +++---
drivers/clk/clk-bd718x7.c |
Header rohm-bd718x7.h was split to generic and component specific
parts. This changed the struct bd718x7. Adapt the clk driver to
these changes.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-bd718x7.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-
Document bindings for regulators (3 bucks, 3 LDOs and 2 LED
drivers) and 4 GPIO pins which can be configured for I/O or
as interrupt sources withe configurable trigger levels.
Signed-off-by: Matti Vaittinen
Reviewed-by: Rob Herring
Acked-by: Linus Walleij
---
.../devicetree/bindings/mfd/rohm,b
ROHM BD70528 PMIC has 4 GPIO pins. Allow them to be
controlled by GPIO framework.
IRQs are handled by regmap-irq and GPIO driver is not
aware of the irq usage.
Signed-off-by: Matti Vaittinen
Reviewed-by: Linus Walleij
---
drivers/gpio/Kconfig| 11 +++
drivers/gpio/Makefile | 1
Support RTC block in ROHM bd70528 power management IC. Support
getting and setting the time and date as well as arming an alarm
which can also be used to wake the PMIC from standby state.
HW supports wake interrupt only for the next 24 hours (sec, minute
and hour information only) so we limit also
This patch series add support of two new discovery boards based on
STM32MP157 MPU: stm32mp157a-dk1 and stm32mp157c-dk2.
stm32mp157a-dk1 board embeds a STM32MP157a SOC with AC package (TFBGA361,
148 ios) and 512MB of DDR3. Several connections are available on this boards:
4*USB2.0, 1*USB2.0 typeC,
Add support of stm32mp157a discovery1 board (part number: STM32MP157A-DK1).
This board embeds a STM32MP157a SOC with AC package (TFBGA361, 148 ios)
and 512MB of DDR3. Several connections are available on this boards:
4*USB2.0, 1*USB2.0 typeC, SDcard, RJ45, HDMI, Arduino connector, ...
This patch e
ROHM BD70528 PMIC includes battery charger block. Support charger
staus queries and doing few basic settings like input current limit
and charging current.
Signed-off-by: Matti Vaittinen
---
drivers/power/supply/Kconfig | 9 +
drivers/power/supply/Makefile | 1 +
drivers/p
Add support of stm32mp157c discovery2 board (part number: STM32MP157C-DK2).
This board is a "super-set" of stm32mp157a-dk1. It embeds a STM32MP157c SOC
with AC package (TFBGA361, 148 ios) and 512MB of DDR3. Same connections
than stm32mp157a-dk1 board are available. Display panel (otm8009a) and
Mura
Initial support for watchdog block included in ROHM BD70528
power management IC.
Configurations for low power states are still to be checked.
Signed-off-by: Matti Vaittinen
Acked-by: Guenter Roeck
---
Please note that I translated following comment:
"Otherwise I am ok with the patch." from Gu
Typo in title, it's a v1 not a v2.
On 2/5/19 10:07 AM, Alexandre Torgue wrote:
This patch series add support of two new discovery boards based on
STM32MP157 MPU: stm32mp157a-dk1 and stm32mp157c-dk2.
stm32mp157a-dk1 board embeds a STM32MP157a SOC with AC package (TFBGA361,
148 ios) and 512MB of
On 2/5/19 7:50 AM, Javier González wrote:
In order to respect mw_cuinits, pblk's write buffer maintains a
backpointer to protect data not yet persisted; when writing to the write
buffer, this backpointer defines a threshold that pblk's rate-limiter
enforces.
On small PU configurations, the follo
From: Bartosz Golaszewski
Add a DT binding document for max77650 ultra-low power PMIC. This
describes the core mfd device and the GPIO module.
Signed-off-by: Bartosz Golaszewski
---
.../devicetree/bindings/mfd/max77650.txt | 47 +++
1 file changed, 47 insertions(+)
create
From: Bartosz Golaszewski
Add basic support for the battery charger for max77650 PMIC.
Signed-off-by: Bartosz Golaszewski
---
drivers/power/supply/Kconfig| 7 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/max77650-charger.c | 355
From: Bartosz Golaszewski
I plan on extending this set of drivers so add myself as maintainer.
Signed-off-by: Bartosz Golaszewski
---
MAINTAINERS | 14 ++
1 file changed, 14 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c68de3cfd80..70106d30272b 100644
--- a/MAINTAIN
From: Bartosz Golaszewski
Add GPIO support for max77650 mfd device. This PMIC exposes a single
GPIO line.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpio/Kconfig | 7 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-max77650.c | 190 +++
From: Bartosz Golaszewski
Add support for the push- and slide-button events for max77650.
Signed-off-by: Bartosz Golaszewski
Acked-by: Dmitry Torokhov
---
drivers/input/misc/Kconfig | 9 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/max77650-onkey.c | 127 +
From: Bartosz Golaszewski
This adds basic support for LEDs for the max77650 PMIC. The device has
three current sinks for driving LEDs.
Signed-off-by: Bartosz Golaszewski
Acked-by: Jacek Anaszewski
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile| 1 +
drivers/leds/le
From: Bartosz Golaszewski
Add the DT binding document for the onkey module of max77650.
Signed-off-by: Bartosz Golaszewski
---
.../bindings/input/max77650-onkey.txt | 26 +++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ma
From: Bartosz Golaszewski
Add the DT binding document for the battery charger module of max77650.
Signed-off-by: Bartosz Golaszewski
---
.../power/supply/max77650-charger.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindin
From: Bartosz Golaszewski
This series adds support for max77650 ultra low-power PMIC. It provides
the core mfd driver and a set of five sub-drivers for the regulator,
power supply, gpio, leds and input subsystems.
Patches 1-4 add the DT binding documents. Patches 5-9 add all drivers.
Last patch
From: Bartosz Golaszewski
Add the core mfd driver for max77650 PMIC. We define five sub-devices
for which the drivers will be added in subsequent patches.
Signed-off-by: Bartosz Golaszewski
---
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/max77650.c
From: Bartosz Golaszewski
Add the DT binding document for the LEDs module of max77650.
Signed-off-by: Bartosz Golaszewski
---
.../bindings/leds/leds-max77650.txt | 57 +++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds
* Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
ST33ZP24_BUFSIZE.
* Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to
TPM_I2C_INFINEON_BUFSIZE.
* Rename TPM_RETRY in tpm_i2c_nuvoton to TPM_I2C_RETRIES.
* Remove TPM_HEADER_SIZE from tpm_i2c_nuvoton.
Cc
On 2/1/19 3:38 AM, Heiner Litz wrote:
This patch fixes a race condition where a write is mapped to the last
sectors of a line. The write is synced to the device but the L2P is not
updated yet. When the line is garbage collected before the L2P update is
performed, the sectors are ignored by the GC
On 04/02/19 13:07, Peter Zijlstra wrote:
> On Mon, Feb 04, 2019 at 01:02:36PM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 17, 2019 at 09:47:37AM +0100, Juri Lelli wrote:
> > > @@ -3233,11 +3233,11 @@ void cpuset_cpus_allowed(struct task_struct *tsk,
> > > struct cpumask *pmask)
> > > {
> > > u
On 04/02/19 12:55, Peter Zijlstra wrote:
> On Thu, Jan 17, 2019 at 09:47:37AM +0100, Juri Lelli wrote:
> > @@ -2366,7 +2366,7 @@ static int cpuset_common_seq_show(struct seq_file
> > *sf, void *v)
> > cpuset_filetype_t type = seq_cft(sf)->private;
> > int ret = 0;
> >
> > - spin_lock_i
On 04/02/19 13:45, Waiman Long wrote:
> On 02/04/2019 07:18 AM, Peter Zijlstra wrote:
> > On Mon, Feb 04, 2019 at 10:02:11AM +0100, Juri Lelli wrote:
> >> On 18/01/19 17:46, Juri Lelli wrote:
> >>> On 18/01/19 08:17, Tejun Heo wrote:
> On Thu, Jan 17, 2019 at 09:47:34AM +0100, Juri Lelli wrote
hi all,
with Kernel 4.9.150, I sometimes have "kernel panic - not syncing: Fatal
exception in interrupt" on two different servers. Dunno how to reproduce but
may be connected to high network traffic. Find screenshots, config.txt and
boot.msg here: https://www.netestate.de/kernel_panic/
cu,
brun
Just nitpicks:
Subject: [PATCH v2 05/20] x86/alternative: initializing temporary mm for
patching
s/initailizing/Initialize/
On Mon, Jan 28, 2019 at 04:34:07PM -0800, Rick Edgecombe wrote:
> From: Nadav Amit
>
> To prevent improper use of the PTEs that are used for text patching, we
> want to
On Mon, Feb 04, 2019 at 10:35:09PM -0500, Alex Kogan wrote:
>
> > On Jan 31, 2019, at 5:00 AM, Peter Zijlstra wrote:
> >
> > On Wed, Jan 30, 2019 at 10:01:35PM -0500, Alex Kogan wrote:
> >> Choose the next lock holder among spinning threads running on the same
> >> socket with high probability r
On Mon, Feb 04, 2019 at 05:09:03PM +, Robin Murphy wrote:
> Hi all,
>
> Following the report of a preemption-related bug in arm-cci, it turns
> out there's a fair bit of cleaning up to do in this area. I've started
> here with the Arm drivers that I'm fairly familiar with - I suspect the
> his
Hi Dmitry,
On Wed, Oct 24, 2018 at 09:29:36PM -0400, Brian Masney wrote:
> This patch adds a new vibrator driver that supports various Qualcomm
> MSM SOCs. Driver was tested on a LG Nexus 5 (hammerhead) phone.
>
> Signed-off-by: Brian Masney
Any chance that I can get a review of this patch seri
On Mon, Feb 04, 2019 at 04:01:01PM -0500, Qian Cai wrote:
> The commit e2a2e56e4082 ("arm64: dump: no need to check return value of
> debugfs_create functions") converted ptdump_debugfs_register() from
> void, but forgot to fix the efi version of ptdump_init().
>
> drivers/firmware/efi/arm-runtime
On Tue, Feb 5, 2019 at 6:00 PM Hans Verkuil wrote:
>
> On 2/5/19 7:26 AM, Tomasz Figa wrote:
> > On Fri, Feb 1, 2019 at 12:18 AM Nicolas Dufresne
> > wrote:
> >>
> >> Le jeudi 31 janvier 2019 à 22:34 +0900, Tomasz Figa a écrit :
> >>> On Thu, Jan 31, 2019 at 9:42 PM Philipp Zabel
> >>> wrote:
On Fri, Feb 1, 2019 at 8:52 AM Eric Biggers wrote:
> From: Eric Biggers
>
> The generic MORUS implementations all fail the improved AEAD tests
> because they produce the wrong result with some data layouts. The issue
> is that they assume that if the skcipher_walk API gives 'nbytes' not
> aligne
On Fri, Feb 1, 2019 at 8:52 AM Eric Biggers wrote:
> From: Eric Biggers
>
> The generic AEGIS implementations all fail the improved AEAD tests
> because they produce the wrong result with some data layouts. The issue
> is that they assume that if the skcipher_walk API gives 'nbytes' not
> aligne
On Fri, Feb 1, 2019 at 8:52 AM Eric Biggers wrote:
> From: Eric Biggers
>
> The x86 AEGIS implementations all fail the improved AEAD tests because
> they produce the wrong result with some data layouts. The issue is that
> they assume that if the skcipher_walk API gives 'nbytes' not aligned to
>
On Fri, Feb 1, 2019 at 8:52 AM Eric Biggers wrote:
> From: Eric Biggers
>
> The x86 MORUS implementations all fail the improved AEAD tests because
> they produce the wrong result with some data layouts. The issue is that
> they assume that if the skcipher_walk API gives 'nbytes' not aligned to
>
On 05/02/2019 09.05, Masahiro Yamada wrote:
> On Mon, Feb 4, 2019 at 4:24 AM Rasmus Villemoes
> wrote:
>>
>> BUILD_BUG_ON() is a little annoying, since it cannot be used outside
>> function scope. So one cannot put assertions about the sizeof() a
>> struct next to the struct definition, but has to
[...]
> > > Then attach_dev() can parse the correct "resource id" (e.g.
> > > IMX_SC_R_SDHC_1) from device tree And store it in per-device struct
> > generic_pm_domain_data for later start()/stop() using.
> >
> > I see, thanks for clarifying.
> >
> > Seem like, we have two options to make this wor
Hi Tony & Suman,
On 04/02/19 18:33, Tony Lindgren wrote:
> Hi,
>
> * Roger Quadros [190204 14:23]:
>> From: Suman Anna
> ...
>> +Example:
>> +
>> +1. /* AM33xx PRU-ICSS */
>> +
>> +pruss: pruss@0 {
>> +compatible = "ti,am3356-pruss";
>> +reg = <0x0 0x2000>,
Hi Andrew,
would you please add this patch set to the kernel tree at the next opportunity?
It has been Acked by Rodolfo Giometti, the PPS maintainer.
Tom Burkart
Tom Burkart (3):
pps: descriptor-based gpio
dt-bindings: pps: pps-gpio PPS ECHO implementation
pps: pps-gpio pps-echo implementat
This patch changes the GPIO access for the pps-gpio driver from the
integer based API to the descriptor based API.
Acked-by: Rodolfo Giometti
Reviewed-by: Philipp Zabel
Signed-off-by: Tom Burkart
---
drivers/pps/clients/pps-gpio.c | 67 +++---
include/linux/
This patch implements the device tree binding changes required for the
pps echo functionality for pps-gpio, that sysfs claims is available
already.
This patch is provided separated from the rest of the patch per
Documentation/devicetree/bindings/submitting-patches.txt.
This patch was originally wr
From: Bartosz Golaszewski
In order to drop the hard-coded GPIO base values from the davinci GPIO
driver's platform data, we first need to get rid of all calls to the
legacy GPIO functions. Convert the mdio configuration to hogging the
relevant GPIO line in the da850-evm board file.
Signed-off-by
This patch implements the pps echo functionality for pps-gpio, that
sysfs claims is available already.
Configuration is done via device tree bindings.
This patch was originally written by Lukas Senger as part of a masters
thesis project and modified for inclusion into the linux kernel by Tom
Burk
On 04/02/19 13:10, Peter Zijlstra wrote:
> On Thu, Jan 17, 2019 at 09:47:38AM +0100, Juri Lelli wrote:
> > No synchronisation mechanism exists between the cpuset subsystem and calls
> > to function __sched_setscheduler(). As such, it is possible that new root
> > domains are created on the cpuset s
On Tue, Feb 05, 2019 at 04:42:53PM +0800, Chen-Yu Tsai wrote:
> On Mon, Feb 4, 2019 at 9:41 PM Maxime Ripard
> wrote:
> >
> > On Mon, Feb 04, 2019 at 06:16:24PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Feb 4, 2019 at 5:34 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Sun, Feb 03, 2019 at 11:
On 05/02/2019 00.12, Andrew Morton wrote:
>>
>> It would be (very) nice to actually use this macro in a few places so
>> it gets its build testing while in -next.
>
> ie, just about every BUILD_BUG_ON in mm/ could use this. Let's switch
> a few?
>
Perhaps, but some make sense where they are, e.
1 - 100 of 928 matches
Mail list logo
