On Tue, Jun 12, 2018 at 01:40:29PM +0800, Songjun Wu wrote:
> From: Yixin Zhu
>
> PLL of GRX500 provide clock to DDR, CPU, and peripherals as show below
>
> +-+
> |--->| LCPLL3 0|--PCIe clk-->
>XO |+-+
> +---|
> |
On Tue, Jun 12, 2018 at 01:40:29PM +0800, Songjun Wu wrote:
> From: Yixin Zhu
>
> PLL of GRX500 provide clock to DDR, CPU, and peripherals as show below
>
> +-+
> |--->| LCPLL3 0|--PCIe clk-->
>XO |+-+
> +---|
> |
On Wed, 13 Jun 2018 08:24:26 +1000
NeilBrown wrote:
> On Tue, Jun 12 2018, Boris Brezillon wrote:
>
> >
> > Just because you managed to solve the problem in one driver does not
> > mean the problem does not exist for others. I read this datasheet [1]
> > several times and couldn't find a way to
On Wed, 13 Jun 2018 08:24:26 +1000
NeilBrown wrote:
> On Tue, Jun 12 2018, Boris Brezillon wrote:
>
> >
> > Just because you managed to solve the problem in one driver does not
> > mean the problem does not exist for others. I read this datasheet [1]
> > several times and couldn't find a way to
On Tue, Jun 12, 2018 at 01:40:30PM +0800, Songjun Wu wrote:
> From: Hua Ma
>
> Add initial support for Intel MIPS interAptiv SoCs made by Intel.
> This series will add support for the GRX500 family.
>
> The series allows booting a minimal system using a initramfs.
>
> Signed-off-by: Hua ma
>
On Tue, Jun 12, 2018 at 01:40:30PM +0800, Songjun Wu wrote:
> From: Hua Ma
>
> Add initial support for Intel MIPS interAptiv SoCs made by Intel.
> This series will add support for the GRX500 family.
>
> The series allows booting a minimal system using a initramfs.
>
> Signed-off-by: Hua ma
>
On Tue, Jun 12, 2018 at 03:08:53PM -0700, Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 2:08 PM Bjorn Helgaas wrote:
> >
> > - squash AER directory into drivers/pci/pcie/aer.c (Bjorn Helgaas)
>
> Could we please see *reasons* for this series of commits?
>
> Those commit messages have
On Tue, Jun 12, 2018 at 03:08:53PM -0700, Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 2:08 PM Bjorn Helgaas wrote:
> >
> > - squash AER directory into drivers/pci/pcie/aer.c (Bjorn Helgaas)
>
> Could we please see *reasons* for this series of commits?
>
> Those commit messages have
On Tue, Jun 12, 2018 at 01:40:28PM +0800, Songjun Wu wrote:
> Previous implementation uses a hard-coded register value to check if
> the current serial entity is the console entity.
> Now the lantiq serial driver uses the aliases for the index of the
> serial port.
> The lantiq danube serial dts
On Tue, Jun 12, 2018 at 01:40:28PM +0800, Songjun Wu wrote:
> Previous implementation uses a hard-coded register value to check if
> the current serial entity is the console entity.
> Now the lantiq serial driver uses the aliases for the index of the
> serial port.
> The lantiq danube serial dts
On Tue, Jun 12 2018, Boris Brezillon wrote:
>
> Just because you managed to solve the problem in one driver does not
> mean the problem does not exist for others. I read this datasheet [1]
> several times and couldn't find a way to say 'I want to keep the CS
> asserted between 2 transactions', so
On Tue, Jun 12 2018, Boris Brezillon wrote:
>
> Just because you managed to solve the problem in one driver does not
> mean the problem does not exist for others. I read this datasheet [1]
> several times and couldn't find a way to say 'I want to keep the CS
> asserted between 2 transactions', so
Hi Janusz,
On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> GPIO lookup table for ams-delta-serio device was introduced by commit
> 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> lookup
Hi Janusz,
On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> GPIO lookup table for ams-delta-serio device was introduced by commit
> 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> lookup
On Sat, Jun 09, 2018 at 04:02:23PM +0200, Janusz Krzysztofik wrote:
> The driver still obtains IRQ number from a hardcoded GPIO. Use IRQ
> resource instead.
>
> For this to work on Amstrad Delta, add the IRQ resource to
> ams-delta-serio platform device structure. Obtain the IRQ number
>
On Sat, Jun 09, 2018 at 04:02:23PM +0200, Janusz Krzysztofik wrote:
> The driver still obtains IRQ number from a hardcoded GPIO. Use IRQ
> resource instead.
>
> For this to work on Amstrad Delta, add the IRQ resource to
> ams-delta-serio platform device structure. Obtain the IRQ number
>
On Tue, Jun 12, 2018 at 01:24:01PM +0800, Baolin Wang wrote:
> This patch adds the binding documentation for Spreadtrum SC27XX series
> PMICs efuse controller device.
>
> Signed-off-by: Baolin Wang
> ---
> .../devicetree/bindings/nvmem/sc27xx-efuse.txt | 52
>
> 1
On Tue, Jun 12, 2018 at 01:24:01PM +0800, Baolin Wang wrote:
> This patch adds the binding documentation for Spreadtrum SC27XX series
> PMICs efuse controller device.
>
> Signed-off-by: Baolin Wang
> ---
> .../devicetree/bindings/nvmem/sc27xx-efuse.txt | 52
>
> 1
On Tue, Jun 12, 2018 at 10:01:07AM +1000, Benjamin Herrenschmidt wrote:
> These days of_address_to_resource() puts a reasonable name
> in the resource struct, thus make the "name" argument an
> optional override.
>
> Signed-off-by: Benjamin Herrenschmidt
> ---
>
> Just something I noticed ...
On Tue, Jun 12, 2018 at 10:01:07AM +1000, Benjamin Herrenschmidt wrote:
> These days of_address_to_resource() puts a reasonable name
> in the resource struct, thus make the "name" argument an
> optional override.
>
> Signed-off-by: Benjamin Herrenschmidt
> ---
>
> Just something I noticed ...
On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> Modify the driver so it no longer requests and manipulates the
> "keybrd_pwr" GPIO pin but a "vcc" regulator supply instead.
>
> For this to work with Amstrad Delta, define a regulator over the
> "keybrd_pwr" GPIO pin with the
On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> Modify the driver so it no longer requests and manipulates the
> "keybrd_pwr" GPIO pin but a "vcc" regulator supply instead.
>
> For this to work with Amstrad Delta, define a regulator over the
> "keybrd_pwr" GPIO pin with the
On Mon, Jun 11, 2018 at 10:22:10PM +0200, Robert Jarzmik wrote:
> This adds a binding for the Marvell PXA audio complex, available in
> pxa2xx and pxa3xx variants.
>
> Signed-off-by: Robert Jarzmik
> ---
> .../bindings/sound/marvell,pxa2xx-ac97.txt | 25
> ++
> 1
On Mon, Jun 11, 2018 at 10:22:10PM +0200, Robert Jarzmik wrote:
> This adds a binding for the Marvell PXA audio complex, available in
> pxa2xx and pxa3xx variants.
>
> Signed-off-by: Robert Jarzmik
> ---
> .../bindings/sound/marvell,pxa2xx-ac97.txt | 25
> ++
> 1
Hey Folks,
I noticed with linus/master wifi wasn't coming up on HiKey960. I
bisected it down and it seems to be due to:
60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
When wifi fails to load, the only useful
Hey Folks,
I noticed with linus/master wifi wasn't coming up on HiKey960. I
bisected it down and it seems to be due to:
60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
When wifi fails to load, the only useful
On 06/12/2018 01:33 PM, kbuild test robot wrote:
Hi subhra,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/sched/core]
[also build test WARNING on v4.17 next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help
On 06/12/2018 01:33 PM, kbuild test robot wrote:
Hi subhra,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/sched/core]
[also build test WARNING on v4.17 next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help
On 21:39-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> > Texas Instrument's System Control Interface (TISCI) permits the
> > ability for Operating Systems to running in virtual machines to be
>
> ...for OSs running in vi
On 21:39-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> > Texas Instrument's System Control Interface (TISCI) permits the
> > ability for Operating Systems to running in virtual machines to be
>
> ...for OSs running in vi
On Tue, Jun 12, 2018 at 2:08 PM Bjorn Helgaas wrote:
>
> - squash AER directory into drivers/pci/pcie/aer.c (Bjorn Helgaas)
Could we please see *reasons* for this series of commits?
Those commit messages have trivial "what", but no explanations "why".
Linus
On Tue, Jun 12, 2018 at 2:08 PM Bjorn Helgaas wrote:
>
> - squash AER directory into drivers/pci/pcie/aer.c (Bjorn Helgaas)
Could we please see *reasons* for this series of commits?
Those commit messages have trivial "what", but no explanations "why".
Linus
On 21:11-20180612, Rob Herring wrote:
[...]
> > diff --git
> > a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > index ebf0e3710cee..de796e90cac6 100644
> > --- a/Documentati
On 21:11-20180612, Rob Herring wrote:
[...]
> > diff --git
> > a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > index ebf0e3710cee..de796e90cac6 100644
> > --- a/Documentati
On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/o
On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/o
On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following
> > property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
>
On Tue, Jun 12 2018, Linus Torvalds wrote:
> Final note (for now) on this: I've merged the nfs code, but I really
> am obviously not happy with these crazy random ad-hoc
> cursor-not-cursor list games.
>
> Linus
Hi Linus,
thanks for merging the code despite your reservations.
On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following
> > property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
>
On Tue, Jun 12 2018, Linus Torvalds wrote:
> Final note (for now) on this: I've merged the nfs code, but I really
> am obviously not happy with these crazy random ad-hoc
> cursor-not-cursor list games.
>
> Linus
Hi Linus,
thanks for merging the code despite your reservations.
Hi Linus,
Here's the second round of patches for XFS for 4.18. Most of the
commits are small cleanups, bug fixes, and continued strengthening of
metadata verifiers; the bulk of the diff is the conversion of the
fs/xfs/ tree to use SPDX tags.
This series has been run through a full xfstests run
Hi Linus,
Here's the second round of patches for XFS for 4.18. Most of the
commits are small cleanups, bug fixes, and continued strengthening of
metadata verifiers; the bulk of the diff is the conversion of the
fs/xfs/ tree to use SPDX tags.
This series has been run through a full xfstests run
On Thu, Jun 07, 2018 at 10:41:05AM +0200, Alexandre Belloni wrote:
> Add missing PMC compatibles to the list of available compatibles.
>
> Signed-off-by: Alexandre Belloni
> ---
> Documentation/devicetree/bindings/clock/at91-clock.txt | 9 -
> 1 file changed, 4 insertions(+), 5
On Thu, Jun 07, 2018 at 10:41:05AM +0200, Alexandre Belloni wrote:
> Add missing PMC compatibles to the list of available compatibles.
>
> Signed-off-by: Alexandre Belloni
> ---
> Documentation/devicetree/bindings/clock/at91-clock.txt | 9 -
> 1 file changed, 4 insertions(+), 5
On Thu, Jun 07, 2018 at 10:41:04AM +0200, Alexandre Belloni wrote:
> The PMC bindings are fully described in
> Documentation/devicetree/bindings/clock/at91-clock.txt. Remove the
> duplicate and incomplete documentation.
>
> Signed-off-by: Alexandre Belloni
> ---
>
On Thu, Jun 07, 2018 at 10:41:04AM +0200, Alexandre Belloni wrote:
> The PMC bindings are fully described in
> Documentation/devicetree/bindings/clock/at91-clock.txt. Remove the
> duplicate and incomplete documentation.
>
> Signed-off-by: Alexandre Belloni
> ---
>
On Wed, Jun 06, 2018 at 02:49:48PM +0200, Michal Simek wrote:
> Bitmain (https://www.bitmain.com) is a vendor of cryptocurrency
> hardware.
>
> Signed-off-by: Michal Simek
> ---
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied.
Rob
On Wed, Jun 06, 2018 at 02:49:48PM +0200, Michal Simek wrote:
> Bitmain (https://www.bitmain.com) is a vendor of cryptocurrency
> hardware.
>
> Signed-off-by: Michal Simek
> ---
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied.
Rob
On Tue, 2018-06-12 at 14:39 -0700, H. Peter Anvin wrote:
> On 06/12/18 14:24, Dmitry Safonov wrote:
> > >
> > > Move align_vdso_addr() after get_unmapped_area() to make sure
> > > that
> > > errata for AMD 15h is always applied.
> >
> > Alternative dirty-hacky idea:
> > specify some (struct
On Tue, 2018-06-12 at 14:39 -0700, H. Peter Anvin wrote:
> On 06/12/18 14:24, Dmitry Safonov wrote:
> > >
> > > Move align_vdso_addr() after get_unmapped_area() to make sure
> > > that
> > > errata for AMD 15h is always applied.
> >
> > Alternative dirty-hacky idea:
> > specify some (struct
On Tue, Jun 12, 2018 at 09:23:19AM +0800, Huang, Ying wrote:
> Daniel Jordan writes:
> >> +#else
> >> +static inline int __swap_duplicate_cluster(swp_entry_t *entry,
> >
> > This doesn't need inline.
>
> Why not? This is just a one line stub.
Forgot to respond to this. The compiler will
On Tue, Jun 12, 2018 at 09:23:19AM +0800, Huang, Ying wrote:
> Daniel Jordan writes:
> >> +#else
> >> +static inline int __swap_duplicate_cluster(swp_entry_t *entry,
> >
> > This doesn't need inline.
>
> Why not? This is just a one line stub.
Forgot to respond to this. The compiler will
On Tue, Jun 12, 2018 at 11:39:56AM +0300, Andy Shevchenko wrote:.
> On Tue, Jun 12, 2018 at 3:39 AM, Tobin C. Harding wrote:
> > Currently the function get_random_bytes_arch() has return value 'void'.
> > If the hw RNG fails we currently fall back to using get_random_bytes().
> > This defeats the
On Tue, Jun 12, 2018 at 11:39:56AM +0300, Andy Shevchenko wrote:.
> On Tue, Jun 12, 2018 at 3:39 AM, Tobin C. Harding wrote:
> > Currently the function get_random_bytes_arch() has return value 'void'.
> > If the hw RNG fails we currently fall back to using get_random_bytes().
> > This defeats the
On Tue, Jun 12, 2018 at 02:44:58PM -0400, Steven Rostedt wrote:
> On Tue, 12 Jun 2018 10:39:13 +1000
> "Tobin C. Harding" wrote:
>
> > Currently we must wait for enough entropy to become available before
> > hashed pointers can be printed. We can remove this wait by using the
> > hw RNG if
Implement a skeleton framework for debugfs support in the AMD
IOMMU. Add an AMD-specific Kconfig boolean that depends upon
general enablement of DebugFS in the IOMMU.
Signed-off-by: Gary R Hook
---
drivers/iommu/Kconfig | 12
drivers/iommu/Makefile|1
On Tue, Jun 12, 2018 at 02:44:58PM -0400, Steven Rostedt wrote:
> On Tue, 12 Jun 2018 10:39:13 +1000
> "Tobin C. Harding" wrote:
>
> > Currently we must wait for enough entropy to become available before
> > hashed pointers can be printed. We can remove this wait by using the
> > hw RNG if
Implement a skeleton framework for debugfs support in the AMD
IOMMU. Add an AMD-specific Kconfig boolean that depends upon
general enablement of DebugFS in the IOMMU.
Signed-off-by: Gary R Hook
---
drivers/iommu/Kconfig | 12
drivers/iommu/Makefile|1
On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TISCI) permits the
> ability for Operating Systems to running in virtual machines to be
...for OSs running in virtual...
> able to independently communicate with the firmware without
On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TISCI) permits the
> ability for Operating Systems to running in virtual machines to be
...for OSs running in virtual...
> able to independently communicate with the firmware without
On 06/12/18 14:24, Dmitry Safonov wrote:
>>
>> Move align_vdso_addr() after get_unmapped_area() to make sure that
>> errata for AMD 15h is always applied.
>
> Alternative dirty-hacky idea:
> specify some (struct file*) to get_unmapped_area() for vdso vma, then
> mapping would be automatically
On 06/12/18 14:24, Dmitry Safonov wrote:
>>
>> Move align_vdso_addr() after get_unmapped_area() to make sure that
>> errata for AMD 15h is always applied.
>
> Alternative dirty-hacky idea:
> specify some (struct file*) to get_unmapped_area() for vdso vma, then
> mapping would be automatically
Commit-ID: f2ae67941138a1e53cb1bc6a1b5878a8bdc74d26
Gitweb: https://git.kernel.org/tip/f2ae67941138a1e53cb1bc6a1b5878a8bdc74d26
Author: Sebastian Andrzej Siewior
AuthorDate: Tue, 12 Jun 2018 18:16:19 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 12 Jun 2018 23:33:24 +0200
alpha:
Commit-ID: f2ae67941138a1e53cb1bc6a1b5878a8bdc74d26
Gitweb: https://git.kernel.org/tip/f2ae67941138a1e53cb1bc6a1b5878a8bdc74d26
Author: Sebastian Andrzej Siewior
AuthorDate: Tue, 12 Jun 2018 18:16:19 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 12 Jun 2018 23:33:24 +0200
alpha:
Call secure services to enable ACTLR[0] (Enable invalidates of BTB with
ICIALLU) when branch hardening is enabled for kernel.
Signed-off-by: Nishanth Menon
---
Based on: next-20180612 +
Uboot series posted: https://marc.info/?l=u-boot=152883522011042=2
With Just u-boot changes alone: OMAP5
Call secure services to enable ACTLR[0] (Enable invalidates of BTB with
ICIALLU) when branch hardening is enabled for kernel.
Signed-off-by: Nishanth Menon
---
Based on: next-20180612 +
Uboot series posted: https://marc.info/?l=u-boot=152883522011042=2
With Just u-boot changes alone: OMAP5
Hi:
On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote:
> Hello,
>
> > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html
> > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html
>
> If I get it right, the first patch is already upstreamed in some
>
Hi:
On Tue, Jun 12, 2018 at 09:43:26PM +0300, Anatoly Trosinenko wrote:
> Hello,
>
> > [1] https://www.spinics.net/lists/linux-fsdevel/msg125241.html
> > [2] https://www.spinics.net/lists/linux-fsdevel/msg126499.html
>
> If I get it right, the first patch is already upstreamed in some
>
On Tue, 12 Jun 2018 15:24:41 -0600
Jens Axboe wrote:
> On 6/12/18 2:20 PM, Stefan Agner wrote:
> > On 12.06.2018 17:24, Jens Axboe wrote:
> >> On 6/12/18 3:17 AM, Stefan Agner wrote:
> >>> [also added Jens Axboe]
> >>>
> >>> On 12.06.2018 10:27, Boris Brezillon wrote:
> On Tue, 12 Jun
On Tue, 12 Jun 2018 15:24:41 -0600
Jens Axboe wrote:
> On 6/12/18 2:20 PM, Stefan Agner wrote:
> > On 12.06.2018 17:24, Jens Axboe wrote:
> >> On 6/12/18 3:17 AM, Stefan Agner wrote:
> >>> [also added Jens Axboe]
> >>>
> >>> On 12.06.2018 10:27, Boris Brezillon wrote:
> On Tue, 12 Jun
Dear Beloved. Greetings through our Lord Jesus Christ. I bring you good news
from Africa. Evangelist Faith Yakubu is my name. Please contact me on my
personal email ate.yakub...@yahoo.com I would love to share it with
you thank you. Hope to read from you soon.
Dear Beloved. Greetings through our Lord Jesus Christ. I bring you good news
from Africa. Evangelist Faith Yakubu is my name. Please contact me on my
personal email ate.yakub...@yahoo.com I would love to share it with
you thank you. Hope to read from you soon.
On 6/12/18 2:20 PM, Stefan Agner wrote:
> On 12.06.2018 17:24, Jens Axboe wrote:
>> On 6/12/18 3:17 AM, Stefan Agner wrote:
>>> [also added Jens Axboe]
>>>
>>> On 12.06.2018 10:27, Boris Brezillon wrote:
On Tue, 12 Jun 2018 10:06:42 +0200
Stefan Agner wrote:
> On 12.06.2018
On 6/12/18 2:20 PM, Stefan Agner wrote:
> On 12.06.2018 17:24, Jens Axboe wrote:
>> On 6/12/18 3:17 AM, Stefan Agner wrote:
>>> [also added Jens Axboe]
>>>
>>> On 12.06.2018 10:27, Boris Brezillon wrote:
On Tue, 12 Jun 2018 10:06:42 +0200
Stefan Agner wrote:
> On 12.06.2018
On Tue, 2018-06-12 at 21:49 +0100, Dmitry Safonov wrote:
> There is errata for AMD family 15h CPUs [1] and since
> commit dfb09f9b7ab03 ("x86, amd: Avoid cache aliasing penalties on
> AMD
> family 15h") bits [14:12] are being cleared for shared libraries.
> Also per-boot ASLR applies over upper
On Tue, 2018-06-12 at 21:49 +0100, Dmitry Safonov wrote:
> There is errata for AMD family 15h CPUs [1] and since
> commit dfb09f9b7ab03 ("x86, amd: Avoid cache aliasing penalties on
> AMD
> family 15h") bits [14:12] are being cleared for shared libraries.
> Also per-boot ASLR applies over upper
On Tue, 12 Jun 2018 22:20:58 +0200
Stefan Agner wrote:
> On 12.06.2018 17:24, Jens Axboe wrote:
> > On 6/12/18 3:17 AM, Stefan Agner wrote:
> >> [also added Jens Axboe]
> >>
> >> On 12.06.2018 10:27, Boris Brezillon wrote:
> >>> On Tue, 12 Jun 2018 10:06:42 +0200
> >>> Stefan Agner wrote:
>
On Tue, 12 Jun 2018 22:20:58 +0200
Stefan Agner wrote:
> On 12.06.2018 17:24, Jens Axboe wrote:
> > On 6/12/18 3:17 AM, Stefan Agner wrote:
> >> [also added Jens Axboe]
> >>
> >> On 12.06.2018 10:27, Boris Brezillon wrote:
> >>> On Tue, 12 Jun 2018 10:06:42 +0200
> >>> Stefan Agner wrote:
>
On Tue, Jun 05, 2018 at 01:16:26AM -0500, Nishanth Menon wrote:
> Secure Proxy is another communication scheme in Texas Instrument's
> devices intended to provide an unique communication path from various
> processors in the System on Chip(SoC) to a central System Controller.
>
> Secure proxy is,
On Tue, Jun 05, 2018 at 01:16:26AM -0500, Nishanth Menon wrote:
> Secure Proxy is another communication scheme in Texas Instrument's
> devices intended to provide an unique communication path from various
> processors in the System on Chip(SoC) to a central System Controller.
>
> Secure proxy is,
On 05.06.2018 10:55, Borislav Petkov wrote:
> On Sun, May 20, 2018 at 12:07:22AM +0200, Maciej S. Szmigiero wrote:
>> Currently, the code scanning a CPU equivalence table read from a microcode
>> container file assumes that it actually contains a terminating zero entry,
>> but if does not then the
On 05.06.2018 10:55, Borislav Petkov wrote:
> On Sun, May 20, 2018 at 12:07:22AM +0200, Maciej S. Szmigiero wrote:
>> Currently, the code scanning a CPU equivalence table read from a microcode
>> container file assumes that it actually contains a terminating zero entry,
>> but if does not then the
PCI changes:
- squash AER directory into drivers/pci/pcie/aer.c (Bjorn Helgaas)
- collect all native hardware drivers under drivers/pci/controller/
(Shawn Lin)
The following changes since commit 3a3869f1c443383ef8354ffa0e5fb8df65d8b549:
Merge tag 'pci-v4.18-changes' of
PCI changes:
- squash AER directory into drivers/pci/pcie/aer.c (Bjorn Helgaas)
- collect all native hardware drivers under drivers/pci/controller/
(Shawn Lin)
The following changes since commit 3a3869f1c443383ef8354ffa0e5fb8df65d8b549:
Merge tag 'pci-v4.18-changes' of
On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
> AM654 uses a UART controller that is compatible (partially) with
> existing 8250 UART, however, has a few differences with respect to DMA
> support and control paths. Introduce a base definition that allows us
> to build up the
On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
> AM654 uses a UART controller that is compatible (partially) with
> existing 8250 UART, however, has a few differences with respect to DMA
> support and control paths. Introduce a base definition that allows us
> to build up the
On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of
On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
> platform, targeted for broad market and industrial control with aim to
> meet the complex processing needs of modern embedded products.
>
> Some highlights of
On 06/12/2018 10:51 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.113 release.
> There are 21 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
On 06/12/2018 10:51 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.113 release.
> There are 21 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
On 06/12/2018 10:51 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.137 release.
> There are 24 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
On 06/12/2018 10:51 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.137 release.
> There are 24 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
On Mon, Jun 04, 2018 at 01:26:24PM +0530, Taniya Das wrote:
> Add device tree bindings for display clock controller for Qualcomm
> Technology Inc's SoCs.
>
> Signed-off-by: Taniya Das
> ---
> .../devicetree/bindings/clock/qcom,dispcc.txt | 19 +
>
On Mon, Jun 04, 2018 at 01:26:24PM +0530, Taniya Das wrote:
> Add device tree bindings for display clock controller for Qualcomm
> Technology Inc's SoCs.
>
> Signed-off-by: Taniya Das
> ---
> .../devicetree/bindings/clock/qcom,dispcc.txt | 19 +
>
On 06/12/2018 10:46 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.108 release.
> There are 31 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
On 06/12/2018 10:46 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.108 release.
> There are 31 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
On Sat, Jun 02, 2018 at 10:24:13PM +0530, Manivannan Sadhasivam wrote:
> Add gpio interrupt bindings for Actions Semi S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> .../bindings/pinctrl/actions,s900-pinctrl.txt | 10 ++
> 1 file changed, 10 insertions(+)
On Sat, Jun 02, 2018 at 10:24:13PM +0530, Manivannan Sadhasivam wrote:
> Add gpio interrupt bindings for Actions Semi S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> .../bindings/pinctrl/actions,s900-pinctrl.txt | 10 ++
> 1 file changed, 10 insertions(+)
On Tue, Jun 12, 2018 at 10:43 PM Bjorn Andersson
wrote:
>
> On Tue 12 Jun 03:54 PDT 2018, Amit Kucheria wrote:
> > diff --git a/drivers/thermal/qcom/tsens-8996.c
> > b/drivers/thermal/qcom/tsens-8996.c
> [..]
> > static const struct tsens_ops ops_8996 = {
> > .init =
On Tue, Jun 12, 2018 at 10:43 PM Bjorn Andersson
wrote:
>
> On Tue 12 Jun 03:54 PDT 2018, Amit Kucheria wrote:
> > diff --git a/drivers/thermal/qcom/tsens-8996.c
> > b/drivers/thermal/qcom/tsens-8996.c
> [..]
> > static const struct tsens_ops ops_8996 = {
> > .init =
201 - 300 of 1386 matches
Mail list logo
