ARMv8.2 requires implementation of the RAS extension. In
this extension, it adds SEI(SError Interrupt) notification
type, this patch adds new GHES error source SEI handling
functions. This error source parsing and handling method
is similar with the SEA.
Expose API ghes_notify_sei() to external
ARMv8.2 requires implementation of the RAS extension. In
this extension, it adds SEI(SError Interrupt) notification
type, this patch adds new GHES error source SEI handling
functions. This error source parsing and handling method
is similar with the SEA.
Expose API ghes_notify_sei() to external
If it is not RAS SError, directly inject virtual SError,
which will keep the old way, otherwise firstly let host
ACPI kernel driver to handle it. If the ACPI handling is
failed, KVM continues categorizing errors by the ESR_ELx.
For the recoverable error (UER), it has not been silently
propagated
The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
guest and user space needs a way to tell KVM this value. So we add a
new ioctl. Before user space specifies the Exception Syndrome Register
ESR(ESR), it firstly checks that whether KVM has the capability to
set the guest ESR, If
From: Xie XiuQi
ARM's v8.2 Extentions add support for Reliability, Availability and
Serviceability (RAS). On CPUs with these extensions system software
can use additional barriers to isolate errors and determine if faults
are pending.
Add cpufeature detection and a barrier
If it is not RAS SError, directly inject virtual SError,
which will keep the old way, otherwise firstly let host
ACPI kernel driver to handle it. If the ACPI handling is
failed, KVM continues categorizing errors by the ESR_ELx.
For the recoverable error (UER), it has not been silently
propagated
The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the
guest and user space needs a way to tell KVM this value. So we add a
new ioctl. Before user space specifies the Exception Syndrome Register
ESR(ESR), it firstly checks that whether KVM has the capability to
set the guest ESR, If
From: Xie XiuQi
ARM's v8.2 Extentions add support for Reliability, Availability and
Serviceability (RAS). On CPUs with these extensions system software
can use additional barriers to isolate errors and determine if faults
are pending.
Add cpufeature detection and a barrier in the context-switch
ARMv8.2 adds a new bit HCR_EL2.TEA which routes synchronous external
aborts to EL2, and adds a trap control bit HCR_EL2.TERR which traps
all Non-secure EL1&0 error record accesses to EL2.
This patch enables the two bits for the guest OS, guaranteeing that
KVM takes external aborts and traps
ARMv8.2 adds a new bit HCR_EL2.TEA which routes synchronous external
aborts to EL2, and adds a trap control bit HCR_EL2.TERR which traps
all Non-secure EL1&0 error record accesses to EL2.
This patch enables the two bits for the guest OS, guaranteeing that
KVM takes external aborts and traps
From: James Morse
When we exit a guest due to an SError the vcpu fault info isn't updated
with the ESR. Today this is only done for traps.
The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's
fault_info with the ESR on SError so that handle_exit() can
From: James Morse
When we exit a guest due to an SError the vcpu fault info isn't updated
with the ESR. Today this is only done for traps.
The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's
fault_info with the ESR on SError so that handle_exit() can determine
if this was a
On 01/05/2018 10:53 PM, Hanjun Guo wrote:
>> + /*
>> +* PTI poisons low addresses in the kernel page tables in the
>> +* name of making them unusable for userspace. To execute
>> +* code at such a low address, the poison must be cleared.
>> +*/
>> + pgd->pgd &=
On 01/05/2018 10:53 PM, Hanjun Guo wrote:
>> + /*
>> +* PTI poisons low addresses in the kernel page tables in the
>> +* name of making them unusable for userspace. To execute
>> +* code at such a low address, the poison must be cleared.
>> +*/
>> + pgd->pgd &=
On 01/05/2018 10:28 PM, Hanjun Guo wrote:
>> +
>> p4d = p4d_alloc(_mm, pgd, vaddr);
> Seems pgd will be re-set after p4d_alloc(), so should
> we put the code behind (or after pud_alloc())?
Yes, it has to go below where the PGD actually gets set which is
after pud_alloc(). You can put it
On 01/05/2018 10:28 PM, Hanjun Guo wrote:
>> +
>> p4d = p4d_alloc(_mm, pgd, vaddr);
> Seems pgd will be re-set after p4d_alloc(), so should
> we put the code behind (or after pud_alloc())?
Yes, it has to go below where the PGD actually gets set which is
after pud_alloc(). You can put it
On 1/6/2018 2:35 AM, Alan Cox wrote:
On Sat, 6 Jan 2018 01:54:36 +0530
"Kohli, Gaurav" wrote:
Hi Alan,
Sorry correcting the typo here:
+retval = tty_ldisc_lock(tty, 5 * HZ);
+if (retval)
+ goto err_release_lock;
tty->port->itty = tty;
/*
* Structures all
On 1/6/2018 2:35 AM, Alan Cox wrote:
On Sat, 6 Jan 2018 01:54:36 +0530
"Kohli, Gaurav" wrote:
Hi Alan,
Sorry correcting the typo here:
+retval = tty_ldisc_lock(tty, 5 * HZ);
+if (retval)
+ goto err_release_lock;
tty->port->itty = tty;
/*
* Structures all installed ... call the
On 2018/1/6 14:28, Hanjun Guo wrote:
> Hi Dave,
>
> Thank you very much for the quick response! Minor comments inline.
>
> On 2018/1/6 14:06, Dave Hansen wrote:
>> On 01/05/2018 08:54 PM, Hanjun Guo wrote:
>>> Do you mean NX bit will be brought back later? I'm asking this because
>>> I tested
On 2018/1/6 14:28, Hanjun Guo wrote:
> Hi Dave,
>
> Thank you very much for the quick response! Minor comments inline.
>
> On 2018/1/6 14:06, Dave Hansen wrote:
>> On 01/05/2018 08:54 PM, Hanjun Guo wrote:
>>> Do you mean NX bit will be brought back later? I'm asking this because
>>> I tested
On Sat, Jan 6, 2018 at 6:07 AM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 8a4816cad00bf14642f0ed6043b32d29a05006ce
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1
On Sat, Jan 6, 2018 at 6:07 AM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 8a4816cad00bf14642f0ed6043b32d29a05006ce
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is
On 2018/1/6 2:33, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Xishi Qiu wrote:
>
>> I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed.
>>
>> ...
>> [0.00] PM: Registered nosave memory: [mem
>> 0x810-0x8ff]
>> [0.00] PM: Registered nosave memory:
On 2018/1/6 2:33, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Xishi Qiu wrote:
>
>> I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed.
>>
>> ...
>> [0.00] PM: Registered nosave memory: [mem
>> 0x810-0x8ff]
>> [0.00] PM: Registered nosave memory:
On 01/05/2018 06:12 PM, Tim Chen wrote:
> Thanks to everyone for the feedback on the initial posting.
> This is an updated patchset and I hope I've captured all
> the review comments. I've done a lot of code clean up
> per everyone's comments. Please let me know if I've missed
> something.
>
On 01/05/2018 06:12 PM, Tim Chen wrote:
> Thanks to everyone for the feedback on the initial posting.
> This is an updated patchset and I hope I've captured all
> the review comments. I've done a lot of code clean up
> per everyone's comments. Please let me know if I've missed
> something.
>
SoundWire bus provides sdw_read() and sdw_write() APIs for Slave
devices to program the registers. Provide support in regmap for
SoundWire bus.
Signed-off-by: Hardik T Shah
Signed-off-by: Sanyog Kale
Reviewed-by: Philippe Ombredanne
SoundWire bus provides sdw_read() and sdw_write() APIs for Slave
devices to program the registers. Provide support in regmap for
SoundWire bus.
Signed-off-by: Hardik T Shah
Signed-off-by: Sanyog Kale
Reviewed-by: Philippe Ombredanne
Acked-by: Pierre-Louis Bossart
Reviewed-by: Takashi Iwai
Hi Dave,
Thank you very much for the quick response! Minor comments inline.
On 2018/1/6 14:06, Dave Hansen wrote:
> On 01/05/2018 08:54 PM, Hanjun Guo wrote:
>> Do you mean NX bit will be brought back later? I'm asking this because
>> I tested this patch which it fixed the boot panic issue but
Hi Dave,
Thank you very much for the quick response! Minor comments inline.
On 2018/1/6 14:06, Dave Hansen wrote:
> On 01/05/2018 08:54 PM, Hanjun Guo wrote:
>> Do you mean NX bit will be brought back later? I'm asking this because
>> I tested this patch which it fixed the boot panic issue but
On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman wrote:
> Dan Williams writes:
>
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One of these, known as
On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman wrote:
> Dan Williams writes:
>
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One of these, known as variant-1, allows
>> explicit bounds checks to be
On 2018/1/5 22:54, Andrew Lunn wrote:
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1126,6 +1126,7 @@ static int hns3_nic_set_features(struct net_device
*netdev,
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
On 2018/1/5 22:54, Andrew Lunn wrote:
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1126,6 +1126,7 @@ static int hns3_nic_set_features(struct net_device
*netdev,
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
On Fri, Jan 05, 2018 at 05:05:52PM +, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote:
> > SoundWire bus provides sdw_read() and sdw_write() APIs for Slave
> > devices to program the registers. Provide support in regmap for
> > SoundWire bus.
>
> I can't apply
On Fri, Jan 05, 2018 at 05:05:52PM +, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote:
> > SoundWire bus provides sdw_read() and sdw_write() APIs for Slave
> > devices to program the registers. Provide support in regmap for
> > SoundWire bus.
>
> I can't apply
On Fri, Jan 05, 2018 at 11:22:15AM -0600, Pierre-Louis Bossart wrote:
> On 1/5/18 11:04 AM, Mark Brown wrote:
> >On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote:
> >
> >>+ /* SoundWire register address are contiguous */
> >>+ if (config->reg_stride != 0)
> >>+ return
On Fri, Jan 05, 2018 at 11:22:15AM -0600, Pierre-Louis Bossart wrote:
> On 1/5/18 11:04 AM, Mark Brown wrote:
> >On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote:
> >
> >>+ /* SoundWire register address are contiguous */
> >>+ if (config->reg_stride != 0)
> >>+ return
On Fri, Jan 05, 2018 at 05:04:21PM +, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote:
>
> > + /* SoundWire register address are contiguous */
> > + if (config->reg_stride != 0)
> > + return -ENOTSUPP;
>
> That doesn't mean the chip hasn't decided
On Fri, Jan 05, 2018 at 05:04:21PM +, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 11:19:38AM +0530, Vinod Koul wrote:
>
> > + /* SoundWire register address are contiguous */
> > + if (config->reg_stride != 0)
> > + return -ENOTSUPP;
>
> That doesn't mean the chip hasn't decided
On 01/05/2018 08:54 PM, Hanjun Guo wrote:
> Do you mean NX bit will be brought back later? I'm asking this because
> I tested this patch which it fixed the boot panic issue but the system
> will hang when rebooting the system, because rebooting will also call efi
> then panic as NS bit is set.
On 01/05/2018 08:54 PM, Hanjun Guo wrote:
> Do you mean NX bit will be brought back later? I'm asking this because
> I tested this patch which it fixed the boot panic issue but the system
> will hang when rebooting the system, because rebooting will also call efi
> then panic as NS bit is set.
On 01/04/18 18:00, David Woodhouse wrote:
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index d4fc98c..1009d1a 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -429,6 +429,19 @@ config GOLDFISH
> def_bool y
> depends on X86_GOLDFISH
>
> +config RETPOLINE
>
On 01/04/18 18:00, David Woodhouse wrote:
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index d4fc98c..1009d1a 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -429,6 +429,19 @@ config GOLDFISH
> def_bool y
> depends on X86_GOLDFISH
>
> +config RETPOLINE
>
On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote:
>> From: Andi Kleen
>>
>> When access_ok fails we should always stop speculating.
>> Add the required
On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote:
>> From: Andi Kleen
>>
>> When access_ok fails we should always stop speculating.
>> Add the required barriers to the x86 access_ok macro.
>
> Honestly, this seems completely bogus.
>
>
Recently, how the pointers being printed with %p has been changed
by commit ad67b74d2469 ("printk: hash addresses printed with %p").
This is causing a regression while showing offset in the
uprobe_events file. Instead of %p, use %px to display offset.
Before patch:
# perf probe -vv -x
Recently, how the pointers being printed with %p has been changed
by commit ad67b74d2469 ("printk: hash addresses printed with %p").
This is causing a regression while showing offset in the
uprobe_events file. Instead of %p, use %px to display offset.
Before patch:
# perf probe -vv -x
Allwinner H6 is a new SoC with Cortex-A53 cores from Allwinner, with its
memory map fully reworked and some high-speed peripherals (PCIe, USB
3.0) introduced.
This commit adds the basical DTSI file of it, including the clock
support and UART support.
Signed-off-by: Icenowy Zheng
Allwinner H6 is a new SoC with Cortex-A53 cores from Allwinner, with its
memory map fully reworked and some high-speed peripherals (PCIe, USB
3.0) introduced.
This commit adds the basical DTSI file of it, including the clock
support and UART support.
Signed-off-by: Icenowy Zheng
---
On Fri, Jan 5, 2018 at 6:55 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
>> +#ifndef nospec_ptr
>> +#define nospec_ptr(ptr, lo, hi)
>>\
>
> Do we actually
On Fri, Jan 5, 2018 at 6:55 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
>> +#ifndef nospec_ptr
>> +#define nospec_ptr(ptr, lo, hi)
>>\
>
> Do we actually want this horrible interface?
>
> It just causes the
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:38 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
>
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:38 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; net...@vger.kernel.org
> Subject:
> -Original Message-
> From: Brown, Aaron F
> Sent: Friday, January 5, 2018 8:34 PM
> To: 'Sagar Arun Kamble' ; linux-
> ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
>
> -Original Message-
> From: Brown, Aaron F
> Sent: Friday, January 5, 2018 8:34 PM
> To: 'Sagar Arun Kamble' ; linux-
> ker...@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; net...@vger.kernel.org
> Subject: RE: [Intel-wired-lan] [PATCH
The Allwinner H6 SoC has a CCU which has been largely rearranged.
Add support for it in the sunxi-ng CCU framework.
Signed-off-by: Icenowy Zheng
---
.../devicetree/bindings/clock/sunxi-ccu.txt|1 +
drivers/clk/sunxi-ng/Kconfig |5 +
The Allwinner H6 SoC has a CCU which has been largely rearranged.
Add support for it in the sunxi-ng CCU framework.
Signed-off-by: Icenowy Zheng
---
.../devicetree/bindings/clock/sunxi-ccu.txt|1 +
drivers/clk/sunxi-ng/Kconfig |5 +
Hi Jiri,
Thanks for the fix, comments inline.
On 2018/1/6 2:19, Jiri Kosina wrote:
>
> [ adding Hugh ]
>
> On Thu, 4 Jan 2018, Dave Hansen wrote:
>
>>> BTW, we have just reported a bug caused by kaiser[1], which looks like
>>> caused by SMEP. Could you please help to have a look?
>>>
>>> [1]
Hi Jiri,
Thanks for the fix, comments inline.
On 2018/1/6 2:19, Jiri Kosina wrote:
>
> [ adding Hugh ]
>
> On Thu, 4 Jan 2018, Dave Hansen wrote:
>
>>> BTW, we have just reported a bug caused by kaiser[1], which looks like
>>> caused by SMEP. Could you please help to have a look?
>>>
>>> [1]
On the new Allwinner H6 SoC, multiple PLL's are NMP style clocks
(modelled as NKMP with no K) and have fixed post-dividers.
Add fixed post divider support to the NKMP style clocks.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 20 +---
On the new Allwinner H6 SoC, multiple PLL's are NMP style clocks
(modelled as NKMP with no K) and have fixed post-dividers.
Add fixed post divider support to the NKMP style clocks.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 20 +---
Use the ratelimited printk() version for swap-device write error
reporting. We can use ZRAM as a swap-device, and the tricky part
here is that zsmalloc() stores compressed objects in memory, thus
it has to allocates pages during swap-out. If the system is short
on memory, then we begin to flood
Use the ratelimited printk() version for swap-device write error
reporting. We can use ZRAM as a swap-device, and the tricky part
here is that zsmalloc() stores compressed objects in memory, thus
it has to allocates pages during swap-out. If the system is short
on memory, then we begin to flood
Loan Offer at 3% Lowest Rate Get Now.
Loan Offer at 3% Lowest Rate Get Now.
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
>
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; net...@vger.kernel.org
> Subject:
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
>
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; net...@vger.kernel.org
> Subject:
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:38 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
>
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:38 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; net...@vger.kernel.org
> Subject:
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
>
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Sagar Arun Kamble
> Sent: Thursday, December 14, 2017 11:39 PM
> To: linux-kernel@vger.kernel.org
> Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> ; Kamble, Sagar A
> ; net...@vger.kernel.org
> Subject:
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Jeff Kirsher
> Sent: Wednesday, December 6, 2017 8:25 AM
> To: Kamble, Sagar A ; linux-
> ker...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org;
>
The Allwinner H6 SoC has two pin controllers, one main controller
(called CPUX-PORT in user manual) and one controller in CPUs power
domain (called CPUS-PORT in user manual).
This commit introduces support for the main pin controller on H6.
The pin bank A and B are not wired out and hidden from
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> Behalf Of Jeff Kirsher
> Sent: Wednesday, December 6, 2017 8:25 AM
> To: Kamble, Sagar A ; linux-
> ker...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org; linux-r...@vger.kernel.org;
> net...@vger.kernel.org; Richard
The Allwinner H6 SoC has two pin controllers, one main controller
(called CPUX-PORT in user manual) and one controller in CPUs power
domain (called CPUS-PORT in user manual).
This commit introduces support for the main pin controller on H6.
The pin bank A and B are not wired out and hidden from
The Allwinner H6 SoC have its pin controllers with the first IRQ-capable
GPIO bank at IRQ bank 1 and the second bank at IRQ bank 5. This
situation cannot be processed with the current pinctrl IRQ code, as it
only expects a offset to all IRQ banks.
Update the code to use a logical IRQ bank to
The Allwinner H6 SoC have its pin controllers with the first IRQ-capable
GPIO bank at IRQ bank 1 and the second bank at IRQ bank 5. This
situation cannot be processed with the current pinctrl IRQ code, as it
only expects a offset to all IRQ banks.
Update the code to use a logical IRQ bank to
The Allwinner H6 pin controllers (both the main one and the CPUs one)
have no bus gate clocks.
Add support for this kind of pin controllers.
Signed-off-by: Icenowy Zheng
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30 --
The Allwinner H6 pin controllers (both the main one and the CPUs one)
have no bus gate clocks.
Add support for this kind of pin controllers.
Signed-off-by: Icenowy Zheng
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30 --
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 +
This patchset adds initial support for the Allwinner H6 SoC.
It's quite different from earlier Allwinner SoCs. For example, the
memory map is refactored, and the CCU is rearranged. It's also the first
Allwinner SoC with PCI Express interface, and the second one with USB
3.0 (the first one is
This patchset adds initial support for the Allwinner H6 SoC.
It's quite different from earlier Allwinner SoCs. For example, the
memory map is refactored, and the CCU is rearranged. It's also the first
Allwinner SoC with PCI Express interface, and the second one with USB
3.0 (the first one is
Hi Geert,
On Fri, 5 Jan 2018, Geert Uytterhoeven wrote:
>
> I assume you meant this to go in through the m68k tree?
>
Yes, please. Because the NuBus-PowerMac port is out-of-tree, the m68k tree
seems more appropriate than the powerpc tree for this submission.
> Can you please run this
Hi Geert,
On Fri, 5 Jan 2018, Geert Uytterhoeven wrote:
>
> I assume you meant this to go in through the m68k tree?
>
Yes, please. Because the NuBus-PowerMac port is out-of-tree, the m68k tree
seems more appropriate than the powerpc tree for this submission.
> Can you please run this
On 01/05/2018 06:12 PM, Tim Chen wrote:
> .macro ENABLE_IBRS
> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> + testl $1, dynamic_ibrs
> + jz .Lskip_\@
There was an earlier suggestion to use STATIC_JUMP_IF_... here. That's
a good suggestion, but we encountered
On 01/05/2018 06:12 PM, Tim Chen wrote:
> .macro ENABLE_IBRS
> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> + testl $1, dynamic_ibrs
> + jz .Lskip_\@
There was an earlier suggestion to use STATIC_JUMP_IF_... here. That's
a good suggestion, but we encountered
On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
wrote:
>
> The fact is, we have to stop speculating when access_ok() does *not*
> fail - because that's when we'll actually do the access. And it's that
> access that needs to be non-speculative.
I also suspect we
On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
wrote:
>
> The fact is, we have to stop speculating when access_ok() does *not*
> fail - because that's when we'll actually do the access. And it's that
> access that needs to be non-speculative.
I also suspect we should probably do this entirely
Hi, Rafael
Best Regards!
Anson Huang
> -Original Message-
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael
> J. Wysocki
> Sent: 2018-01-05 8:21 PM
> To: Anson Huang
> Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
Hi, Rafael
Best Regards!
Anson Huang
> -Original Message-
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael
> J. Wysocki
> Sent: 2018-01-05 8:21 PM
> To: Anson Huang
> Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; Linux
> PM ; Linux
Add 696MHz operating point according to datasheet
(Rev. 0, 12/2015).
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6ul.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index d5181f8..963e169
Add 696MHz operating point for i.MX6UL, only for those
parts with speed grading fuse set to 2b'10 supports
696MHz operating point, so, speed grading check is also
added for i.MX6UL in this patch, the clock tree for each
operating point are as below:
696MHz:
pll1
Add 696MHz operating point according to datasheet
(Rev. 0, 12/2015).
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6ul.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index d5181f8..963e169 100644
---
Add 696MHz operating point for i.MX6UL, only for those
parts with speed grading fuse set to 2b'10 supports
696MHz operating point, so, speed grading check is also
added for i.MX6UL in this patch, the clock tree for each
operating point are as below:
696MHz:
pll1
On Fri, 2018-01-05 at 15:28 -0800, Hugh Dickins wrote:
> On Fri, Jan 5, 2018 at 6:03 AM, Mike Galbraith wrote:
> > On Fri, 2018-01-05 at 14:34 +0100, Greg Kroah-Hartman wrote:
> >>
> >> Ok, we found two patches that were missing in 4.4-stable that were in
> >> the SLES12 tree
On Fri, 2018-01-05 at 15:28 -0800, Hugh Dickins wrote:
> On Fri, Jan 5, 2018 at 6:03 AM, Mike Galbraith wrote:
> > On Fri, 2018-01-05 at 14:34 +0100, Greg Kroah-Hartman wrote:
> >>
> >> Ok, we found two patches that were missing in 4.4-stable that were in
> >> the SLES12 tree (thanks to Jamie
On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
> +#ifndef nospec_ptr
> +#define nospec_ptr(ptr, lo, hi)
> \
Do we actually want this horrible interface?
It just causes the compiler - or inline asm - to generate worse
On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
> +#ifndef nospec_ptr
> +#define nospec_ptr(ptr, lo, hi)
> \
Do we actually want this horrible interface?
It just causes the compiler - or inline asm - to generate worse code,
because it needs to
1 - 100 of 1582 matches
Mail list logo