On Tue, Feb 12, 2019 at 12:21 PM Andy Shevchenko
wrote:
>
> On Tue, Feb 12, 2019 at 12:15 PM Anders Roxell
> wrote:
> >
> > Commit a893ea15d764 ("tpm: move tpm_chip definition to
> > include/linux/tpm.h") introduced a build error when both ima and efi is
&
e 'NONE' constant, and it broke when they started getting included
> from the same file.
> We only need one of the two patches applied.
I would argue that we need two patches applied. Namespace is a hidden
issue in the code.
This patch looks good to me, FWIW,
Reviewed-by: Andy
subsystem prefix if it has a special meaning
> inside a subsystem.
I was about to say the same thing.
--
With Best Regards,
Andy Shevchenko
On Fri, Aug 31, 2018 at 08:41:28AM -0700, Andi Kleen wrote:
> Andy Shevchenko writes:
> > +
> > +#define INTEL_CPU_FAM_ANY_NODATA(_family, _model) \
> > + INTEL_CPU_FAM_ANY(_family, _model, NULL)
> > +
> > +#de
These macros are often used by drivers and we have already a lot of
duplication as ICPU() macro across the drivers.
Provide a generic x86 macro for users.
This adds no driver data variants.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-family.h | 10 --
1 file changed
Replace custom grown macro with generic INTEL_CPU_FAM6_NODATA() one.
No functional change intended.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/x86/utils.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86
Replace custom grown macro with generic INTEL_CPU_FAM6_NODATA() one.
No functional change intended.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_lpss.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index
Replace custom grown macro with generic INTEL_CPU_FAM_ANY() one.
No functional change intended.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-family.h | 2 ++
arch/x86/platform/efi/quirks.c | 6 +-
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86
On Mon, 2018-07-16 at 16:51 +0200, Ard Biesheuvel wrote:
> Thanks, I'll queue this in efi/next
Thanks!
Btw, you ACKed patch against efivars, who is supposed to apply it?
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-efi&qu
The commit
2f74f09bce4f ("efi: parse ARM processor error")
brought inconsistency in UUID types which are used across the CPER.
Fix this by moving to use guid_t API everywhere.
Cc: Tyler Baicar
Signed-off-by: Andy Shevchenko
---
drivers/firmware/efi/cper.c | 2 +-
1 file
uuid_le_to_bin() is deprecated API and take into consideration that variable,
to where we store parsed data, is type of guid_t we switch to guid_parse()
for sake of consistency.
While here, add error checking to it.
Signed-off-by: Andy Shevchenko
---
fs/efivarfs/inode.c | 4 +++-
1 file
standard and might lead to
unspecified behaviour.
More information is available in this [1] blog post.
[1]: https://davmac.wordpress.com/2010/02/26/c99-revisited/
Acked-by: Ard Biesheuvel
Signed-off-by: Andy Shevchenko
---
- change a wording for Apple case to explicitly tell
that properties
On Mon, May 14, 2018 at 11:44 PM, Rafael J. Wysocki wrote:
> On Mon, May 14, 2018 at 6:13 PM, Andy Shevchenko
> wrote:
>> On Mon, 2018-05-14 at 17:40 +0200, Lukas Wunner wrote:
>>> On Mon, May 14, 2018 at 03:48:09PM +0300, Andy Shevchenko wrote:
>>> Well if that is
On Mon, 2018-05-14 at 17:40 +0200, Lukas Wunner wrote:
> On Mon, May 14, 2018 at 03:48:09PM +0300, Andy Shevchenko wrote:
> > On Mon, 2018-05-14 at 14:18 +0200, Lukas Wunner wrote:
> > > On Tue, May 08, 2018 at 04:15:47PM +0300, Andy Shevchenko wrote:
> > > > --
On Mon, 2018-05-14 at 14:18 +0200, Lukas Wunner wrote:
> On Tue, May 08, 2018 at 04:15:47PM +0300, Andy Shevchenko wrote:
> > --- a/drivers/firmware/efi/apple-properties.c
> > +++ b/drivers/firmware/efi/apple-properties.c
> > @@ -13,6 +13,9 @@
> > *
> > * You s
able in this [1] blog post.
[1]: https://davmac.wordpress.com/2010/02/26/c99-revisited/
Signed-off-by: Andy Shevchenko
---
- extend commit message to explain what union aliasing is and why it's not good
drivers/base/property.c | 99 -
The commit
318a19718261 ("device property: refactor built-in properties support")
went way too far and brought a union aliasing. Partially revert it here
to get rid of union aliasing.
Note, Apple properties support is still utilizing this trick.
Signed-off-by: Andy Shevchenko
--
On Sun, Apr 8, 2018 at 8:40 PM, Hans de Goede wrote:
> Add touchscreen info for the Chuwi Vi8 Plus tablet. This tablet uses a
> Chipone ICN8505 touchscreen controller, with the firmware used by the
> touchscreen embedded in the EFI firmware.
>
Acked-by: Andy Shevchenko
> Signed-
thus a copy of the firmware, as part of their EFI code.
>
> This commit adds the necessary info for the new EFI embedded-firmware code
> to extract these firmwares, making the touchscreen work OOTB without the
> user needing to manually add the firmware.
>
Acked-by: Andy Shevchenko
ttern in kernel that we don't rename drivers; I guess
here we are on the safe side b/c this driver is used standalone
Taking above into attention, and assuming it will go via some other tree,
Acked-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> MAINTAINERS
hardware has a 32 bit
> UEFI,
> even though the processor is 64 bit capable (AFAIK 64 bit Windows drivers
> were
> not ready in time so all Bay Trail devices shipped with a 32 bit Windows).
Almost.
Lenovo Thinkpad 10 tablet has 64-bit firmware.
--
With Best Regards,
Andy Shevchenko
-
On Tue, 2018-02-27 at 17:31 +, Ard Biesheuvel wrote:
> On 27 February 2018 at 17:27, Andy Shevchenko
> wrote:
> > The memory we are accessing through virtual address has no IO side
> > effects. Moreover, for IO memory we have to use special accessors,
> > which we don&
On Wed, 2018-02-28 at 19:14 +0100, Lukas Wunner wrote:
> On Wed, Feb 28, 2018 at 07:25:59PM +0200, Andy Shevchenko wrote:
> > Instead of mapping to built-in device properties, implement a full
> > property provider.
> >
> > This is needed due to an architectural d
Instead of mapping to built-in device properties, implement a full
property provider.
This is needed due to an architectural differences between built-in
device property data structures and ones that are used on Apple
machines.
Signed-off-by: Andy Shevchenko
---
Hi, Lukas.
This is a skeleton
The memory we are accessing through virtual address has no IO side
effects. Moreover, for IO memory we have to use special accessors,
which we don't use.
Due to above, convert the driver to use memremap() instead of ioremap().
Signed-off-by: Andy Shevchenko
---
drivers/firmware/efi/
On Tue, 2018-02-27 at 12:55 +0200, Andy Shevchenko wrote:
> On Tue, 2018-02-27 at 06:20 +0100, Lukas Wunner wrote:
> In that case it can't use built-in device properties at all.
I think I know how to avoid this.
But it requires some time to implement.
--
Andy Shevchenko
Intel Finla
On Tue, 2018-02-27 at 06:20 +0100, Lukas Wunner wrote:
> On Mon, Feb 26, 2018 at 11:32:48PM +0200, Andy Shevchenko wrote:
> > There is as far as we know no type field in the struct dev_header
> > provided. Thus, assume that values of all properties are type of
> > u32.
>
There is as far as we know no type field in the struct dev_header
provided. Thus, assume that values of all properties are type of u32.
Deterministic type of property values is required to avoid union
aliasing in the code.
Signed-off-by: Andy Shevchenko
---
- the union aliasing fix for built
There is no need to artificially supply a property length and fake data
if property has type of boolean.
Remove redundant piece of data and code.
Signed-off-by: Andy Shevchenko
---
drivers/firmware/efi/apple-properties.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git
gt; +#define CPER_ARM_ERR_VALID_ADDRESS_SPACE 0x0200
> +#define CPER_ARM_ERR_VALID_MEM_ATTRIBUTES0x0400
> +#define CPER_ARM_ERR_VALID_ACCESS_MODE 0x0800
BIT() is already being used in this file.
> +
> +#define CPER_ARM_ERR_TRANSACTION_SHIFT 16
> +#define CPER
On Wed, 2017-08-30 at 14:38 +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> > Yep! There are so many conflicts that would be better just to push
> > through your tree.
> >
> > I have just sent a v2 of this patch sep
On Sun, 2017-07-30 at 10:37 -0700, Greg Kroah-Hartman wrote:
> On Sun, Jul 30, 2017 at 08:26:48PM +0300, Andy Shevchenko wrote:
> > On Sun, Jul 30, 2017 at 6:32 PM, Greg Kroah-Hartman
> > wrote:
> > > Doesn't apply to the staging tree at all :(
> >
> >
On Sun, Jul 30, 2017 at 6:32 PM, Greg Kroah-Hartman
wrote:
> On Wed, Jul 26, 2017 at 01:01:41PM +0300, Andy Shevchenko wrote:
>> On Wed, 2017-07-19 at 21:28 +0300, Andy Shevchenko wrote:
>> > There are new types and helpers that are supposed to be used in new
>> > code.
On Wed, 2017-07-26 at 02:27 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 03:35:01 AM Andy Shevchenko wrote:
> > On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki > t> wrote:
> > > Andy, do you want me to apply this?
> >
> > If you woul
On Wed, 2017-07-19 at 21:28 +0300, Andy Shevchenko wrote:
> There are new types and helpers that are supposed to be used in new
> code.
>
> As a preparation to get rid of legacy types and API functions do
> the conversion here.
>
> While here, re-indent couple of lines to
On Wed, Jul 26, 2017 at 3:21 AM, Rafael J. Wysocki wrote:
> On Tuesday, July 25, 2017 05:12:35 PM Mika Westerberg wrote:
>> On Wed, Jul 19, 2017 at 09:28:57PM +0300, Andy Shevchenko wrote:
>> > There are new types and helpers that are supposed to be used in new code.
>> &g
On Thu, 2017-07-20 at 13:18 +0100, Ard Biesheuvel wrote:
> On 19 July 2017 at 19:28, Andy Shevchenko
> wrote:
> > There are new types and helpers that are supposed to be used in new
> > code.
> >
> > As a preparation to get rid of legacy types and API functi
are kernel internal types mistakenly put to UAPI in the
first place.
Consistency here is how we treat those types in user space, starting
from v4.13 uuid_be gone from that header. uuid_le is luckily will be
gone soon.
> This file is also used by our kernel
> mode code.
It will work
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Cc: "Rafael J. Wysocki"
Cc: Mika Westerberg
Cc: linux-a...@vger.kernel.org
Signed-off-by: Andy Shevchenko
---
dr
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Cc: Tomas Winkler
Cc: Guenter Roeck
Cc: Samuel Ortiz
Signed-off-by: Andy Shevchenko
---
drivers/misc/mei/bus-fixup.c| 35
...@unisys.com
Cc: de...@driverdev.osuosl.org
Signed-off-by: Andy Shevchenko
---
drivers/staging/unisys/Documentation/overview.txt | 14 +++
drivers/staging/unisys/include/channel.h | 45 ++--
drivers/staging/unisys/include/iochannel.h | 14 +--
drivers/staging/unisys
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Cc: Matt Fleming
Cc: Ard Biesheuvel
Signed-off-by: Andy Shevchenko
---
drivers/firmware/efi/cper.c | 10 ++---
include/linux/cper.h
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: de...@linuxdriverproject.org
Signed-off-by: Andy
amuel Ortiz
Cc: Guenter Roeck
Cc: David Kershner
Cc: Greg Kroah-Hartman
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Andy Shevchenko (6):
efi: Switch to use new generic UUID API
mei: Switch to use new g
There is no more users for uapi/uuid.h. Remove it for good.
Anyone needs it in user space better to use libuuid.
Signed-off-by: Andy Shevchenko
---
include/linux/uuid.h | 20 +++-
include/uapi/linux/uuid.h | 42 --
scripts/mod
arlycon should work if you add proper parameters
to the command line (including port base address, no ttySx), though I
don't remember if it makes really "early".
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-
As of today linux-next when _kexec:ed_ works fine to me
Perhaps I can test this later with direct boot from SD card.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gt; from the crypto code.
>
> And whether the code generated by gcc would look much saner. Because
> the
> CPU can handle two qwords much better/faster than 16 u8s.
>
> Anyway, in case someone feels bored...
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2017-04-23 at 20:20 +, Winkler, Tomas wrote:
> On Sun, 2017-04-23 at 15:42 +0300, Andy Shevchenko wrote:
> > On Sun, Apr 23, 2017 at 1:29 PM, Winkler, Tomas > .
> > com> wrote:
> > > > New helpers take pointers to uuid_{be|le} as parameters.
> >
On Mon, 2017-04-24 at 10:21 +0530, Vinod Koul wrote:
> On Fri, Apr 21, 2017 at 05:46:39PM +0300, Andy Shevchenko wrote:
> > Recently introduced helpers take pointers to uuid_{be|le} instead of
> > reference.
>
> Are they in linus's tree, if not it introduces dependenc
he _pp types are just enough.
I looked at existing users and there are cases like
#define XXX_UUID UUID_...(a, b, c, ...)
uuid_.*_cmp(value, XXX_UUID)
For _pp variant if would be _cmp_pp(value, &XXX_UUID) which is
slightly worse than for _p variant.
--
With Best Regards,
Andy Shevchenko
--
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: Srinivas Pandruvada
Cc: Benjamin Tissoires
Signed-off-by: Andy Shevchenko
---
drivers/hid/intel-ish-hid/ishtp/bus.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: Tomas Winkler
Signed-off-by: Andy Shevchenko
---
drivers/misc/mei/bus-fixup.c | 2 +-
drivers/misc/mei/bus.c | 2 +-
drivers/misc/mei/client.c| 4 ++--
3 files
jamin Tissoires
Cc: Kirti Wankhede
Cc: Alex Williamson
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Tomas Winkler
Cc: Matt Fleming
Cc: Ard Biesheuvel
Cc: "Rafael J. Wysocki"
Signed-off-by: Andy Shevchenko
---
include/linux/uuid.h | 20 +++
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: Matt Fleming
Cc: Ard Biesheuvel
Signed-off-by: Andy Shevchenko
---
drivers/firmware/efi/cper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Signed-off-by: Andy Shevchenko
---
drivers/hv/channel_mgmt.c | 10 +-
drivers/hv/vmbus_drv.c
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Vinod Koul
Signed-off-by: Andy Shevchenko
---
sound/soc/intel/skylake/skl-pcm.c | 2 +-
sound/soc/intel/skylake/skl-sst-utils.c | 4
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: "Rafael J. Wysocki"
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_extlog.c | 2 +-
drivers/acpi/apei/ghes.c | 8
2 files changed, 5 insertions(+), 5
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.
Using them makes code less ugly.
Cc: Kirti Wankhede
Cc: Alex Williamson
Signed-off-by: Andy Shevchenko
---
drivers/vfio/mdev/mdev_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
t; efi_capsule_identify_image is only effective on Quark processors.
>
FWIW:
Reviewed-by: Andy Shevchenko
> Signed-off-by: Jan Kiszka
> ---
> arch/x86/platform/efi/quirks.c | 137
> +
> drivers/firmware/efi/Kconfig | 9 +++
> 2
uark_setup_quirk(...)
{
}
struct _info efi_capsule_quark_info = {
.setup = ..._setup_quirk,
};
#define ICPU(family, model, ddata) ...
static const struct x86_cpu_id quark_ids[] = {
ICPU(5, 9, efi_capsule_quark_info),
{}
};
Though didn't hear back on it.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 10, 2017 at 4:16 PM, David Howells wrote:
> Andy Shevchenko wrote:
>
>> >> It looks a bit fragile when responsility of whatever reasons kernel
>> >> can't serve become a driver burden.
>> >> Can we fix this in debugfs framework instea
On Fri, Apr 7, 2017 at 3:50 PM, David Howells wrote:
> Andy Shevchenko wrote:
>
>> > From: Matthew Garrett
>> >
>> > We have no way of validating what all of the Asus WMI methods do on a given
>> > machine - and there's a risk that some will allow
1, asus->debug.method_id,
> &input, &output);
>
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
f its mandatory secure boot.
The series looks good to me from code prospective. It's clean and
understandable, though I have couple of comments (see related
patches).
Please, address them.
I wasn't able to test it, thus FWIW:
Reviewed-by: Andy Shevchenko
>
> Jan
>
> Jan Kiszk
r_debug("Quark security header detected\n");
> +
> + if (csh->rsvd_next_header != 0) {
> + pr_err("multiple Quark security headers not supported\n");
> + return -EINVAL;
> + }
> +
> + cap_info->total_size =
sglist[j].length = sz;
>
> imagesize -= sz;
> count--;
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 94d34e0..d83095c6 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
>
ral shape of the code), and the
> > original
> > ccp-platform.c is no longer built.
> >
> > Shouldn't ccp-platform.c be deleted by this patch?
> >
>
> Good catch. Both ccp-platform.c and ccp-pci.c should have been
> deleted
> by this patch.
ytes >> 40);
>> + else if (bytes & 0xfff)
>> + snprintf(buf, size, "%llu PiB", bytes >> 50);
>> + else
>> + snprintf(buf, size, "%llu EiB", bytes >> 60);
>> + return buf;
For me it looks li
On Wed, Jan 7, 2015 at 4:08 AM, Andy Shevchenko
wrote:
> We have to check the pointer before dereferencing it. The patch fixes
> such issues in the efivars module.
Discard this, sorry for noise.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/firmware/
We have to check the pointer before dereferencing it. The patch fixes
such issues in the efivars module.
Signed-off-by: Andy Shevchenko
---
drivers/firmware/efi/efivars.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/efi/efivars.c
71 matches
Mail list logo
