> Still, you're right that adding the GET_TIME check wouldn't hurt... at
> worst it just does nothing. I'll try it out.
Hmm... so it basically works (when you hack the RTC read out of the
firmware), but only on reboot for some reason (which makes it way less
useful). After a full power off I'm
point), we
read out the (adjusted) alarm time beforehand and write it (newly
adjusted) back afterwards. This way, system time and alarm time will
always stay on the same calendar (as long as we're able to keep track
of our anchor point, at least).
Signed-off-by: Julius Werner <jwer...
Add CS polarity flag to be able to set the CS polarity
via the DT property spi-cs-high.
Signed-off-by: Andreas Werner
---
drivers/spi/spi-fsl-espi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index c27124a
Add CS polarity flag to be able to set the CS polarity
via the DT property spi-cs-high.
Signed-off-by: Andreas Werner <andreas.wer...@men.de>
---
drivers/spi/spi-fsl-espi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/s
> If you set the alarm
> for Dec 25th and it's currently Oct 31st then you'll have to adjust in
> the alarm code and you'll really set it for Dec 24th. As per above,
> we're in S3 (presumably) or have some persistent kernel state so we
> know to adjust everything when we wake up (even if we wake
> How would such a hook work? If userspace sees the system suspend on
> Nov 30th and sees the system wake up on Dec 1st, how does it know
> whether it should adjust? If it's truly Dec 1st then the kernel will
> have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec
> 2nd then the
> If a device is in S3 for the whole day that the glitch occurs and then
> we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd,
> right? That case _could_ be handled by knowing that the last time we
> read the clock it was before 12/1 and that this time it is after
> 11/30.
: exception Emask 0x50 SAct 0x0 SErr 0x800 action 0x6 frozen
t4
[ 13.359281] ata1: SError: { HostInt }
[ 13.361644] ata1: hard resetting link
Signed-off-by: Andreas Werner
---
drivers/ata/sata_fsl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/sata_fsl.c b
Some controller lockup on a ata_read_log_page.
Add new ata port flag ATA_FLAG_NO_LOG_PAGE which can used
to blacklist a controller.
If this flag is set, any attempt to read a log page returns an error
without actually issuing the command.
Signed-off-by: Andreas Werner
---
drivers/ata/libata
test robot
Andreas Werner (2):
libata-eh.c: Introduce new ata port flag for controller which lockup
on read log page
ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller
for log page reads
drivers/ata/libata-eh.c | 9 +
drivers/ata/sata_fsl.c | 3 ++-
include
Hi,
argh sorry send the wrong patches from a broken tree.
Will send a v2
Regards
Andy
--
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 http://vger.kernel.org/majordomo-info.html
Please read
: exception Emask 0x50 SAct 0x0 SErr 0x800 action 0x6 frozen
t4
[ 13.359281] ata1: SError: { HostInt }
[ 13.361644] ata1: hard resetting link
Signed-off-by: Andreas Werner
---
drivers/ata/sata_fsl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/sata_fsl.c b
Some controller lockup on a ata_read_log_page.
Add new ata port flag ATA_FLAG_NO_LOG_PAGE which can used
to blacklist a controller.
If this flag is set, any attempt to read a log page returns an error
without actually issuing the command.
Signed-off-by: Andreas Werner
---
drivers/ata/libata
.
The device failed during initialisation if the SATA device includes the
devslp feature.
With this patchset, we blacklist the fsl sata controller and return
a error on any attempt to read a log page. This allows us to access
the mSATA.
Andreas Werner (2):
libata-eh.c: Introduce new ata port flag
: exception Emask 0x50 SAct 0x0 SErr 0x800 action 0x6 frozen
t4
[ 13.359281] ata1: SError: { HostInt }
[ 13.361644] ata1: hard resetting link
Signed-off-by: Andreas Werner <andreas.wer...@men.de>
---
drivers/ata/sata_fsl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Some controller lockup on a ata_read_log_page.
Add new ata port flag ATA_FLAG_NO_LOG_PAGE which can used
to blacklist a controller.
If this flag is set, any attempt to read a log page returns an error
without actually issuing the command.
Signed-off-by: Andreas Werner <andreas.wer...@men
.
The device failed during initialisation if the SATA device includes the
devslp feature.
With this patchset, we blacklist the fsl sata controller and return
a error on any attempt to read a log page. This allows us to access
the mSATA.
Andreas Werner (2):
libata-eh.c: Introduce new ata port flag
: exception Emask 0x50 SAct 0x0 SErr 0x800 action 0x6 frozen
t4
[ 13.359281] ata1: SError: { HostInt }
[ 13.361644] ata1: hard resetting link
Signed-off-by: Andreas Werner <andreas.wer...@men.de>
---
drivers/ata/sata_fsl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Some controller lockup on a ata_read_log_page.
Add new ata port flag ATA_FLAG_NO_LOG_PAGE which can used
to blacklist a controller.
If this flag is set, any attempt to read a log page returns an error
without actually issuing the command.
Signed-off-by: Andreas Werner <andreas.wer...@men
test robot
Andreas Werner (2):
libata-eh.c: Introduce new ata port flag for controller which lockup
on read log page
ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller
for log page reads
drivers/ata/libata-eh.c | 9 +
drivers/ata/sata_fsl.c | 3 ++-
include
Hi,
argh sorry send the wrong patches from a broken tree.
Will send a v2
Regards
Andy
--
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 http://vger.kernel.org/majordomo-info.html
Please read
> If a device is in S3 for the whole day that the glitch occurs and then
> we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd,
> right? That case _could_ be handled by knowing that the last time we
> read the clock it was before 12/1 and that this time it is after
> 11/30.
> How would such a hook work? If userspace sees the system suspend on
> Nov 30th and sees the system wake up on Dec 1st, how does it know
> whether it should adjust? If it's truly Dec 1st then the kernel will
> have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec
> 2nd then the
> If you set the alarm
> for Dec 25th and it's currently Oct 31st then you'll have to adjust in
> the alarm code and you'll really set it for Dec 24th. As per above,
> we're in S3 (presumably) or have some persistent kernel state so we
> know to adjust everything when we wake up (even if we wake
> I would have liked to be in copy of that mail. Maybe you used
> get_maintainers on an old tree?
Oops, yes, sorry, I ran it on a 3.14 backport and then just added
people I found in older patches for that file.
> I hope reading the time properly fails thanks to the rtc_valid_tm(tm) in
>
On Thu, Dec 03, 2015 at 10:15:49AM -0500, Tejun Heo wrote:
> Hello,
>
> On Thu, Dec 03, 2015 at 10:33:55AM +0100, Andreas Werner wrote:
> > All the other "flag" fields in the structs are used and/or reserved
> > and it seems to be no good place for such flags.
On Wed, Dec 02, 2015 at 11:47:53AM -0500, Tejun Heo wrote:
> Hello, Andreas.
>
> On Wed, Dec 02, 2015 at 10:33:10AM +0100, Andreas Werner wrote:
> > Blacklisting the controller would be a solution yes, but I just
> > wanna wait the answer from the FAE to be sure we real
On Wed, Dec 02, 2015 at 11:47:53AM -0500, Tejun Heo wrote:
> Hello, Andreas.
>
> On Wed, Dec 02, 2015 at 10:33:10AM +0100, Andreas Werner wrote:
> > Blacklisting the controller would be a solution yes, but I just
> > wanna wait the answer from the FAE to be sure we real
> I would have liked to be in copy of that mail. Maybe you used
> get_maintainers on an old tree?
Oops, yes, sorry, I ran it on a 3.14 backport and then just added
people I found in older patches for that file.
> I hope reading the time properly fails thanks to the rtc_valid_tm(tm) in
>
On Thu, Dec 03, 2015 at 10:15:49AM -0500, Tejun Heo wrote:
> Hello,
>
> On Thu, Dec 03, 2015 at 10:33:55AM +0100, Andreas Werner wrote:
> > All the other "flag" fields in the structs are used and/or reserved
> > and it seems to be no good place for such flags.
on the Gregorian one). Those edge cases can only really be
solved by regularly syncing to an external time source (e.g. NTP).
Signed-off-by: Julius Werner
Reviewed-by: Chris Zhong
---
drivers/rtc/rtc-rk808.c | 93 ++---
1 file changed, 50 insertions(+), 43
On Tue, Dec 01, 2015 at 02:04:10PM -0500, Tejun Heo wrote:
> On Tue, Dec 01, 2015 at 11:17:15AM -0500, Tejun Heo wrote:
> > So, I suppose this is a fallout from 9faa643855df ("libata: use
> > READ_LOG_DMA_EXT"). The description just says "we should try use it"
> > but is there any benefit from
On Tue, Dec 01, 2015 at 02:04:10PM -0500, Tejun Heo wrote:
> On Tue, Dec 01, 2015 at 11:17:15AM -0500, Tejun Heo wrote:
> > So, I suppose this is a fallout from 9faa643855df ("libata: use
> > READ_LOG_DMA_EXT"). The description just says "we should try use it"
> > but is there any benefit from
on the Gregorian one). Those edge cases can only really be
solved by regularly syncing to an external time source (e.g. NTP).
Signed-off-by: Julius Werner <jwer...@chromium.org>
Reviewed-by: Chris Zhong <z...@rock-chips.com>
---
drivers/rtc/rtc-
Hi,
first sorry for the bad email format, but the IT decided to add my Email
signature as HTML
on the Exchange Server, this is why lkml rejected the email.
Therefore I will switch to my private address.
I do not think that the commit you mention is the root cause for this problem,
because it is
Hi,
first sorry for the bad email format, but the IT decided to add my Email
signature as HTML
on the Exchange Server, this is why lkml rejected the email.
Therefore I will switch to my private address.
I do not think that the commit you mention is the root cause for this problem,
because it is
> To handle things smarter, I think I need to research how to deal with
> hubs attached to hubs attached to hubs. For instance:
>
> dwc2
> -> multi_tt hub
> -> single_tt hub
> -> device 1
> -> device 2
Keep in mind that there's always at most one (active) TT between host
and
Another point to note, which I think is what prevents the flow Alan
suggested from working, is this little snippet in DWC2's hub_control
GetPortStatus callback:
if (!hsotg->flags.b.port_connect_status) {
/*
* The port is
> To handle things smarter, I think I need to research how to deal with
> hubs attached to hubs attached to hubs. For instance:
>
> dwc2
> -> multi_tt hub
> -> single_tt hub
> -> device 1
> -> device 2
Keep in mind that there's always at most one (active) TT between host
and
Another point to note, which I think is what prevents the flow Alan
suggested from working, is this little snippet in DWC2's hub_control
GetPortStatus callback:
if (!hsotg->flags.b.port_connect_status) {
/*
* The port is
Yet another thing.
if i will implement the open drain support, does it really makes sense to go
with the
generic gpio lib?
I need to replace the direction_input and direction_outpu functions
because if the userland set an open drain pin to input i need to
set the pin to High-Z (driver "1")
Hi,
i have an additional question regarding the Open Drain setting.
The register is currently impelemented as a read/write register
which means the pin mode is configurable by software to
Push Pull or Open Drain.
There is also the possiblity (normal way) that the HW (FPGA) configures
each pin to
Hi,
i have an additional question regarding the Open Drain setting.
The register is currently impelemented as a read/write register
which means the pin mode is configurable by software to
Push Pull or Open Drain.
There is also the possiblity (normal way) that the HW (FPGA) configures
each pin to
Yet another thing.
if i will implement the open drain support, does it really makes sense to go
with the
generic gpio lib?
I need to replace the direction_input and direction_outpu functions
because if the userland set an open drain pin to input i need to
set the pin to High-Z (driver "1")
On Tue, Oct 06, 2015 at 09:35:51AM +0200, Linus Walleij wrote:
> On Mon, Oct 5, 2015 at 8:09 PM, Andreas Werner wrote:
>
> > The 16Z127 is a GPIO controller on a MCB FPGA and has 32
> > configurable GPIOs.
> > The GPIOs can be configured as inputs and outputs
> &
On Tue, Oct 06, 2015 at 09:35:51AM +0200, Linus Walleij wrote:
> On Mon, Oct 5, 2015 at 8:09 PM, Andreas Werner <a...@wernerandy.de> wrote:
>
> > The 16Z127 is a GPIO controller on a MCB FPGA and has 32
> > configurable GPIOs.
> > The GPIOs can be configured as inp
The 16Z127 is a GPIO controller on a MCB FPGA and has 32
configurable GPIOs.
The GPIOs can be configured as inputs and outputs
Signed-off-by: Andreas Werner
---
drivers/gpio/Kconfig| 6 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-menz127.c | 186
the resources. This function also takes care of
the memory region naming allocated by the driver for each of the instances.
Signed-off-by: Andreas Werner
---
drivers/tty/serial/men_z135_uart.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial
The 16Z127 is a GPIO controller on a MCB FPGA and has 32
configurable GPIOs.
The GPIOs can be configured as inputs and outputs
Signed-off-by: Andreas Werner <a...@wernerandy.de>
---
drivers/gpio/Kconfig| 6 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-menz127.c
the resources. This function also takes care of
the memory region naming allocated by the driver for each of the instances.
Signed-off-by: Andreas Werner <a...@wernerandy.de>
---
drivers/tty/serial/men_z135_uart.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff
> > From: Werner Johansson
> >
> > The driver occasionally got stuck in suspend mode or other strange
> > states as those parts of the props struct were never initialized.
>
> Acked-by: Milo Kim
>
> Thanks for catching this.
You're most welcome! These i
From: Werner Johansson werner.johans...@sonymobile.com
The driver occasionally got stuck in suspend mode or other strange
states as those parts of the props struct were never initialized.
Acked-by: Milo Kim milo@ti.com
Thanks for catching this.
You're most welcome! These issues
> But I don't see how you will make it work when the root hub itself is
> not enabled for wakeup and a non-hub device plugged into one of the
> root hub's ports is enabled.
>
> It seems like you would need a usb_hcd_wakeup_not_needed(hcd, port)
> subroutine.
We'd just put that in the Tegra
But I don't see how you will make it work when the root hub itself is
not enabled for wakeup and a non-hub device plugged into one of the
root hub's ports is enabled.
It seems like you would need a usb_hcd_wakeup_not_needed(hcd, port)
subroutine.
We'd just put that in the Tegra platform
> Doug, how would you feel about reworking the patch that exports
> usb_wakeup_enabled_descendants()? Instead of doing it that way, create
> and export a new subroutine in hcd.c called
> usb_hcd_wakeup_not_needed(), or something similar.
We have a use case with another host controller (Tegra,
Doug, how would you feel about reworking the patch that exports
usb_wakeup_enabled_descendants()? Instead of doing it that way, create
and export a new subroutine in hcd.c called
usb_hcd_wakeup_not_needed(), or something similar.
We have a use case with another host controller (Tegra, which
Hi,
i am currently working on a driver using regmap.
The test system i my Mac Book Air using the i2c-stub driver for the first tests.
The Kernel is the Arch Linux Kernel 4.0.2-1-ARCH.
First thing after setting up all the ranges was to check the debugfs.
After i did a cat on the ranges debugfs
Hi,
i am currently working on a driver using regmap.
The test system i my Mac Book Air using the i2c-stub driver for the first tests.
The Kernel is the Arch Linux Kernel 4.0.2-1-ARCH.
First thing after setting up all the ranges was to check the debugfs.
After i did a cat on the ranges debugfs
On Tue, May 26, 2015 at 02:00:39PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, May 26, 2015 at 08:54:25PM +0200, Andreas Werner wrote:
> > i have a question regarding regmap usage.
> >
> > I have a i2c multifunction device which does have a register and valu
Hi,
i have a question regarding regmap usage.
I have a i2c multifunction device which does have a register and value width of
8bits except
the revision register. The revision can only be read by a i2c block transfer.
Does it makes sense to read the Revision once by the i2c API and let the rest
Hi,
i have a question regarding regmap usage.
I have a i2c multifunction device which does have a register and value width of
8bits except
the revision register. The revision can only be read by a i2c block transfer.
Does it makes sense to read the Revision once by the i2c API and let the rest
On Tue, May 26, 2015 at 02:00:39PM -0500, Felipe Balbi wrote:
Hi,
On Tue, May 26, 2015 at 08:54:25PM +0200, Andreas Werner wrote:
i have a question regarding regmap usage.
I have a i2c multifunction device which does have a register and value
width of 8bits except the revision
On Thu, May 14, 2015 at 11:14:19PM -0700, Guenter Roeck wrote:
> On 05/14/2015 10:43 PM, Andreas Werner wrote:
> >On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote:
> >>On 05/14/2015 07:09 AM, Andreas Werner wrote:
> >>>On Thu, May 14, 2015 at 06:30:0
On Thu, May 14, 2015 at 11:14:19PM -0700, Guenter Roeck wrote:
> On 05/14/2015 10:43 PM, Andreas Werner wrote:
> >On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote:
> >>On 05/14/2015 07:09 AM, Andreas Werner wrote:
> >>>On Thu, May 14, 2015 at 06:30:0
On Thu, May 14, 2015 at 11:14:19PM -0700, Guenter Roeck wrote:
On 05/14/2015 10:43 PM, Andreas Werner wrote:
On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote:
On 05/14/2015 07:09 AM, Andreas Werner wrote:
On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote:
On 05/14
On Thu, May 14, 2015 at 11:14:19PM -0700, Guenter Roeck wrote:
On 05/14/2015 10:43 PM, Andreas Werner wrote:
On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote:
On 05/14/2015 07:09 AM, Andreas Werner wrote:
On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote:
On 05/14
On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote:
> On 05/14/2015 07:09 AM, Andreas Werner wrote:
> >On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote:
> >>On 05/14/2015 04:56 AM, Andreas Werner wrote:
> >>>Hi,
> >>>in t
On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote:
> On 05/14/2015 04:56 AM, Andreas Werner wrote:
> >Hi,
> >in the next few weeks I need to write a driver for a window wachtdog
> >implemented in a CPLD. I have some questions about the design
> >of the drive
Hi,
in the next few weeks I need to write a driver for a window wachtdog
implemented in a CPLD. I have some questions about the design
of the driver and the best way to write this driver to also be able
to submit it.
The triggering and configuration of the Watchdog is done by several GPIOs which
On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote:
On 05/14/2015 04:56 AM, Andreas Werner wrote:
Hi,
in the next few weeks I need to write a driver for a window wachtdog
implemented in a CPLD. I have some questions about the design
of the driver and the best way to write
Hi,
in the next few weeks I need to write a driver for a window wachtdog
implemented in a CPLD. I have some questions about the design
of the driver and the best way to write this driver to also be able
to submit it.
The triggering and configuration of the Watchdog is done by several GPIOs which
On Thu, May 14, 2015 at 05:52:38PM -0700, Guenter Roeck wrote:
On 05/14/2015 07:09 AM, Andreas Werner wrote:
On Thu, May 14, 2015 at 06:30:05AM -0700, Guenter Roeck wrote:
On 05/14/2015 04:56 AM, Andreas Werner wrote:
Hi,
in the next few weeks I need to write a driver for a window wachtdog
evice tree entry that can configure this
delay in terms of nanoseconds. The kernel will calculate the
best-fitting amount of parent clock ticks to program the controller with
based on that.
Signed-off-by: Julius Werner
---
.../devicetree/bindings/spi/spi-rockchip.txt| 4
drive
is even) that then results in an
effective frequency of 9900 / 2 == 4950 (potentially exceeding
the flash chip's specifications).
This patch changes the division to round up to fix this problem.
Signed-off-by: Julius Werner
---
drivers/spi/spi-rockchip.c | 2 +-
1 file changed, 1
entry that can configure this
delay in terms of nanoseconds. The kernel will calculate the
best-fitting amount of parent clock ticks to program the controller with
based on that.
Signed-off-by: Julius Werner jwer...@chromium.org
---
.../devicetree/bindings/spi/spi-rockchip.txt| 4
is even) that then results in an
effective frequency of 9900 / 2 == 4950 (potentially exceeding
the flash chip's specifications).
This patch changes the division to round up to fix this problem.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/spi/spi-rockchip.c | 2 +-
1
> @@ -2703,7 +2703,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
> gusbcfg = readl(hsotg->regs + GUSBCFG);
> gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
> writel(gusbcfg, hsotg->regs + GUSBCFG);
> - usleep_range(10, 15);
> + usleep_range(25000, 5);
@@ -2703,7 +2703,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg)
gusbcfg = readl(hsotg-regs + GUSBCFG);
gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
writel(gusbcfg, hsotg-regs + GUSBCFG);
- usleep_range(10, 15);
+ usleep_range(25000, 5);
The point
on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..26bdd96 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
on other controllers.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..26bdd96 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers
on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
> You should use a sleeping function call, not a delay.
Whoops... yes, of course. Guess too much firmware work made me forget
what multithreading is there for a moment. Will send a v2.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
You should use a sleeping function call, not a delay.
Whoops... yes, of course. Guess too much firmware work made me forget
what multithreading is there for a moment. Will send a v2.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
on other controllers.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers
on other controllers.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
on other controllers.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index aeb50bb..d1d0a66 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers
>> The EHCI controller doesn't properly detect the case when
>
> "The" EHCI controller? I don't know what EHCI controller you're
> talking about, but my controllers don't have any trouble detecting
> device removal during suspend.
This is similar to other SoC-based controllers that loose state
The EHCI controller doesn't properly detect the case when
The EHCI controller? I don't know what EHCI controller you're
talking about, but my controllers don't have any trouble detecting
device removal during suspend.
This is similar to other SoC-based controllers that loose state in
On Wed, Nov 19, 2014 at 1:47 AM, 李云志 wrote:
> hi Julius & Alan
>
> Shall we use dwc2's private status "hsotg->lx_state" here instesd of
> "hcd->state" for checking root hub is in suspend state ?
> I see the EHCI driver do something like this(ehci->rh_state ==
> EHCI_RH_SUSPENDED) before
On Wed, Nov 19, 2014 at 1:47 AM, 李云志 l...@rock-chips.com wrote:
hi Julius Alan
Shall we use dwc2's private status hsotg-lx_state here instesd of
hcd-state for checking root hub is in suspend state ?
I see the EHCI driver do something like this(ehci-rh_state ==
EHCI_RH_SUSPENDED) before
>> You should be aware that it's not safe to use hcd->state for anything
>> in a host controller driver. That field is owned by usbcore, not by
>> the HCD, and it is not protected by any locks.
>>
>> Thus, for example, hcd->state does not get set to HC_STATE_SUSPENDED
>> until some time after the
You should be aware that it's not safe to use hcd-state for anything
in a host controller driver. That field is owned by usbcore, not by
the HCD, and it is not protected by any locks.
Thus, for example, hcd-state does not get set to HC_STATE_SUSPENDED
until some time after the bus_suspend
On Mon, Nov 17, 2014 at 5:14 AM, Kever Yang wrote:
> After we implement the bus_suspend/resume, auto suspend id enabled.
> The root hub will be auto suspend if there is no device connected,
> we need to resume the root hub when a device connect detect.
>
> This patch tested on rk3288.
>
>
On Mon, Nov 17, 2014 at 5:14 AM, Kever Yang kever.y...@rock-chips.com wrote:
After we implement the bus_suspend/resume, auto suspend id enabled.
The root hub will be auto suspend if there is no device connected,
we need to resume the root hub when a device connect detect.
This patch tested on
> I will figure out how to make dwc2 detect the device connect after auto
> suspend,
> or disable the auto suspend feature for the dwc2 hcd.
I think auto-suspend of the root hub device (which is what calls
bus_suspend, but is not the host controller device itself) is expected
to always happen and
I will figure out how to make dwc2 detect the device connect after auto
suspend,
or disable the auto suspend feature for the dwc2 hcd.
I think auto-suspend of the root hub device (which is what calls
bus_suspend, but is not the host controller device itself) is expected
to always happen and
for frequency and 1024-based size
units (Hz/KHz/MHz/GHz/THz and KiB/MiB/GiB/TiB), since allowing any three
character combinations might be too lenient. The list can later be
expanded as needed.
Signed-off-by: Julius Werner
---
scripts/checkpatch.pl | 4 +++-
1 file changed, 3 insertions(+), 1
>> The contract for bus_suspend() is that it will suspend all ports not
>> yet suspended, keep track of those ports and then only resume those in
>> bus_resume() (compare, for example, how XHCI keeps track of that with
>> xhci_bus_state.bus_suspended in xhci_bus_suspend/resume()). So you
>> need
The contract for bus_suspend() is that it will suspend all ports not
yet suspended, keep track of those ports and then only resume those in
bus_resume() (compare, for example, how XHCI keeps track of that with
xhci_bus_state.bus_suspended in xhci_bus_suspend/resume()). So you
need something
for frequency and 1024-based size
units (Hz/KHz/MHz/GHz/THz and KiB/MiB/GiB/TiB), since allowing any three
character combinations might be too lenient. The list can later be
expanded as needed.
Signed-off-by: Julius Werner jwer...@chromium.org
---
scripts/checkpatch.pl | 4 +++-
1 file changed, 3
201 - 300 of 1003 matches
Mail list logo
