SoC: txx9: Remove driver
I think dma and ASoC drivers are hard to maintain now, and can be
dropped for basic support for RBTX4927.
(TX39 boards does not have audio-support, so dma txx9 driver can be
dropped too)
---
Atsushi Nemoto
Is that sufficient to keep it?
It have been about 10 years since last time I see any TX49 board :-)
AFAIK Geert is the last user of TX49 SoC.
I'm OK with whole TX49xx (and TX39xx) removal if Geert (or any other
users) agreed.
---
Atsushi Nemoto
eert Uytterhoeven
Thank you for fixing this. It looks OK for me.
Reviewed-by: Atsushi Nemoto
---
Atsushi Nemoto
I slot. If you had an legacy PCI NIC card, trying
with it might help finding the bug.
> My next guess is an unaligned access not using {get,put}_unaligned(), which
> doesn't seem to work on tx4927, but doesn't cause an exception neither.
IIRC, TX49 can raise an exception on unaligned access.
I slot. If you had an legacy PCI NIC card, trying
with it might help finding the bug.
> My next guess is an unaligned access not using {get,put}_unaligned(), which
> doesn't seem to work on tx4927, but doesn't cause an exception neither.
IIRC, TX49 can raise an exception on unaligned access.
pe these options still works correctly with recent kernel but not
sure.
Also, disabling i-cache makes your board VERY slow, of course.
---
Atsushi Nemoto
pe these options still works correctly with recent kernel but not
sure.
Also, disabling i-cache makes your board VERY slow, of course.
---
Atsushi Nemoto
tions(+), 3 deletions(-)
Thank you for fixing this long standing issue. It looks OK for me.
Reviewed-by: Atsushi Nemoto
---
Atsushi Nemoto
tions(+), 3 deletions(-)
Thank you for fixing this long standing issue. It looks OK for me.
Reviewed-by: Atsushi Nemoto
---
Atsushi Nemoto
(dev);
This change will break exit_put error path.
I think kfree will be called from txx9_device_release by put_device.
Please refer James's comment on previous trial:
<https://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips=20180305221833.GJ4197%40saruman>
---
Atsushi Nemoto
(dev);
This change will break exit_put error path.
I think kfree will be called from txx9_device_release by put_device.
Please refer James's comment on previous trial:
<https://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips=20180305221833.GJ4197%40saruman>
---
Atsushi Nemoto
res for many years).
Thank you. Good catch.
Reviewed-by: Atsushi Nemoto <an...@mba.ocn.ne.jp>
---
Atsushi Nemoto
Good catch.
Reviewed-by: Atsushi Nemoto
---
Atsushi Nemoto
Zero length transfer becomes invalid since
"spi: core: Validate length of the transfers in message" commit,
but it should be valid to support an odd device, for example, which
requires long delay between chipselect and the first transfer, etc.
Signed-off-by: Atsushi Nemoto
---
drivers
ich
>> requires long delay between chipselect and the first transfer, etc.
>
> Can you submit a patch adding that support back please?
OK, I will send a patch against spi.git/for-next branch.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscri
chipselect and the first transfer, etc.
Can you submit a patch adding that support back please?
OK, I will send a patch against spi.git/for-next branch.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Zero length transfer becomes invalid since
spi: core: Validate length of the transfers in message commit,
but it should be valid to support an odd device, for example, which
requires long delay between chipselect and the first transfer, etc.
Signed-off-by: Atsushi Nemoto an...@mba.ocn.ne.jp
f
course, and "xfer->len % w_size" part looks no problem.
I just want to keep ways to handle an odd device, for example, which
requires long delay between chipselect and the first transfer, etc.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscri
% w_size part looks no problem.
I just want to keep ways to handle an odd device, for example, which
requires long delay between chipselect and the first transfer, etc.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
spi/spi-summary, zeto length transfer seems
valid.
+ optionally defining short delays after transfers ... using
the spi_transfer.delay_usecs setting (this delay can be the
only protocol effect, if the buffer length is zero);
---
Atsushi Nemoto
--
To unsubscribe from this l
transfer seems
valid.
+ optionally defining short delays after transfers ... using
the spi_transfer.delay_usecs setting (this delay can be the
only protocol effect, if the buffer length is zero);
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe
please convert all
platform_get_drvdata and platform_set_drvdata to dev_get_drvdata and
dev_set_drvdata. We should avoid mixing two APIs.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
dev_get_drvdata, please convert all
platform_get_drvdata and platform_set_drvdata to dev_get_drvdata and
dev_set_drvdata. We should avoid mixing two APIs.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
Correct the offset by subtracting 20 from tm_hour before taking
the modulo 12.
Reported-and-tested-by: James Nute
Signed-off-by: Atsushi Nemoto
---
drivers/rtc/rtc-rs5c348.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-rs5c348.c b/drivers/rtc
Correct the offset by subtracting 20 from tm_hour before taking
the modulo 12.
Reported-and-tested-by: James Nute newte...@gmail.com
Signed-off-by: Atsushi Nemoto an...@mba.ocn.ne.jp
---
drivers/rtc/rtc-rs5c348.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git
then I guess I
> missed the original point. Sorry.
Yes. I want to use zero length transfer with delay_usecs to achieve
CS-CLK delay for my funny device. And I was too lazy to reject true
nop transfer.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe li
the original point. Sorry.
Yes. I want to use zero length transfer with delay_usecs to achieve
CS-CLK delay for my funny device. And I was too lazy to reject true
nop transfer.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
> Is this kind of device so common that we need to do all that work? or can we
> leave it as is (verified to work only with atmel_spi)?
I think my case is not so common. But if the driver could support
zero length transfer easily, there is no reason to reject it.
And if nobody wanted to support
with atmel_spi)?
I think my case is not so common. But if the driver could support
zero length transfer easily, there is no reason to reject it.
And if nobody wanted to support zero length transfer on that driver,
it would be no reason to update it ;)
---
Atsushi Nemoto
--
To unsubscribe from this list
lly nice...
Well, simple grepping drivers/net/phy enlighten us ;)
Anyway, this patch fixes problem with 10Mbps on AT91SAM9260 board.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On Thu, 21 Feb 2008 15:12:46 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
wrote:
> I have to admit that even after looking through include/linux/phy.h and
> include/linux/mii.h, I don't have the faintest idea what values we can
> expect to find in the "speed" field of phydev. The comment above
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
conversion to generic PHY layer in kernel 2.6.23.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 81bf005..1d210ed 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/
Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
conversion to generic PHY layer in kernel 2.6.23.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 81bf005..1d210ed 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
On Thu, 21 Feb 2008 15:12:46 +0100, Haavard Skinnemoen [EMAIL PROTECTED]
wrote:
I have to admit that even after looking through include/linux/phy.h and
include/linux/mii.h, I don't have the faintest idea what values we can
expect to find in the speed field of phydev. The comment above struct
, this patch fixes problem with 10Mbps on AT91SAM9260 board.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
all
CSRn.CPOL match for the transfer before activating chipselect. For
longer term, the best fix might be to let NPCS0 stay selected
permanently in MR and overwrite CSR0 with to the new slave's settings
before asserting CS.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
Acked-by: H
gh it can be possible to avoid starting DMA for zero length
transfer, I think it is not worth to optimize for such a rare case.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
A spi transfer with zero length is not invalid. Such transfer can be
used to achieve delay before first CLK edge after chipselect assertion.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index 293b7ca..5dff5e0
ked-by to the patch already in mm?
The patch in mm also lacks my Signed-off line. I had thought Andrew
never take a patch without Signed-off line ;)
Should I resend my patch with my Signed-off and Haavard's Acked-by?
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe
also lacks my Signed-off line. I had thought Andrew
never take a patch without Signed-off line ;)
Should I resend my patch with my Signed-off and Haavard's Acked-by?
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
A spi transfer with zero length is not invalid. Such transfer can be
used to achieve delay before first CLK edge after chipselect assertion.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index 293b7ca..5dff5e0 100644
transfer, I think it is not worth to optimize for such a rare case.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
all
CSRn.CPOL match for the transfer before activating chipselect. For
longer term, the best fix might be to let NPCS0 stay selected
permanently in MR and overwrite CSR0 with to the new slave's settings
before asserting CS.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
Acked-by: Haavard
not work. The clock state did not change by
writing MR register.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
o time at
> all.
No, I did not enabled debugging.
> If you can confirm that my patch helps, I think that's the one we want
> in mainline.
Unfortunately I had no time to try it today. Hopefully tomorrow...
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsub
that's the one we want
in mainline.
Unfortunately I had no time to try it today. Hopefully tomorrow...
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
did not change by
writing MR register.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|~|___|~~~|___|~~~|___|~~~|___
SO ~~|___|~~~|___|~~~|___|~~~|_
MSB
T0-T1 was relatively longer then T1-T2. I suppose T1 is not the
point of updating MR register, but the point of starting DMA transfer.
Anyway, I will try your patch in a few days.
---
Atsushi Nemoto
--
To
~~|___|~~~|___|~~~|___|~~~|_
MSB
T0-T1 was relatively longer then T1-T2. I suppose T1 is not the
point of updating MR register, but the point of starting DMA transfer.
Anyway, I will try your patch in a few days.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux
On Sat, 16 Feb 2008 10:58:48 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> On Saturday 16 February 2008, Atsushi Nemoto wrote:
> > Hi. Is it legal to use zero for 'len' field of struct spi_transfer?
> > I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.
>
> Ye
On Sat, 16 Feb 2008 10:58:48 -0800, David Brownell [EMAIL PROTECTED] wrote:
On Saturday 16 February 2008, Atsushi Nemoto wrote:
Hi. Is it legal to use zero for 'len' field of struct spi_transfer?
I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.
Yes that should work ... it's uncommon
. But it seems some drivers do not
handle this case properly.
Is this driver's bug, or we need additional delay field in struct
spi_device for such case?
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
spi_writel(as, CSR0 + 4 * i, csr ^ SPI_BIT(CPOL));
+ }
mr = spi_readl(as, MR);
mr = SPI_BFINS(PCS, ~(1 << spi->chip_select), mr);
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
* i, csr ^ SPI_BIT(CPOL));
+ }
mr = spi_readl(as, MR);
mr = SPI_BFINS(PCS, ~(1 spi-chip_select), mr);
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
. But it seems some drivers do not
handle this case properly.
Is this driver's bug, or we need additional delay field in struct
spi_device for such case?
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
uest :).
>
> From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> Subject: [PATCH] ide: ide_init_port() bugfix
Thanks! Looks sane for me :)
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
Zolnierkiewicz [EMAIL PROTECTED]
Subject: [PATCH] ide: ide_init_port() bugfix
Thanks! Looks sane for me :)
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
>swdma_mask = hwif->mwdma_mask = hwif->ultra_mask = 0;
It might be too late, but "host_flags && IDE_HFLAGS_NO_DMA" seems
wrong for me.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
;
It might be too late, but host_flags IDE_HFLAGS_NO_DMA seems
wrong for me.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
+ds1511_rtc_exit(void)
> +{
> + return platform_driver_unregister(_rtc_driver);
> +}
Do not return void value. Please check rtc-ds1553 changes in current
git tree.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
. Please check
rtc-ds1553 changes in current git tree.
+ static void __exit
+ds1511_rtc_exit(void)
+{
+ return platform_driver_unregister(ds1511_rtc_driver);
+}
Do not return void value. Please check rtc-ds1553 changes in current
git tree.
---
Atsushi Nemoto
--
To unsubscribe from
tion.
So I'd suggest using workqueue for your led driver, as like as the
leds-gpio driver. Or you can just use the leds-gpio driver and
implement the gpio interface (gpio_set_value_cansleep) instead of the
led interface.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsub
for your led driver, as like as the
leds-gpio driver. Or you can just use the leds-gpio driver and
implement the gpio interface (gpio_set_value_cansleep) instead of the
led interface.
---
Atsushi Nemoto
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Some error paths in txx9spi_probe wrongly return 0. This patch fixes
them by using the devres interfaces.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
drivers/spi/spi_txx9.c | 40
1 files changed, 20 insertions(+), 20 deletions(-)
diff
After 49dce689ad4ef0fd1f970ef762168e4bd46f69a3, device_for_each_child
iteration hits the master device itself. Do not call
spi_unregister_device() for the master device.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
drivers/spi/spi.c |8 +---
1 files changed, 5 insertions
Some error paths in txx9spi_probe wrongly return 0. This patch fixes
them by using the devres interfaces.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
drivers/spi/spi_txx9.c | 40
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git
After 49dce689ad4ef0fd1f970ef762168e4bd46f69a3, device_for_each_child
iteration hits the master device itself. Do not call
spi_unregister_device() for the master device.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
drivers/spi/spi.c |8 +---
1 files changed, 5 insertions(+), 3
h adds checking for oldstate value to fix this probelm.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c
index 6846a6c..7ad2192 100644
--- a/drivers/serial/serial_txx9.c
+++ b/drivers/serial/serial_txx9.c
@@ -657,7 +657,
checking for oldstate value to fix this probelm.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c
index 6846a6c..7ad2192 100644
--- a/drivers/serial/serial_txx9.c
+++ b/drivers/serial/serial_txx9.c
@@ -657,7 +657,15 @@ static
to have
> whatever-patch-this-is queued up anywhere?
Here is an original patch I proposed (http://lkml.org/lkml/2007/10/18/292)
--
Subject: serial: do not call ->pm() on initialization for console port
From: Atsushi Nemoto <[EMAIL PRO
to investigate further to refresh myself with what's going
> on here, but your patch looks wrong.
Now rc1 is released. Any chances for this patch?
If none, I should push other workaround to fix this issue on 2.6.24.
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line "unsubscri
with what's going
on here, but your patch looks wrong.
Now rc1 is released. Any chances for this patch?
If none, I should push other workaround to fix this issue on 2.6.24.
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
-this-is queued up anywhere?
Here is an original patch I proposed (http://lkml.org/lkml/2007/10/18/292)
--
Subject: serial: do not call -pm() on initialization for console port
From: Atsushi Nemoto [EMAIL PROTECTED]
If the port was already enabled
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 107787a..07b4215 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -103,7 +103,7 @@ struct clocksource {
#
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 107787a..07b4215 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -103,7 +103,7 @@ struct clocksource {
#define CLOCK_SOURCE_VALID_FOR_HRES
xx9_initialize(port);
+ /* This port will be initialized in subsequent serial_txx9_pm() */
}
static const char *
Hope these patches help your refreshing.
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
n
->pm() if oldstate was -1.
--
Subject: serial: do not call ->pm() on initialization for console port
From: Atsushi Nemoto <[EMAIL PROTECTED]>
If the port was already enabled as a serial console, there is no need
to call pm callback t
.
--
Subject: serial: do not call -pm() on initialization for console port
From: Atsushi Nemoto [EMAIL PROTECTED]
If the port was already enabled as a serial console, there is no need
to call pm callback to power it up. This patch fixes serial console
() */
}
static const char *
Hope these patches help your refreshing.
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
ilar to serial_txx9.c:
quot >>= 1;
if (quot < 256)
sibgr = quot | TXX9_SIBGR_BCLK_T0;
else if (quot < (256 << 2))
sibgr = (quot >> 2) | TXX9_SIBGR_BCLK_T2;
else if (quot < (256 << 4))
) | TXX9_SIBGR_BCLK_T4;
else if (quot (256 6))
sibgr = (quot 6) | TXX9_SIBGR_BCLK_T6;
else
sibgr = 0xff | TXX9_SIBGR_BCLK_T6;
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
The UPF_FIXED_PORT flags was introduced in 2.6.22 and it can be used
instead of the driver specific verify_port routine.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
drivers/serial/serial_txx9.c | 26 +-
1 files changed, 5 insertions(+), 21 deletions(-)
The UPF_FIXED_PORT flags was introduced in 2.6.22 and it can be used
instead of the driver specific verify_port routine.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
drivers/serial/serial_txx9.c | 26 +-
1 files changed, 5 insertions(+), 21 deletions(-)
diff
ntiate the ds1742 platform device appropriately).
>
> Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Thanks!
Acked-by: Atsushi Nemoto <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Currently the rtc driver, rtc-ds1552.c uses an unsigned long to store
the base mmio address of the NVRAM/RTC. This breaks on 32-bit systems
with larger physical addresses.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/rtc/rtc-ds1553.c b/drivers/rtc/rtc-ds1553.c
Currently the rtc driver, rtc-ds1552.c uses an unsigned long to store
the base mmio address of the NVRAM/RTC. This breaks on 32-bit systems
with larger physical addresses.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
diff --git a/drivers/rtc/rtc-ds1553.c b/drivers/rtc/rtc-ds1553.c
index
).
Signed-off-by: David Gibson [EMAIL PROTECTED]
Thanks!
Acked-by: Atsushi Nemoto [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
form_device_register().
Yes, if the current in-tree users (JMR3927 and RBTX4927 board) really
wanted to hotplug this driver. And I believe they won't :-)
I just want to fix a potential problem in rtc-ds1742 driver for
someone who want to hotplug it. That's all.
---
Atsushi Nemoto
-
To unsu
platform driver. But it seems the discussion
is not DS1742 specific at all, and I guess ds1742 is not a good
example for hotplugging, so I welcome your $SUBJECT fix :-)
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
The rtc-ds1742 platform driver name doesn't match its module name,
which might prevents it from properly hotplugging. There is only two
in-tree user of its driver, which are fixed by this patch too.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
arch/mips/jmr3927/rbhma3100/s
The rtc-rs5c348 SPI driver name doesn't match its module name, which
prevents it from properly hotplugging. There is only one in-tree user
of its driver, which is fixed by this patch too.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
arch/mips/tx4938/toshiba_rbtx4938/setup.c
The rtc-ds1553 platform driver name doesn't match its module name,
which might prevent it from properly hotplugging. This driver has no
in-tree users.
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
The "take 2" of this patch was just a typo-fix ("1553" vs. &quo
LIAS, right?
I will send a patch to change the driver name string, because I did
not use the different name intentionally, I just had not thought about
hotplugging at all. I think there is no serious reason to stick with
current driver name anyway.
---
Atsushi Nemoto
-
To unsubscribe from this
, because I did
not use the different name intentionally, I just had not thought about
hotplugging at all. I think there is no serious reason to stick with
current driver name anyway.
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
The rtc-rs5c348 SPI driver name doesn't match its module name, which
prevents it from properly hotplugging. There is only one in-tree user
of its driver, which is fixed by this patch too.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
arch/mips/tx4938/toshiba_rbtx4938/setup.c |2
The rtc-ds1553 platform driver name doesn't match its module name,
which might prevent it from properly hotplugging. This driver has no
in-tree users.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
The take 2 of this patch was just a typo-fix (1553 vs. 1742).
diff --git a/drivers/rtc/rtc
The rtc-ds1742 platform driver name doesn't match its module name,
which might prevents it from properly hotplugging. There is only two
in-tree user of its driver, which are fixed by this patch too.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
arch/mips/jmr3927/rbhma3100/setup.c
. But it seems the discussion
is not DS1742 specific at all, and I guess ds1742 is not a good
example for hotplugging, so I welcome your $SUBJECT fix :-)
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
, if the current in-tree users (JMR3927 and RBTX4927 board) really
wanted to hotplug this driver. And I believe they won't :-)
I just want to fix a potential problem in rtc-ds1742 driver for
someone who want to hotplug it. That's all.
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line
on't think this is a big compatibility
problem.
---
Atsushi Nemoto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1 - 100 of 234 matches
Mail list logo
