On 2017-02-20 02:33, Bryan O'Donoghue wrote:
>
>
> On 19/02/17 13:33, Jan Kiszka wrote:
>>> I would not object strongly to having conditionally compiled code in
>>> mainline that adds support for this, but bodging the default code path
>>> like this for a Quark quirk is out of the question imo.
On 2017-02-20 02:33, Bryan O'Donoghue wrote:
>
>
> On 19/02/17 13:33, Jan Kiszka wrote:
>>> I would not object strongly to having conditionally compiled code in
>>> mainline that adds support for this, but bodging the default code path
>>> like this for a Quark quirk is out of the question imo.
On Wed, Mar 1, 2017 at 4:02 PM, Bryan O'Donoghue
wrote:
>>> So, summarize, you state that
>>> 1. CONFIG_SMP=y and
>>> 2. CONFIG_M686=y and
>>> 3. Kernel works on Quark
>>>
>>> Is it correct?
>> Logically yes. It's a very long time since I looked in detail. No harm
On Wed, Mar 1, 2017 at 4:02 PM, Bryan O'Donoghue
wrote:
>>> So, summarize, you state that
>>> 1. CONFIG_SMP=y and
>>> 2. CONFIG_M686=y and
>>> 3. Kernel works on Quark
>>>
>>> Is it correct?
>> Logically yes. It's a very long time since I looked in detail. No harm
>> in checking it out though.
On 28/02/17 17:42, Bryan O'Donoghue wrote:
On 28/02/17 17:18, Andy Shevchenko wrote:
On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
A kernel compiled like this
make menuconfig ARCH=i386
I hope you care that it is equivalent to
make menuconfig ARCH=i686
make bzImage -j 8
will run
On 28/02/17 17:42, Bryan O'Donoghue wrote:
On 28/02/17 17:18, Andy Shevchenko wrote:
On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
A kernel compiled like this
make menuconfig ARCH=i386
I hope you care that it is equivalent to
make menuconfig ARCH=i686
make bzImage -j 8
will run
On 28/02/17 17:18, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
>> A kernel compiled like this
>>
>> make menuconfig ARCH=i386
>
> I hope you care that it is equivalent to
>
> make menuconfig ARCH=i686
>
>> make bzImage -j 8
>>
>> will run just fine on Quark x1000
On 28/02/17 17:18, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
>> A kernel compiled like this
>>
>> make menuconfig ARCH=i386
>
> I hope you care that it is equivalent to
>
> make menuconfig ARCH=i686
>
>> make bzImage -j 8
>>
>> will run just fine on Quark x1000
On 28/02/17 15:27, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
> wrote:
>> On 28/02/17 13:36, Andy Shevchenko wrote:
>>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>>> wrote:
On Tue, Feb 28, 2017
On 28/02/17 15:27, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
> wrote:
>> On 28/02/17 13:36, Andy Shevchenko wrote:
>>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>>> wrote:
On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
wrote:
> On 28
On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
wrote:
> On 28/02/17 15:27, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
>> wrote:
>>> On 28/02/17 13:36, Andy Shevchenko wrote:
On Tue, Feb 28, 2017
On Tue, Feb 28, 2017 at 6:52 PM, Bryan O'Donoghue
wrote:
> On 28/02/17 15:27, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
>> wrote:
>>> On 28/02/17 13:36, Andy Shevchenko wrote:
On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
wrote:
> On Tue, Feb
On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
wrote:
> On 28/02/17 13:36, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>> wrote:
>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>>
On Tue, Feb 28, 2017 at 5:07 PM, Bryan O'Donoghue
wrote:
> On 28/02/17 13:36, Andy Shevchenko wrote:
>> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
>> wrote:
>>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>>> wrote:
On 28 February 2017 at 12:29, Matt Fleming
wrote:
>
On 28/02/17 13:36, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
> wrote:
>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>> wrote:
>>> On 28 February 2017 at 12:29, Matt Fleming
On 28/02/17 13:36, Andy Shevchenko wrote:
> On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
> wrote:
>> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
>> wrote:
>>> On 28 February 2017 at 12:29, Matt Fleming wrote:
On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>
>>> As I said before,
On 28/02/17 15:07, Bryan O'Donoghue wrote:
> a big fat ia32
*allow a full fat..
--
bod
On 28/02/17 15:07, Bryan O'Donoghue wrote:
> a big fat ia32
*allow a full fat..
--
bod
On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
wrote:
> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
> wrote:
>> On 28 February 2017 at 12:29, Matt Fleming wrote:
>>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka
On Tue, Feb 28, 2017 at 3:35 PM, Andy Shevchenko
wrote:
> On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
> wrote:
>> On 28 February 2017 at 12:29, Matt Fleming wrote:
>>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>
>> As I said before, I'd be ok with it if we select it compile time,
>>
On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
wrote:
> On 28 February 2017 at 12:29, Matt Fleming wrote:
>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
> As I said before, I'd be ok with it if we select it compile time,
> i.e., no
On Tue, Feb 28, 2017 at 3:25 PM, Ard Biesheuvel
wrote:
> On 28 February 2017 at 12:29, Matt Fleming wrote:
>> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
> As I said before, I'd be ok with it if we select it compile time,
> i.e., no runtime logic that infers whether we are running on such
On 28 February 2017 at 12:29, Matt Fleming wrote:
> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>
>> From you POV, does this exclude upstream quirk support for already
>> shipped devices?
>
> It would need to be an extremely small, well-contained change, that
> had
On 28 February 2017 at 12:29, Matt Fleming wrote:
> On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>>
>> From you POV, does this exclude upstream quirk support for already
>> shipped devices?
>
> It would need to be an extremely small, well-contained change, that
> had no chance of disrupting
On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>
> From you POV, does this exclude upstream quirk support for already
> shipped devices?
It would need to be an extremely small, well-contained change, that
had no chance of disrupting other users of the capsule interface and
where I had a good
On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote:
>
> From you POV, does this exclude upstream quirk support for already
> shipped devices?
It would need to be an extremely small, well-contained change, that
had no chance of disrupting other users of the capsule interface and
where I had a good
On 2017-02-28 13:12, Matt Fleming wrote:
> On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote:
>>
>> I just can re-express my frustration that this essential step hasn't
>> been started years ago by whoever designed the extension. Then I bet
>> there would have been constructive feedback on the
On 2017-02-28 13:12, Matt Fleming wrote:
> On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote:
>>
>> I just can re-express my frustration that this essential step hasn't
>> been started years ago by whoever designed the extension. Then I bet
>> there would have been constructive feedback on the
On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote:
>
> I just can re-express my frustration that this essential step hasn't
> been started years ago by whoever designed the extension. Then I bet
> there would have been constructive feedback on the interface BEFORE its
> ugliness spread to broader
On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote:
>
> I just can re-express my frustration that this essential step hasn't
> been started years ago by whoever designed the extension. Then I bet
> there would have been constructive feedback on the interface BEFORE its
> ugliness spread to broader
On 2017-02-19 17:33, Bryan O'Donoghue wrote:
>
>
> On 19/02/17 13:33, Jan Kiszka wrote:
>>> I would not object strongly to having conditionally compiled code in
>>> mainline that adds support for this, but bodging the default code path
>>> like this for a Quark quirk is out of the question imo.
On 2017-02-19 17:33, Bryan O'Donoghue wrote:
>
>
> On 19/02/17 13:33, Jan Kiszka wrote:
>>> I would not object strongly to having conditionally compiled code in
>>> mainline that adds support for this, but bodging the default code path
>>> like this for a Quark quirk is out of the question imo.
On 19/02/17 13:33, Jan Kiszka wrote:
I would not object strongly to having conditionally compiled code in
mainline that adds support for this, but bodging the default code path
like this for a Quark quirk is out of the question imo.
I'm open for any consensus that avoids bending mainline too
On 19/02/17 13:33, Jan Kiszka wrote:
I would not object strongly to having conditionally compiled code in
mainline that adds support for this, but bodging the default code path
like this for a Quark quirk is out of the question imo.
I'm open for any consensus that avoids bending mainline too
rnel
>>>> Mailing
>>>> List <linux-kernel@vger.kernel.org>; Borislav Petkov <b...@alien8.de>;
>>>> Kweh,
>>>> Hock Leong <hock.leong.k...@intel.com>; Bryan O'Donoghue
>>>> <pure.lo...@nexus-software.ie>
>>
sday, February 16, 2017 3:00 AM
>>>> To: Andy Shevchenko
>>>> Cc: Matt Fleming ; Ard Biesheuvel
>>>> ; linux-...@vger.kernel.org; Linux Kernel
>>>> Mailing
>>>> List ; Borislav Petkov ;
>>>> Kweh,
>>>> Hock L
slav Petkov <b...@alien8.de>; Kweh,
>>> Hock Leong <hock.leong.k...@intel.com>; Bryan O'Donoghue
>>> <pure.lo...@nexus-software.ie>
>>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>>> images
>>>
>>> On 2
>>> Cc: Matt Fleming ; Ard Biesheuvel
>>> ; linux-...@vger.kernel.org; Linux Kernel Mailing
>>> List ; Borislav Petkov ; Kweh,
>>> Hock Leong ; Bryan O'Donoghue
>>>
>>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>&g
On 17/02/17 10:14, Jan Kiszka wrote:
> On 2017-02-17 10:51, Bryan O'Donoghue wrote:
>> On 17/02/17 08:23, Kweh, Hock Leong wrote:
>>> And to have UEFI expand
>>> it capsule support and take in signed binary would be a more secured way.
>>> So, influencing UEFI community to have such support would
On 17/02/17 10:14, Jan Kiszka wrote:
> On 2017-02-17 10:51, Bryan O'Donoghue wrote:
>> On 17/02/17 08:23, Kweh, Hock Leong wrote:
>>> And to have UEFI expand
>>> it capsule support and take in signed binary would be a more secured way.
>>> So, influencing UEFI community to have such support would
On 2017-02-17 10:51, Bryan O'Donoghue wrote:
> On 17/02/17 08:23, Kweh, Hock Leong wrote:
>> And to have UEFI expand
>> it capsule support and take in signed binary would be a more secured way.
>> So, influencing UEFI community to have such support would be the right
>> move throughout the
On 2017-02-17 10:51, Bryan O'Donoghue wrote:
> On 17/02/17 08:23, Kweh, Hock Leong wrote:
>> And to have UEFI expand
>> it capsule support and take in signed binary would be a more secured way.
>> So, influencing UEFI community to have such support would be the right
>> move throughout the
On 17/02/17 08:23, Kweh, Hock Leong wrote:
> And to have UEFI expand
> it capsule support and take in signed binary would be a more secured way.
> So, influencing UEFI community to have such support would be the right
> move throughout the discussion. That is my summary.
CSH stands for "Clanton
On 17/02/17 08:23, Kweh, Hock Leong wrote:
> And to have UEFI expand
> it capsule support and take in signed binary would be a more secured way.
> So, influencing UEFI community to have such support would be the right
> move throughout the discussion. That is my summary.
CSH stands for "Clanton
vger.kernel.org; Linux Kernel
>>>> Mailing List <linux-kernel@vger.kernel.org>; Borislav Petkov
>>>> <b...@alien8.de>; Kweh, Hock Leong <hock.leong.k...@intel.com>; Bryan
>>>> O'Donoghue <pure.lo...@nexus-software.ie>
>>>> Subject: Re:
Fleming ; Ard Biesheuvel
>> ; linux-...@vger.kernel.org; Linux Kernel Mailing
>> List ; Borislav Petkov
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>>
>>
>> On 16/02/17 03:00, Kweh, Hock Leong wrote:
>>>
ail.com>
> Cc: Matt Fleming <m...@codeblueprint.co.uk>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>; linux-...@vger.kernel.org; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; Borislav Petkov <b...@alien8.de>
> Subject: Re: [PATCH 0/2] efi: Enhance capsule
ing
> List ; Borislav Petkov
> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
> images
>
>
>
> On 16/02/17 03:00, Kweh, Hock Leong wrote:
> >> -Original Message-
> >> From: Jan Kiszka [mailto:jan.kis...@siemens.com]
<ard.biesheu...@linaro.org>; linux-...@vger.kernel.org; Linux Kernel Mailing
List <linux-kernel@vger.kernel.org>; Borislav Petkov <b...@alien8.de>; Kweh,
Hock Leong <hock.leong.k...@intel.com>; Bryan O'Donoghue
<pure.lo...@nexus-software.ie>
Subject: Re: [PATCH 0/2] efi: Enhance cap
; Kweh,
Hock Leong ; Bryan O'Donoghue
Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
images
On 2017-02-15 19:50, Jan Kiszka wrote:
On 2017-02-15 19:46, Andy Shevchenko wrote:
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka
wrote:
See patch 2 for the background.
Series
..@codeblueprint.co.uk>; Ard Biesheuvel
>> <ard.biesheu...@linaro.org>; linux-...@vger.kernel.org; Linux Kernel Mailing
>> List <linux-kernel@vger.kernel.org>; Borislav Petkov <b...@alien8.de>; Kweh,
>> Hock Leong <hock.leong.k...@intel.com>; Bryan O'Donoghue
>&
el.org; Linux Kernel Mailing
>> List ; Borislav Petkov ; Kweh,
>> Hock Leong ; Bryan O'Donoghue
>>
>> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
>> images
>>
>> On 2017-02-15 19:50, Jan Kiszka wrote:
>>> On 2017-02-15 1
o.org>; linux-...@vger.kernel.org; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; Borislav Petkov <b...@alien8.de>; Kweh,
> Hock Leong <hock.leong.k...@intel.com>; Bryan O'Donoghue
> <pure.lo...@nexus-software.ie>
> Subject: Re: [PATCH 0/2] efi: Enhance
> Hock Leong ; Bryan O'Donoghue
>
> Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark
> images
>
> On 2017-02-15 19:50, Jan Kiszka wrote:
> > On 2017-02-15 19:46, Andy Shevchenko wrote:
> >> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka
> wrote:
On 2017-02-15 19:50, Jan Kiszka wrote:
> On 2017-02-15 19:46, Andy Shevchenko wrote:
>> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
>>> See patch 2 for the background.
>>>
>>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>>> a
On 2017-02-15 19:50, Jan Kiszka wrote:
> On 2017-02-15 19:46, Andy Shevchenko wrote:
>> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
>>> See patch 2 for the background.
>>>
>>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>>> a firmware.cap without security
On 2017-02-15 19:46, Andy Shevchenko wrote:
> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
>> See patch 2 for the background.
>>
>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>> a firmware.cap without security header and the SIMATIC
On 2017-02-15 19:46, Andy Shevchenko wrote:
> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
>> See patch 2 for the background.
>>
>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>> a firmware.cap without security header and the SIMATIC IOT2040 which
>> requires
On 2017-02-15 19:17, Ard Biesheuvel wrote:
> On 15 February 2017 at 18:14, Jan Kiszka wrote:
>> See patch 2 for the background.
>>
>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>> a firmware.cap without security header and the SIMATIC IOT2040
On 2017-02-15 19:17, Ard Biesheuvel wrote:
> On 15 February 2017 at 18:14, Jan Kiszka wrote:
>> See patch 2 for the background.
>>
>> Series has been tested on the Galileo Gen2, to exclude regressions, with
>> a firmware.cap without security header and the SIMATIC IOT2040 which
>> requires the
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its mandatory secure boot.
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its
On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its mandatory secure boot.
>
>
On 15 February 2017 at 18:14, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its
On 15 February 2017 at 18:14, Jan Kiszka wrote:
> See patch 2 for the background.
>
> Series has been tested on the Galileo Gen2, to exclude regressions, with
> a firmware.cap without security header and the SIMATIC IOT2040 which
> requires the header because of its mandatory secure boot.
>
66 matches
Mail list logo