Prarit Bhargava writes:
> Blacklisting a module in linux has long been a problem. The process of
> blacklisting a module has changed over time, and it seems that every OS
> does it slightly differently and depends on the age of the init system
> used on that OS.
Hi Prarit,
I don't mind
With the commit "Fix 64-bit code passing control to image kernel", there
is no longer a problem with hibernation resuming a KASLR-booted kernel
image.
Signed-off-by: Kees Cook
---
Depends on: https://lkml.org/lkml/2016/6/13/442
---
Documentation/kernel-parameters.txt | 10 --
arch/x86/bo
The ACPI 6.1 specification was recently released at the end of January
2016, but the arm64 kernel documentation for the use of ACPI was written
for the 5.1 version of the spec. There were significant additions to the
spec that had not yet been mentioned -- for example, the 6.0 mechanisms
added to
This is a resend only: Ping? Last ping was 26 May; there has been zero
response since then. Already have one ACK from Lorenzo; another from an
arm64 maintainer would be really helpful.
The ACPI 6.1 specification was recently released at the end of January
2016, but the arm64 kernel documentatio
From: Thor Thayer
In preparation for the Arria10 ECC modules, check the status
of the parent in the device tree to ensure the block is enabled.
Skip if no parent phandle is set in the device tree.
Signed-off-by: Thor Thayer
---
v2 No change
v3 Move check into validate_parent_available().
---
From: Thor Thayer
In preparation for additional memory module ECCs, the
IRQ function will check a panic flag before doing a
kernel panic on double bit errors. ECCs on buffers
will not cause a kernel panic on DBERRs.
Signed-off-by: Thor Thayer
---
v2 New patch. Add panic flag to IRQ function.
v
On Mon 2016-06-13 17:10:02, João Paulo Rechi Vita wrote:
> On 13 June 2016 at 17:01, Pavel Machek wrote:
> > On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote:
> >> On 13 June 2016 at 15:00, Pavel Machek wrote:
> >> > Hi!
> >> >
> >> >> > João, that means you should send a patch to add the
From: Thor Thayer
Add the device tree bindings needed to support the Altera Ethernet
FIFO buffers on the Arria10 chip.
Signed-off-by: Thor Thayer
---
v2 No Change
v3 Change to common compatible string based on maintainer comments
Add local IRQ values.
---
.../bindings/arm/altera/socfpga-
From: Thor Thayer
In preparation for additional memory module ECCs, add the
memory initialization functions and helper functions used
for memory initialization.
Signed-off-by: Thor Thayer
---
v2: Specify INTMODE selection -> IRQ on each ECC error.
Insert functions above memory-specific func
From: Thor Thayer
Add Altera Arria10 Ethernet FIFO memory EDAC support. Update
to support a common compatibility string for all ethernet
FIFOs in the DT.
Signed-off-by: Thor Thayer
---
v2 Remove (void *) cast from altr_edac_device_of_match[]
Addition of panic flag to ethernet private data.
From: Thor Thayer
Add the device tree entries needed to support the Altera Ethernet
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
v2 No change
v3 Add interrupts for SBERR and DBERR.
---
arch/arm/boot/dts/socfpga_arria10.dtsi | 16
1 file changed, 16
From: Thor Thayer
In preparation for additional memory module ECCs, the IRQ and
check_deps() functions are being made available to all the memory
buffers. Move them outside of the OCRAM only area.
Signed-off-by: Thor Thayer
---
v2 New patch. Move shared functions outside OCRAM only area.
v3 C
From: Thor Thayer
This patch set adds the Ethernet EDAC and memory initialization functions
for Altera's Arria10 peripherals. The ECC memory init functions are common
to all the peripheral memory buffers.
Thor Thayer (7):
EDAC, altera: Check parent status for Arria10 EDAC block
EDAC, altera:
On 13 June 2016 at 17:01, Pavel Machek wrote:
> On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote:
>> On 13 June 2016 at 15:00, Pavel Machek wrote:
>> > Hi!
>> >
>> >> > João, that means you should send a patch to add the ::rfkill suffix.
>> >> >
>> >>
>> >> IMO "airplane" (or maybe "airpla
On Mon 2016-06-13 15:59:35, João Paulo Rechi Vita wrote:
> On 13 June 2016 at 15:00, Pavel Machek wrote:
> > Hi!
> >
> >> > João, that means you should send a patch to add the ::rfkill suffix.
> >> >
> >>
> >> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
> >> reflects the la
On Fri, 10 Jun 2016, Trent Piepho wrote:
> On Fri, 2016-02-05 at 15:30 -0600, at...@opensource.altera.com wrote:
> > Supports Altera SOCFPGA bridges:
> > * fpga2sdram
> > * fpga2hps
> > * hps2fpga
> > * lwhps2fpga
> >
> > Allows enabling/disabling the bridges through the FPGA
> > Bridge Frame
On 13 June 2016 at 15:00, Pavel Machek wrote:
> Hi!
>
>> > João, that means you should send a patch to add the ::rfkill suffix.
>> >
>>
>> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
>> reflects the label on the machine's chassis. I'll name it
>> "asus-wireless::airplane" a
Hi!
> > João, that means you should send a patch to add the ::rfkill suffix.
> >
>
> IMO "airplane" (or maybe "airplane-mode") is a better suffix, as it
> reflects the label on the machine's chassis. I'll name it
> "asus-wireless::airplane" and send this through platform-drivers-x86,
> as this is
On Mon, Jun 13, 2016 at 09:00:41AM -0700, Christoph Hellwig wrote:
> On Fri, Jun 10, 2016 at 04:49:47PM +0200, Luis R. Rodriguez wrote:
> > Do we not expect the number of argument to grow ? This "cleanup" would
> > do away with such possibilities, and then require adding the API later,
> > and this
On Fri, Jun 10, 2016 at 04:49:47PM +0200, Luis R. Rodriguez wrote:
> Do we not expect the number of argument to grow ? This "cleanup" would
> do away with such possibilities, and then require adding the API later,
> and this requiring a full set of collateral evolutions again when this
> is needed.
On 9 June 2016 at 08:43, Johannes Berg wrote:
> On Thu, 2016-05-19 at 09:16 +0200, Pavel Machek wrote:
>
(...)
>> LED
>> subsystem seems to use suffix of LED name to do that. So if we
>> standartize, lets say "::rfkill" suffix for this, it should work and
>> follow existing practice.
> [...]
>>
On 06/13/2016 07:03 AM, Matt Fleming wrote:
> On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote:
>>
>> So maybe something along the lines of an enum that would have entries
>> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could
>> be added later as needed.
>
> Sure, that works
On Thu, 09 Jun, at 01:33:30PM, Tom Lendacky wrote:
>
> I was trying to play it safe here, but as you say, the firmware should
> be using our page tables so we can get rid of this call. The problem
> will actually be if we transition to a 32-bit efi. The encryption bit
> will be lost in cr3 and so
Hi, again
I found another issue in binfmt_ilp32.c. We are using the ELF_ET_DYN_BASE
for ilp32 application. The default ELF_ET_DYN_BASE is calculated by
TASK_SIZE_64. IIUC, we should define the following things in binfmt_ilp32.c
which is the same value as aarch32:
+#undef ELF_ET_DYN_BASE
+#define
On Mon, 13 Jun, at 01:03:22PM, Matt Fleming wrote:
>
> Would we need a new function? Couldn't we just have a new
> FIXMAP_PAGE_* constant? e.g. would something like this work?
>
> ---
>
> enum memremap_owner {
> KERNEL_DATA = 0,
> BOOT_DATA,
> };
>
> void __init *
> early_memremap(r
Blacklisting a module in linux has long been a problem. The process of
blacklisting a module has changed over time, and it seems that every OS
does it slightly differently and depends on the age of the init system
used on that OS.
The current Fedora/systemd procedure is to use rd.blacklist=module
On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote:
>
> So maybe something along the lines of an enum that would have entries
> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could
> be added later as needed.
Sure, that works for me, though maybe BOOT_DATA would be more
applica
On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
31 matches
Mail list logo
