Hi Tony,
On Tue, 8 Jan 2019 at 00:38, Tony Lindgren wrote:
>
> Hi all,
>
> Looks like commit 8234f6734c5d ("PM-runtime: Switch autosuspend
> over to using hrtimers") caused a regression on at least
> omap5-uevm where 8250 UART rx wake no longer works. I have not
> noticed this happening on
Reviewed-by: Sagi Grimberg
Alex Williamson writes:
...
>
> Numbering options for clarity:
>
> 1)
>> ccflags-y += -I$(src)
>> would add the header search path for all files in drivers/vfio/pci/
>> whereas only the drivers/vfio/pci/vfio_pci_nvlink2.c needs it.
>>
>
> 2)
>> CFLAGS_vfio_pci_nvlink2.o += -I$(src)
>> is a bit
On Mon, Jan 07, 2019 at 07:56:47PM -0500, Lyude Paul wrote:
> Since I've had to fix two cases of drivers not checking the return code
> from this function, let's make the compiler complain so this doesn't
> come up again in the future.
>
> Signed-off-by: Lyude Paul
> Cc: Jerry Zuo
> Cc: Daniel
On 07.01.19 00:32, Halil Pasic wrote:
On Wed, 19 Dec 2018 20:17:52 +0100
Michael Mueller wrote:
The patch adds the parameter irq_flags and allows to
restore the Interruption Alert Mask (IAM) in the GISA
atomically while guaranteeing the IPM is clean.
The function returns the IPM of the
On Mon, Jan 07, 2019 at 04:04:59PM +0800, Pingfan Liu wrote:
> Customer reported a bug on a high end server with many pcie devices, where
> kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> though we still see much memory under 896 MB, the finding still failed
> intermittently.
The vsock core only supports 32bit CID, but the Virtio-vsock spec define
CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as
zero. This inconsistency causes one bug in vhost vsock driver. The
scenarios is:
0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock
On Mon, Jan 7, 2019 at 6:51 PM Geert Uytterhoeven
wrote:
> --- a/drivers/reset/core.c
> +++ b/drivers/reset/core.c
> @@ -459,6 +459,42 @@ static void __reset_control_put_internal(struct
> reset_control *rstc)
> kref_put(>refcnt, __reset_control_release);
> }
>
> +static bool
This patch series adds support for L2 internal asynchronous error detection
caused by L2 RAM double-bit ECC error or illegal writes to the
Interrupt Controller memory-map region on the Cortex A15.
Testing:
- works as module (loadable & unloadable) - OK
- works as build in kernel driver - OK
-
This driver adds support for L2 internal asynchronous error detection
caused by L2 RAM double-bit ECC error or illegal writes to the
Interrupt Controller memory-map region on the Cortex A15.
Signed-off-by: Wladislav Wiebe
---
MAINTAINERS | 1 +
drivers/edac/Kconfig
Add property description + example for using the
Cortex A15 L2 asynchronous error detection driver.
Signed-off-by: Wladislav Wiebe
---
.../bindings/edac/cortex_a15_l2_async_edac.txt | 22 ++
MAINTAINERS| 7 +++
2 files
On Tue 08-01-19 05:58:41, Tetsuo Handa wrote:
> On 2019/01/07 23:38, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Historically we have called mark_oom_victim only to the main task
> > selected as the oom victim because oom victims have access to memory
> > reserves and granting the access
Hi, as the subject, this is a patch that links the new introduced
.platform keyring into .secondary_trusted_keys keyring. This is
mainly for the kexec_file_load, make kexec_file_load be able to verify
the kernel image agains keys provided by platform or firmware.
kexec_file_load already could
Currently kexec may need to verify the kerne image, and the kernel image
could be signed with third part keys which are provided by paltform or
firmware (eg. stored in MokListRT EFI variable). And the same time,
kexec_file_load will only verify the image agains .builtin_trusted_keys
or
On Tue 08-01-19 05:59:49, Tetsuo Handa wrote:
> On 2019/01/07 23:38, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Tetsuo has reported [1] that a single process group memcg might easily
> > swamp the log with no-eligible oom victim reports due to race between
> > the memcg charge and
The xenstore 'ring-page-order' is used globally for each blkback queue and
therefore should be read from xenstore only once. However, it is obtained
in read_per_ring_refs() which might be called multiple times during the
initialization of each blkback queue.
If the blkfront is malicious and the
As 'be->blkif' is used for many times in connect_ring(), the stack variable
'blkif' is added to substitute 'be-blkif'.
Suggested-by: Paul Durrant
Signed-off-by: Dongli Zhang
Reviewed-by: Paul Durrant
Reviewed-by: Roger Pau Monné
---
drivers/block/xen-blkback/xenbus.c | 27
On Mon, Jan 07, 2019 at 07:26:50PM -0800, Deepa Dinamani wrote:
> Many architectures maintain an arch specific copy of the
> file even though there are no differences with the asm-generic
> one. Allow these architectures to use the generic one instead.
>
> Signed-off-by: Deepa Dinamani
> ---
>
Am Freitag, den 04.01.2019, 08:53 -0800 schrieb Andrey Smirnov:
> Add code needed to support i.MX8MQ variant.
>
> > Cc: Bjorn Helgaas
> > Cc: Fabio Estevam
> > Cc: Chris Healy
> > Cc: Lucas Stach
> > Cc: Leonard Crestez
> > Cc: "A.s. Dong"
> > Cc: Richard Zhu
> > Cc: Rob Herring ,
> > Cc:
On Tue, Jan 08, 2019 at 12:23:52PM +0500, Ivan Mironov wrote:
> SDL 1.2 sets all fields related to the pixel format to zero in some
> cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
> pixel format changing requests"), there was an unintentional workaround
> for this that
Am Freitag, den 04.01.2019, 08:53 -0800 schrieb Andrey Smirnov:
> Both i.MX7D and i.MX8MQ have the same behaviour when it comes to
> clearing DIRECT_SPEED_CHANGE bit when no speed change occur. To
> account for that change the code handling that to use a generic flag
> instead of checking IP block
On Mon 07-01-19 20:53:08, Qian Cai wrote:
>
>
> On 1/7/19 1:43 PM, Michal Hocko wrote:
> > On Fri 04-01-19 15:18:08, Qian Cai wrote:
> > [...]
> >> Though, I can't see any really benefit of this approach apart from
> >> "beautify"
> >
> > This is not about beautifying! This is about making the
oops. Please ignore this v5 patch.
I just realized Linus suggested in an old email not use BUG()/BUG_ON() in the
code.
I will switch to the WARN() solution and resend again.
Sorry for the junk email.
Dongli Zhang
On 2019/1/8 下午4:15, Dongli Zhang wrote:
> The xenstore 'ring-page-order' is
On Mon, 2019-01-07 at 19:34 +0100, Lubomir Rintel wrote:
> It doesn't make sense to always have this built-in, e.g. on ARM
> multiplatform kernels.
>
> A better way to address the problem the original commit aimed to solve is
> to fix Kconfig. That is what the next commit in the series does.
>
>
On Tue, Jan 08, 2019 at 11:12:41AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> 'amdgpu_dm_mode_config_init':
>
Hi,
On Tue, 2019-01-08 at 09:16 +0800, Ayaka wrote:
>
> Sent from my iPad
>
> > On Jan 7, 2019, at 5:57 PM, Paul Kocialkowski
> > wrote:
> >
> > Hi,
> >
> > > On Mon, 2019-01-07 at 11:49 +0800, Randy Li wrote:
> > > > On 12/12/18 8:51 PM, Paul Kocialkowski wrote:
> > > > Hi,
> > > >
> > >
On January 7, 2019 12:52:57 AM PST, Cao jin wrote:
>Hi,
>
>On 1/7/19 3:59 PM, h...@zytor.com wrote:
>> On January 6, 2019 11:40:56 PM PST, Cao jin
> wrote:
>>> According to objdump output of setup, function memset is not used in
>>> setup code. Currently, all usage of memset in setup come from
Add basic documentation in YAML format for the sx130x series concentrators
from Semtech.
Required is; the location on the SPI bus, the reset gpio and the node for
downstream IQ radios, typically sx125x.
Signed-off-by: Ben Whitten
---
.../bindings/lora/semtech,sx130x.yaml | 87
The sx125x family are IQ radio transceivers from Semtech configured over
SPI, they are typically connected to an sx130x series concentrator however
may be connected to a host directly.
Required properties include the radio number of the host or concentrator
bus.
Signed-off-by: Ben Whitten
---
The sx125x consumes a 32MHz clock and if it is coupled with a sx130x
concentrator may also provide a gated version of this 32MHz for the
concentrator.
In the example we connect to output 0 of "txco" clock source. The radio
also provides a single clock output, hence "#clock-cells = <0>", named
The sx130x family consumes two clocks, a 32MHz clock provided by a
connected IQ transceiver, and a 133MHz high speed clock.
In the example we connect the concentrator to output 0 of a fixed clock
providing the 133MHz high speed clock, and we connect to output 0 of a
connected transceiver 32MHz
Hi Guenter Roeck,
Thanks for your reply.
-Original Message-
From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter Roeck
Sent: 2019年1月7日 22:04
To: Liu, Xiaoting ; jdelv...@suse.com
Cc: open...@lists.ozlabs.org; linux-hw...@vger.kernel.org;
linux-kernel@vger.kernel.org;
One more question: in compressed/, for mem*(), it seems we both use the
macros of boot/string.h, and the functions of compressed/string.c. Is
that what we want?
compressed/ is compiled with -O2, so it cannot be told by objdump -d,
but still can be confirmed by nm <*.o>, for example:
$nm
On 08.01.2019 06:35, Wei Wang wrote:
> On 01/07/2019 09:49 PM, Christian Borntraeger wrote:
>>
>> On 07.01.2019 08:01, Wei Wang wrote:
>>> virtio-ccw has deadlock issues with reading the config space inside the
>>> interrupt context, so we tweak the virtballoon_changed implementation
>>> by
On 01/08/19 at 01:24pm, Baoquan He wrote:
> On 12/28/18 at 09:12am, Dave Young wrote:
> > The code cleanup mentioned in Fixes tag changed the behavior of
> > kexec_locate_mem_hole. The kexec_locate_mem_hole will try to
> > allocate free memory only when kbuf.mem is initialized as zero.
> >
> >
Christophe Leroy writes:
> Le 04/01/2019 à 16:24, Horia Geanta a écrit :
>> On 1/4/2019 5:17 PM, Horia Geanta wrote:
>>> On 12/21/2018 10:07 AM, Christophe Leroy wrote:
>>> [snip]
IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.
Below is the list of build error/warning regressions/improvements in
v5.0-rc1[1] compared to v4.20[2].
Summarized:
- build errors: +12/-4
- build warnings: +405/-350
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1]
On 01/06/19 at 08:27am, Mike Rapoport wrote:
> I do not suggest to discard the bottom-up method, I merely suggest to allow
> it to use [0, kernel_start).
Sorry for late reply.
I misunderstood it, sorry.
> > This bottom-up way is taken on many ARCHes, it works well on system if
> > KASLR is not
Hi Michal,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc1 next-20190108]
[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
On Sat, Jan 05, 2019 at 01:54:03PM -0800, Linus Torvalds wrote:
> On Sat, Jan 5, 2019 at 12:43 PM Jiri Kosina wrote:
> >
> > > Who actually _uses_ mincore()? That's probably the best guide to what
> > > we should do. Maybe they open the file read-only even if they are the
> > > owner, and we
On 01/08/19 at 04:46pm, Dave Young wrote:
> > Wondering why this place doesn't need the initialization assignment.
> > Isn't it to assign in all places before kexec_add_buffer() calling?
>
> C designated initializers will make sure to initialize it as zero.
> We set KEXEC_BUF_MEM_UNKNOWN as 0 so
On Tue, Jan 8, 2019 at 1:43 AM Changbin Du wrote:
>
> On Mon, Jan 07, 2019 at 01:32:56PM +0900, Masahiro Yamada wrote:
> > (+CC Changbin Du, Arnd Bergmann)
> >
> >
> >
> [...]
> > > This branch already added a couple of extra inline markers just to
> > > make code work reasonably. How many tens
On 2019/1/7 21:58, Guenter Roeck wrote:
> On 1/7/19 3:00 AM, Xiaoting Liu wrote:
>> Bindings for DPS650AB power, voltage, temperature, and fan monitering.
>>
>> Signed-off-by: Xiaoting Liu
>> ---
>> v2:
>>Change the patch subject.
>> ---
>>
On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
> On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard
> wrote:
> >
> > On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
> > > On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Mon, Dec 10, 2018 at
On 2019-01-08 13:47:19 [+0900], Sergey Senozhatsky wrote:
> On (01/07/19 22:26), Steven Rostedt wrote:
> > > On (01/07/19 14:52), Steven Rostedt wrote:
> > > > Subject: [PATCH RT 01/13] work-simple: drop a shit statement in
> > > > SWORK_EVENT_PENDING
> > >
> > >
Hi Mike,
On 01/08/19 at 10:05am, Mike Rapoport wrote:
> I'm not thrilled by duplicating this code (yet again).
> I liked the v3 of this patch [1] more, assuming we allow bottom-up mode to
> allocate [0, kernel_start) unconditionally.
> I'd just replace you first patch in v3 [2] with something
On Tue, Jan 8, 2019 at 9:49 AM Geert Uytterhoeven wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.0-rc1[1] compared to v4.20[2].
>
> Summarized:
> - build errors: +12/-4
> - build warnings: +405/-350
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team
On 02.01.19 18:45, Pierre Morel wrote:
On 19/12/2018 20:17, Michael Mueller wrote:
By initializing the GIB, it will be used by the kvm host.
Signed-off-by: Michael Mueller
---
arch/s390/kvm/kvm-s390.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
On 08.01.19 08:37, Christophe Leroy wrote:
> Instead of opencoding, use probe_user_read() to failessly
> read a user location.
>
> Signed-off-by: Christophe Leroy
> ---
> v2: Using probe_user_read() instead of probe_user_address()
>
> arch/powerpc/kernel/process.c | 12 +---
>
On Tue, Jan 08, 2019 at 06:30:59AM +0100, Mike Galbraith wrote:
> On Mon, 2019-01-07 at 13:52 +0100, Peter Zijlstra wrote:
> > On Mon, Jan 07, 2019 at 01:28:34PM +0100, Mike Galbraith wrote:
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 960ad0ce77d7..420624c49f38 100644
The light sensor's power supply could be controllable by regulator
on some platforms, such as i.MX6Q-SABRESD board, the light sensor
isl29023's power supply is controlled by a GPIO fixed regulator,
need to make sure the regulator is enabled before any operation of
sensor, this patch adds vcc
From: Linus Torvalds
> Sent: 07 January 2019 17:44
> On Mon, Jan 7, 2019 at 1:55 AM David Laight wrote:
> >
> > I needed to open-code one part because it wants to do copy_to_user()
> > from a PCIe address buffer (which has to work).
>
> It will never work for memcpy_fromio(). Any driver that
On 01/08/19 at 04:51pm, Baoquan He wrote:
> On 01/08/19 at 04:46pm, Dave Young wrote:
> > > Wondering why this place doesn't need the initialization assignment.
> > > Isn't it to assign in all places before kexec_add_buffer() calling?
> >
> > C designated initializers will make sure to initialize
On Mon, Jan 07, 2019 at 03:43:54PM -0800, Andrew Morton wrote:
> On Fri, 4 Jan 2019 12:49:46 + Mel Gorman
> wrote:
>
> > This series reduces scan rates and success rates of compaction, primarily
> > by using the free lists to shorten scans, better controlling of skip
> > information and
Hi Guenter Roeck,
Thanks for your reply.
On 2019/1/7 22:04, Guenter Roeck wrote:
> On 1/7/19 3:06 AM, Xiaoting Liu wrote:
>> Provide support for PSU DPS-650AB from Delta Electronics, INC.
>>
> Where is patch 3/4 ?
Sorry for forgetting to send patch 3/4 to you, please refer to the
following
The accelerometer's power supplies could be controllable on some
platforms, add property "vdd/vddio" power supply to let device tree
to pass phandles to the regulators to driver.
Signed-off-by: Anson Huang
---
Documentation/devicetree/bindings/iio/accel/mma8452.txt | 4
1 file changed, 4
From: Bartosz Golaszewski
Hi Sekhar,
now that all dependencies are in and v5.0-rc1 is tagged, please consider
picking up the second batch of davinci-specific changes into your tree.
Once that's done, please provide me with an immutable branch for me to
apply the last patch to my at24 tree.
On 05/01/2019 20:38, Vlastimil Babka wrote:
[...]
> I was thinking about "return true" here, assuming that userspace generally
> wants
> to ensure itself there won't be page faults when it starts doing something
> critical, and if it sees a "false" it will try to do some kind of prefaulting,
>
From: Bartosz Golaszewski
There are no more users of davinci_get_mac_addr(). Remove it.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/common.c | 15 ---
include/linux/davinci_emac.h | 1 -
2 files changed, 16 deletions(-)
diff --git
The magnetometer's power supplies could be controllable on some platforms,
such as i.MX6Q-SABRESD board, the mag3110's power supplies are controlled
by a GPIO fixed regulator, need to make sure the regulators are enabled
before any communication with mag3110, this patch adds vdd/vddio regulator
From: Bartosz Golaszewski
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the
From: Bartosz Golaszewski
There are no more users of at24_platform_data. Remove the relevant
header and modify the driver code to not use it anymore.
Signed-off-by: Bartosz Golaszewski
---
MAINTAINERS| 1 -
drivers/misc/eeprom/at24.c | 162
The accelerometer's power supply could be controllable on some
platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
are controlled by a GPIO fixed regulator, need to make sure the
regulators are enabled before any communication with mma8451, this
patch adds vdd/vddio regulator
From: Bartosz Golaszewski
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the
From: Bartosz Golaszewski
Stop using the at24_platform_data setup callback in favor of nvmem
notifiers.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-mityomapl138.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git
On 07.01.19 14:44, Vitaly Kuznetsov wrote:
> David Hildenbrand writes:
>
>> On 04.01.19 15:19, Vitaly Kuznetsov wrote:
>>> Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use
>>> 128M. To deal with it we implement partial section onlining by registering
>>> custom page
From: Bartosz Golaszewski
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the
Hi, Jonathan
Best Regards!
Anson Huang
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 2019年1月6日 1:43
> To: Anson Huang
> Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
>
>
From: Bartosz Golaszewski
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the
From: Bartosz Golaszewski
The currently used 24lc64 i2c device name doesn't match against any
of the devices supported by the at24 driver. Change it to the closest
compatible chip.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-sffsdr.c | 2 +-
1 file changed, 1
From: Bartosz Golaszewski
This is now done by the emac driver using a registered nvmem cell.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-mityomapl138.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
From: Bartosz Golaszewski
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the
From: Bartosz Golaszewski
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the
From: Bartosz Golaszewski
We no longer need to register the MTD notifier to read the MAC address
as it's now being done in the emac driver.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-da850-evm.c | 28 -
1 file changed, 28 deletions(-)
diff
Hi, Jonathan
Best Regards!
Anson Huang
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 2019年1月6日 1:30
> To: Anson Huang
> Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net;
> robh...@kernel.org; mark.rutl...@arm.com; mart...@posteo.de; Leonard
>
Hi Sakari,
On 07-Jan-19 11:58, Sakari Ailus wrote:
> Hi Luis,
>
> On Fri, Oct 19, 2018 at 02:52:24PM +0200, Luis Oliveira wrote:
>> Add of Synopsys MIPI D-PHY in RX mode support.
>> Separated in the implementation are platform dependent probing functions.
>>
>> Signed-off-by: Luis Oliveira
>
>
Hi, Jonathan
Best Regards!
Anson Huang
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 2019年1月6日 1:47
> To: Anson Huang
> Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net;
> rtres...@electromag.com.au; linux-...@vger.kernel.org;
>
Le 08/01/2019 à 10:04, David Hildenbrand a écrit :
On 08.01.19 08:37, Christophe Leroy wrote:
Instead of opencoding, use probe_user_read() to failessly
read a user location.
Signed-off-by: Christophe Leroy
---
v2: Using probe_user_read() instead of probe_user_address()
On Mon, 7 Jan 2019 at 20:22, Greg Kroah-Hartman
wrote:
>
> On Mon, Jan 07, 2019 at 01:31:48PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.92 release.
> > There are 101 patches in this series, all will be posted as a response
> > to this one. If
Hi Uwe,
On 08.01.2019 00:10, Uwe Kleine-König wrote:
> Hello Claudiu,
>
> On Mon, Jan 07, 2019 at 09:30:55AM +, claudiu.bez...@microchip.com wrote:
>> On 05.01.2019 23:05, Uwe Kleine-König wrote:
>>> On Thu, Jan 03, 2019 at 01:29:44PM +, claudiu.bez...@microchip.com
>>> wrote:
Fixes: 8c4905b995c6 ("libbpf: make sure bpf headers are c++ include-able")
Signed-off-by: Anders Roxell
---
tools/testing/selftests/bpf/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/bpf/.gitignore
b/tools/testing/selftests/bpf/.gitignore
index
When test_tcpbpf_user runs it complains that it can't find files
tcp_server.py and tcp_client.py.
Rework so that tcp_server.py and tcp_client.py gets installed, added them
to the variable TEST_PROGS_EXTENDED.
Fixes: d6d4f60c3a09 ("bpf: add selftest for tcpbpf")
Signed-off-by: Anders Roxell
---
- Add driver for NXP FlexSPI host controller
FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475,
which supports two SPI channels and up to 4 external devices.
Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8
bidirectional data lines)
i.e. FlexSPI
Add maintainers for the NXP FlexSPI driver
Signed-off-by: Yogesh Narayan Gaur
---
Changes for v6:
- None
Changes for v5:
- Add maintainers for binding file
Changes for v4:
- None
Changes for v3:
- None
Changes for v2:
- None
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff
- Add driver for NXP FlexSPI host controller
(0) What is the FlexSPI controller?
FlexSPI is a flexsible SPI host controller which supports two SPI
channels and up to 4 external devices. Each channel supports
Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional
data lines) i.e.
Enable driver support of NXP FlexSPI controller.
Signed-off-by: Yogesh Narayan Gaur
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 3ef443cfbab6..fe7f35824a79 100644
---
Add binding file for NXP FlexSPI controller
Signed-off-by: Yogesh Narayan Gaur
Reviewed-by: Rob Herring
---
Changes for v6:
- None
Changes for v5:
- None
Changes for v4:
- Incorporated Rob review comments.
Changes for v3:
- Removed node property 'big-endian'.
Changes for v2:
- Incorporated Rob
Add fspi node property for LX2160A SoC for FlexSPI driver.
Property added for the FlexSPI controller and for the connected
slave device for the LX2160ARDB target.
This is having two SPI-NOR flash device, mt35xu512aba, connected
at CS0 and CS1.
Signed-off-by: Yogesh Narayan Gaur
---
Changes for
On Tue, Jan 08, 2019 at 09:47:18AM +0200, Adrian Hunter wrote:
> On 7/01/19 6:32 PM, Peter Zijlstra wrote:
> > On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote:
> >> Nadav Amit writes:
> >>>
> >>> - Do we use periodic learning or not? Josh suggested to reconfigure the
> >>> branches
Commit cda261f421ba ("selftests: add txtimestamp kselftest") introduced
a warning:
Makefile:14: warning: overriding recipe for target 'clean'
../../lib.mk:137: warning: ignoring old recipe for target 'clean'
Theres no need for timestamping to have its own 'clean' target. The
lib.mk file's
Fixes: 2a31b9db1535 ("kvm: introduce manual dirty log reprotect")
Fixes: 7edcb7343327 ("KVM: selftests: Add hyperv_cpuid test")
Signed-off-by: Anders Roxell
---
tools/testing/selftests/kvm/.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/kvm/.gitignore
Finn Thain writes:
> On Mon, 7 Jan 2019, Michael Ellerman wrote:
>
>> Arnd Bergmann writes:
>> > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
>> > wrote:
>> >
>> >> +static ssize_t ppc_nvram_get_size(void)
>> >> +{
>> >> + if (ppc_md.nvram_size)
>> >> + return
This fixes false-positive kmemleak reports about leaked neighbour entries:
unreferenced object 0x8885c6e4d0a8 (size 1024):
comm "softirq", pid 0, jiffies 4294922664 (age 167640.804s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 20 2c f3 83 ff ff ff ff ,..
08 c0
On Tue, Jan 08, 2019 at 08:45:18AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Jan 07, 2019 at 01:17:49PM -0800, Guenter Roeck wrote:
> > On Mon, Jan 07, 2019 at 01:30:37PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.20.1 release.
> > > There are
> Subject: Re: [PATCH v2 2/2] driver: clocksource: Add nxp system counter timer
> driver support
>
> Hi,
>
> On 12/11/18 9:28 PM, Jacky Bai wrote:
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index c57b156..7e5f2de 100644
> > --- a/drivers/clocksource/Kconfig
>
Hi Michael and Russell,
Any idea why:
- checkpatch reports missing Signed-off-by:
- Snowpatch build fails on PPC64 (it seems unrelated to the patch,
something wrong in lib/genalloc.c)
Thanks
Christophe
Le 08/01/2019 à 08:37, Christophe Leroy a écrit :
Instead of opencoding, use
It is perfectly okay to call riscv_hartid_to_cpuid for a
hartid that is not mapped with an CPU id. It can happen
if the calling functions retrieves the hartid from DT.
However, that hartid was never brought online by the firmware
or kernel for any reasons.
No need to BUG() in the above case. A
Currently, logical CPU id to physical hartid mapping is
defined for both smp and non-smp configurations. This
is not required as we need this only for smp configuration.
The mapping function can define directly boot_cpu_hartid
for non-smp use case.
The reverse mapping function i.e. hartid to
Currently, clocksource registration happens for an invalid cpu
for non-smp kernels. This lead to kernel panic as cpu hotplug
registration will fail for those cpus. Moreover,
riscv_hartid_to_cpuid can return errors now.
Do not proceed if hartid or cpuid is invalid. Take this opprtunity
to print
In non-smp configuration, hartid can be higher that NR_CPUS.
riscv_of_processor_hartid should not be compared to hartid to
NR_CPUS in that case. Moreover, this function checks all the
DT properties of a hart node. NR_CPUS comparison seems out of
place.
Signed-off-by: Atish Patra
---
1 - 100 of 1482 matches
Mail list logo
