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: sta...@vger.k
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 didn't
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
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/drive
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/
this issue on the 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
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 Kroah-Hart
off-by: 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:
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
no time and will 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:
- ad
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.
Signe
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.
Signe
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
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_gpiod_
Hi,
friendly question for the status of this patchset of mine.
thanks®ards;Richard.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 of
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.
Signe
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.
Signe
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
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
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
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
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.
Signe
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.
Signe
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
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
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 does
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
>>
>> 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
>>
>> Replace the hardcoded PCI vendor ID of Netlogic with a definition in
>> pci_ids.h
>
> Why? It's only being us
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
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
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
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
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
>> +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 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
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 02/19/2018 04:59 PM, Greg KH wrote:
> On Mon, Feb 19, 2018 at 01:01:07PM +0100, Richard Leitner wrote:
>> From: Richard Leitner
>>
>> For some userspace applications information on the number of
>> over-current conditions at specific USB hub ports is relevan
Hi,
On 02/19/2018 02:53 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. Therefo
From: Richard Leitner
For some userspace applications information on the number of
over-current conditions at specific USB hub ports is relevant. Therefore
introduce a oc_counter in the usb port struct which is exported via
sysfs.
Signed-off-by: Richard Leitner
---
Tested on an i.MX6DL based
From: Richard Leitner
As suggested by Rob Herring [1] rename the previously introduced
reset-{,post-}delay-us bindings to the clearer reset-{,de}assert-us
[1] https://patchwork.kernel.org/patch/10104905/
Signed-off-by: Richard Leitner
---
Documentation/devicetree/bindings/net/phy.txt | 8
Hi Rob,
On 12/15/2017 11:17 PM, Rob Herring wrote:
> On Mon, Dec 11, 2017 at 01:16:57PM +0100, Richard Leitner wrote:
>> From: Richard Leitner
>>
>> Some PHYs need a minimum time after the reset gpio was asserted and/or
>> deasserted. To ensure we meet these timi
From: Richard Leitner
Some PHYs need the refclk to be a continuous clock. Therefore they don't
allow turning it off and on again during operation. Nonetheless such a
clock switching is performed by some ETH drivers (namely FEC [1]) for
power saving reasons. An example for an affected PHY i
From: Richard Leitner
This patch series fixes the use of the SMSC LAN8710/20 with a Freescale ETH
when the refclk is generated by the FSL.
This patchset depends on the "phylib: Add device reset GPIO support" patch
submitted by Geert Uytterhoeven/Sergei Shtylyov, which was merged to
n
From: Richard Leitner
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: op
From: Richard Leitner
The Microchip/SMSC LAN8710/LAN8720 PHYs need (according to their
datasheet [1]) a continuous REF_CLK when configured to "REF_CLK In Mode".
Therefore set the PHY_RST_AFTER_CLK_EN flag for those PHYs to let the
ETH driver reset them after the REF_CLK is enabled.
From: Richard Leitner
Some PHYs need a minimum time after the reset gpio was asserted and/or
deasserted. To ensure we meet these timing requirements add two new
optional devicetree parameters for the phy: reset-delay-us and
reset-post-delay-us.
Signed-off-by: Richard Leitner
Reviewed-by: Geert
Hi Geert,
On 12/07/2017 03:52 PM, Geert Uytterhoeven wrote:
> Hi Richard,
>
> On Thu, Dec 7, 2017 at 3:43 PM, Richard Leitner wrote:
>> --- a/drivers/net/phy/mdio_device.c
>> +++ b/drivers/net/phy/mdio_device.c
>> @@ -24,6 +24,7 @@
>> #include
>>
From: Richard Leitner
The Microchip/SMSC LAN8710/LAN8720 PHYs need (according to their
datasheet [1]) a continuous REF_CLK when configured to "REF_CLK In Mode".
Therefore set the PHY_RST_AFTER_CLK_EN flag for those PHYs to let the
ETH driver reset them after the REF_CLK is enabled.
From: Richard Leitner
This patch series fixes the use of the SMSC LAN8710/20 with a Freescale ETH
when the refclk is generated by the FSL.
This patchset depends on the "phylib: Add device reset GPIO support" patch
submitted by Geert Uytterhoeven/Sergei Shtylyov, which was merged to
n
From: Richard Leitner
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: op
From: Richard Leitner
Some PHYs need the refclk to be a continuous clock. Therefore they don't
allow turning it off and on again during operation. Nonetheless such a
clock switching is performed by some ETH drivers (namely FEC [1]) for
power saving reasons. An example for an affected PHY i
From: Richard Leitner
Some PHYs need a minimum time after the reset gpio was asserted and/or
deasserted. To ensure we meet these timing requirements add two new
optional devicetree parameters for the phy: reset-delay-us and
reset-post-delay-us.
Signed-off-by: Richard Leitner
Reviewed-by: Geert
Hi Andy,
On 12/06/2017 02:50 AM, Andy Duan wrote:
> From: Richard Leitner Sent: Tuesday, December 05, 2017 9:26
> PM
>> Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
>> the refclk on and off again during operation (according to their datasheet).
Hi Andrew,
On 12/05/2017 06:34 PM, Andrew Lunn wrote:
On Tue, Dec 05, 2017 at 02:25:58PM +0100, Richard Leitner wrote:
From: Richard Leitner
Some PHYs need the refclk to be a continuous clock. Therefore they don't
allow turning it off and on again during operation. Nonetheless such a
Hi Andrew,
On 12/05/2017 06:28 PM, Andrew Lunn wrote:
Hi Richard
+++ b/drivers/of/of_mdio.c
@@ -77,6 +77,14 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
if (of_property_read_bool(child, "broken-turn-around"))
mdio->phy_ignore_ta_mask |= 1 << addr;
+ if
Hi Geert,
On 12/05/2017 02:54 PM, Geert Uytterhoeven wrote:
> Hi Richard,
>
> On Tue, Dec 5, 2017 at 2:25 PM, Richard Leitner wrote:
>> From: Richard Leitner
>>
>> Some PHYs need a minimum time after the reset gpio was asserted and/or
>> deasserted. To ensure
From: Richard Leitner
This patch series fixes the use of the SMSC LAN8710/20 with a Freescale ETH
when the refclk is generated by the FSL.
This patch depends on the "phylib: Add device reset GPIO support" patch
submitted by Geert Uytterhoeven/Sergei Shtylyov, see:
From: Richard Leitner
Some PHYs need the refclk to be a continuous clock. Therefore they don't
allow turning it off and on again during operation. Nonetheless such a
clock switching is performed by some ETH drivers (namely FEC [1]) for
power saving reasons. An example for an affected PHY i
From: Richard Leitner
Some PHYs need a minimum time after the reset gpio was asserted and/or
deasserted. To ensure we meet these timing requirements add two new
optional devicetree parameters for the phy: reset-delay-us and
reset-post-delay-us.
This patch depends on the "phylib: Add d
From: Richard Leitner
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: op
From: Richard Leitner
The Microchip/SMSC LAN8710/LAN8720 PHYs need (according to their
datasheet [1]) a continuous REF_CLK when configured to "REF_CLK In Mode".
Therefore set the PHY_RST_AFTER_CLK_EN flag for those PHYs to let the
ETH driver reset them after the REF_CLK is enabled.
ng initial setup]
> [geert: Consolidate GPIO descriptor acquiring code]
> Signed-off-by: Geert Uytterhoeven
> ---
Successfully tested this patch on a i.MX6SOLO based board containing a
LAN8710 PHY:
Tested-by: Richard Leitner
On 11/27/2017 02:50 PM, Andrew Lunn wrote:
> On Mon, Nov 27, 2017 at 08:16:45AM +0100, Richard Leitner wrote:
>> From: Richard Leitner
>>
>> Previously phy_id was u32 and phy_id_mask was unsigned int. As the
>> phy_id_mask defines the important bits of the phy_id (a
From: Richard Leitner
Previously phy_id was u32 and phy_id_mask was unsigned int. As the
phy_id_mask defines the important bits of the phy_id (and is therefore
the same size) these two variables should be the same data type.
Signed-off-by: Richard Leitner
Reviewed-by: Florian Fainelli
From: Richard Leitner
Previously phy_id was u32 and phy_id_mask was unsigned int. As the
phy_id_mask defines the important bits of the phy_id (and is therefore
the same size) these two variables should be the same data type.
Signed-off-by: Richard Leitner
---
This patch is extracted from the
On 11/20/2017 02:13 PM, Geert Uytterhoeven wrote:
> Hi Richard,
>
> On Mon, Nov 20, 2017 at 1:55 PM, Richard Leitner
> wrote:
>> On 11/20/2017 11:35 AM, Andy Duan wrote:
>>> 3. add reset gpio descriptor for common phy device driver.
>>
>> ... if I understo
On 11/20/2017 11:35 AM, Andy Duan wrote:
> From: Richard Leitner Sent: Monday, November
> 20, 2017 5:57 PM
>> To: Andy Duan ; f.faine...@gmail.com;
>> and...@lunn.ch
>> Cc: Richard Leitner ; net...@vger.kernel.org; linux-
>> ker...@vger.kernel.org
>> Subje
On 11/20/2017 10:47 AM, Andy Duan wrote:
> From: Richard Leitner Sent: Monday, November 20, 2017 4:34
> PM
>> To: f.faine...@gmail.com; Andy Duan ;
>> and...@lunn.ch
>> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> richard.leit...@skidata.com
From: Richard Leitner
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: op
From: Richard Leitner
The fec_reset_phy function allowed only one execution during probeing.
To make it more usable move the dt parsing and gpio allocation to the
probe function. The parameters of the phy reset are added to the
fec_enet_private struct. As a result the fec_reset_phy function may
From: Richard Leitner
Previously phy_id was u32 and phy_id_mask was unsigned int. As the
phy_id_mask defines the important bits of the phy_id (and is therefore the
same size) these two variables should be the same datatype.
Signed-off-by: Richard Leitner
---
include/linux/phy.h | 2 +-
1 file
1 - 100 of 206 matches
Mail list logo
