[PATCH] Input: elan_i2c - fix a typo in parameter name
s/max_baseliune/max_baseline/
Signed-off-by: Nikolai Kostrigin
---
drivers/input/mouse/elan_i2c.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/elan_i2c.h b/drivers/input/mouse/elan_i2c.h
index e12da5b024b0..55cdf60fe231 100644
--- a/drivers/input/mouse/elan_i2c.h
+++ b/drivers/input/mouse/elan_i2c.h
@@ -73,7 +73,7 @@ struct elan_transport_ops {
int (*calibrate_result)(struct i2c_client *client, u8 *val);
int (*get_baseline_data)(struct i2c_client *client,
-bool max_baseliune, u8 *value);
+bool max_baseline, u8 *value);
int (*get_version)(struct i2c_client *client, u8 pattern, bool iap,
u8 *version);
--
2.29.2
Re: elan_i2c: failed to read report data: -71
Hi!
05.03.2021 22:18, Uwe Kleine-König пишет:
> On Thu, Mar 04, 2021 at 11:49:59AM +0300, Nikolai Kostrigin wrote:
>> Hi,
>>
>> 04.03.2021 09:59, Uwe Kleine-König пишет:
>>> Hello,
>>>
>>> On Wed, Mar 03, 2021 at 05:53:37PM -0800, 'Dmitry Torokhov' wrote:
>>>> On Wed, Mar 03, 2021 at 09:03:30PM +0100, Uwe Kleine-König wrote:
>>>>> On Wed, Mar 03, 2021 at 07:32:23PM +0100, Uwe Kleine-König wrote:
>>>>>> On Wed, Mar 03, 2021 at 11:13:21AM +0800, jingle wrote:
>>>>>>> Please updates this patchs.
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=056115daede8d01f71732bc7d778fb85acee8eb6
>>>>>>>
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=e4c9062717feda88900b566463228d1c4910af6d
>>>>>>
>>>>>> The first was one of the two patches I already tried, but the latter
>>>>>> indeed fixes my problem \o/.
>>>>>>
>>>>>> @Dmitry: If you don't consider your tree stable, feel free to add a
>>>>>>
>>>>>> Tested-by: Uwe Kleine-König
>>>>>>
>>>>>> to e4c9062717feda88900b566463228d1c4910af6d.
>>>>>
>>>>> Do you consider this patch for stable? I'd like to see it in Debian's
>>>>> 5.10 kernel and I guess I'm not the only one who would benefit from such
>>>>> a backport.
>>>>
>>>> When I was applying the patches I did not realize that there was already
>>>> hardware in the wild that needed it. The patches are now in mainline, so
>>>> I can no longer adjust the tags, but I will not object if you propose
>>>> them for stable.
>>>
>>> I want to propose to backport commit
>>>
>>> e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints
>>> in SMBus mode")
>>>
>>> to the active stable kernels. This commit repairs the track point and
>>> the touch pad buttons on a Lenovo Thinkpad E15 here. Without this change
>>> I don't get any events apart from an error message for each button press
>>> or move of the track point in the kernel log. (Also the error message is
>>> the same for all buttons and the track point, so I cannot create a new
>>> input event driver in userspace that emulates the right event depending
>>> on the error message :-)
>>>
>>> At least to 5.10.x it applies cleanly, I didn't try the older stable
>>> branches.
>>>
>>> Best regards and thanks
>>> Uwe
>>>
>>
>> I'd like to propose to backport [1] also as it was checked along with
>> previously proposed patch and fixes Elan Trackpoint operation on
>> Thinkpad L13.
>>
>> Both patches apply cleanly to 5.10.17 in my case.
>>
>> I also tried to apply to 5.4.x, but failed.
>>
>> [1] 056115daede8 Input: elan_i2c - add new trackpoint report type 0x5F
>>
>> Additional info is available here:
>>
>> https://lore.kernel.org/linux-input/fe31f6f8-6e38-2ed6-8548-6fa271bf3...@basealt.ru/T/#m514047f2c5e7e2ec4ed9658782f14221ed7598fc
>
> FTR: I tested 5.10 + e4c9062717fe ("Input: elantech - fix protocol
> errors for some trackpoints in SMBus mode") now and in this setup the
> touchpad is still broken. I assume that in combination with 056115daede8
> it will work. The working setup I tested was 5.10 + c7f0169e3bd2 +
> 056115daede8 + e4c9062717fe and I assume c7f0169e3bd2 isn't relevant.
>
> Best regards
> Uwe
>
>
Now when both patches (056115daede8 + e4c9062717fe) are in stable since
5.10.22 trackpoint works just fine on TP L13 after computer boot.
But there is one more thing to add:
when resuming from hibernation mode trackpoint loses the workaround and
continue to send long packets (please refer to attached log).
This happens because the device was powered off and during wake-up the
code from 'psmouse' containing packet type switch was not run.
drivers/input/mouse/elantech.c:
if (elantech_change_report_id(psmouse)) {
psmouse_info(psmouse,
"Trackpoint report is broken,
forcing standard PS/2 protocol\n");
return -ENODEV;
}
Power management is handled by elan_i2c driver.
drivers/input/mouse/elan_i2c_core.c:
[...]
static SIMPLE_DEV_PM_OPS(elan_pm_ops, elan_suspend, elan_resume);
[...]
Resume from suspend is not a
Re: Need some help on "Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2"
Hi, resending this once again, hoping it wouldn't contain any HTML and wouldn't be filtered by LKML. 03.03.2021 13:11, Nikolai Kostrigin пишет: > Hi, > > 25.02.2021 12:38, Wolfram Sang пишет: >> Hi, >> >>> I had a preliminary discussion with Benjamin Tissoires and according to >>> our agreement I repost it for wider audience. >>> Blacklisting the device was decided to be a bad idea. >>> But actually I managed to get touchpad totally operational via SMBus >>> using a following hack: >>> >>> providing a parameter to i2c_i801 driver: >>> >>> modprobe i2c_i801 disable_features=0x2 (i.e. disable the block buffer). >> So, from an I2C perspective, there are two things to mention here: >> >> a) I am in the process of extending the I2C core to allow block >> transfers > 32 byte. This is a slow process, though, because we need to >> pay attention to not break userspace ABI. If this is done *and* the i801 >> driver supports length > 32 bytes, too, then it would work natively. If >> the i801 can do this, this is a question for Jean Delvare. >> >> b) I don't know Elantech HW but there are devices out there which allow >> configuration for the block size. Something like a bit specifying if >> block transfers > 32 are allowed. Or the SMBus version to support. Block >> transfers > 32 are SMBus 3.0+ only. If your HW does not have that, >> disabling SMBus is an option, too. Disabling it in the i801 driver is >> too much of a hammer, I'd say. >> >> Hope this helps! Happy hacking, >> >>Wolfram > Thank you for the information, Wolfram! > > Finally it turned out that the solution was near me from the very > beginning, but I failed to check mainline code at that moment (which is > now 5.11). > Happily Jingle Wu has pointed me to a couple of patches of his > (co-authored by Dmitry Torokhov): > > https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=056115daede8d01f71732bc7d778fb85acee8eb6 > > https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=e4c9062717feda88900b566463228d1c4910af6d > > I applied those to 5.10.17 and trackpoint works like a charm. > So I guess theese patches are worth being backported to the longterm > 5.10 branch. > I'm really sorry for the noise. > -- Best regards, Nikolai Kostrigin
Re: Need some help on "Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2"
Hi, 25.02.2021 12:38, Wolfram Sang пишет: > Hi, > >> I had a preliminary discussion with Benjamin Tissoires and according to >> our agreement I repost it for wider audience. >> Blacklisting the device was decided to be a bad idea. >> But actually I managed to get touchpad totally operational via SMBus >> using a following hack: >> >> providing a parameter to i2c_i801 driver: >> >> modprobe i2c_i801 disable_features=0x2 (i.e. disable the block buffer). > So, from an I2C perspective, there are two things to mention here: > > a) I am in the process of extending the I2C core to allow block > transfers > 32 byte. This is a slow process, though, because we need to > pay attention to not break userspace ABI. If this is done *and* the i801 > driver supports length > 32 bytes, too, then it would work natively. If > the i801 can do this, this is a question for Jean Delvare. > > b) I don't know Elantech HW but there are devices out there which allow > configuration for the block size. Something like a bit specifying if > block transfers > 32 are allowed. Or the SMBus version to support. Block > transfers > 32 are SMBus 3.0+ only. If your HW does not have that, > disabling SMBus is an option, too. Disabling it in the i801 driver is > too much of a hammer, I'd say. > > Hope this helps! Happy hacking, > >Wolfram Thank you for the information, Wolfram! Finally it turned out that the solution was near me from the very beginning, but I failed to check mainline code at that moment (which is now 5.11). Happily Jingle Wu has pointed me to a couple of patches of his (co-authored by Dmitry Torokhov): https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=056115daede8d01f71732bc7d778fb85acee8eb6 https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=next&id=e4c9062717feda88900b566463228d1c4910af6d I applied those to 5.10.17 and trackpoint works like a charm. So I guess theese patches are worth being backported to the longterm 5.10 branch. I'm really sorry for the noise. -- Best regards, Nikolai Kostrigin
Re: Need some help on "Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2"
Hi, List!
I'd like to draw attention of Elantech and Lenovo engineers to an issue
of a non-working trackpoint.
Earlier this month I've discovered that Lenovo Thinkpad L13 trackpoint
doesn't work on Linux while touchpad does.
Both use elan_i2c + i2c_i801 drivers. The issue is confirmed for 5.4 and
5.10 kernels.
I had a preliminary discussion with Benjamin Tissoires and according to
our agreement I repost it for wider audience.
Blacklisting the device was decided to be a bad idea.
But actually I managed to get touchpad totally operational via SMBus
using a following hack:
providing a parameter to i2c_i801 driver:
modprobe i2c_i801 disable_features=0x2 (i.e. disable the block buffer).
If any additional information is needed I'm ready to provide it.
Some technical details on the issue we've managed to figure out by now
are here-in-after:
19.02.2021 11:30, Benjamin Tissoires пишет:
> Hi Nikolai,
>
> On Thu, Feb 18, 2021 at 6:05 PM Nikolai Kostrigin wrote:
>> Hi, Benjamin!
>>
>> Sorry for bothering you directly.
>>
>> I have a question concerning the work on the issue we were discussing on
>> linux-input mailing list.
>>
>> https://patchwork.kernel.org/project/linux-input/patch/20210208075205.3784059-1-nic...@altlinux.org/
[...]
>> With elantech-smbus protocol I was getting persistent messages in dmesg:
>>
>> elan_i2c [...] :00:1f.4 failed to read report data: -71
>>
>> I managed to track -71 (-EPROTO) error code to drivers/i2c/busses/i2c-i801.c
>>
>> Actually I managed to get Touchpad totally operational via SMBus using a
>> following hack:
>> providing a parameter to i2c_i801 driver:
>>
>> modprobe i2c_i801 disable_features=0x2 (i.e. disable the block buffer).
> ooh...
>
>> This makes code operating in other way and recover from illegal SMBus
>> block read size (giving warning messages in dmesg though).
>>
>>
>> [ 1270.105103] i801_smbus :00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93
>> [ 1270.119337] i801_smbus :00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93
>> [ 1270.133108] i801_smbus :00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93 <- theese are from trackpoint
>> [ 1270.167344] i801_smbus :00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93
>> [ 1399.869023] i801_smbus :00:1f.4: SMBus block read size is 32
>> [ 1399.882266] i801_smbus :00:1f.4: SMBus block read size is 32
>> [ 1399.896619] i801_smbus :00:1f.4: SMBus block read size is 32
>> [ 1399.909850] i801_smbus :00:1f.4: SMBus block read size is 32
>> <- these are from touchpad
>> [ 1399.924117] i801_smbus :00:1f.4: SMBus block read size is 32
>>
>>
>> We end up in this piece of code that has a built-in workaround and makes
>> Trackpoint work with SMBus
>>
>> NB: pay attention to /* FIXME: Recover */ priv->len = I2C_SMBUS_BLOCK_MAX;
>> All code snippets are from drivers/i2c/busses/i2c-i801.c here-in-after
>> (with some debug messages of mine).
>>
>> static void i801_isr_byte_done(struct i801_priv *priv)
>> {
>> if (priv->is_read) {
>> /* For SMBus block reads, length is received with first
>> byte */
>> if (((priv->cmd & 0x1c) == I801_BLOCK_DATA) &&
>> (priv->count == 0)) {
>> priv->len = inb_p(SMBHSTDAT0(priv));
>> if (priv->len < 1 || priv->len >
>> I2C_SMBUS_BLOCK_MAX) {
>> dev_err(&priv->pci_dev->dev,
>> "Illegal SMBus block read size
>> from i801_isr_byte_done %d\n",
>> priv->len);
>> /* FIXME: Recover */
>> priv->len = I2C_SMBUS_BLOCK_MAX;
>> } else {
>> dev_dbg(&priv->pci_dev->dev,
>> "SMBus block read size is %d\n",
>> priv->len);
>> }
>> priv->data[-1] = priv->len;
>> }
>>
>>
>>
>> But with no param passed to i2c_i801 driver we end up here due to len=93
>> with our trackpoint:
>>
>> static int i801_block_transaction_by_block(struct i801_priv *priv,
>>union i2c_smbus_data *data,
>>
Re: [PATCH] Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2
Hi, Benjamin!
08.02.2021 11:06, Benjamin Tissoires пишет:
> Hi Nikolai,
>
> On Mon, Feb 8, 2021 at 9:01 AM Nikolai Kostrigin wrote:
>> ThinkPad L13 Gen2 has both touchpad and trackpoint.
>> PNP: LEN2146 PNP0f13
>> With the default protocol (elantech-smbus) trackpoint is not operating,
>> while touchpad does. Changing to elantech renders both operational.
>>
>> Signed-off-by: Nikolai Kostrigin
> Instead of downgrading the capabilities of the touchpad, couldn't we
> fix the trackpoint issues?
Yes, I consider fixing the issue would be better than downgrading
touchpad capabilities.
Blacklisting was the first and most obvious idea to test.
I'm eager to perform additional diagnostics to choose a better solution.
Your advice would be appreciated.
>
> I am surprised elantech doesn't work with the trackpoint, because I am
> pretty sure I wrote patches in that regard. Which kernel version have
> you been testing?
The patch was tested with 5.10.13 only, but the trackpoint behaviour is
the same on 5.4.92.
> Cheers,
> Benjamin
>
>
>> ---
>> drivers/input/mouse/elantech.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
>> index 90f8765f9efc..c4c3fa5828d8 100644
>> --- a/drivers/input/mouse/elantech.c
>> +++ b/drivers/input/mouse/elantech.c
>> @@ -1776,6 +1776,7 @@ static const char * const i2c_blacklist_pnp_ids[] = {
>> * These are known to not be working properly as bits are missing
>> * in elan_i2c.
>> */
>> + "LEN2146", /* ThinkPad L13 Gen2 */
>> NULL
>> };
>>
>> --
>> 2.29.2
>>
--
Best regards,
Nikolai Kostrigin
[PATCH] Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2
ThinkPad L13 Gen2 has both touchpad and trackpoint.
PNP: LEN2146 PNP0f13
With the default protocol (elantech-smbus) trackpoint is not operating,
while touchpad does. Changing to elantech renders both operational.
Signed-off-by: Nikolai Kostrigin
---
drivers/input/mouse/elantech.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 90f8765f9efc..c4c3fa5828d8 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1776,6 +1776,7 @@ static const char * const i2c_blacklist_pnp_ids[] = {
* These are known to not be working properly as bits are missing
* in elan_i2c.
*/
+ "LEN2146", /* ThinkPad L13 Gen2 */
NULL
};
--
2.29.2
Re: [PATCH RESEND 1/1] PCI: Add ATS-disable quirk for AMD Radeon R7 GPUs
[+cc] linux-kernel@, linux-pci@ 10.04.2019 10:26, Nikolai Kostrigin пишет: > Hello! > > 10.04.2019 00:59, Bjorn Helgaas пишет: >> [+cc Alex] >> >> This claims to be a resend, but I don't see a previous posting. > For some reason, unknown to me, my previous letter didn't appear > neither in linux-kernel@, nor in linux-pci@ mailing lists. I'm sorry. Now it's obvious I didn't manage to turn HTML formatting off before. > >> There *was* discussion when the quirk was added two years ago for a >> different device. As part of that, Alex thought only that device >> would be affected and ATS was validated on other GPUs: >> >> >> https://lore.kernel.org/lkml/bn6pr12mb165278346be8a76b1e4412aff7...@bn6pr12mb1652.namprd12.prod.outlook.com/ > I'm aware of that and it was Joerg who pointed me to the above thread > when I asked him for help. > In my case both devices mentioned in quirks are present in a laptop. > Unfortunately I have no hardware with standalone AMD R7 GPU > (0102:6900) to check whether unpatched kernel would fail > the same way with both ATS and IOMMU enabled. > >> On Mon, Apr 08, 2019 at 01:37:25PM +0300, Nikolai Kostrigin wrote: >>> ATS is broken on this hardware (at least for Stoney Ridge >>> based laptop) and causes IOMMU stalls and >>> system failure. Disable ATS on these devices to make them >>> usable again with IOMMU enabled >>> Thanks to Joerg Roedel for help. >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=194521 >>> >>> Signed-off-by: Nikolai Kostrigin >> Joerg, I'm happy to merge this if you would review or ack it. I don't >> know enough to conclude that this is the root cause It'd be nice to >> have an actual AMD erratum. Maybe it would even have a list of >> affected devices so we could get them all at once so people wouldn't >> have to trip over them one by one. >> >>> --- >>> drivers/pci/quirks.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >>> index 4700d24e5d55..abb2532e16bf 100644 >>> --- a/drivers/pci/quirks.c >>> +++ b/drivers/pci/quirks.c >>> @@ -4876,6 +4876,7 @@ static void quirk_no_ats(struct pci_dev *pdev) >>> >>> /* AMD Stoney platform GPU */ >>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats); >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6900, quirk_no_ats); >>> #endif /* CONFIG_PCI_ATS */ >>> >>> /* Freescale PCIe doesn't support MSI in RC mode */ >>> -- >>> 2.21.0 >>> > > -- > Best regards, > Nikolai Kostrigin -- Best regards, Nikolai Kostrigin
[PATCH RESEND 0/1] PCI: Add ATS-disable quirk for AMD Radeon R7 GPUs
This solves system hang and file system corruption for Stoney Ridge systems (with built-in Radeon R4/R5 + discreet AMD Radeon R7 GPU) Such system example: HP laptop 17-ak041ur (more HW info at https://bugzilla.kernel.org/show_bug.cgi?id=194521) Nikolai Kostrigin (1): PCI: Add ATS-disable quirk for AMD Radeon R7 GPUs drivers/pci/quirks.c | 1 + 1 file changed, 1 insertion(+) -- 2.21.0
[PATCH RESEND 1/1] PCI: Add ATS-disable quirk for AMD Radeon R7 GPUs
ATS is broken on this hardware (at least for Stoney Ridge based laptop) and causes IOMMU stalls and system failure. Disable ATS on these devices to make them usable again with IOMMU enabled Thanks to Joerg Roedel for help. https://bugzilla.kernel.org/show_bug.cgi?id=194521 Signed-off-by: Nikolai Kostrigin --- drivers/pci/quirks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 4700d24e5d55..abb2532e16bf 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4876,6 +4876,7 @@ static void quirk_no_ats(struct pci_dev *pdev) /* AMD Stoney platform GPU */ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x98e4, quirk_no_ats); +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6900, quirk_no_ats); #endif /* CONFIG_PCI_ATS */ /* Freescale PCIe doesn't support MSI in RC mode */ -- 2.21.0
