Hi Pavel,
Thank you very much for pointing out the issues.
I redesign all the code deeply, as Alexandre Belloni suggested [1], and
the lines you have mentioned are to be fixed too.
Unfortunately, it takes more time than I supposed.
Thank you again!
--
Best Regards,
Kirill Kapranov
Software
Hi Dan,
Thank you very much for pointing out the issues.
However, I'm not sure that the code, you have analyzed, will be a part
of final patch set. I intend to redesign all the code deeply, as
Alexandre Belloni suggested [1].
Thank you again!
--
Best Regards,
Kirill Kapranov
Software
for usage of this feature.
TIA!
Kirill
Kirill Kapranov (4):
dt-bindings: rtc: abracon,abx80x: Add sqw property
rtc:abx80x: Enable SQW output
dt-bindings: rtc: abracon,abx80x: Add xt-frequency property
rtc:abx80x: Enable xt digital calibration
.../devicetree/bindings/rtc/abracon,abx80x.txt | 25
The XT digital calibration feature allows to improve the RTC accuracy,
using a Distributed Digital Calibration function.
See ch. 5.9.1 of AB08XX Series Ultra Low Power RTC IC User's Guide
https://abracon.com/realtimeclock/AB08XX-Application-Manual.pdf
Signed-off-by: Kirill Kapranov
---
drivers
pplication-Manual.pdf
Signed-off-by: Kirill Kapranov
---
Documentation/devicetree/bindings/rtc/abracon,abx80x.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt
b/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt
index 4c
Introduce the string property "sqw" to control Square Wave Output register.
This enables pulse generation output, that is useful for xtal calibration
or for an external usage.
Signed-off-by: Kirill Kapranov
---
Documentation/devicetree/bindings/rtc/abracon,abx80x.txt | 12 ++
The RTCs of the family are able to produce square wave output for RTC
calibration purposes or for an external usage.
Signed-off-by: Kirill Kapranov
---
drivers/rtc/rtc-abx80x.c | 126 +++
1 file changed, 126 insertions(+)
diff --git a/drivers/rtc/rtc
ote:
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Kirill Kapranov
commit 1a4327fbf4554d5b78d75b19a13d40d6de220159 upstream.
On systems where some controllers get a dynamic ID assigned and some have
a fixed number (e.g. from ACPI tables), t
ote:
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Kirill Kapranov
commit 1a4327fbf4554d5b78d75b19a13d40d6de220159 upstream.
On systems where some controllers get a dynamic ID assigned and some have
a fixed number (e.g. from ACPI tables), t
On 08/14/2018 05:18 PM, Mark Brown wrote:
> Is this something that's actually happened for you?
Yes, I observed it.
Background:
The platform: fitlet2 [1] , CPU Intel(R) Celeron(R) CPU J3455 @ 1.50GHz.
On an extension board there are three SPI master controllers "Intel
Corporation
On 08/14/2018 05:18 PM, Mark Brown wrote:
> Is this something that's actually happened for you?
Yes, I observed it.
Background:
The platform: fitlet2 [1] , CPU Intel(R) Celeron(R) CPU J3455 @ 1.50GHz.
On an extension board there are three SPI master controllers "Intel
Corporation
gets the same ID and predictably fails.
Fix this by means of checking-in fixed IDsin IDR as far as dynamic ones
at the moment of the controller registration.
Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
Signed-off-by: Kirill Kapranov
---
drivers/spi/spi.c | 9
gets the same ID and predictably fails.
Fix this by means of checking-in fixed IDsin IDR as far as dynamic ones
at the moment of the controller registration.
Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias)
Signed-off-by: Kirill Kapranov
---
drivers/spi/spi.c | 9
Fri, 29/03/2013 14:38 -0400, David Miller пишет:
> Why are you posting this again? I've applied your patch 3 days
> ago.
oops...
The last letter I sent was a coding style correction -- removing
trailing whitespace in response to remark of Tue, 26 Mar 2013 12:59:13
-0400 (EDT) by David Miller:
Fri, 29/03/2013 14:38 -0400, David Miller пишет:
Why are you posting this again? I've applied your patch 3 days
ago.
oops...
The last letter I sent was a coding style correction -- removing
trailing whitespace in response to remark of Tue, 26 Mar 2013 12:59:13
-0400 (EDT) by David Miller:
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so further cable hook-up leads to nonoperable link
state.
Signed-off-by: Kirill Kapranov
---
drivers/net/phy
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so further cable hook-up leads to nonoperable link
state.
Signed-off-by: Kirill Kapranov kapran...@inbox.ru
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so further cable hook-up leads to nonoperable link
state.
Signed-off-by: Kirill Kapranov
---
drivers/net/phy
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so further cable hook-up leads to nonoperable link
state.
Signed-off-by: Kirill Kapranov kapran...@inbox.ru
Does the absence of criticism mean that this patch is ready for
upstream?
Maybe I shall write more verbose explanation additionally?
--
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
Does the absence of criticism mean that this patch is ready for
upstream?
Maybe I shall write more verbose explanation additionally?
--
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
15/03/2013 08:35 -0400, David Miller wrote:
> From: Kirill Kapranov
> Date: Thu, 14 Mar 2013 14:40:52 +0400
>
> > @@ -867,7 +821,6 @@ void phy_state_machine(struct work_struct *work)
> > netif_carrier_on(phydev->attached_dev);
> &
15/03/2013 08:35 -0400, David Miller wrote:
From: Kirill Kapranov kapran...@inbox.ru
Date: Thu, 14 Mar 2013 14:40:52 +0400
@@ -867,7 +821,6 @@ void phy_state_machine(struct work_struct *work)
netif_carrier_on(phydev-attached_dev);
} else
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so further cable hook-up leads to nonoperable link
state.
Signed-off-by: Kirill Kapranov
---
drivers/net/phy
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so further cable hook-up leads to nonoperable link
state.
Signed-off-by: Kirill Kapranov kapran...@inbox.ru
>From Kirill Kapranov ,
NET/PHY: Eliminate the forced speed reduction algorithm.
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so further hooking up a ca
From Kirill Kapranov k...@nita.ru,kapran...@inbox.ru
NET/PHY: Eliminate the forced speed reduction algorithm.
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
slows down a NIC speed, so
s.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov ,
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.0 +0400
@@ -457,34 +457,6 @@ void phy_stop_machine(struct
at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov k...@nita.ru,kapran...@inbox.ru
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.0 +0400
@@ -457,34 +457,6 @@ void phy_stop_machine(struct
uot; gives
no result. AFAIK, this behaviour is not RFCs' recommended.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov ,
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.0 +0400
no result. AFAIK, this behaviour is not RFCs' recommended.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov k...@nita.ru,kapran...@inbox.ru
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49
behaviour is not RFCs' recommended.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov ,
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.0 +0400
@@ -457,34 +457,6 @@ void phy_stop_mach
is not RFCs' recommended.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov k...@nita.ru,kapran...@inbox.ru
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.0 +0400
@@ -457,34 +457,6
behaviour is not RFCs' recommended.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov ,
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.0 +0400
@@ -457,34 +457,6 @@ void phy_stop_mach
is not RFCs' recommended.
Tested at 2.6.38.7, applicable up to for 3.0.4.
Signed-off-by: Kirill Kapranov k...@nita.ru,kapran...@inbox.ru
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.0 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.0 +0400
@@ -457,34 +457,6
35 matches
Mail list logo
