On Fri, Aug 21, 2020 at 09:21:37AM +, Robin Gong wrote:
> On 2020/08/21 12:34 Richard Leitner wrote:
> > On Thu, Aug 20, 2020 at 03:01:44PM +, Robin Gong wrote:
> > > On 2020/08/19 22:26 Benjamin Bara - SKIDATA
> > wrote:
> > > >
> > > > @
On Thu, Aug 20, 2020 at 03:01:44PM +, Robin Gong wrote:
> On 2020/08/19 22:26 Benjamin Bara - SKIDATA
> wrote:
> >
> > @Robin:
> > Is it possible to tag the commits for the stable-tree
> > Cc: sta...@vger.kernel.org?
> Could my patch work in your side? If yes, I will add
> Cc:
On Mon, Jul 27, 2020 at 10:33:29AM +0200, Christian Eggers wrote:
> On Sonday, greg k-h wrote:
> > Please resend the whole series, not just a single patch, as it makes it
> > very difficult to pick the "correct" patches to be applied...
Hi Christian,
sorry for the late reply. My MUA somehow
On Fri, Aug 14, 2020 at 11:18:10AM +0200, Robin Gong wrote:
>
> On 2020/08/13 19:23: Richard Leitner wrote:
> > Hi,
> > we've found a race condition with the PCM on the i.MX6 which results
> > in an -EIO for the SNDRV_PCM_IOCTL_READI_FRAMES ioctl after an -EPIPE
> &g
r to this patch.
As you suggested I've tested the two patches on my custom i.MX6DL
board. Therefore please feel free to add:
Tested-by: Richard Leitner
regards;rl
> ---
> drivers/dma/imx-sdma.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/dm
r to this patch.
As you suggested I've tested the two patches on my custom i.MX6DL
board. Therefore please feel free to add:
Tested-by: Richard Leitner
regards;rl
> ---
> drivers/dma/imx-sdma.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/dma/imx-s
he current v5.4.y LTS branch,
but it also affects v5.8.y.
Any feedback or pointers how we may fix the problem are warmly welcome!
If anything is unclear please just ask :-)
regards;
Richard Leitner
Benjamin Bara
[1]https://elixir.bootlin.com/linux/v5.8/source/drivers/dma/imx-sdma.c#L1066
[2]htt
On 17/10/2019 01:23, Greg Kroah-Hartman wrote:
On Wed, Oct 16, 2019 at 11:35:18PM +0100, Mark Brown wrote:
On Wed, Oct 16, 2019 at 03:10:25PM -0700, Greg Kroah-Hartman wrote:
On Wed, Oct 16, 2019 at 11:00:44PM +0100, Mark Brown wrote:
On Wed, Oct 16, 2019 at 02:51:44PM -0700, Greg
y: Oleksandr Suvorov
Reviewed-by: Marcel Ziswiler
Reviewed-by: Igor Opaniuk
Reviewed-by: Fabio Estevam
Link:
https://lore.kernel.org/r/20190719100524.23300-5-oleksandr.suvo...@toradex.com
Signed-off-by: Mark Brown
Signed-off-by: Richard Leitner
Fixes: e9f621efaebd ("ASoC: sgtl5000: Fix o
To be consistent change the S35390A_FLAG defines to use the BIT
macro (like the S35390A_INT2_MODE defines).
Signed-off-by: Richard Leitner
---
drivers/rtc/rtc-s35390a.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc
Alarms are only supported on a per minute basis. This is why
uie_unsupported is set. Furthermore issue a warning when a second based
alarm is requested.
Signed-off-by: Richard Leitner
---
drivers/rtc/rtc-s35390a.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/rtc/rtc
in "clarify INT2 pin output modes"
- add "change FLAG defines to use BIT macro"
Richard Leitner (4):
rtc: s35390a: clarify INT2 pin output modes
rtc: s35390a: set uie_unsupported
rtc: s35390a: introduce struct device in probe
rtc: s35390a: change FLAG defines to use
To simplify access and shorten code introduce a struct device pointer in
the s35390a probe function.
Signed-off-by: Richard Leitner
---
drivers/rtc/rtc-s35390a.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc
rent
modes in the comments.
Signed-off-by: Richard Leitner
---
drivers/rtc/rtc-s35390a.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index 3c64dbb08109..fb795c454077 100644
--- a/drivers/rtc/rtc-s3539
On 21/05/2019 17:54, Alexandre Belloni wrote:
Hello,
This seems good to me but...
On 21/05/2019 16:20:22+0200, Richard Leitner wrote:
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -45,12 +45,13 @@
/* flag for STATUS2 */
#define S35390A_FLAG_TEST 0x01
-#define
Alarms are only supported on a per minute basis. This is why
uie_unsupported is set. Furthermore issue a warning when a second based
alarm is requested.
Signed-off-by: Richard Leitner
---
drivers/rtc/rtc-s35390a.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/rtc/rtc
To simplify access and shorten code introduce a struct device pointer in
the s35390a probe function.
Signed-off-by: Richard Leitner
---
drivers/rtc/rtc-s35390a.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc
As the s35390a does only support per-minute based alarms we have to
set the uie_unsupported flag. Otherwise it delays for 10sec and
fails afterwards with modern hwclock versions.
Furthermore some other minor changes are made.
All patches were tested on an i.MX6 platform.
Richard Leitner (3
Fix the INT2 mode mask to not include the "TEST" flag. Furthermore
remove the not needed reversion of bits when parsing the INT2 modes.
Instead reverse the INT2_MODE defines.
Additionally mention the flag names from the datasheet for the different
modes in the comments.
Signed-off-b
Hi Joe,
On 29/01/2019 06:40, Joe Perches wrote:
On Mon, 2019-01-28 at 16:25 -0800, Dmitry Torokhov wrote:
On Tue, Dec 18, 2018 at 09:40:02AM +0100, Richard Leitner wrote:
Some of the #defined register values are one-bit flags. Convert them to
use the BIT(x) macro instead of 1 byte hexadecimal
ll come back to it in XXX"...
But please give at least some kind of response... Thanks!
regards;Richard.L
On 18/12/2018 09:35, Richard Leitner wrote:
Add reset-gpio, sx8654[056] and common of_touchscreen functions support
for the sx8654 driver.
Changes RESEND v2:
- added "Revie
of_touchscreen.c provides a common interface for a axis invertion and
swapping of touchscreens. Therefore use it in the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 193 +
1 file changed, 173 insertions(+), 20 deletions(-)
diff --git a/drivers
Some of the #defined register values are one-bit flags. Convert them to
use the BIT(x) macro instead of 1 byte hexadecimal values. This improves
readability and clarifies the intent.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 11 ++-
1 file changed, 6
As the sx8650 is quite similar to the sx8654 support for it will be
added in the driver. Therefore add it to the compatibles.
Signed-off-by: Richard Leitner
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 1 +
1 file changed, 1 insertion(+)
diff
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.
If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: Richard Leitner
---
drivers/input
Document the reset-gpio property for the sx8654 touchscreen controller
driver.
Signed-off-by: Richard Leitner
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings
ags to BIT() in a separate patch
- replace hrtimer with "regular" timer
- use of_device_get_match_data instead of of_match_device
- add driver data to i2c_device_id table for non-DT fallback
- fix sequence of common touchscreen initialization
- div. minor st
Hi,
another friendly reminder for this patchset...
Any comments/objections?
regards;Richard.L
On 17.10.18 14:51, Richard Leitner wrote:
> Add reset-gpio, sx8654[056] and common of_touchscreen functions support
> for the sx8654 driver.
>
> Changes v2:
> - use devm_gpi
Hi,
another friendly reminder for this patchset...
Any comments/objections?
regards;Richard.L
On 17.10.18 14:51, Richard Leitner wrote:
> Add reset-gpio, sx8654[056] and common of_touchscreen functions support
> for the sx8654 driver.
>
> Changes v2:
> - use devm_gpi
Hi,
friendly question for the status of this patchset of mine.
thanksRichard.L
On 10/17/18 2:51 PM, Richard Leitner wrote:
Add reset-gpio, sx8654[056] and common of_touchscreen functions support
for the sx8654 driver.
Changes v2:
- use devm_gpiod_get_optional in probe instead
Hi,
friendly question for the status of this patchset of mine.
thanksRichard.L
On 10/17/18 2:51 PM, Richard Leitner wrote:
Add reset-gpio, sx8654[056] and common of_touchscreen functions support
for the sx8654 driver.
Changes v2:
- use devm_gpiod_get_optional in probe instead
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
Document the reset-gpio property for the sx8654 touchscreen controller
driver.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
Document the reset-gpio property for the sx8654 touchscreen controller
driver.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.
If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: Richard Leitner
---
drivers/input
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.
If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: Richard Leitner
---
drivers/input
uot; timer
- use of_device_get_match_data instead of of_match_device
- add driver data to i2c_device_id table for non-DT fallback
- fix sequence of common touchscreen initialization
- div. minor stlye changes
Richard Leitner (8):
dt-bindings: input: touchscreen: sx8654: add
uot; timer
- use of_device_get_match_data instead of of_match_device
- add driver data to i2c_device_id table for non-DT fallback
- fix sequence of common touchscreen initialization
- div. minor stlye changes
Richard Leitner (8):
dt-bindings: input: touchscreen: sx8654: add
of_touchscreen.c provides a common interface for a axis invertion and
swapping of touchscreens. Therefore use it in the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers
of_touchscreen.c provides a common interface for a axis invertion and
swapping of touchscreens. Therefore use it in the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers
Some of the #defined register values are one-bit flags. Convert them to
use the BIT(x) macro instead of 1 byte hexadecimal values. This improves
readability and clarifies the intent.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 11 ++-
1 file changed, 6
Some of the #defined register values are one-bit flags. Convert them to
use the BIT(x) macro instead of 1 byte hexadecimal values. This improves
readability and clarifies the intent.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 11 ++-
1 file changed, 6
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 193 +
1 file changed, 173 insertions(+), 20 deletions(-)
diff --git a/drivers
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 193 +
1 file changed, 173 insertions(+), 20 deletions(-)
diff --git a/drivers
As the sx8650 is quite similar to the sx8654 support for it will be
added in the driver. Therefore add it to the compatibles.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation
As the sx8650 is quite similar to the sx8654 support for it will be
added in the driver. Therefore add it to the compatibles.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation
On 10/16/18 7:48 PM, Dmitry Torokhov wrote:
On Tue, Oct 16, 2018 at 11:22:48AM +0200, Richard Leitner wrote:
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
...
/* bits for I2C_REG_CHANMASK */
-#define CONV_X
On 10/16/18 7:48 PM, Dmitry Torokhov wrote:
On Tue, Oct 16, 2018 at 11:22:48AM +0200, Richard Leitner wrote:
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
...
/* bits for I2C_REG_CHANMASK */
-#define CONV_X
Hi Dimitry,
thanks for the quick reply!
On 10/16/18 7:39 PM, Dmitry Torokhov wrote:
Hi Richard,
On Tue, Oct 16, 2018 at 11:16:48AM +0200, Richard Leitner wrote:
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST
Hi Dimitry,
thanks for the quick reply!
On 10/16/18 7:39 PM, Dmitry Torokhov wrote:
Hi Richard,
On Tue, Oct 16, 2018 at 11:16:48AM +0200, Richard Leitner wrote:
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
Document the reset-gpio property for the sx8654 touchscreen controller
driver.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
Add reset-gpio, sx8654[056] and common of_touchscreen functions support
for the sx8654 driver.
Richard Leitner (7):
dt-bindings: input: touchscreen: sx8654: add reset-gpio property
Input: sx8654 - add reset-gpio support
dt-bindings: input: touchscreen: sx8654: add compatible models
Input
Add reset-gpio, sx8654[056] and common of_touchscreen functions support
for the sx8654 driver.
Richard Leitner (7):
dt-bindings: input: touchscreen: sx8654: add reset-gpio property
Input: sx8654 - add reset-gpio support
dt-bindings: input: touchscreen: sx8654: add compatible models
Input
Document the reset-gpio property for the sx8654 touchscreen controller
driver.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.
If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: Richard Leitner
---
drivers/input
As the sx865[456] share the same datasheet and differ only in the
presence of a "capacitive proximity detection circuit" and a "haptics
motor driver for LRA/ERM" add them to the compatbiles. As the driver
doesn't implement these features it should be no problem.
Signed-off
The sx8654 features a NRST input which may be connected to a GPIO.
Therefore add support for hard-resetting the sx8654 via this NRST.
If the reset-gpio property is provided the sx8654 is resetted via NRST
instead of the soft-reset via I2C.
Signed-off-by: Richard Leitner
---
drivers/input
of_touchscreen.c provides a common interface for a axis invertion and
swapping of touchscreens. Therefore use it in the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions
of_touchscreen.c provides a common interface for a axis invertion and
swapping of touchscreens. Therefore use it in the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 186 -
1 file changed, 163 insertions(+), 23 deletions(-)
diff --git a/drivers
The sx8654 and sx8650 are quite similar, therefore add support for the
sx8650 within the sx8654 driver.
Signed-off-by: Richard Leitner
---
drivers/input/touchscreen/sx8654.c | 186 -
1 file changed, 163 insertions(+), 23 deletions(-)
diff --git a/drivers
As the sx8650 is quite similar to the sx8654 support for it will be
added in the driver. Therefore add it to the compatibles.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation
As the sx8650 is quite similar to the sx8654 support for it will be
added in the driver. Therefore add it to the compatibles.
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation
From: Richard Leitner <richard.leit...@skidata.com>
For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant.
In our case we have a series of USB hardware (using the cp210x driver)
which communicates using a proprietary pr
From: Richard Leitner
For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant.
In our case we have a series of USB hardware (using the cp210x driver)
which communicates using a proprietary protocol. These devices sometimes
On 03/15/2018 10:26 AM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 16:44 +0100 schrieb Richard Leitner:
>> On 03/14/2018 04:27 PM, Oliver Neukum wrote:
>>> Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:
>>>>
>>> Well, but it do
On 03/15/2018 10:26 AM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 16:44 +0100 schrieb Richard Leitner:
>> On 03/14/2018 04:27 PM, Oliver Neukum wrote:
>>> Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:
>>>>
>>> Well, but it do
On 03/14/2018 04:27 PM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:
>> Hi Oliver,
>> thank you for your feedback!
>>
>> On 03/14/2018 01:17 PM, Oliver Neukum wrote:
>>> Am Mittwoch, den 14.03.2018, 11:29 +010
On 03/14/2018 04:27 PM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:
>> Hi Oliver,
>> thank you for your feedback!
>>
>> On 03/14/2018 01:17 PM, Oliver Neukum wrote:
>>> Am Mittwoch, den 14.03.2018, 11:29 +010
Hi Oliver,
thank you for your feedback!
On 03/14/2018 01:17 PM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner:
>> From: Richard Leitner <richard.leit...@skidata.com>
>>
>> Replace the hardcoded PCI vendor ID of Netlogic with a
Hi Oliver,
thank you for your feedback!
On 03/14/2018 01:17 PM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 11:29 +0100 schrieb Richard Leitner:
>> From: Richard Leitner
>>
>> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
>> pci_ids.h
&g
On 03/14/2018 11:48 AM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:29:32AM +0100, Richard Leitner wrote:
>> From: Richard Leitner <richard.leit...@skidata.com>
>>
>> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
>> pci_ids.h
>
> Why
On 03/14/2018 11:48 AM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:29:32AM +0100, Richard Leitner wrote:
>> From: Richard Leitner
>>
>> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
>> pci_ids.h
>
> Why? It's only bei
On 03/14/2018 11:49 AM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:29:33AM +0100, Richard Leitner wrote:
>> From: Richard Leitner <richard.leit...@skidata.com>
>>
>> Introduce Renesas uPD72020{1,2} PCI device IDs in pci_ids.h and replace
>> the harcoded v
On 03/14/2018 11:49 AM, Greg KH wrote:
> On Wed, Mar 14, 2018 at 11:29:33AM +0100, Richard Leitner wrote:
>> From: Richard Leitner
>>
>> Introduce Renesas uPD72020{1,2} PCI device IDs in pci_ids.h and replace
>> the harcoded values with them.
>>
From: Richard Leitner <richard.leit...@skidata.com>
Instead of the hardcoded hexadecimal PCI IDs use the existing macros
from pci_ids.h for Intel IDs.
Signed-off-by: Richard Leitner <richard.leit...@skidata.com>
---
drivers/usb/host/pci-quirks.c | 10 +-
drivers/usb/hos
From: Richard Leitner
Instead of the hardcoded hexadecimal PCI IDs use the existing macros
from pci_ids.h for Intel IDs.
Signed-off-by: Richard Leitner
---
drivers/usb/host/pci-quirks.c | 10 +-
drivers/usb/host/xhci-pci.c | 3 ++-
include/linux/pci_ids.h | 1 +
3 files
From: Richard Leitner <richard.leit...@skidata.com>
Centralize some hardcoded PCI IDs as definitions in the global
include/linux/pci_ids.h file. This is done to reduce the amount of
scattered PCI ID definitions and hardcoded values across the kernel.
Richard Leitner (3):
usb: host: pc
From: Richard Leitner
Centralize some hardcoded PCI IDs as definitions in the global
include/linux/pci_ids.h file. This is done to reduce the amount of
scattered PCI ID definitions and hardcoded values across the kernel.
Richard Leitner (3):
usb: host: pci: use existing Intel PCI ID macros
From: Richard Leitner <richard.leit...@skidata.com>
Replace the hardcoded PCI vendor ID of Netlogic with a definition in
pci_ids.h
Signed-off-by: Richard Leitner <richard.leit...@skidata.com>
---
drivers/usb/host/pci-quirks.c | 2 +-
include/linux/pci_ids.h | 2 ++
2 file
From: Richard Leitner <richard.leit...@skidata.com>
Introduce Renesas uPD72020{1,2} PCI device IDs in pci_ids.h and replace
the harcoded values with them.
Signed-off-by: Richard Leitner <richard.leit...@skidata.com>
---
drivers/usb/host/pci-quirks.c | 6 --
drivers/usb/host/xhci
From: Richard Leitner
Replace the hardcoded PCI vendor ID of Netlogic with a definition in
pci_ids.h
Signed-off-by: Richard Leitner
---
drivers/usb/host/pci-quirks.c | 2 +-
include/linux/pci_ids.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host
From: Richard Leitner
Introduce Renesas uPD72020{1,2} PCI device IDs in pci_ids.h and replace
the harcoded values with them.
Signed-off-by: Richard Leitner
---
drivers/usb/host/pci-quirks.c | 6 --
drivers/usb/host/xhci-pci.c | 4 ++--
include/linux/pci_ids.h | 2 ++
3 files
From: Richard Leitner <richard.leit...@skidata.com>
For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant.
In our case we have a series of USB hardware (using the cp210x driver)
which communicates using a proprietary pr
From: Richard Leitner
For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant.
In our case we have a series of USB hardware (using the cp210x driver)
which communicates using a proprietary protocol. These devices sometimes
+What: /sys/bus/usb/devices/.../(hub
>> interface)/portX/over_current_count
>> +Date: February 2018
>> +Contact:Richard Leitner <richard.leit...@skidata.com>
>> +Description:
>> +Most hubs are able to detect over-current situati
+What: /sys/bus/usb/devices/.../(hub
>> interface)/portX/over_current_count
>> +Date: February 2018
>> +Contact:Richard Leitner
>> +Description:
>> +Most hubs are able to detect over-current situations on their
>> +ports and
On 02/20/2018 12:55 PM, Felipe Balbi wrote:
>
> Hi,
>
> Richard Leitner <d...@g0hl1n.net> writes:
>> From: Richard Leitner <richard.leit...@skidata.com>
>>
>> For some userspace applications information on the number of
>> over-current
On 02/20/2018 12:55 PM, Felipe Balbi wrote:
>
> Hi,
>
> Richard Leitner writes:
>> From: Richard Leitner
>>
>> For some userspace applications information on the number of
>> over-current conditions at specific USB hub ports is relevant.
>>
>&
From: Richard Leitner <richard.leit...@skidata.com>
For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant.
In our case we have a series of USB hardware (using the cp210x driver)
which communicates using a proprietary pr
From: Richard Leitner
For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant.
In our case we have a series of USB hardware (using the cp210x driver)
which communicates using a proprietary protocol. These devices sometimes
1 - 100 of 382 matches
Mail list logo
