Signed-off-by: Jeremy Kerr
---
tools/testing/selftests/efivarfs/efivarfs.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/testing/selftests/efivarfs/efivarfs.sh
b/tools/testing/selftests/efivarfs/efivarfs.sh
index e8c0d27..3af4b37 100755
--- a/tools/testing
This change adds a few initial efivarfs tests to the
tools/testing/selftests directory.
The open-unlink test is based on code from
Lingzhu Xiang .
Signed-off-by: Jeremy Kerr
---
tools/testing/selftests/Makefile |2
tools/testing/selftests/efivarfs/Makefile | 12
ntics
covered by these.
Cheers,
Jeremy
--
v2: Remove qemu check, add a couple of tests
v3: Change expected empty read() behaviour to return EOF
---
Jeremy Kerr (3):
selftests: Add tests for efivarfs
selftests/efivarfs: Add empty file creation test
selftests/efivarfs: Add create
Test that reads from a newly-created efivarfs file (with no data
written) will return EOF.
Signed-off-by: Jeremy Kerr
---
tools/testing/selftests/efivarfs/Makefile |2
tools/testing/selftests/efivarfs/create-read.c | 38 +
tools/testing/selftests/efivarfs
Hi Andrew,
Thanks for taking a look at these.
@@ -1,4 +1,4 @@
-TARGETS = breakpoints kcmp mqueue vm cpu-hotplug memory-hotplug
+TARGETS = breakpoints kcmp mqueue vm cpu-hotplug memory-hotplug efivarfs
bah. This sort of Makefile construct is a wonderful source of patch
rejects and fixups. I'
your feature is unconfigured.
This change adds a little documentation to the tests under
tools/testing/selftests/, based on akpm's explanation.
Signed-off-by: Jeremy Kerr
---
Documentation/selftests.txt | 43
1 file changed, 43 insertions
Hi hpa,
Thanks for the review!
However, I have a question... rather than putting the attributes as the
first data bytes, would it be better to make it either part of the
filename (assuming there is at least one character other than / which
can be reasonably relied upon to not be part of the nam
hi hpa,
> Wouldn't that be better handled by O_APPEND?
Possibly, but this then means that there are now two "interfaces" that
specify the variable attributes.
[Also, in that case we should support the same mechanism through open();
llseek(0, SEEK_END) then, right?]
In general, I think the attri
Hi hpa,
> Well, appending is an action, not really a property of the variable
> that sticks around, no?
True, but they're still all defined as the same thing in the UEFI spec.
If you're looking to define which attributes to pass, you now need to
know the extra information that you pass most of th
Hi Matt,
Jeremy, did you want to pick this up as part of your series?
I have this in my series, yes. I'm just working on the authenticated
delete code, then will send out the next revision.
Speaking of which - Peter: I've realised that doing a GetVariable()
after the SetVariable is a much
From: Lee, Chun-Yi
UEFI variable filesystem need a new mount point, so this patch add
efivars kobject to efi_kobj for create a /sys/firmware/efi/efivars
folder.
Cc: Matt Fleming
Cc: Jeremy Kerr
Cc: Matthew Garrett
Cc: H. Peter Anvin
Signed-off-by: Lee, Chun-Yi
Signed-off-by: Jeremy Kerr
e for this. So,
instead, let's add a filesystem. Variables can be read, written and
created, with the first 4 bytes of each variable representing its UEFI
attributes. The create() method doesn't actually commit to flash since
zero-length variables can't exist per-spec.
Updates from J
ith a zero datasize).
This change re-reads the updated variable from firmware, to check for
size changes and deletions. In the latter case, we need to drop the
dentry.
Signed-off-by: Jeremy Kerr
---
drivers/firmware/efivars.c | 49 +
1 file changed, 39 inserti
Hi Joey,
Since more people prefer to use "efivarfs", so, I modified the patch for
replace "efivars" to "efivarfs" like following:
I'd intentionally left this patch as-is. I think that the filesystem
should be called "efivarfs", while the directory should be called
"efivars". Same style as sy
e for this. So,
instead, let's add a filesystem. Variables can be read, written and
created, with the first 4 bytes of each variable representing its UEFI
attributes. The create() method doesn't actually commit to flash since
zero-length variables can't exist per-spec.
Updates from J
Hi Matt,
Am I correct in thinking that this filesystem doesn't handle deletion of
authenticated variables?
Unless I'm missing something, this should work fine; we just pass the
EFI_VARIABLE_AUTHENTICATION_2 descriptor (with the usual attribute
header), but no data following the descriptor.
Hi Matt,
I think this is the problematic chunk of code,
static int efivars_unlink(struct inode *dir, struct dentry *dentry)
{
struct efivar_entry *var = dentry->d_inode->i_private;
struct efivars *efivars = var->efivars;
efi_status_t status;
spin_lock(&efiva
Hi Linus,
> Is Jeremy the patchwork maintainer?
Yep, that's me.
> and it turns out that apparently 'patchwork' is just making up random
> times, because when you download the email as an mbox, it will turn
> this into that corrupt and incorrect
>
> Date: Thu, 06 Jun 2013 19:42:54 -
>
>
Hi Linus,
> No. The date from the email was
>
> Date: Fri, 7 Jun 2013 15:42:54 +1000
>
> and we want *that* date.
Ah, gotchya.
So, we now use the original date header (if present) in the mbox views:
$ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
Date: Fri, 7 Jun
nd mounts as expected.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi all,
>>> This patch looks like it should be in the 3.8-stable tree, should we apply
>>> it?
>>
>> I queue up networking patches as needed and that queue is
>> visible at:
>>
>> http://patchwork.ozlabs.org/user/bundle/2566/?state=*
>
> Actually, this bundle is not visible via that link. It app
rfs paths.
Signed-off-by: Jeremy Kerr
---
drivers/firmware/efivars.c | 68 +++--
1 file changed, 43 insertions(+), 25 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 5765664..a86eb55 100644
--- a/drivers/firmware/efivar
Hi Andy,
> Signed-off-by: Andy Whitcroft
> ---
> drivers/firmware/efivars.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Looks good to me.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux
Hi Andy,
d_alloc_name() copies the passed name to new storage, once complete we
no longer need our name.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Hi Andy,
@@ -969,16 +970,18 @@
return -ENOMEM;
list_for_each_entry_safe(entry, n, &efivars->list, list) {
- struct inode *inode;
struct dentry *dentry, *root = efivarfs_sb->s_root;
- char *name;
unsigned long si
Hi Andy,
When d_make_root() fails it will automatically drop the reference
on the root inode. We should not be doing so as well.
Looks good:
Acked-by: Jeremy Kerr
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi Andy,
Looks good. Thanks for taking the time to review the efivarfs changes.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Hi Greg,
Should this be backported to the stable kernels?
No, the efivarfs code that this touches was only recently committed; it
won't be in any of the stable series.
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to major
er_block *sb)
{
kill_litter_super(sb);
efivarfs_sb = NULL;
}
Which I believe will clean them up.
Awesome, thanks for that. Looks good to me.
Acked-by: Jeremy Kerr
Cheers,
Jeremy Kerr
--
To unsubscribe from this list: send the line "unsubscribe linux-efi&
Hi Andrew,
> Perhaps export it from within a powerpc-specific C file (along with
> suitable comment) to prevent people from generally relying upon the
> export?
Even better, I'll export it from a Cell-specific C file. I'll follow
this up in my own spufs series for .25.
Cheers,
Jeremy
-
To
This change allows force_sig_info to be called from modules.
Signed-off-by: Jeremy Kerr <[EMAIL PROTECTED]>
--
Any objections to exporting this symbol? I'm planning to move some
SPU fault-handling code from the kernel to the spufs.ko object.
---
kernel/signal.c |1 +
1 file
> Mismerge in
> commit 8b6f50ef1d5cc86b278eb42bc91630fad455fb10
> Author: Jeremy Kerr <[EMAIL PROTECTED]>
> Date: Sat Jul 21 04:37:51 2007 -0700
> spufs: make signal-notification files readonly for NOSCHED
> contexts
>
> structs got duplicated.
>
Hi Thiago,
> So even if not ideal, the solution above is desirable for powerpc. We would
> like to preserve the ability of allowing userspace to pass parameters to the
> OS via the DTB, even if secure boot is enabled.
>
> I would like to turn the above into a proposal:
>
> Extend the syscall a
We'll want non-core fsi code to trigger a rescan, so introduce a
non-static fsi_master_rescan() function. Use this for the existing
unscan/scan behaviour too.
Signed-off-by: Jeremy Kerr
Reviewed-by: Joel Stanley
Reviewed-by: Christopher Bostic
---
v2:
- Add EXPORT_SYMBO
Hi Arnd,
> gcc warns about the return type of this function:
>
> drivers/fsi/fsi-core.c:535:8: error: type qualifiers ignored on function
> return type [-Werror=ignored-qualifiers]
>
> This removes the 'const' attribute, as suggested by the warning.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
Hi Joel,
>> +static ssize_t external_mode_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct fsi_master_gpio *master = dev_get_drvdata(dev);
>> +
>> + return snprintf(buf, PAGE_SIZE - 1, "%u",
>
> I gave this a spin on a machine tod
states for the trans, mux and enable
gpios, and prevent access to clk & data from the FSI core code (by
returning EBUSY).
External mode is controlled by a sysfs attribute, so add the relevent
information to Documentation/ABI/
Signed-off-by: Jeremy Kerr
Reviewed-by: Joel Stanley
---
.../ABI
c64 and printing a 64-bit number for
> consistency.
If we still have spufs in the tree in 2038 I'd be worried :) But good
to keep things consistent.
Acked-by: Jeremy Kerr
Michael: want to take this directly through your tree?
Cheers,
Jeremy
Hi Tal,
Thanks for the contribution! Some comments:
> mctp-i2c rx implementation doesn't call
> __i2c_transfer which calls the i2c reply trace function.
No, but we can trace the i2c rx path through the trace_i2c_slave
tracepoint. It is a little messier than tracing trace_i2c_write, but
has been
Hi Tal,
> > > mctp-i2c rx implementation doesn't call
> > > __i2c_transfer which calls the i2c reply trace function.
> >
> > No, but we can trace the i2c rx path through the trace_i2c_slave
> > tracepoint. It is a little messier than tracing trace_i2c_write,
> > but
> > has been sufficient with t
Hi Michael,
This series looks good to me, thanks for the fixes. I'll do some testing
tomorrow but it looks like it'll be fine as-is.
Andrew - almost all of these are for spufs, the notable exception being:
[PATCH 12/15] Cleanup ELF coredump extra notes logic
which touches the generic elf/core
Hi Stan,
> The new kernel compiled and booted with no errors, with these
> STACKPROTECTOR options in .config (the last two revealed the bug):
>
> CONFIG_HAVE_STACKPROTECTOR=y
> CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
> CONFIG_STACKPROTECTOR=y
> CONFIG_STACKPROTECTOR_STRONG=y
Brilliant, thanks for te
posed fix from Finn Thain .
Signed-off-by: Jeremy Kerr
Reported-by: Stan Johnson
Tested-by: Stan Johnson
Reported-by: Finn Thain
---
drivers/net/ethernet/apple/bmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/apple/bmac.c
b/drivers/net/ether
ead of our own.
Signed-off-by: Jeremy Kerr
---
Ingo: 6b6350f1 is currently in tip; this fixes a build breakage for spufs
---
arch/powerpc/platforms/cell/spufs/sched.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/cell/spufs/sched.c
b/arch/powerpc/platforms/
.
Makes sense.
Acked-by: Jeremy Kerr
> @@ -58,12 +56,12 @@ int spu_handle_mm_fault(struct mm_struct *mm, unsigned
> long ea,
> goto out_unlock;
> }
>
> - is_write = dsisr & MFC_DSISR_ACCESS_PUT;
> + is_write = dsisr & DSISR_ISST
Hi Mikey & Ian,
> __spu_trap_data_seg() currently contains code to determine the VSID and ESID
> required for a particular EA and mm struct.
>
> This code is generically useful for other co-processors. This moves the code
> of the cell platform so it can be used by other powerpc code.
OK, nice.
7;re seeing with the ast driver on OpenPOWER
machines, thanks!
Acked-by: Jeremy Kerr
Cheers,
Jeremy
driver, which is a significantly better
result.
Tested-by: Jeremy Kerr
[now to sort out the issue in the ast driver...]
Cheers,
Jeremy
Hi Ming,
> Not sure this one is needed for stable because it justs dumps
> a warning, and not set a valid period to ops->cur_blink_jiffies.
>
> So I guess other fix patch is still required for the soft lockup
> issue, right?
The main thing is that we don't set cur_blink_jiffies to the < 50ms
val
Hi Ming,
>Then looks there are two fix patches acked & tested:
>
> - the patch in this thread
> - another one "[PATCH] tty: vt: Fix soft lockup in fbcon cursor
>blink timer."
> https://lkml.org/lkml/2016/5/17/455
>
>So which one will be pushed to linus?
Not that it's my call, but we may want both
Hi Rob,
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index 20da3ad..8c7b607 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -493,6 +493,15 @@ static int device_add_attrs(struct device *dev)
>> goto err_remove_dev_groups;
>> }
>
Hi Rob,
> struct device doesn't have an of_node member if !CONFIG_OF, so we'll
> need to disable this block in the preprocessor.
Scratch that, I was looking at the wrong header - we do indeed have the
of_node available independently of CONFIG_OF, and this makes the logic a
little cleaner.
Cheers
Currently, we may perform a copy_to_user (through
simple_read_from_buffer()) while holding a context's register_lock,
while accessing the context save area.
This change uses a temporary buffers for the context save area data,
which we then pass to simple_read_from_buffer.
Signed-off-by: J
Hi Christoph,
> FYI, these little hunks reduce the difference to my version, maybe
> you can fold them in?
Sure, no problem.
How do you want to coordinate these? I can submit mine through mpe, but
that may make it tricky to synchronise with your changes. Or, you can
include this change in your s
Hi Christoph,
> And another one that should go on top of this one to address Al's other
> compaint:
Yeah, I was pondering that one. The access_ok() is kinda redundant, but
it does avoid forcing a SPU context save on those errors.
However, it's not like we really need to optimise for the case of
Hi Joel,
> The subsystem was merged some time ago but we did not have a
> maintainers
> entry.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
Hi Mark & Chris,
> On Tue, Dec 06, 2016 at 06:14:26PM -0600, Chris Bostic wrote:
>> From: Jeremy Kerr
>>
>> For debugging, add a fake master driver, that only supports reads,
>> returning a fixed set of data.
>
>> +config FSI_MASTER_FAKE
>> +tri
Hi Greg,
> Why not just create lib/crc4.c with these functions, like the other crc
> functions in the kernel?
Two (bad) reasons:
- The crc4 implementation here is pretty specific to the FSI
usage (only supporting 4-bit-sized chunks), to keep the math & lookup
table simple
- I'm lazy
So
Hi Chris,
>From this:
>> +
>> +The standard FSI master node
>> +
>> +This node describes a FSI master implmemented fully in hardware
>> +with dedicated input/output pins required for its function (i.e.
>> +not using generic GPIO pins).
>> +Required property:
>> +co
Hi Chris,
> +static ssize_t store_scan(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct fsi_master_gpio *master = dev_get_drvdata(dev);
> +
> + f
Hi Geert,
>> --- /dev/null
>> +++ b/drivers/fsi/Kconfig
>> @@ -0,0 +1,12 @@
>> +#
>> +# FSI subsystem
>> +#
>> +
>> +menu "FSI support"
>> +
>> +config FSI
>> + tristate "FSI support"
>
> I guess this should depend on some POWER symbol || COMPILE_TEST?
No, this is pretty hardware-independe
), so this is purely a readability fix.
Signed-off-by: Jeremy Kerr
---
kernel/irq/spurious.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c
index 5707f97..061ba7e 100644
--- a/kernel/irq/spurious.c
+++ b/kernel/irq/spurious.c
1fc76bc72 ("arm: dts: aspeed: Add vuart
> aspeed,sirq-polarity-sense...")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Joel Stanley
LGTM. I've tested this on the s2600st, which is strapped for eSPI. All
good there too, as expected.
Tested-by: Jeremy Kerr
and/or:
Reviewed-by: Jeremy Kerr
Cheers,
Jeremy
;
> Reported-by: kernel test robot
> Signed-off-by: Arnd Bergmann
Looks good to me, thanks.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
le.
Reviewed-by: Jeremy Kerr
Cheers,
Jeremy
; we're
reading two bytes at a time there.
Can you try the attached patch?
Ben/Paul - any thoughts?
Cheers,
Jeremy
-
>From 141b20bcbdb3ad7c166b83b4ea61f3521d0a0679 Mon Sep 17 00:00:00 2001
From: Jeremy Kerr
Date: Mon, 18 May 2020 08:54:25 +0800
Subject: [PATCH] net: bmac: Fix r
Hi Eddie,
> +Required properties:
> + - compatible = "ibm,i2cm-fsi";
> + - reg = < address size >; : The FSI CFAM address and address space
> + size.
> + - #address-cells = <1>; : Number of address cells in child nodes
> + - #size-cells =
Hi Eddie,
>> Those child nodes represent the downstream i2c buses, and so also
>> contain the i2c slave devices, right? If so, you may want to document
>> that, and/or add a simple device to that example (say, an EEPROM).
>
> Yes, good point, but the driver currently wouldn't do anything with tha
Hi Thierry,
> I /think/ Jeremy Kerr (To'ed) would be a good person to contact about
> this.
>
> Jeremy, anything you can do about this?
OK, all sorted. I've updated Jerome's entry in the database to suit.
Cheers,
Jeremy
Hi Joel,
> This fix registers the bus with postcore_initcall instead, to ensure
> it is registered earlier on.
Looks good to me.
Acked-by: Jeremy Kerr
Cheers,
Jeremy
es change, we should see an
separate AEN for that event.
Acked-by: Jeremy Kerr
However: we're looking at some behaviour of Broadcom NICs at the moment,
where the phy will be reset on link change events. We'd want to make
sure that we're not just seeing the HNCDSC events for tha
Hi Brendan,
> The driver was handling interaction with userspace on its own. This
> patch changes it to use the functionality of the ipmi_bmc framework
> instead.
>
> Note that this removes the ability for the BMC to set SMS_ATN by making
> an ioctl. If this functionality is required, it can be a
Hi Chris,
> I don't think we'd want this per master. The lock is for the 'top'
> master issuing commands. Only the top master can initiate any
> transactions on the bus to any devices connected downstream. Downstream
> masters such as hub masters, etc... cannot initiate a command.
I think what
Hi Steven,
Thanks for checking this out.
>> +TRACE_EVENT(fsi_master_write,
>> +TP_PROTO(const struct fsi_master *master, int link, int id,
>> +uint32_t addr, size_t size, const void *data),
>> +TP_ARGS(master, link, id, addr, size, data),
>> +TP_STRUCT__entry(
>> +
Since we're only
inserting one character, it's fine for the flag to be "fixed".
Signed-off-by: Jeremy Kerr
CC: Peter Hurley
---
RFC: I'm certainly no expert on the tty layer, and perhaps there's a
good reason to always allocate a flags buffer. However, this seems to
Currently, we perform GPIO accesses in fsi_master_gpio_break and
fsi_master_link_enable, without holding cmd_lock. This change adds the
appropriate locking.
Signed-off-by: Jeremy Kerr
Reviewed-by: Joel Stanley
Reviewed-by: Christopher Bostic
---
drivers/fsi/fsi-master-gpio.c | 7 +++
1
states for the trans, mux and enable
gpios, and prevent access to clk & data from the FSI core code (by
returning EBUSY).
External mode is controlled by a sysfs attribute, so add the relevent
information to Documentation/ABI/
Signed-off-by: Jeremy Kerr
Reviewed-by: Joel Stanley
---
.../ABI
sm for the kernel to retain exclusive access to those GPIOs.
Cheers,
Jeremy
---
Jeremy Kerr (3):
fsi: Add fsi_master_rescan()
fsi/master-gpio: Add locking around gpio operations during break &
link enable
fsi/master-gpio: Add external mode
.../ABI/testing/sysfs-driver-fsi-master-g
We'll want non-core fsi code to trigger a rescan, so introduce a
non-static fsi_master_rescan() function. Use this for the existing
unscan/scan behaviour too.
Signed-off-by: Jeremy Kerr
Reviewed-by: Joel Stanley
Reviewed-by: Christopher Bostic
---
drivers/fsi/fsi-core.c
Hi Vincent,
> No need to get into the submenu to disable all FSI-related config entries
Sounds reasonable to me.
Acked-by: Jeremy Kerr
Greg: do you want Joel (or me) to manage FSI patches, or would you
prefer to take this directly?
Cheers,
Jeremy
Commit-ID: 74b8af7837fa55c020e2ad1b34a6b10dfe25a9b1
Gitweb: http://git.kernel.org/tip/74b8af7837fa55c020e2ad1b34a6b10dfe25a9b1
Author: Jeremy Kerr
AuthorDate: Tue, 11 Feb 2014 14:05:17 +0800
Committer: Ingo Molnar
CommitDate: Tue, 11 Feb 2014 09:58:33 +0100
powerpc/spufs: Remove
Commit-ID: 5d4bac9a5f4ef24b2482529bda6661a58e5b5b65
Gitweb: http://git.kernel.org/tip/5d4bac9a5f4ef24b2482529bda6661a58e5b5b65
Author: Jeremy Kerr
AuthorDate: Thu, 16 Feb 2017 12:24:09 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 16 Feb 2017 15:32:19 +0100
genirq: Clarify logic
82 matches
Mail list logo
