-reg_temp_over[r2]);
+ swap(data-reg_temp_hyst[r1], data-reg_temp_hyst[r2]);
+ swap(data-reg_temp_config[r1], data-reg_temp_config[r2]);
}
static void
Looks good. Applied, thanks.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
with them as aligned.
As the driver maintainer, I am fine with both unaligned or tab-aligned.
Space-aligned as I did originally was not a good idea, I admit.
--
Jean Delvare
SUSE L3 Support
--
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/
r = {
> .name = "panel",
> - .attach = panel_attach,
> + .match_port = panel_attach,
> .detach = panel_detach,
> + .probe = panel_probe,
> };
>
> /* init function */
--
Jean Delvare
SUSE L3 Support
--
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/
cd1.1,
pcd2.2 etc?
> parport_put_port(port);
> + kfree(par_cb);
If you don't need par_cb anywhere else then you shouldn't be allocating
it dynamically. It's small enough to fit on the stack really.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "un
aybe you can check of the
presence of either to decide that this is a device model driver.
> +
> static struct parport_driver i2c_parport_driver = {
> .name = "i2c-parport",
> - .attach = i2c_parport_attach,
> + .match_port = i2c_parport_attach,
> .detach = i2c
e const.
Also I don't much like the name "cnt", as the value is not a count,
it's an index or identifier. What about "id"?
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
,
+ .probe = i2c_parport_probe,
};
/* - Module loading, unloading and information
*/
Tested OK on my ADM1032 evaluation board.
Tested-by: Jean Delvare jdelv...@suse.de
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line
void panel_detach(struct parport *port)
static struct parport_driver panel_driver = {
.name = panel,
- .attach = panel_attach,
+ .match_port = panel_attach,
.detach = panel_detach,
+ .probe = panel_probe,
};
/* init function */
--
Jean Delvare
SUSE L3 Support
don't much like the name cnt, as the value is not a count,
it's an index or identifier. What about id?
--
Jean Delvare
SUSE L3 Support
--
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
it dynamically. It's small enough to fit on the stack really.
--
Jean Delvare
SUSE L3 Support
--
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
in the future and still readable IMO.
It was having space originally. I changed that into tab as it was
looking good with them as aligned.
As the driver maintainer, I am fine with both unaligned or tab-aligned.
Space-aligned as I did originally was not a good idea, I admit.
--
Jean Delvare
ctronics, so had a small count
of users, and the driver would always be loaded last anyway, so it was
not a problem in practice. Still I agree with the change as it makes
things cleaner and more flexible.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "un
Le Tuesday 19 May 2015 à 14:14 +0530, Sudip Mukherjee a écrit :
> On Tue, May 19, 2015 at 09:50:47AM +0200, Jean Delvare wrote:
> > Hi Sudip,
> >
> > Le Wednesday 06 May 2015 à 15:46 +0530, Sudip Mukherjee a écrit :
> > > as of now i2c-parport was connecting
specified.
> + return;
> + }
>
> adapter = kzalloc(sizeof(struct i2c_par), GFP_KERNEL);
> if (adapter == NULL) {
> @@ -298,5 +313,11 @@ MODULE_AUTHOR("Jean Delvare ");
> MODULE_DESCRIPTION("I2C bus over parallel port");
>
@@ MODULE_AUTHOR(Jean Delvare jdelv...@suse.de);
MODULE_DESCRIPTION(I2C bus over parallel port);
MODULE_LICENSE(GPL);
+module_param_array(parport, int, NULL, 0);
+MODULE_PARM_DESC(parport, Atmost 4 instances are allowed.\n
You should first say what the parameter does, before going
Le Tuesday 19 May 2015 à 14:14 +0530, Sudip Mukherjee a écrit :
On Tue, May 19, 2015 at 09:50:47AM +0200, Jean Delvare wrote:
Hi Sudip,
Le Wednesday 06 May 2015 à 15:46 +0530, Sudip Mukherjee a écrit :
as of now i2c-parport was connecting to all the available parallel
ports. Lets
, and the driver would always be loaded last anyway, so it was
not a problem in practice. Still I agree with the change as it makes
things cleaner and more flexible.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Hi Linus,
Please pull dmi subsystem fixes for Linux 4.1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git dmi-for-linus
drivers/firmware/dmi_scan.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
---
Jean Delvare (2):
firmware
Hi Linus,
Please pull dmi subsystem fixes for Linux 4.1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git dmi-for-linus
drivers/firmware/dmi_scan.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
---
Jean Delvare (2):
firmware
even though it's also a letter, as it's
really an address modifier, which affects neither the direction nor the
length. But again it's really only a suggestion, if you can come up
with something clearer and/or easier to implement, please do.
> So much for the quick response, I'll have a closer look late
plement
the feature, as Wolfram did.
--
Jean Delvare
SUSE L3 Support
--
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/
On Thu, 7 May 2015 22:08:12 +0200, Jean Delvare wrote:
> Hi Wolfram,
>
> On Fri, 27 Feb 2015 17:16:56 +0100, Wolfram Sang wrote:
> > This tool allows to construct and concat multiple I2C messages into one
> > single transfer. Its aim is to test I2C master controllers, and so
On Thu, 7 May 2015 22:08:12 +0200, Jean Delvare wrote:
Hi Wolfram,
On Fri, 27 Feb 2015 17:16:56 +0100, Wolfram Sang wrote:
This tool allows to construct and concat multiple I2C messages into one
single transfer. Its aim is to test I2C master controllers, and so there
is no SMBus fallback
, if you can come up
with something clearer and/or easier to implement, please do.
So much for the quick response, I'll have a closer look later.
I wouldn't call it quick ;-) but you're welcome.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
.
--
Jean Delvare
SUSE L3 Support
--
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/
is inconsistent to not free yours. Freeing the memory
explicitly makes the code easier to read and debug as it documents the
lifetime of allocated buffers (for both humans and tools like
valgrind.) So please free your memory buffers explicitly.
> + exit(0);
> +}
--
Jean Delvare
SUSE L3 Support
--
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/
it is inconsistent to not free yours. Freeing the memory
explicitly makes the code easier to read and debug as it documents the
lifetime of allocated buffers (for both humans and tools like
valgrind.) So please free your memory buffers explicitly.
+ exit(0);
+}
--
Jean Delvare
SUSE L3 Support
arport0" where 0 is the
instance number of the i2c-parport device - it may be connected to
parport0 but it's only by chance and it may well be connected to another
parallel port.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
On Mon, 4 May 2015 11:10:12 +0530, Sudip Mukherjee wrote:
> On Sun, May 03, 2015 at 03:33:40PM +0200, Jean Delvare wrote:
> > On Tue, 28 Apr 2015 17:00:21 +0530, Sudip Mukherjee wrote:
> > > + adapter->pdev = parport_register
On Mon, 4 May 2015 11:10:12 +0530, Sudip Mukherjee wrote:
On Sun, May 03, 2015 at 03:33:40PM +0200, Jean Delvare wrote:
On Tue, 28 Apr 2015 17:00:21 +0530, Sudip Mukherjee wrote:
+ adapter-pdev = parport_register_dev_model(port, name
be connected to another
parallel port.
--
Jean Delvare
SUSE L3 Support
--
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
+
> 2 files changed, 74 insertions(+), 28 deletions(-)
> (...)
Functional testing with a single device (ADM1032 eval board) went fine.
I didn't test interrupts but as you didn't touch that part of the code
I don't expect any specific problem.
--
Jean Delvare
SUSE L3 Support
--
To unsubs
" 7 = One For All JP1 parallel port adapter\n"
> );
> +
> +static int parport[4] = {0, -1, -1, -1};
> +module_param_array(parport, int, NULL, 0);
> +MODULE_PARM_DESC(parport, "Atmost 4 instances are allowed.\n"
> + "Mention portnumbers
Hi Sudip,
On Sun, 3 May 2015 12:07:33 +0530, Sudip Mukherjee wrote:
> On Sat, May 02, 2015 at 04:20:53PM +0200, Jean Delvare wrote:
> > On Tue, 28 Apr 2015 17:00:20 +0530, Sudip Mukherjee wrote:
> > > another WIP for your review. since this is not a formal patch for
> &g
Hi Sudip,
On Sun, 3 May 2015 12:07:33 +0530, Sudip Mukherjee wrote:
On Sat, May 02, 2015 at 04:20:53PM +0200, Jean Delvare wrote:
On Tue, 28 Apr 2015 17:00:20 +0530, Sudip Mukherjee wrote:
another WIP for your review. since this is not a formal patch for
applying so writing the comments
(+), 28 deletions(-)
(...)
Functional testing with a single device (ADM1032 eval board) went fine.
I didn't test interrupts but as you didn't touch that part of the code
I don't expect any specific problem.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe
and i2c-parport-light drivers, and this
parameter is irrelevant for the latter.
Ideally the support for multiple instances and the conversion to the
new parport device model should also be added in separate patches.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line
vers/parport/share.c | 266
> ---
> include/linux/parport.h | 41 ++-
> 4 files changed, 308 insertions(+), 18 deletions(-)
> (...)
Patch tested, no functional regression found.
Tested-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
, 308 insertions(+), 18 deletions(-)
(...)
Patch tested, no functional regression found.
Tested-by: Jean Delvare jdelv...@suse.de
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
I have nothing to do with this, please drop me from Cc.
Thanks,
Jean
On Thu, 30 Apr 2015 15:36:47 -0700, Tadeusz Struk wrote:
> This patch set introduces a Public Key Encryption API.
> What is proposed is a new crypto type called crypto_pke_type
> plus new struct pke_alg and struct pke_tfm
I have nothing to do with this, please drop me from Cc.
Thanks,
Jean
On Thu, 30 Apr 2015 15:36:47 -0700, Tadeusz Struk wrote:
This patch set introduces a Public Key Encryption API.
What is proposed is a new crypto type called crypto_pke_type
plus new struct pke_alg and struct pke_tfm together
points, as they do not specify a structure count.
Fixes: fc43026278 ("dmi: add support for SMBIOS 3.0 64-bit entry point")
Signed-off-by: Jean Delvare
Cc: Leif Lindholm
Cc: Matt Fleming
Cc: Ard Biesheuvel
---
Changes since v1:
* Added comments to explain the logic of the code.
Hi Ard,
Le Thursday 30 April 2015 à 12:37 +0200, Ard Biesheuvel a écrit :
> On 28 April 2015 at 20:41, Jean Delvare wrote:
> > From: Jean Delvare
> > Subject: firmware: dmi_scan: Only honor end-of-table for 64-bit tables
> >
> > A 32-bit entry point to a DMI tab
points, as they do not specify a structure count.
Fixes: fc43026278 (dmi: add support for SMBIOS 3.0 64-bit entry point)
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Leif Lindholm leif.lindh...@linaro.org
Cc: Matt Fleming matt.flem...@intel.com
Cc: Ard Biesheuvel ard.biesheu...@linaro.org
Hi Ard,
Le Thursday 30 April 2015 à 12:37 +0200, Ard Biesheuvel a écrit :
On 28 April 2015 at 20:41, Jean Delvare jdelv...@suse.de wrote:
From: Jean Delvare jdelv...@suse.de
Subject: firmware: dmi_scan: Only honor end-of-table for 64-bit tables
A 32-bit entry point to a DMI table says
o worry. Feel free to
update your source to the new location whenever you want.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
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.kern
Apparently the compiler does fine without it, but it feels safer and
clearer to add the missing attribute.
Signed-off-by: Jean Delvare
---
include/linux/dmi.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.1-rc1.orig/include/linux/dmi.h 2015-04-28 20:42:00.496086088
Apparently the compiler does fine without it, but it feels safer and
clearer to add the missing attribute.
Signed-off-by: Jean Delvare jdelv...@suse.de
---
include/linux/dmi.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.1-rc1.orig/include/linux/dmi.h 2015-04-28 20
to the new location whenever you want.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
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
From: Jean Delvare
Subject: firmware: dmi_scan: Only honor end-of-table for 64-bit tables
A 32-bit entry point to a DMI table says how many structures the table
contains. The SMBIOS specification explicitly says that end-of-table
markers should be ignored if they are not actually at the end
Hi Ivan, Ard,
On Mon, 27 Apr 2015 18:17:15 +0300, Ivan.khoronzhuk wrote:
> On 26.04.15 23:47, Jean Delvare wrote:
> > The SMBIOS v3 entry points specify a maximum length for the DMI table,
> > not the exact length. Thus there may be garbage after the end-of-table
> > marker
| 9 +
> > drivers/i2c/busses/Makefile| 1 +
> > drivers/i2c/busses/i2c-mt65xx.c| 748
> > +
> > 4 files changed, 799 insertions(+)
> > create mode 100644 Documentation/devicetree/bindin
Hi Ivan,
On Mon, 27 Apr 2015 19:10:05 +0300, subscivan wrote:
> On 21.04.15 15:45, Jean Delvare wrote:
> > The trailing .x adds no information for the reader, and if anyone
> > tries to parse that line, this is more work as they have 3 different
> > formats to hand
Hi Ivan, Ard,
On Mon, 27 Apr 2015 18:17:15 +0300, Ivan.khoronzhuk wrote:
On 26.04.15 23:47, Jean Delvare wrote:
The SMBIOS v3 entry points specify a maximum length for the DMI table,
not the exact length. Thus there may be garbage after the end-of-table
marker, which we don't want
From: Jean Delvare jdelv...@suse.de
Subject: firmware: dmi_scan: Only honor end-of-table for 64-bit tables
A 32-bit entry point to a DMI table says how many structures the table
contains. The SMBIOS specification explicitly says that end-of-table
markers should be ignored if they are not actually
100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
create mode 100644 drivers/i2c/busses/i2c-mt65xx.c
Why have you sent me this?
Mind you, I was wondering exactly the same ;-)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Hi Ivan,
On Mon, 27 Apr 2015 19:10:05 +0300, subscivan wrote:
On 21.04.15 15:45, Jean Delvare wrote:
The trailing .x adds no information for the reader, and if anyone
tries to parse that line, this is more work as they have 3 different
formats to handle instead of 2. Plus, this makes
I'll be maintaining the pending patches to the dmi_scan and dmi-id
drivers as a quilt tree.
Signed-off-by: Jean Delvare
---
MAINTAINERS |1 +
1 file changed, 1 insertion(+)
--- linux-4.1-rc1.orig/MAINTAINERS 2015-04-27 16:33:57.946487307 +0200
+++ linux-4.1-rc1/MAINTAINERS 2015-04
I'll be maintaining the pending patches to the dmi_scan and dmi-id
drivers as a quilt tree.
Signed-off-by: Jean Delvare jdelv...@suse.de
---
MAINTAINERS |1 +
1 file changed, 1 insertion(+)
--- linux-4.1-rc1.orig/MAINTAINERS 2015-04-27 16:33:57.946487307 +0200
+++ linux-4.1-rc1
.
Signed-off-by: Jean Delvare
Cc: Ivan Khoronzhuk
---
drivers/firmware/dmi_scan.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
--- linux-4.1-rc0.orig/drivers/firmware/dmi_scan.c 2015-04-26
18:56:15.65785 +0200
+++ linux-4.1-rc0/drivers/firmware/dmi_scan.c
.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
drivers/firmware/dmi_scan.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
--- linux-4.1-rc0.orig/drivers/firmware/dmi_scan.c 2015-04-26
18:56:15.65785 +0200
Le Tuesday 21 April 2015 à 19:03 +0300, Ivan.khoronzhuk a écrit :
> On 21.04.15 18:36, Jean Delvare wrote:
> > I just found that more work is needed here for the SMBIOS v3 entry
> > point case. These entry points do not specify the exact length of the
> > table, but only
Le Tuesday 21 April 2015 à 19:03 +0300, Ivan.khoronzhuk a écrit :
On 21.04.15 18:36, Jean Delvare wrote:
I just found that more work is needed here for the SMBIOS v3 entry
point case. These entry points do not specify the exact length of the
table, but only its maximum. The real world
tate to the final state. Maybe something like that can be done for
CONFIG_I8K if you want to rename it.
--
Jean Delvare
SUSE L3 Support
--
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/
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
This allows for a transparent migration to the new names from a user's
perspective, as long as they do not jump directly from the original
state to the final state. Maybe something like that can be done for
CONFIG_I8K if you want to rename it.
--
Jean Delvare
s to be trimmed to the actual table size before the
attribute above is created. I have an idea how this could be
implemented easily, let me give it a try.
Maybe we should trim the length for previous implementations, too.
There is no reason to walk past a type 127 structure anyway, ever.
--
Jean Delvare
ithout /dev/mem. Also patch adds
> raw dmi table to simplify dmi table processing in user space, as
> proposed by Jean Delvare.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
> .../ABI/testing/sysfs-firmware-dmi-tables | 22 ++
> drivers/firmware/dmi-sysfs.c
. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.
Signed-off-by: Jean Delvare
Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from
SMBIOS if it exists")
Fixes: 79bae42d51a5 ("dmi_scan: refactor d
The trailing .x adds no information for the reader, and if anyone
tries to parse that line, this is more work as they have 3 different
formats to handle instead of 2. Plus, this makes backporting fixes
harder.
Signed-off-by: Jean Delvare
Fixes: 95be58df74a5 ("firmware: dmi_scan: Use ful
The trailing .x adds no information for the reader, and if anyone
tries to parse that line, this is more work as they have 3 different
formats to handle instead of 2. Plus, this makes backporting fixes
harder.
Signed-off-by: Jean Delvare jdelv...@suse.de
Fixes: 95be58df74a5 (firmware: dmi_scan
. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.
Signed-off-by: Jean Delvare jdelv...@suse.de
Fixes: 9f9c9cbb6057 (drivers/firmware/dmi_scan.c: fetch dmi version from
SMBIOS if it exists)
Fixes: 79bae42d51a5 (dmi_scan: refactor
dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
.../ABI/testing/sysfs-firmware-dmi-tables | 22 ++
drivers/firmware/dmi-sysfs.c | 17 +++--
drivers
to the actual table size before the
attribute above is created. I have an idea how this could be
implemented easily, let me give it a try.
Maybe we should trim the length for previous implementations, too.
There is no reason to walk past a type 127 structure anyway, ever.
--
Jean Delvare
SUSE L3 Support
t; and some
> > more beautification. However, I've been using it already to test the
> > i2c_quirk
> > infrastructure and Renesas I2C controllers.
>
> Jean, my tests went well and so I want to brush it up for inclusion into
> i2c-tools upstream. Any show-stoppers you see from a high-
I2C controllers.
Jean, my tests went well and so I want to brush it up for inclusion into
i2c-tools upstream. Any show-stoppers you see from a high-level point of
view?
I think it is a good idea, just I couldn't find the time to review it,
sorry :(
--
Jean Delvare
SUSE L3 Support
Hi Matt,
Le Friday 17 April 2015 à 14:40 +0100, Matt Fleming a écrit :
> On Thu, 16 Apr, at 10:35:11AM, Jean Delvare wrote:
> >
> > I don't really care who picks these patches up and sends them to Linus,
> > but I think they should all follow the same route so that Linus ha
On Thu, 16 Apr 2015 20:27:00 +0300, subscivan wrote:
> On 16.04.15 18:44, Jean Delvare wrote:
> > Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
> >> We cannot be sure that firmware_kobj created at time of dmi_init().
> >> The sources don't oblige y
On Fri, 17 Apr 2015 15:04:23 +0300, Ivan.khoronzhuk wrote:
> On 17.04.15 13:11, Ivan.khoronzhuk wrote:
> > On 17.04.15 11:54, Jean Delvare wrote:
> >> I have no formal tree yet, but my current patch set can be seen at:
> >> http://jdelvare.nerim.net/devel/linux-3/jdel
On Fri, 17 Apr 2015 10:13:25 +0200, Jean Delvare wrote:
> In function dmi_present(), dmi_walk_early() calls dmi_table(), which
> calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
> function makes a decision based on the value of global variable
> dmi_ver.
Hi Ivan,
On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
> On 16.04.15 11:35, Jean Delvare wrote:
> > On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
> >> Jean, do you want me to pick this patch up or are you going to?
> > Good question, we nee
. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.
Signed-off-by: Jean Delvare
Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from
SMBIOS if it exists")
Fixes: 79bae42d51a5 ("dmi_scan: refactor d
Hi Ivan,
On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
On 16.04.15 11:35, Jean Delvare wrote:
On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
Jean, do you want me to pick this patch up or are you going to?
Good question, we need to agree on a strategy.
There are 3
. The second breakage is more problematic as
it affects the vast majority of x86 systems manufactured since 2009.
Signed-off-by: Jean Delvare jdelv...@suse.de
Fixes: 9f9c9cbb6057 (drivers/firmware/dmi_scan.c: fetch dmi version from
SMBIOS if it exists)
Fixes: 79bae42d51a5 (dmi_scan: refactor
On Fri, 17 Apr 2015 10:13:25 +0200, Jean Delvare wrote:
In function dmi_present(), dmi_walk_early() calls dmi_table(), which
calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
function makes a decision based on the value of global variable
dmi_ver. The problem
On Fri, 17 Apr 2015 15:04:23 +0300, Ivan.khoronzhuk wrote:
On 17.04.15 13:11, Ivan.khoronzhuk wrote:
On 17.04.15 11:54, Jean Delvare wrote:
I have no formal tree yet, but my current patch set can be seen at:
http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/
First 2 patches from you
On Thu, 16 Apr 2015 20:27:00 +0300, subscivan wrote:
On 16.04.15 18:44, Jean Delvare wrote:
Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
We cannot be sure that firmware_kobj created at time of dmi_init().
The sources don't oblige you to call it at core level
Hi Matt,
Le Friday 17 April 2015 à 14:40 +0100, Matt Fleming a écrit :
On Thu, 16 Apr, at 10:35:11AM, Jean Delvare wrote:
I don't really care who picks these patches up and sends them to Linus,
but I think they should all follow the same route so that Linus has as
little merge work
Hi Ivan,
Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
> On 16.04.15 12:52, Jean Delvare wrote:
> > On Thu, 2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:
> >> +static BIN_ATTR(smbios_entry_point, S_IRUSR, raw_table_read, NULL, 0);
> > This one
ithout /dev/mem. Also patch adds
> raw dmi table to simplify dmi table processing in user space, as
> proposed by Jean Delvare.
>
> Signed-off-by: Ivan Khoronzhuk
> ---
> .../ABI/testing/sysfs-firmware-dmi-tables | 22 ++
> drivers/firmware/dmi-sysfs.c
Le Thursday 16 April 2015 à 16:46 +0800, Zhenzhong Duan a écrit :
> On 2015/4/16 15:09, Jean Delvare wrote:
> > Le Thursday 16 April 2015 à 14:22 +0800, Zhenzhong Duan a écrit :
> >> The basic idea is right, but you ignore the case dmi_walk_early may
> >> fail, though l
o that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.
Thanks,
--
Jean Delvare
SUSE L3 Support
Hi zduan,
Thanks for your reply.
Le Thursday 16 April 2015 à 14:22 +0800, Zhenzhong Duan a écrit :
> On 2015/4/15 17:02, Jean Delvare wrote:
> > In function dmi_present(), dmi_walk_early() calls dmi_table(), which
> > calls dmi_decode(), which ultimately calls dmi_save_uu
ols.
If there really ever is a need to ignore the _SM3_ entry point, I'd
rather have a kernel boot parameter for this. This would guarantee that
the kernel and user-space applications always operate on the same data.
So I would keep the sysfs interface simple, as Ivan implemented it.
keep the sysfs interface simple, as Ivan implemented it.
--
Jean Delvare
SUSE L3 Support
--
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
Hi zduan,
Thanks for your reply.
Le Thursday 16 April 2015 à 14:22 +0800, Zhenzhong Duan a écrit :
On 2015/4/15 17:02, Jean Delvare wrote:
In function dmi_present(), dmi_walk_early() calls dmi_table(), which
calls dmi_decode(), which ultimately calls dmi_save_uuid(). This last
function
. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Le Thursday 16 April 2015 à 16:46 +0800, Zhenzhong Duan a écrit :
On 2015/4/16 15:09, Jean Delvare wrote:
Le Thursday 16 April 2015 à 14:22 +0800, Zhenzhong Duan a écrit :
The basic idea is right, but you ignore the case dmi_walk_early may
fail, though looks impossible when bootup
dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
.../ABI/testing/sysfs-firmware-dmi-tables | 22 ++
drivers/firmware/dmi-sysfs.c | 11 ++-
drivers
Hi Ivan,
Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
On 16.04.15 12:52, Jean Delvare wrote:
On Thu, 2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:
+static BIN_ATTR(smbios_entry_point, S_IRUSR, raw_table_read, NULL, 0);
This one could be world-readable
/sys/firmware/dmi/
> +What:/sys/firmware/dmi/entries/
> Date:February 2011
> Contact: Mike Waychison
> Description:
Thanks for doing this.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list:
801 - 900 of 3166 matches
Mail list logo
