devices).
Signed-off-by: Maximilian Luz
---
drivers/misc/surface_aggregator/Kconfig | 12 +
drivers/misc/surface_aggregator/Makefile | 4 +
drivers/misc/surface_aggregator/bus.c | 419 ++
drivers/misc/surface_aggregator/bus.h | 22 ++
drivers/misc
commit.
Signed-off-by: Maximilian Luz
---
drivers/misc/surface_aggregator/Makefile | 3 +
drivers/misc/surface_aggregator/controller.c | 5 +
drivers/misc/surface_aggregator/core.c| 3 +
.../surface_aggregator/ssh_packet_layer.c | 21 +
.../surface_aggregator
.
Signed-off-by: Maximilian Luz
---
drivers/misc/surface_aggregator/core.c| 27 ++-
.../surface_aggregator/ssh_packet_layer.c | 47 +++
.../surface_aggregator/ssh_packet_layer.h | 3 ++
3 files changed, 67 insertions(+), 10 deletions(-)
diff --git a/drivers/misc
n test that at
this point. I'd be happy to work out any issues regarding SAM on
the Pro X at some point in the future, provided someone can/wants
to actually test it.
[2]: https://github.com/linux-surface/surface-aggregator-module
[3]: https://github.com/linux-surface/linux-surface
Maximilian
iver which, based
on some DMI matching, marks the corresponding GPE of the lid device for
wake and enables it during suspend. The behavior of this driver models
the behavior of the ACPI/PM core for normal wakeup GPEs, properly
declared via the _PRW field.
Signed-off-by: Maximilian Luz
---
Cha
On 9/16/20 7:13 PM, Barnabás Pőcze wrote:
...
+ }s
+
+ return 0;
+}
[...]
+static int surface_gpe_probe(struct platform_device *pdev)
+{
+ struct surface_lid_device *lid;
+ u32 gpe_number;
+ int status;
+
+ status = device_property_read_u32(>dev, "gpe",
Hi,
On 9/16/20 1:58 AM, Barnabás Pőcze wrote:
Hi
[...]
+static int surface_lid_enable_wakeup(struct device *dev, bool enable)
+{
+ const struct surface_lid_device *lid = dev_get_drvdata(dev);
+ int action = enable ? ACPI_GPE_ENABLE : ACPI_GPE_DISABLE;
+ acpi_status status;
On 9/12/20 12:10 AM, mark gross wrote:
Surface devices are tablets with detachable keyboards. they don't really
have a "lid" as the tablet is the "lid".
The Surface Laptop series doesn't have a detachable keyboard, yet still
requires this. Arguably, the Surface Books are also more laptop than
I've just sent v2.
Thank you for your comments,
Max
iver which, based
on some DMI matching, marks the corresponding GPE of the lid device for
wake and enables it during suspend. The behavior of this driver models
the behavior of the ACPI/PM core for normal wakeup GPEs, properly
declared via the _PRW field.
Signed-off-by: Maximilian Luz
---
Cha
On 9/8/20 8:40 PM, Andy Shevchenko wrote:
On Tue, Sep 8, 2020 at 8:20 PM Maximilian Luz wrote:
...
+ .gpe_number = 0x17,
+ .gpe_number = 0x4D,
+ .gpe_number = 0x4F,
+ .gpe_number = 0x57,
From where these numbers come from? Can we get them from firmware (ACPI
iver which, based
on some DMI matching, marks the corresponding GPE of the lid device for
wake and enables it during suspend. The behavior of this driver models
the behavior of the ACPI/PM core for normal wakeup GPEs, properly
declared via the _PRW field.
Signed-off-by: Maximilian Luz
---
This drive
On 8/25/20 9:30 PM, Brian Norris wrote:
Also, while technically the regressing commit (e18696786548 ("mwifiex:
Prevent memory corruption handling keys")) was fixing a potential
overflow, the encasing command structure (struct host_cmd_ds_command)
is a union of a ton of other command layouts, and
On 8/25/20 8:51 PM, Dan Carpenter wrote:
I sort of feel like the code was broken before I added the bounds
checking but it's also okay if the Fixes tag points to my change as
well just to make backporting easier.
I'd argue the same. Any critical out-of-bounds access was just never
discovered
orage size for AES keys to 256 bit.
Signed-off-by: Maximilian Luz
Reported-by: Kaloyan Nikolov
Tested-by: Kaloyan Nikolov
---
drivers/net/wireless/marvell/mwifiex/fw.h | 2 +-
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
mit
commit 6d232b29cfce65961db4a668c2c6c6987cd24d45
Author: Maximilian Luz
Date: Tue Dec 17 11:35:22 2019 -0800
ACPICA: Dispatcher: always generate buffer objects for ASL create_field()
operator
ACPICA commit 79a466b64e6af36cc83102f05915e56cb7dd89ab
According to table 19-419 of th
Hi,
On 10/10/19 12:22 PM, Hans de Goede wrote:
This patch looks good to me and it works on my test hw with serial
attached BT HCI:
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede
Regards,
Hans
Awesome, thank you!
Regards,
Maximilian
to this again.
I have now also tested your patch on the Surface Book 2. Does not cause
any issues as far as I can tell.
Tested-by: Maximilian Luz
And if that is needed/wanted
Acked-by: Maximilian Luz
Regards,
Maximilian
Hi,
On 10/5/19 3:20 PM, Hans de Goede wrote:
Hi,
S-o-b is only for patches which pass through your hands, e.g. if
you make changes to my patch and submit a v2 of it.
I guess you mean / want one of:
Acked-by: ...
or
Reviewed-by: ...
?
I apologize if the s-o-b was misplaced here, it was
a comment mentioned that gpiod_get() returning
-EPROBE_DEFER would be the proper way to detect this, I decided on this
change.
Might I suggest the following addition:
Signed-off-by: Maximilian Luz
---
drivers/input/misc/soc_button_array.c | 25 -
1 file changed, 20
Hi,
I have just submitted v2 of this patch.
Regards,
Maximilian
and drivers/spi/spi.c, specifically commit
4c3c59544f33e97cf8557f27e05a9904ead16363 ("spi/acpi: enumerate all SPI
slaves in the namespace").
Signed-off-by: Maximilian Luz
---
Changes compared to v1:
- Patch now reflects the behavior of the existing ACPI serial bus
implementations (drivers/i2
Hi,
On 9/23/19 10:14 AM, Hans de Goede wrote:
Ack, this is what drivers/i2c/i2c-core-acpi.c is doing and more in general
all ACPI enumeration code always first checks _STA before doing anything
else, so I think it would be best to do this here too.
Actually I think it might be best to fully
Hi all,
On 9/20/19 5:00 PM, Hans de Goede wrote:
So as promised I've given this patch a try, unfortunately it breaks
existing users of ACPI serdev device instantation.
After adding this patch "ls /sys/bus/serial/devices" is empty,
where as before it gives:
[root@dhcp-45-50 ~]# ls -l
Hi,
So as promised I've given this patch a try, unfortunately it breaks
existing users of ACPI serdev device instantation.
I've only had a short look at it so far. As far as I can tell, there are
two options: Either the device does not match/is being skipped, or there
are errors (which are
Hi,
On 9/20/19 10:50 AM, Hans de Goede wrote:
Also I will give this a test-run on some of the existing devices
which rely on the instantiation of serdev devices for ACPI
devices which are childs of the uart device.
Thank you for testing! Will get to your other mail shortly.
Given the above
, indicating the controller
device. To address this, we need to walk over the whole ACPI namespace,
looking at each resource definition, and match the client device to the
controller via this field.
Signed-off-by: Maximilian Luz
---
This patch is similar to the the implementations in drivers/spi/spi.c
On 7/27/19 11:14 AM, Dmitry Torokhov wrote:
On Sat, Jul 20, 2019 at 05:05:11PM +0200, Maximilian Luz wrote:
-
- error = gpiod_count(dev, NULL);
- if (error < 0) {
- dev_dbg(dev, "no GPIO attached, ignoring...\n");
- return -ENODEV;
I do
On 7/22/19 10:00 AM, Enrico Weigelt, metux IT consult wrote:
On 20.07.19 17:05, Maximilian Luz wrote:
Power and volume button support for 5th and 6th generation Microsoft
Surface devices via soc_button_array.
Note that these devices use the same MSHW0040 device as on the Surface
Pro 4, however
I have updated the patches with the requested changes and sent a v3.
Best,
Maximilian
implementation is significantly different. This patch ensures
that the surfacepro3_button driver is only used on the Pro 3 and 4
models, allowing a different driver to bind on other models.
Signed-off-by: Maximilian Luz
---
drivers/platform/x86/surfacepro3_button.c | 47 +++
1 file
check for surfacepro3_button
No changes.
- [PATCH 2/2] input: soc_button_array for newer surface devices
Ensure the patch compiles without CONFIG_ACPI.
Maximilian Luz (2):
platform/x86: surfacepro3_button: Fix device check
Input: soc_button_array - Add support for newer surface devices
we only load
this driver on the correct devices.
Signed-off-by: Maximilian Luz
---
drivers/input/misc/Kconfig| 6 +-
drivers/input/misc/soc_button_array.c | 141 +++---
2 files changed, 131 insertions(+), 16 deletions(-)
diff --git a/drivers/input/misc/Kconfig
On 7/16/19 10:18 PM, Dmitry Torokhov wrote:
OK, fair enough. By the way, I see you are adding some #ifdef
CONFIG_ACPI and stubbing out new functions, but the driver does not
really work without ACPI (acpi_match_device() will fail in this case I
would think and that will cause probe() to abort).
Hi,
On 7/16/19 9:21 AM, Dmitry Torokhov wrote:
When you are saying that Pro 4 and later models use different
notifications, does this mean that Pro 4 does not define any GPIOs?
Unfortunately, at least the Surface Book (first generation, buttons are
handled the same way as on the Pro 4) has
On 7/2/19 2:37 AM, Maximilian Luz wrote:
+static int soc_device_check_MSHW0040(struct device *dev)
+{
+ acpi_handle handle = ACPI_HANDLE(dev);
+ union acpi_object *result;
+ u64 oem_platform_rev = 0;
+ int gpios;
+
+ // get OEM platform revision
+ result
On 7/2/19 7:13 PM, Andy Shevchenko wrote:
I re-pushed to my queue, though if you are going to send a new
version, check my repository for the titles of the patches (you need
to use correct templates for the subsystems).
Got it, sorry for the inconvenience.
Thank you!
Maximilian
On 7/2/19 3:57 AM, Yu Chen wrote:
How about using a boolean, according to the function name, if a mshw0040 revison
is detected then returns true other wise false. Other than that,
Acked-by: Chen Yu
I can change that if you want me to. Just thought this might be a bit
more flexible in case we
On 7/2/19 3:25 AM, Maximilian Luz wrote:
On 7/2/19 3:14 AM, Yu Chen wrote:
On Tue, Jul 02, 2019 at 02:37:39AM +0200, Maximilian Luz wrote:
+/*
+ * Surface Pro 4 and Surface Book 2 / Surface Pro 2017 use the same device
+ * ID (MSHW0040) for the power/volume buttons. Make sure this is the right
On 7/2/19 3:14 AM, Yu Chen wrote:
On Tue, Jul 02, 2019 at 02:37:39AM +0200, Maximilian Luz wrote:
+/*
+ * Surface Pro 4 and Surface Book 2 / Surface Pro 2017 use the same device
+ * ID (MSHW0040) for the power/volume buttons. Make sure this is the right
+ * device by checking for the _DSM
On 6/29/19 4:18 PM, Andy Shevchenko wrote:
Pushed to my review and testing queue, thanks!
Sorry for my rookie mistake of not checking that this works without
CONFIG_ACPI. I have updated and re-sent the patches to fix this.
Maximilian
we only load
this driver on the correct devices.
Signed-off-by: Maximilian Luz
---
drivers/input/misc/soc_button_array.c | 145 +++---
1 file changed, 133 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/soc_button_array.c
b/drivers/input/misc
implementation is significantly different. This patch ensures
that the surfacepro3_button driver is only used on the Pro 3 and 4
models, allowing a different driver to bind on other models.
Signed-off-by: Maximilian Luz
---
drivers/platform/x86/surfacepro3_button.c | 38 +++
1 file
No changes.
- [PATCH 2/2] input: soc_button_array for newer surface devices
Ensure the patch compiles without CONFIG_ACPI.
Maximilian Luz (2):
platform: Fix device check for surfacepro3_button
input: soc_button_array for newer surface devices
drivers/input/misc/soc_button_array.c | 145
On 6/20/19 7:53 AM, Andy Shevchenko wrote:
No top post, please.
Sorry, will do better!
And yes, submit it as a series. Also Cc to Benjamin Tissoires.
Done.
Thank you,
Maximilian
implementation is significantly different. This patch ensures
that the surfacepro3_button driver is only used on the Pro 3 and 4
models, allowing a different driver to bind on other models.
Signed-off-by: Maximilian Luz
---
drivers/platform/x86/surfacepro3_button.c | 38 +++
1 file
we only load
this driver on the correct devices.
Signed-off-by: Maximilian Luz
---
drivers/input/misc/soc_button_array.c | 134 +++---
1 file changed, 122 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/soc_button_array.c
b/drivers/input/misc
power-/volume-button devices more
easily, I'm not sure if there may be reasons against this.
These patches have also been tested on various Surface devices via the
github.com/jakeday/linux-surface patchset.
Maximilian Luz (2):
platform: Fix device check for surfacepro3_button
input
Since there are no comments on this, should I simply submit this as patch?
Maximilian
On 6/1/19 9:07 PM, Maximilian Luz wrote:
Hi,
any comments on this?
I should also mention that this has been tested via
https://github.com/jakeday/linux-surface.
Maximilian
Hi,
any comments on this?
I should also mention that this has been tested via
https://github.com/jakeday/linux-surface.
Maximilian
On 5/16/19 4:25 PM, Maximilian Luz wrote:
This series adds suport for power and volume buttons on 5th and 6th
generation Microsoft Surface devices. Specifically
Without USB_QUIRK_NO_LPM ethernet will not work and rtl8152 will
complain with
r8152 : Stop submitting intr, status -71
Adding the quirk resolves this. As the dock is externally powered, this
should not have any drawbacks.
Signed-off-by: Maximilian Luz
---
drivers/usb/core/quirks.c | 3
power-/volume-button devices more
easily, I'm not sure if there may be reasons against this.
Maximilian Luz (2):
platform: Fix device check for surfacepro3_button
input: soc_button_array for newer surface devices
drivers/input/misc/soc_button_array.c | 134 --
drivers
implementation is significantly different. This patch ensures
that the surfacepro3_button driver is only used on the Pro 3 and 4
models, allowing a different driver to bind on other models.
Signed-off-by: Maximilian Luz
---
drivers/platform/x86/surfacepro3_button.c | 38 +++
1 file
we only load
this driver on the correct devices.
Signed-off-by: Maximilian Luz
---
drivers/input/misc/soc_button_array.c | 134 +++---
1 file changed, 122 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/soc_button_array.c
b/drivers/input/misc
201 - 254 of 254 matches
Mail list logo
