[PATCH 07/29] rtc: opal: switch to RTC_FEATURE_UPDATE_INTERRUPT
Stop using uie_unsupported and clear RTC_FEATURE_UPDATE_INTERRUPT instead. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-opal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c index f8f49a969c23..ad41aaf8a17f 100644 --- a/drivers/rtc/rtc-opal.c +++ b/drivers/rtc/rtc-opal.c @@ -250,7 +250,7 @@ static int opal_rtc_probe(struct platform_device *pdev) rtc->ops = _rtc_ops; rtc->range_min = RTC_TIMESTAMP_BEGIN_; rtc->range_max = RTC_TIMESTAMP_END_; - rtc->uie_unsupported = 1; + clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features); return devm_rtc_register_device(rtc); } -- 2.35.1
Re: [PATCH v3 0/5] rtc: nintendo: Add a RTC driver for the GameCube, Wii and Wii U
On 16/12/2021 21:22:20+0100, Emmanuel Gil Peyrot wrote: > On Thu, Dec 16, 2021 at 10:49:44AM +0100, Alexandre Belloni wrote: > > On Wed, 15 Dec 2021 18:54:56 +0100, Emmanuel Gil Peyrot wrote: > > > These three consoles share a device, the MX23L4005, which contains a > > > clock and 64 bytes of SRAM storage, and is exposed on the EXI bus > > > (similar to SPI) on channel 0, device 1. This driver allows it to be > > > used as a Linux RTC device, where time can be read and set. > > > > > > The hardware also exposes two timers, one which shuts down the console > > > and one which powers it on, but these aren’t supported currently. > > > > > > [...] > > > > Applied, thanks! > > > > [1/5] rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U > > commit: 86559400b3ef9de93ba50523cffe767c35cd531a > > [2/5] rtc: gamecube: Report low battery as invalid data > > commit: 322539a014bcd24cbb9281832c09b24e07912237 > > [3/5] powerpc: wii.dts: Expose HW_SRNPROT on this platform > > commit: 5479618e1e2641dd57352a73b7b7b2f6908fbeee > > [4/5] powerpc: gamecube_defconfig: Enable the RTC driver > > commit: 57bd7d356506b713d0df8d8e42da7810a18864df > > [5/5] powerpc: wii_defconfig: Enable the RTC driver > > commit: 69e8ba80ddda4db31e59facbf2db19773ad3785b > > > > This one didn't apply ceanly but I believe I did the right thing. Can you > > check? > > I believe you didn’t, at least that commit[1] seems to have one “+” too > many in the modified line, whereas the previous one[2] doesn’t. > I knew I needed you to check, this is fixed now. https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git/commit/?id=c636783d594f6cfc95db51c796761719317ce5eb -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v3 0/5] rtc: nintendo: Add a RTC driver for the GameCube, Wii and Wii U
Hello, On 16/12/2021 15:52:59+1100, Michael Ellerman wrote: > > Emmanuel Gil Peyrot (5): > > rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U > > rtc: gamecube: Report low battery as invalid data > > powerpc: wii.dts: Expose HW_SRNPROT on this platform > > powerpc: gamecube_defconfig: Enable the RTC driver > > powerpc: wii_defconfig: Enable the RTC driver > > > > drivers/rtc/Kconfig | 11 + > > drivers/rtc/Makefile| 1 + > > drivers/rtc/rtc-gamecube.c | 377 > > This is basically an rtc series as far as I'm concerned. > > > arch/powerpc/boot/dts/wii.dts | 5 + > > arch/powerpc/configs/gamecube_defconfig | 2 +- > > arch/powerpc/configs/wii_defconfig | 2 +- > > I have nothing queued in the powerpc tree that touches any of those > files, so conflicts are unlikely. > > So I'm happy for this to go via the rtc tree whenever it's ready. > > Acked-by: Michael Ellerman (powerpc) That's done, thanks. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v3 0/5] rtc: nintendo: Add a RTC driver for the GameCube, Wii and Wii U
On Wed, 15 Dec 2021 18:54:56 +0100, Emmanuel Gil Peyrot wrote: > These three consoles share a device, the MX23L4005, which contains a > clock and 64 bytes of SRAM storage, and is exposed on the EXI bus > (similar to SPI) on channel 0, device 1. This driver allows it to be > used as a Linux RTC device, where time can be read and set. > > The hardware also exposes two timers, one which shuts down the console > and one which powers it on, but these aren’t supported currently. > > [...] Applied, thanks! [1/5] rtc: gamecube: Add a RTC driver for the GameCube, Wii and Wii U commit: 86559400b3ef9de93ba50523cffe767c35cd531a [2/5] rtc: gamecube: Report low battery as invalid data commit: 322539a014bcd24cbb9281832c09b24e07912237 [3/5] powerpc: wii.dts: Expose HW_SRNPROT on this platform commit: 5479618e1e2641dd57352a73b7b7b2f6908fbeee [4/5] powerpc: gamecube_defconfig: Enable the RTC driver commit: 57bd7d356506b713d0df8d8e42da7810a18864df [5/5] powerpc: wii_defconfig: Enable the RTC driver commit: 69e8ba80ddda4db31e59facbf2db19773ad3785b This one didn't apply ceanly but I believe I did the right thing. Can you check? Best regards, -- Alexandre Belloni
Re: [PATCH v2 2/5] rtc: gamecube: Report low battery as invalid data
Hello,
On 28/10/2021 00:35:12+0200, Emmanuel Gil Peyrot wrote:
> I haven’t been able to test this patch as all of my consoles have a
> working RTC battery, but according to the documentation it should work
> like that.
>
> Signed-off-by: Emmanuel Gil Peyrot
> ---
> drivers/rtc/rtc-gamecube.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/rtc/rtc-gamecube.c b/drivers/rtc/rtc-gamecube.c
> index e8260c82c07d..1932c6fe1301 100644
> --- a/drivers/rtc/rtc-gamecube.c
> +++ b/drivers/rtc/rtc-gamecube.c
> @@ -83,6 +83,10 @@
> #define RTC_CONTROL0 0x21000c
> #define RTC_CONTROL1 0x21000d
>
> +/* RTC flags */
> +#define RTC_CONTROL0_UNSTABLE_POWER 0x0800
> +#define RTC_CONTROL0_LOW_BATTERY 0x0200
> +
> struct priv {
> struct regmap *regmap;
> void __iomem *iob;
> @@ -182,9 +186,35 @@ static int gamecube_rtc_set_time(struct device *dev,
> struct rtc_time *t)
> return regmap_write(d->regmap, RTC_COUNTER, timestamp - d->rtc_bias);
> }
>
> +static int gamecube_rtc_ioctl(struct device *dev, unsigned int cmd, unsigned
> long arg)
> +{
> + struct priv *d = dev_get_drvdata(dev);
> + int value;
> + int control0;
> + int ret;
> +
> + switch (cmd) {
> + case RTC_VL_READ:
> + ret = regmap_read(d->regmap, RTC_CONTROL0, );
> + if (ret)
> + return ret;
> +
> + value = 0;
> + if (control0 & RTC_CONTROL0_UNSTABLE_POWER)
> + value |= RTC_VL_DATA_INVALID;
> + if (control0 & RTC_CONTROL0_LOW_BATTERY)
> + value |= RTC_VL_DATA_INVALID;
Shouldn't that one be RTC_VL_BACKUP_LOW?
Else, the driver is great, I'm ready to apply it.
> + return put_user(value, (unsigned int __user *)arg);
> +
> + default:
> + return -ENOIOCTLCMD;
> + }
> +}
> +
> static const struct rtc_class_ops gamecube_rtc_ops = {
> .read_time = gamecube_rtc_read_time,
> .set_time = gamecube_rtc_set_time,
> + .ioctl = gamecube_rtc_ioctl,
> };
>
> static int gamecube_rtc_read_offset_from_sram(struct priv *d)
> --
> 2.33.1
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH] bus: Make remove callback return void
On 06/07/2021 11:50:37+0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Signed-off-by: Uwe Kleine-König Acked-by: Alexandre Belloni > --- > Hello, > > this patch depends on "PCI: endpoint: Make struct pci_epf_driver::remove > return void" that is not yet applied, see > https://lore.kernel.org/r/20210223090757.57604-1-u.kleine-koe...@pengutronix.de. > > I tested it using allmodconfig on amd64 and arm, but I wouldn't be > surprised if I still missed to convert a driver. So it would be great to > get this into next early after the merge window closes. > > I send this mail to all people that get_maintainer.pl emits for this > patch. I wonder how many recipents will refuse this mail because of the > long Cc: list :-) > > Best regards > Uwe > > arch/arm/common/locomo.c | 3 +-- > arch/arm/common/sa.c | 4 +--- > arch/arm/mach-rpc/ecard.c | 4 +--- > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- > arch/parisc/kernel/drivers.c | 5 ++--- > arch/powerpc/platforms/ps3/system-bus.c | 3 +-- > arch/powerpc/platforms/pseries/ibmebus.c | 3 +-- > arch/powerpc/platforms/pseries/vio.c | 3 +-- > drivers/acpi/bus.c| 3 +-- > drivers/amba/bus.c| 4 +--- > drivers/base/auxiliary.c | 4 +--- > drivers/base/isa.c| 4 +--- > drivers/base/platform.c | 4 +--- > drivers/bcma/main.c | 6 ++ > drivers/bus/sunxi-rsb.c | 4 +--- > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/dma/idxd/sysfs.c | 4 +--- > drivers/firewire/core-device.c| 4 +--- > drivers/firmware/arm_scmi/bus.c | 4 +--- > drivers/firmware/google/coreboot_table.c | 4 +--- > drivers/fpga/dfl.c| 4 +--- > drivers/hid/hid-core.c| 4 +--- > drivers/hid/intel-ish-hid/ishtp/bus.c | 4 +--- > drivers/hv/vmbus_drv.c| 5 + > drivers/hwtracing/intel_th/core.c | 4 +--- > drivers/i2c/i2c-core-base.c | 5 + > drivers/i3c/master.c | 4 +--- > drivers/input/gameport/gameport.c | 3 +-- > drivers/input/serio/serio.c | 3 +-- > drivers/ipack/ipack.c | 4 +--- > drivers/macintosh/macio_asic.c| 4 +--- > drivers/mcb/mcb-core.c| 4 +--- > drivers/media/pci/bt8xx/bttv-gpio.c | 3 +-- > drivers/memstick/core/memstick.c | 3 +-- > drivers/mfd/mcp-core.c| 3 +-- > drivers/misc/mei/bus.c| 4 +--- > drivers/misc/tifm_core.c | 3 +-- > drivers/mmc/core/bus.c| 4 +--- > drivers/mmc/core/sdio_bus.c | 4 +--- > drivers/net/netdevsim/bus.c | 3 +-- > drivers/ntb/core.c| 4 +--- > drivers/ntb/ntb_transport.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- > drivers/pci/endpoint/pci-epf-core.c | 4 +--- > drivers/pci/pci-driver.c | 3 +-- > drivers/pcmcia/ds.c | 4 +--- > drivers/platform/surface/aggregator/bus.c | 4 +--- > drivers/platform/x86/wmi.c| 4 +--- > drivers/pnp/driver.c | 3 +-- > drivers/rapidio/rio-driver.c | 4 +--- > drivers/rpmsg/rpmsg_core.c| 4 +--- > drivers/scsi/scsi_debug.c | 3 +-- > drivers/siox/siox-core.c | 4 +--- > drivers/slimbus/core.c| 4 +--- > drivers/soc/qcom/apr.c| 4 +--- > drivers/spi/spi.c | 4 +--- > drivers/spmi/spmi.c | 3 +-- > drivers/ssb/main.c| 4 +--- > drivers/staging/fieldbus/anybuss/host.c | 4 +--- > drivers/staging/greybus/gbphy.c | 4 +--- > drivers/target/loopback/tcm_loop.c| 5 ++---
Re: [PATCH 04/17] rtc: cmos: remove cmos_rtc_ops_no_alarm
Hello, On 29/04/2021 02:49:46+0800, youling257 wrote: > this patch cause suspend failed on my Bay trail z3735f tablet. > > [ 162.038713] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x40 returns > -22 > [ 162.038760] alarmtimer alarmtimer.0.auto: PM: failed to suspend: error -22 I think I know what is happening, there is one patch I wanted to send this cycle but didn't, can you test it? https://github.com/alexandrebelloni/linux/commit/50641a5a19cedf7561410d7db614da46c228bacc Thanks for the report! -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH V3 -next] powerpc: kernel/time.c - cleanup warnings
On 24/03/2021 17:46:19+0800, heying (H) wrote: > Many thanks for your suggestion. As you suggest, rtc_lock should be local to > platforms. > > Does it mean not only powerpc but also all other platforms should adapt this > change? Not all the other ones, in the current state, x86 still needs it. I'll work on that. Again, the patch is fine as is. Reviewed-by: Alexandre Belloni -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH V3 -next] powerpc: kernel/time.c - cleanup warnings
On 24/03/2021 05:09:39-0400, He Ying wrote:
> We found these warnings in arch/powerpc/kernel/time.c as follows:
> warning: symbol 'decrementer_max' was not declared. Should it be static?
> warning: symbol 'rtc_lock' was not declared. Should it be static?
> warning: symbol 'dtl_consumer' was not declared. Should it be static?
>
> Declare 'decrementer_max' in powerpc asm/time.h.
> Include linux/mc146818rtc.h in powerpc kernel/time.c where 'rtc_lock'
> is declared. And remove duplicated declaration of 'rtc_lock' in powerpc
> platforms/chrp/time.c because it has included linux/mc146818rtc.h.
> Move 'dtl_consumer' definition behind "include " because it
> is declared there.
>
> Reported-by: Hulk Robot
> Signed-off-by: He Ying
> ---
> V2:
> - Instead of including linux/mc146818rtc.h in powerpc kernel/time.c, declare
> rtc_lock in powerpc asm/time.h.
> V3:
> - Recover to V1, that is including linux/mc146818rtc.h in powerpc
> kernel/time.c. And remove duplicated declaration of 'rtc_lock' in powerpc
> platforms/chrp/time.c because it has included linux/mc146818rtc.h.
>
> arch/powerpc/include/asm/time.h| 1 +
> arch/powerpc/kernel/time.c | 9 -
> arch/powerpc/platforms/chrp/time.c | 2 --
> 3 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
> index 8dd3cdb25338..2cd2b50bedda 100644
> --- a/arch/powerpc/include/asm/time.h
> +++ b/arch/powerpc/include/asm/time.h
> @@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy;
> extern unsigned long tb_ticks_per_usec;
> extern unsigned long tb_ticks_per_sec;
> extern struct clock_event_device decrementer_clockevent;
> +extern u64 decrementer_max;
>
>
> extern void generic_calibrate_decr(void);
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index b67d93a609a2..ac81f043bf49 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -55,8 +55,9 @@
> #include
> #include
> #include
> -#include
> +#include
I'm fine with that but I really think my suggestion to make the rtc_lock
local to the platforms was better because it is only used to synchronize
between concurrent invocations of chrp_set_rtc_time or
maple_set_rtc_time. The rtc core will never do that and the only case
would be concurrent calls to rtc_ops.set_time and
update_persistent_clock64 (which should also be removed at some point).
>
> +#include
> #include
> #include
> #include
> @@ -150,10 +151,6 @@ bool tb_invalid;
> u64 __cputime_usec_factor;
> EXPORT_SYMBOL(__cputime_usec_factor);
>
> -#ifdef CONFIG_PPC_SPLPAR
> -void (*dtl_consumer)(struct dtl_entry *, u64);
> -#endif
> -
> static void calc_cputime_factors(void)
> {
> struct div_result res;
> @@ -179,6 +176,8 @@ static inline unsigned long read_spurr(unsigned long tb)
>
> #include
>
> +void (*dtl_consumer)(struct dtl_entry *, u64);
> +
> /*
> * Scan the dispatch trace log and count up the stolen time.
> * Should be called with interrupts disabled.
> diff --git a/arch/powerpc/platforms/chrp/time.c
> b/arch/powerpc/platforms/chrp/time.c
> index acde7bbe0716..b94dfd5090d8 100644
> --- a/arch/powerpc/platforms/chrp/time.c
> +++ b/arch/powerpc/platforms/chrp/time.c
> @@ -30,8 +30,6 @@
>
> #include
>
> -extern spinlock_t rtc_lock;
> -
> #define NVRAM_AS0 0x74
> #define NVRAM_AS1 0x75
> #define NVRAM_DATA 0x77
> --
> 2.17.1
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v2 -next] powerpc: kernel/time.c - cleanup warnings
On 24/03/2021 09:19:58+0100, Geert Uytterhoeven wrote: > Hi Alexandre, > > On Tue, Mar 23, 2021 at 11:18 PM Alexandre Belloni > wrote: > > On 23/03/2021 05:12:57-0400, He Ying wrote: > > > We found these warnings in arch/powerpc/kernel/time.c as follows: > > > warning: symbol 'decrementer_max' was not declared. Should it be static? > > > warning: symbol 'rtc_lock' was not declared. Should it be static? > > > warning: symbol 'dtl_consumer' was not declared. Should it be static? > > > > > > Declare 'decrementer_max' and 'rtc_lock' in powerpc asm/time.h. > > > Rename 'rtc_lock' in drviers/rtc/rtc-vr41xx.c to 'vr41xx_rtc_lock' to > > > avoid the conflict with the variable in powerpc asm/time.h. > > > Move 'dtl_consumer' definition behind "include " because it > > > is declared there. > > > > > > Reported-by: Hulk Robot > > > Signed-off-by: He Ying > > > --- > > > v2: > > > - Instead of including linux/mc146818rtc.h in powerpc kernel/time.c, > > > declare > > > rtc_lock in powerpc asm/time.h. > > > > > > > V1 was actually the correct thing to do. rtc_lock is there exactly > > because chrp and maple are using mc146818 compatible RTCs. This is then > > useful because then drivers/char/nvram.c is enabled. The proper fix > > would be to scrap all of that and use rtc-cmos for those platforms as > > this drives the RTC properly and exposes the NVRAM for the mc146818. > > > > Or at least, if there are no users for the char/nvram driver on those > > two platforms, remove the spinlock and stop enabling CONFIG_NVRAM or > > more likely rename the symbol as it seems to be abused by both chrp and > > powermac. > > IIRC, on CHRP LongTrail, NVRAM was inherited from CHRP's Mac ancestry, > not from CHRP's PC ancestry, and thus NVRAM is not the one in the > mc146818-compatible RTC. > > http://users.telenet.be/geertu/Linux/PPC/DeviceTree.html confirms that, > showing that nvram is a different device node than rtc. > Yes, what I missed was the ifdefery in drivers/char/nvram.c that makes it a completely different driver on both platforms. I tend to forget about that as reading this driver is not a pleasant experience. I would really like to get rid of the x86 part which would in turn allow to remove the global rtc_lock spinlock on all architectures. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v2 -next] powerpc: kernel/time.c - cleanup warnings
On 23/03/2021 23:18:17+0100, Alexandre Belloni wrote: > Hello, > > On 23/03/2021 05:12:57-0400, He Ying wrote: > > We found these warnings in arch/powerpc/kernel/time.c as follows: > > warning: symbol 'decrementer_max' was not declared. Should it be static? > > warning: symbol 'rtc_lock' was not declared. Should it be static? > > warning: symbol 'dtl_consumer' was not declared. Should it be static? > > > > Declare 'decrementer_max' and 'rtc_lock' in powerpc asm/time.h. > > Rename 'rtc_lock' in drviers/rtc/rtc-vr41xx.c to 'vr41xx_rtc_lock' to > > avoid the conflict with the variable in powerpc asm/time.h. > > Move 'dtl_consumer' definition behind "include " because it > > is declared there. > > > > Reported-by: Hulk Robot > > Signed-off-by: He Ying > > --- > > v2: > > - Instead of including linux/mc146818rtc.h in powerpc kernel/time.c, declare > > rtc_lock in powerpc asm/time.h. > > > > V1 was actually the correct thing to do. rtc_lock is there exactly > because chrp and maple are using mc146818 compatible RTCs. This is then > useful because then drivers/char/nvram.c is enabled. The proper fix > would be to scrap all of that and use rtc-cmos for those platforms as > this drives the RTC properly and exposes the NVRAM for the mc146818. > > Or at least, if there are no users for the char/nvram driver on those > two platforms, remove the spinlock and stop enabling CONFIG_NVRAM or > more likely rename the symbol as it seems to be abused by both chrp and > powermac. > Ok so rtc_lock is not even used by the char/nvram.c driver as it is completely compiled out. I guess it is fine having it move to the individual platform as looking very quickly at the Kconfig, it is not possible to select both simultaneously. Tentative patch: 8<- >From dfa59b6f44fdfdefafffa7666aec89e62bbd5c80 Mon Sep 17 00:00:00 2001 From: Alexandre Belloni Date: Wed, 24 Mar 2021 00:00:03 +0100 Subject: [PATCH] powerpc: move rtc_lock to specific platforms Signed-off-by: Alexandre Belloni --- arch/powerpc/kernel/time.c | 3 --- arch/powerpc/platforms/chrp/time.c | 2 +- arch/powerpc/platforms/maple/time.c | 2 ++ 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 67feb3524460..d3bb189ea7f4 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -123,9 +123,6 @@ EXPORT_SYMBOL(tb_ticks_per_usec); unsigned long tb_ticks_per_sec; EXPORT_SYMBOL(tb_ticks_per_sec); /* for cputime_t conversions */ -DEFINE_SPINLOCK(rtc_lock); -EXPORT_SYMBOL_GPL(rtc_lock); - static u64 tb_to_ns_scale __read_mostly; static unsigned tb_to_ns_shift __read_mostly; static u64 boot_tb __read_mostly; diff --git a/arch/powerpc/platforms/chrp/time.c b/arch/powerpc/platforms/chrp/time.c index acde7bbe0716..ea90c15f5edd 100644 --- a/arch/powerpc/platforms/chrp/time.c +++ b/arch/powerpc/platforms/chrp/time.c @@ -30,7 +30,7 @@ #include -extern spinlock_t rtc_lock; +DEFINE_SPINLOCK(rtc_lock); #define NVRAM_AS0 0x74 #define NVRAM_AS1 0x75 diff --git a/arch/powerpc/platforms/maple/time.c b/arch/powerpc/platforms/maple/time.c index 78209bb7629c..ddda02010d86 100644 --- a/arch/powerpc/platforms/maple/time.c +++ b/arch/powerpc/platforms/maple/time.c @@ -34,6 +34,8 @@ #define DBG(x...) #endif +DEFINE_SPINLOCK(rtc_lock); + static int maple_rtc_addr; static int maple_clock_read(int addr) -- 2.25.1 > I'm not completely against the rename in vr41xxx but the fix for the > warnings can and should be contained in arch/powerpc. > > > arch/powerpc/include/asm/time.h | 3 +++ > > arch/powerpc/kernel/time.c | 6 ++ > > drivers/rtc/rtc-vr41xx.c| 22 +++--- > > 3 files changed, 16 insertions(+), 15 deletions(-) > > > > diff --git a/arch/powerpc/include/asm/time.h > > b/arch/powerpc/include/asm/time.h > > index 8dd3cdb25338..64a3ef0b4270 100644 > > --- a/arch/powerpc/include/asm/time.h > > +++ b/arch/powerpc/include/asm/time.h > > @@ -12,6 +12,7 @@ > > #ifdef __KERNEL__ > > #include > > #include > > +#include > > > > #include > > #include > > @@ -22,6 +23,8 @@ extern unsigned long tb_ticks_per_jiffy; > > extern unsigned long tb_ticks_per_usec; > > extern unsigned long tb_ticks_per_sec; > > extern struct clock_event_device decrementer_clockevent; > > +extern u64 decrementer_max; > > +extern spinlock_t rtc_lock; > > > > > > extern void generic_calibrate_decr(void); > > diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c > > index b67d93a609a2..60b6ac7d3685 100644 > > --- a/arch/powerpc/kernel/time.c > > +++ b/arch/
Re: [PATCH v2 -next] powerpc: kernel/time.c - cleanup warnings
ime64_to_tm((high << 17) | (mid << 1) | (low >> 15), time);
>
> @@ -159,7 +159,7 @@ static int vr41xx_rtc_set_alarm(struct device *dev,
> struct rtc_wkalrm *wkalrm)
>
> alarm_sec = rtc_tm_to_time64(>time);
>
> - spin_lock_irq(_lock);
> + spin_lock_irq(_rtc_lock);
>
> if (alarm_enabled)
> disable_irq(aie_irq);
> @@ -173,7 +173,7 @@ static int vr41xx_rtc_set_alarm(struct device *dev,
> struct rtc_wkalrm *wkalrm)
>
> alarm_enabled = wkalrm->enabled;
>
> - spin_unlock_irq(_lock);
> + spin_unlock_irq(_rtc_lock);
>
> return 0;
> }
> @@ -202,7 +202,7 @@ static int vr41xx_rtc_ioctl(struct device *dev, unsigned
> int cmd, unsigned long
>
> static int vr41xx_rtc_alarm_irq_enable(struct device *dev, unsigned int
> enabled)
> {
> - spin_lock_irq(_lock);
> + spin_lock_irq(_rtc_lock);
> if (enabled) {
> if (!alarm_enabled) {
> enable_irq(aie_irq);
> @@ -214,7 +214,7 @@ static int vr41xx_rtc_alarm_irq_enable(struct device
> *dev, unsigned int enabled)
> alarm_enabled = 0;
> }
> }
> - spin_unlock_irq(_lock);
> + spin_unlock_irq(_rtc_lock);
> return 0;
> }
>
> @@ -296,7 +296,7 @@ static int rtc_probe(struct platform_device *pdev)
> rtc->range_max = (1ULL << 33) - 1;
> rtc->max_user_freq = MAX_PERIODIC_RATE;
>
> - spin_lock_irq(_lock);
> + spin_lock_irq(_rtc_lock);
>
> rtc1_write(ECMPLREG, 0);
> rtc1_write(ECMPMREG, 0);
> @@ -304,7 +304,7 @@ static int rtc_probe(struct platform_device *pdev)
> rtc1_write(RTCL1LREG, 0);
> rtc1_write(RTCL1HREG, 0);
>
> - spin_unlock_irq(_lock);
> + spin_unlock_irq(_rtc_lock);
>
> aie_irq = platform_get_irq(pdev, 0);
> if (aie_irq <= 0) {
> --
> 2.17.1
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[PATCH 17/17] rtc: tps65910: remove tps65910_rtc_ops_noirq
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of
having a supplementary struct rtc_class_ops without alarm callbacks.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-tps65910.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-tps65910.c b/drivers/rtc/rtc-tps65910.c
index 2d87b62826a8..e1415a49f4ee 100644
--- a/drivers/rtc/rtc-tps65910.c
+++ b/drivers/rtc/rtc-tps65910.c
@@ -361,13 +361,6 @@ static const struct rtc_class_ops tps65910_rtc_ops = {
.set_offset = tps65910_set_offset,
};
-static const struct rtc_class_ops tps65910_rtc_ops_noirq = {
- .read_time = tps65910_rtc_read_time,
- .set_time = tps65910_rtc_set_time,
- .read_offset= tps65910_read_offset,
- .set_offset = tps65910_set_offset,
-};
-
static int tps65910_rtc_probe(struct platform_device *pdev)
{
struct tps65910 *tps65910 = NULL;
@@ -425,12 +418,12 @@ static int tps65910_rtc_probe(struct platform_device
*pdev)
irq = -1;
tps_rtc->irq = irq;
- if (irq != -1) {
+ if (irq != -1)
device_set_wakeup_capable(>dev, 1);
- tps_rtc->rtc->ops = _rtc_ops;
- } else
- tps_rtc->rtc->ops = _rtc_ops_noirq;
+ else
+ clear_bit(RTC_FEATURE_ALARM, tps_rtc->rtc->features);
+ tps_rtc->rtc->ops = _rtc_ops;
tps_rtc->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
tps_rtc->rtc->range_max = RTC_TIMESTAMP_END_2099;
--
2.29.2
[PATCH 16/17] rtc: rv8803: constify rv8803_rtc_ops
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available
instead of changing the global struct rtc_class_ops, allowing to make it
const.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-rv8803.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-rv8803.c b/drivers/rtc/rtc-rv8803.c
index d4ea6db51b26..8821264e9385 100644
--- a/drivers/rtc/rtc-rv8803.c
+++ b/drivers/rtc/rtc-rv8803.c
@@ -471,10 +471,13 @@ static int rv8803_nvram_read(void *priv, unsigned int
offset,
return 0;
}
-static struct rtc_class_ops rv8803_rtc_ops = {
+static const struct rtc_class_ops rv8803_rtc_ops = {
.read_time = rv8803_get_time,
.set_time = rv8803_set_time,
.ioctl = rv8803_ioctl,
+ .read_alarm = rv8803_get_alarm,
+ .set_alarm = rv8803_set_alarm,
+ .alarm_irq_enable = rv8803_alarm_irq_enable,
};
static int rx8900_trickle_charger_init(struct rv8803_data *rv8803)
@@ -567,12 +570,10 @@ static int rv8803_probe(struct i2c_client *client,
if (err) {
dev_warn(>dev, "unable to request IRQ, alarms
disabled\n");
client->irq = 0;
- } else {
- rv8803_rtc_ops.read_alarm = rv8803_get_alarm;
- rv8803_rtc_ops.set_alarm = rv8803_set_alarm;
- rv8803_rtc_ops.alarm_irq_enable =
rv8803_alarm_irq_enable;
}
}
+ if (!client->irq)
+ clear_bit(RTC_FEATURE_ALARM, rv8803->rtc->features);
err = rv8803_write_reg(rv8803->client, RV8803_EXT, RV8803_EXT_WADA);
if (err)
--
2.29.2
[PATCH 15/17] rtc: rv3032: constify rv3032_rtc_ops
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available
instead of changing the global struct rtc_class_ops, allowing to make it
const.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-rv3032.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-rv3032.c b/drivers/rtc/rtc-rv3032.c
index c9bcea727757..5161016bce00 100644
--- a/drivers/rtc/rtc-rv3032.c
+++ b/drivers/rtc/rtc-rv3032.c
@@ -804,12 +804,15 @@ static void rv3032_hwmon_register(struct device *dev)
devm_hwmon_device_register_with_info(dev, "rv3032", rv3032,
_hwmon_chip_info, NULL);
}
-static struct rtc_class_ops rv3032_rtc_ops = {
+static const struct rtc_class_ops rv3032_rtc_ops = {
.read_time = rv3032_get_time,
.set_time = rv3032_set_time,
.read_offset = rv3032_read_offset,
.set_offset = rv3032_set_offset,
.ioctl = rv3032_ioctl,
+ .read_alarm = rv3032_get_alarm,
+ .set_alarm = rv3032_set_alarm,
+ .alarm_irq_enable = rv3032_alarm_irq_enable,
};
static const struct regmap_config regmap_config = {
@@ -868,12 +871,10 @@ static int rv3032_probe(struct i2c_client *client)
if (ret) {
dev_warn(>dev, "unable to request IRQ, alarms
disabled\n");
client->irq = 0;
- } else {
- rv3032_rtc_ops.read_alarm = rv3032_get_alarm;
- rv3032_rtc_ops.set_alarm = rv3032_set_alarm;
- rv3032_rtc_ops.alarm_irq_enable =
rv3032_alarm_irq_enable;
}
}
+ if (!client->irq)
+ clear_bit(RTC_FEATURE_ALARM, rv3032->rtc->features);
ret = regmap_update_bits(rv3032->regmap, RV3032_CTRL1,
RV3032_CTRL1_WADA, RV3032_CTRL1_WADA);
--
2.29.2
[PATCH 13/17] rtc: rv3028: constify rv3028_rtc_ops
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available
instead of changing the global struct rtc_class_ops, allowing to make it
const.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-rv3028.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-rv3028.c b/drivers/rtc/rtc-rv3028.c
index 979407a51c7a..2004f8c5397f 100644
--- a/drivers/rtc/rtc-rv3028.c
+++ b/drivers/rtc/rtc-rv3028.c
@@ -770,9 +770,12 @@ static int rv3028_clkout_register_clk(struct rv3028_data
*rv3028,
}
#endif
-static struct rtc_class_ops rv3028_rtc_ops = {
+static const struct rtc_class_ops rv3028_rtc_ops = {
.read_time = rv3028_get_time,
.set_time = rv3028_set_time,
+ .read_alarm = rv3028_get_alarm,
+ .set_alarm = rv3028_set_alarm,
+ .alarm_irq_enable = rv3028_alarm_irq_enable,
.read_offset = rv3028_read_offset,
.set_offset = rv3028_set_offset,
.ioctl = rv3028_ioctl,
@@ -841,12 +844,10 @@ static int rv3028_probe(struct i2c_client *client)
if (ret) {
dev_warn(>dev, "unable to request IRQ, alarms
disabled\n");
client->irq = 0;
- } else {
- rv3028_rtc_ops.read_alarm = rv3028_get_alarm;
- rv3028_rtc_ops.set_alarm = rv3028_set_alarm;
- rv3028_rtc_ops.alarm_irq_enable =
rv3028_alarm_irq_enable;
}
}
+ if (!client->irq)
+ clear_bit(RTC_FEATURE_ALARM, rv3028->rtc->features);
ret = regmap_update_bits(rv3028->regmap, RV3028_CTRL1,
RV3028_CTRL1_WADA, RV3028_CTRL1_WADA);
--
2.29.2
[PATCH 14/17] rtc: rv3029: constify rv3029_rtc_ops
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available
instead of changing the global struct rtc_class_ops, allowing to make it
const.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-rv3029c2.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-rv3029c2.c b/drivers/rtc/rtc-rv3029c2.c
index dc1bda62095e..c1f4c0bba1e5 100644
--- a/drivers/rtc/rtc-rv3029c2.c
+++ b/drivers/rtc/rtc-rv3029c2.c
@@ -694,10 +694,13 @@ static void rv3029_hwmon_register(struct device *dev,
const char *name)
#endif /* CONFIG_RTC_DRV_RV3029_HWMON */
-static struct rtc_class_ops rv3029_rtc_ops = {
+static const struct rtc_class_ops rv3029_rtc_ops = {
.read_time = rv3029_read_time,
.set_time = rv3029_set_time,
.ioctl = rv3029_ioctl,
+ .read_alarm = rv3029_read_alarm,
+ .set_alarm = rv3029_set_alarm,
+ .alarm_irq_enable = rv3029_alarm_irq_enable,
};
static int rv3029_probe(struct device *dev, struct regmap *regmap, int irq,
@@ -739,12 +742,10 @@ static int rv3029_probe(struct device *dev, struct regmap
*regmap, int irq,
if (rc) {
dev_warn(dev, "unable to request IRQ, alarms
disabled\n");
rv3029->irq = 0;
- } else {
- rv3029_rtc_ops.read_alarm = rv3029_read_alarm;
- rv3029_rtc_ops.set_alarm = rv3029_set_alarm;
- rv3029_rtc_ops.alarm_irq_enable =
rv3029_alarm_irq_enable;
}
}
+ if (!rv3029->irq)
+ clear_bit(RTC_FEATURE_ALARM, rv3029->rtc->features);
rv3029->rtc->ops = _rtc_ops;
rv3029->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
--
2.29.2
[PATCH 12/17] rtc: opal: constify opal_rtc_ops
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available
instead of changing the global struct rtc_class_ops, allowing to make it
const.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-opal.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c
index c586f695bdc9..f8f49a969c23 100644
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -224,9 +224,12 @@ static int opal_tpo_alarm_irq_enable(struct device *dev,
unsigned int enabled)
return enabled ? 0 : opal_set_tpo_time(dev, );
}
-static struct rtc_class_ops opal_rtc_ops = {
+static const struct rtc_class_ops opal_rtc_ops = {
.read_time = opal_get_rtc_time,
.set_time = opal_set_rtc_time,
+ .read_alarm = opal_get_tpo_time,
+ .set_alarm = opal_set_tpo_time,
+ .alarm_irq_enable = opal_tpo_alarm_irq_enable,
};
static int opal_rtc_probe(struct platform_device *pdev)
@@ -239,12 +242,10 @@ static int opal_rtc_probe(struct platform_device *pdev)
if (pdev->dev.of_node &&
(of_property_read_bool(pdev->dev.of_node, "wakeup-source") ||
-of_property_read_bool(pdev->dev.of_node, "has-tpo")/* legacy */)) {
+of_property_read_bool(pdev->dev.of_node, "has-tpo")/* legacy */))
device_set_wakeup_capable(>dev, true);
- opal_rtc_ops.read_alarm = opal_get_tpo_time;
- opal_rtc_ops.set_alarm = opal_set_tpo_time;
- opal_rtc_ops.alarm_irq_enable = opal_tpo_alarm_irq_enable;
- }
+ else
+ clear_bit(RTC_FEATURE_ALARM, rtc->features);
rtc->ops = _rtc_ops;
rtc->range_min = RTC_TIMESTAMP_BEGIN_;
--
2.29.2
[PATCH 10/17] rtc: pcf85363: drop a struct rtc_class_ops
Merge both struct rtc_class_ops in a single one and use RTC_FEATURE_ALARM
to signal to the core whether alarms are available.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pcf85363.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
index a574c8d15a5c..8c2dcbac0d7b 100644
--- a/drivers/rtc/rtc-pcf85363.c
+++ b/drivers/rtc/rtc-pcf85363.c
@@ -285,11 +285,6 @@ static irqreturn_t pcf85363_rtc_handle_irq(int irq, void
*dev_id)
static const struct rtc_class_ops rtc_ops = {
.read_time = pcf85363_rtc_read_time,
.set_time = pcf85363_rtc_set_time,
-};
-
-static const struct rtc_class_ops rtc_ops_alarm = {
- .read_time = pcf85363_rtc_read_time,
- .set_time = pcf85363_rtc_set_time,
.read_alarm = pcf85363_rtc_read_alarm,
.set_alarm = pcf85363_rtc_set_alarm,
.alarm_irq_enable = pcf85363_rtc_alarm_irq_enable,
@@ -403,6 +398,7 @@ static int pcf85363_probe(struct i2c_client *client,
pcf85363->rtc->ops = _ops;
pcf85363->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
pcf85363->rtc->range_max = RTC_TIMESTAMP_END_2099;
+ clear_bit(RTC_FEATURE_ALARM, pcf85363->rtc->features);
if (client->irq > 0) {
regmap_write(pcf85363->regmap, CTRL_FLAGS, 0);
@@ -415,7 +411,7 @@ static int pcf85363_probe(struct i2c_client *client,
if (ret)
dev_warn(>dev, "unable to request IRQ, alarms
disabled\n");
else
- pcf85363->rtc->ops = _ops_alarm;
+ set_bit(RTC_FEATURE_ALARM, pcf85363->rtc->features);
}
ret = devm_rtc_register_device(pcf85363->rtc);
--
2.29.2
[PATCH 11/17] rtc: m41t80: constify m41t80_rtc_ops
Use RTC_FEATURE_ALARM to signal to the core whether alarms are available
instead of changing the global struct rtc_class_ops, allowing to make it
const.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-m41t80.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
index 160dcf68e64e..e3ddd660d68c 100644
--- a/drivers/rtc/rtc-m41t80.c
+++ b/drivers/rtc/rtc-m41t80.c
@@ -397,10 +397,13 @@ static int m41t80_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
return 0;
}
-static struct rtc_class_ops m41t80_rtc_ops = {
+static const struct rtc_class_ops m41t80_rtc_ops = {
.read_time = m41t80_rtc_read_time,
.set_time = m41t80_rtc_set_time,
.proc = m41t80_rtc_proc,
+ .read_alarm = m41t80_read_alarm,
+ .set_alarm = m41t80_set_alarm,
+ .alarm_irq_enable = m41t80_alarm_irq_enable,
};
#ifdef CONFIG_PM_SLEEP
@@ -913,13 +916,10 @@ static int m41t80_probe(struct i2c_client *client,
wakeup_source = false;
}
}
- if (client->irq > 0 || wakeup_source) {
- m41t80_rtc_ops.read_alarm = m41t80_read_alarm;
- m41t80_rtc_ops.set_alarm = m41t80_set_alarm;
- m41t80_rtc_ops.alarm_irq_enable = m41t80_alarm_irq_enable;
- /* Enable the wakealarm */
+ if (client->irq > 0 || wakeup_source)
device_init_wakeup(>dev, true);
- }
+ else
+ clear_bit(RTC_FEATURE_ALARM, m41t80_data->rtc->features);
m41t80_data->rtc->ops = _rtc_ops;
m41t80_data->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
--
2.29.2
[PATCH 05/17] rtc: mv: remove mv_rtc_alarm_ops
Move the alarm callbacks in mv_rtc_ops and clear RTC_FEATURE_ALARM to
signal that alarms are not available instead of having a supplementary
struct rtc_class_ops.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-mv.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/rtc/rtc-mv.c b/drivers/rtc/rtc-mv.c
index f8e2ecea1d8d..6c526e2ec56d 100644
--- a/drivers/rtc/rtc-mv.c
+++ b/drivers/rtc/rtc-mv.c
@@ -200,11 +200,6 @@ static irqreturn_t mv_rtc_interrupt(int irq, void *data)
static const struct rtc_class_ops mv_rtc_ops = {
.read_time = mv_rtc_read_time,
.set_time = mv_rtc_set_time,
-};
-
-static const struct rtc_class_ops mv_rtc_alarm_ops = {
- .read_time = mv_rtc_read_time,
- .set_time = mv_rtc_set_time,
.read_alarm = mv_rtc_read_alarm,
.set_alarm = mv_rtc_set_alarm,
.alarm_irq_enable = mv_rtc_alarm_irq_enable,
@@ -268,13 +263,12 @@ static int __init mv_rtc_probe(struct platform_device
*pdev)
}
}
- if (pdata->irq >= 0) {
+ if (pdata->irq >= 0)
device_init_wakeup(>dev, 1);
- pdata->rtc->ops = _rtc_alarm_ops;
- } else {
- pdata->rtc->ops = _rtc_ops;
- }
+ else
+ clear_bit(RTC_FEATURE_ALARM, pdata->rtc->features);
+ pdata->rtc->ops = _rtc_ops;
pdata->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
pdata->rtc->range_max = RTC_TIMESTAMP_END_2099;
--
2.29.2
[PATCH 06/17] rtc: m48t59: remove m48t02_rtc_ops
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of
having a supplementary struct rtc_class_ops without alarm callbacks.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-m48t59.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
index 5f5898d3b055..1d2e99a70fce 100644
--- a/drivers/rtc/rtc-m48t59.c
+++ b/drivers/rtc/rtc-m48t59.c
@@ -313,11 +313,6 @@ static const struct rtc_class_ops m48t59_rtc_ops = {
.alarm_irq_enable = m48t59_rtc_alarm_irq_enable,
};
-static const struct rtc_class_ops m48t02_rtc_ops = {
- .read_time = m48t59_rtc_read_time,
- .set_time = m48t59_rtc_set_time,
-};
-
static int m48t59_nvram_read(void *priv, unsigned int offset, void *val,
size_t size)
{
@@ -366,7 +361,6 @@ static int m48t59_rtc_probe(struct platform_device *pdev)
struct m48t59_private *m48t59 = NULL;
struct resource *res;
int ret = -ENOMEM;
- const struct rtc_class_ops *ops;
struct nvmem_config nvmem_cfg = {
.name = "m48t59-",
.word_size = 1,
@@ -438,17 +432,21 @@ static int m48t59_rtc_probe(struct platform_device *pdev)
if (ret)
return ret;
}
+
+ m48t59->rtc = devm_rtc_allocate_device(>dev);
+ if (IS_ERR(m48t59->rtc))
+ return PTR_ERR(m48t59->rtc);
+
switch (pdata->type) {
case M48T59RTC_TYPE_M48T59:
- ops = _rtc_ops;
pdata->offset = 0x1ff0;
break;
case M48T59RTC_TYPE_M48T02:
- ops = _rtc_ops;
+ clear_bit(RTC_FEATURE_ALARM, m48t59->rtc->features);
pdata->offset = 0x7f0;
break;
case M48T59RTC_TYPE_M48T08:
- ops = _rtc_ops;
+ clear_bit(RTC_FEATURE_ALARM, m48t59->rtc->features);
pdata->offset = 0x1ff0;
break;
default:
@@ -459,11 +457,7 @@ static int m48t59_rtc_probe(struct platform_device *pdev)
spin_lock_init(>lock);
platform_set_drvdata(pdev, m48t59);
- m48t59->rtc = devm_rtc_allocate_device(>dev);
- if (IS_ERR(m48t59->rtc))
- return PTR_ERR(m48t59->rtc);
-
- m48t59->rtc->ops = ops;
+ m48t59->rtc->ops = _rtc_ops;
nvmem_cfg.size = pdata->offset;
ret = devm_rtc_nvmem_register(m48t59->rtc, _cfg);
--
2.29.2
[PATCH 09/17] rtc: rx8010: drop a struct rtc_class_ops
Merge both struct rtc_class_ops in a single one and use RTC_FEATURE_ALARM
to signal to the core whether alarms are available.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-rx8010.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 8340ab47a059..1a05e4654290 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -354,13 +354,7 @@ static int rx8010_ioctl(struct device *dev, unsigned int
cmd, unsigned long arg)
}
}
-static const struct rtc_class_ops rx8010_rtc_ops_default = {
- .read_time = rx8010_get_time,
- .set_time = rx8010_set_time,
- .ioctl = rx8010_ioctl,
-};
-
-static const struct rtc_class_ops rx8010_rtc_ops_alarm = {
+static const struct rtc_class_ops rx8010_rtc_ops = {
.read_time = rx8010_get_time,
.set_time = rx8010_set_time,
.ioctl = rx8010_ioctl,
@@ -409,12 +403,11 @@ static int rx8010_probe(struct i2c_client *client)
dev_err(dev, "unable to request IRQ\n");
return err;
}
-
- rx8010->rtc->ops = _rtc_ops_alarm;
} else {
- rx8010->rtc->ops = _rtc_ops_default;
+ clear_bit(RTC_FEATURE_ALARM, rx8010->rtc->features);
}
+ rx8010->rtc->ops = _rtc_ops;
rx8010->rtc->max_user_freq = 1;
rx8010->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
rx8010->rtc->range_max = RTC_TIMESTAMP_END_2099;
--
2.29.2
[PATCH 08/17] rtc: pcf85063: remove pcf85063_rtc_ops_alarm
Move the alarm callbacks in pcf85063_rtc_ops and use RTC_FEATURE_ALARM to
signal to the core whether alarms are available instead of having a
supplementary struct rtc_class_ops without alarm callbacks.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pcf85063.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
index e19cf2adbc35..f7e7c9eb0781 100644
--- a/drivers/rtc/rtc-pcf85063.c
+++ b/drivers/rtc/rtc-pcf85063.c
@@ -307,14 +307,6 @@ static int pcf85063_ioctl(struct device *dev, unsigned int
cmd,
}
static const struct rtc_class_ops pcf85063_rtc_ops = {
- .read_time = pcf85063_rtc_read_time,
- .set_time = pcf85063_rtc_set_time,
- .read_offset= pcf85063_read_offset,
- .set_offset = pcf85063_set_offset,
- .ioctl = pcf85063_ioctl,
-};
-
-static const struct rtc_class_ops pcf85063_rtc_ops_alarm = {
.read_time = pcf85063_rtc_read_time,
.set_time = pcf85063_rtc_set_time,
.read_offset= pcf85063_read_offset,
@@ -587,6 +579,7 @@ static int pcf85063_probe(struct i2c_client *client)
pcf85063->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
pcf85063->rtc->range_max = RTC_TIMESTAMP_END_2099;
pcf85063->rtc->uie_unsupported = 1;
+ clear_bit(RTC_FEATURE_ALARM, pcf85063->rtc->features);
if (config->has_alarms && client->irq > 0) {
err = devm_request_threaded_irq(>dev, client->irq,
@@ -597,7 +590,7 @@ static int pcf85063_probe(struct i2c_client *client)
dev_warn(>rtc->dev,
"unable to request IRQ, alarms disabled\n");
} else {
- pcf85063->rtc->ops = _rtc_ops_alarm;
+ set_bit(RTC_FEATURE_ALARM, pcf85063->rtc->features);
device_init_wakeup(>dev, true);
err = dev_pm_set_wake_irq(>dev, client->irq);
if (err)
--
2.29.2
[PATCH 07/17] rtc: pcf2127: remove pcf2127_rtc_alrm_ops
Move the alarm callbacks in pcf2127_rtc_ops and use RTC_FEATURE_ALARM to
signal to the core whether alarms are available instead of having a
supplementary struct rtc_class_ops without alarm callbacks.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pcf2127.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index 39a7b5116aa4..68160d857ac1 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -225,12 +225,6 @@ static int pcf2127_rtc_ioctl(struct device *dev,
}
}
-static const struct rtc_class_ops pcf2127_rtc_ops = {
- .ioctl = pcf2127_rtc_ioctl,
- .read_time = pcf2127_rtc_read_time,
- .set_time = pcf2127_rtc_set_time,
-};
-
static int pcf2127_nvmem_read(void *priv, unsigned int offset,
void *val, size_t bytes)
{
@@ -459,7 +453,7 @@ static irqreturn_t pcf2127_rtc_irq(int irq, void *dev)
return IRQ_HANDLED;
}
-static const struct rtc_class_ops pcf2127_rtc_alrm_ops = {
+static const struct rtc_class_ops pcf2127_rtc_ops = {
.ioctl= pcf2127_rtc_ioctl,
.read_time= pcf2127_rtc_read_time,
.set_time = pcf2127_rtc_set_time,
@@ -584,6 +578,7 @@ static int pcf2127_probe(struct device *dev, struct regmap
*regmap,
pcf2127->rtc->range_max = RTC_TIMESTAMP_END_2099;
pcf2127->rtc->set_start_time = true; /* Sets actual start to 1970 */
pcf2127->rtc->uie_unsupported = 1;
+ clear_bit(RTC_FEATURE_ALARM, pcf2127->rtc->features);
if (alarm_irq > 0) {
ret = devm_request_threaded_irq(dev, alarm_irq, NULL,
@@ -598,7 +593,7 @@ static int pcf2127_probe(struct device *dev, struct regmap
*regmap,
if (alarm_irq > 0 || device_property_read_bool(dev, "wakeup-source")) {
device_init_wakeup(dev, true);
- pcf2127->rtc->ops = _rtc_alrm_ops;
+ set_bit(RTC_FEATURE_ALARM, pcf2127->rtc->features);
}
if (has_nvmem) {
--
2.29.2
[PATCH 04/17] rtc: cmos: remove cmos_rtc_ops_no_alarm
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of
having a supplementary struct rtc_class_ops with a NULL .set_alarm.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-cmos.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 51e80bc70d42..c3746e249f5a 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -574,12 +574,6 @@ static const struct rtc_class_ops cmos_rtc_ops = {
.alarm_irq_enable = cmos_alarm_irq_enable,
};
-static const struct rtc_class_ops cmos_rtc_ops_no_alarm = {
- .read_time = cmos_read_time,
- .set_time = cmos_set_time,
- .proc = cmos_procfs,
-};
-
/**/
/*
@@ -857,12 +851,12 @@ cmos_do_probe(struct device *dev, struct resource *ports,
int rtc_irq)
dev_dbg(dev, "IRQ %d is already in use\n", rtc_irq);
goto cleanup1;
}
-
- cmos_rtc.rtc->ops = _rtc_ops;
} else {
- cmos_rtc.rtc->ops = _rtc_ops_no_alarm;
+ clear_bit(RTC_FEATURE_ALARM, cmos_rtc.rtc->features);
}
+ cmos_rtc.rtc->ops = _rtc_ops;
+
retval = devm_rtc_register_device(cmos_rtc.rtc);
if (retval)
goto cleanup2;
--
2.29.2
[PATCH 03/17] rtc: armada38x: remove armada38x_rtc_ops_noirq
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of
having a supplementary struct rtc_class_ops with a NULL .set_alarm.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-armada38x.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
index 807a79c07f08..cc542e6b1d5b 100644
--- a/drivers/rtc/rtc-armada38x.c
+++ b/drivers/rtc/rtc-armada38x.c
@@ -458,14 +458,6 @@ static const struct rtc_class_ops armada38x_rtc_ops = {
.set_offset = armada38x_rtc_set_offset,
};
-static const struct rtc_class_ops armada38x_rtc_ops_noirq = {
- .read_time = armada38x_rtc_read_time,
- .set_time = armada38x_rtc_set_time,
- .read_alarm = armada38x_rtc_read_alarm,
- .read_offset = armada38x_rtc_read_offset,
- .set_offset = armada38x_rtc_set_offset,
-};
-
static const struct armada38x_rtc_data armada38x_data = {
.update_mbus_timing = rtc_update_38x_mbus_timing_params,
.read_rtc_reg = read_rtc_register_38x_wa,
@@ -540,20 +532,15 @@ static __init int armada38x_rtc_probe(struct
platform_device *pdev)
}
platform_set_drvdata(pdev, rtc);
- if (rtc->irq != -1) {
+ if (rtc->irq != -1)
device_init_wakeup(>dev, 1);
- rtc->rtc_dev->ops = _rtc_ops;
- } else {
- /*
-* If there is no interrupt available then we can't
-* use the alarm
-*/
- rtc->rtc_dev->ops = _rtc_ops_noirq;
- }
+ else
+ clear_bit(RTC_FEATURE_ALARM, rtc->rtc_dev->features);
/* Update RTC-MBUS bridge timing parameters */
rtc->data->update_mbus_timing(rtc);
+ rtc->rtc_dev->ops = _rtc_ops;
rtc->rtc_dev->range_max = U32_MAX;
return devm_rtc_register_device(rtc->rtc_dev);
--
2.29.2
[PATCH 01/17] rtc: introduce features bitfield
Introduce a bitfield to allow the drivers to announce the available
features for an RTC.
The main use case would be to better handle alarms, that could be present
or not or have a minute resolution or may need a correct week day to be set.
Use the newly introduced RTC_FEATURE_ALARM bit to then test whether alarms
are available instead of relying on the presence of ops->set_alarm.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/class.c | 5 +
drivers/rtc/interface.c | 12 ++--
include/linux/rtc.h | 2 ++
include/uapi/linux/rtc.h | 5 +
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 7e470fbd5e4d..03abd0aa229a 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -231,6 +231,8 @@ static struct rtc_device *rtc_allocate_device(void)
rtc->pie_timer.function = rtc_pie_update_irq;
rtc->pie_enabled = 0;
+ set_bit(RTC_FEATURE_ALARM, rtc->features);
+
return rtc;
}
@@ -386,6 +388,9 @@ int __devm_rtc_register_device(struct module *owner, struct
rtc_device *rtc)
return -EINVAL;
}
+ if (!rtc->ops->set_alarm)
+ clear_bit(RTC_FEATURE_ALARM, rtc->features);
+
rtc->owner = owner;
rtc_device_get_offset(rtc);
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 794a4f036b99..dcb34c73319e 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -186,7 +186,7 @@ static int rtc_read_alarm_internal(struct rtc_device *rtc,
if (!rtc->ops) {
err = -ENODEV;
- } else if (!rtc->ops->read_alarm) {
+ } else if (!test_bit(RTC_FEATURE_ALARM, rtc->features) ||
!rtc->ops->read_alarm) {
err = -EINVAL;
} else {
alarm->enabled = 0;
@@ -392,7 +392,7 @@ int rtc_read_alarm(struct rtc_device *rtc, struct
rtc_wkalrm *alarm)
return err;
if (!rtc->ops) {
err = -ENODEV;
- } else if (!rtc->ops->read_alarm) {
+ } else if (!test_bit(RTC_FEATURE_ALARM, rtc->features) ||
!rtc->ops->read_alarm) {
err = -EINVAL;
} else {
memset(alarm, 0, sizeof(struct rtc_wkalrm));
@@ -436,7 +436,7 @@ static int __rtc_set_alarm(struct rtc_device *rtc, struct
rtc_wkalrm *alarm)
if (!rtc->ops)
err = -ENODEV;
- else if (!rtc->ops->set_alarm)
+ else if (!test_bit(RTC_FEATURE_ALARM, rtc->features))
err = -EINVAL;
else
err = rtc->ops->set_alarm(rtc->dev.parent, alarm);
@@ -451,7 +451,7 @@ int rtc_set_alarm(struct rtc_device *rtc, struct rtc_wkalrm
*alarm)
if (!rtc->ops)
return -ENODEV;
- else if (!rtc->ops->set_alarm)
+ else if (!test_bit(RTC_FEATURE_ALARM, rtc->features))
return -EINVAL;
err = rtc_valid_tm(>time);
@@ -531,7 +531,7 @@ int rtc_alarm_irq_enable(struct rtc_device *rtc, unsigned
int enabled)
/* nothing */;
else if (!rtc->ops)
err = -ENODEV;
- else if (!rtc->ops->alarm_irq_enable)
+ else if (!test_bit(RTC_FEATURE_ALARM, rtc->features) ||
!rtc->ops->alarm_irq_enable)
err = -EINVAL;
else
err = rtc->ops->alarm_irq_enable(rtc->dev.parent, enabled);
@@ -843,7 +843,7 @@ static int rtc_timer_enqueue(struct rtc_device *rtc, struct
rtc_timer *timer)
static void rtc_alarm_disable(struct rtc_device *rtc)
{
- if (!rtc->ops || !rtc->ops->alarm_irq_enable)
+ if (!rtc->ops || !test_bit(RTC_FEATURE_ALARM, rtc->features) ||
!rtc->ops->alarm_irq_enable)
return;
rtc->ops->alarm_irq_enable(rtc->dev.parent, false);
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 568909449c13..bd611e26291d 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -141,6 +141,8 @@ struct rtc_device {
*/
unsigned long set_offset_nsec;
+ unsigned long features[BITS_TO_LONGS(RTC_FEATURE_CNT)];
+
time64_t range_min;
timeu64_t range_max;
time64_t start_secs;
diff --git a/include/uapi/linux/rtc.h b/include/uapi/linux/rtc.h
index fa9aff91cbf2..f950bff75e97 100644
--- a/include/uapi/linux/rtc.h
+++ b/include/uapi/linux/rtc.h
@@ -110,6 +110,11 @@ struct rtc_pll_info {
#define RTC_AF 0x20/* Alarm interrupt */
#define RTC_UF 0x10/* Update interrupt for 1Hz RTC */
+/* feature list */
+#define RTC_FEATURE_ALARM 0
+#define RTC_FEATURE_ALARM_RES_MINUTE 1
+#define RTC_FEATURE_NEED_WEEK_DAY 2
+#define RTC_FEATURE_CNT3
#define RTC_MAX_FREQ 8192
--
2.29.2
[PATCH 00/17] rtc: constify all rtc_class_ops
Hello, This first introduces a features bitfield that is used to handle the presence or absence of alarms instead of relying only on the presence of the alarm callbacks. The drivers modifying a struct rtc_class_ops or using two different structures are then converted. Alexandre Belloni (17): rtc: introduce features bitfield rtc: pl031: use RTC_FEATURE_ALARM rtc: armada38x: remove armada38x_rtc_ops_noirq rtc: cmos: remove cmos_rtc_ops_no_alarm rtc: mv: remove mv_rtc_alarm_ops rtc: m48t59: remove m48t02_rtc_ops rtc: pcf2127: remove pcf2127_rtc_alrm_ops rtc: pcf85063: remove pcf85063_rtc_ops_alarm rtc: rx8010: drop a struct rtc_class_ops rtc: pcf85363: drop a struct rtc_class_ops rtc: m41t80: constify m41t80_rtc_ops rtc: opal: constify opal_rtc_ops rtc: rv3028: constify rv3028_rtc_ops rtc: rv3029: constify rv3029_rtc_ops rtc: rv3032: constify rv3032_rtc_ops rtc: rv8803: constify rv8803_rtc_ops rtc: tps65910: remove tps65910_rtc_ops_noirq drivers/rtc/class.c | 5 + drivers/rtc/interface.c | 12 ++-- drivers/rtc/rtc-armada38x.c | 21 - drivers/rtc/rtc-cmos.c | 12 +++- drivers/rtc/rtc-m41t80.c| 14 +++--- drivers/rtc/rtc-m48t59.c| 22 -- drivers/rtc/rtc-mv.c| 14 -- drivers/rtc/rtc-opal.c | 13 +++-- drivers/rtc/rtc-pcf2127.c | 11 +++ drivers/rtc/rtc-pcf85063.c | 11 ++- drivers/rtc/rtc-pcf85363.c | 8 ++-- drivers/rtc/rtc-pl031.c | 8 ++-- drivers/rtc/rtc-rv3028.c| 11 ++- drivers/rtc/rtc-rv3029c2.c | 11 ++- drivers/rtc/rtc-rv3032.c| 11 ++- drivers/rtc/rtc-rv8803.c| 11 ++- drivers/rtc/rtc-rx8010.c| 13 +++-- drivers/rtc/rtc-tps65910.c | 15 --- include/linux/rtc.h | 2 ++ include/uapi/linux/rtc.h| 5 + 20 files changed, 91 insertions(+), 139 deletions(-) -- 2.29.2
[PATCH 02/17] rtc: pl031: use RTC_FEATURE_ALARM
Clear RTC_FEATURE_ALARM instead of setting set_alarm, read_alarm and
alarm_irq_enable to NULL.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-pl031.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 224bbf096262..7c3967df4f9a 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -352,12 +352,8 @@ static int pl031_probe(struct amba_device *adev, const
struct amba_id *id)
}
}
- if (!adev->irq[0]) {
- /* When there's no interrupt, no point in exposing the alarm */
- ops->read_alarm = NULL;
- ops->set_alarm = NULL;
- ops->alarm_irq_enable = NULL;
- }
+ if (!adev->irq[0])
+ clear_bit(RTC_FEATURE_ALARM, ldata->rtc->features);
device_init_wakeup(>dev, true);
ldata->rtc = devm_rtc_allocate_device(>dev);
--
2.29.2
[PATCH] rtc: opal: set range
It is a BCD RTC with 4 digits for the year.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-opal.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-opal.c b/drivers/rtc/rtc-opal.c
index 7b9f8bcf86fe..c586f695bdc9 100644
--- a/drivers/rtc/rtc-opal.c
+++ b/drivers/rtc/rtc-opal.c
@@ -233,6 +233,10 @@ static int opal_rtc_probe(struct platform_device *pdev)
{
struct rtc_device *rtc;
+ rtc = devm_rtc_allocate_device(>dev);
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
+
if (pdev->dev.of_node &&
(of_property_read_bool(pdev->dev.of_node, "wakeup-source") ||
of_property_read_bool(pdev->dev.of_node, "has-tpo")/* legacy */)) {
@@ -242,14 +246,12 @@ static int opal_rtc_probe(struct platform_device *pdev)
opal_rtc_ops.alarm_irq_enable = opal_tpo_alarm_irq_enable;
}
- rtc = devm_rtc_device_register(>dev, DRVNAME, _rtc_ops,
- THIS_MODULE);
- if (IS_ERR(rtc))
- return PTR_ERR(rtc);
-
+ rtc->ops = _rtc_ops;
+ rtc->range_min = RTC_TIMESTAMP_BEGIN_;
+ rtc->range_max = RTC_TIMESTAMP_END_;
rtc->uie_unsupported = 1;
- return 0;
+ return devm_rtc_register_device(rtc);
}
static const struct of_device_id opal_rtc_match[] = {
--
2.29.2
Re: [PATCH v2 0/5] drop unused BACKLIGHT_GENERIC option
Hi,
On 08/12/2020 17:34:46+0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On Tue, 1 Dec 2020 22:29:17 +, Andrey Zhizhikin wrote:
> > Since the removal of generic_bl driver from the source tree in commit
> > 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> > unused") BACKLIGHT_GENERIC config option became obsolete as well and
> > therefore subject to clean-up from all configuration files.
> >
> > This series introduces patches to address this removal, separated by
> > architectures in the kernel tree.
> >
> > [...]
>
> While my plan was to only take the arm specific patches, it seems
> nobody else has applied the other architecture specific ones,
> but there have been a lot of Acks. Also, b4 makes it easy to
> merge the entire branch, so I'll just take all of these.
>
> Applied to arm/defconfig, thanks!
>
> [1/5] ARM: configs: drop unused BACKLIGHT_GENERIC option
> commit: 0437141b4e2233ae0109a9584e7a003cd05b0a20
> [2/5] arm64: defconfig: drop unused BACKLIGHT_GENERIC option
> commit: 717c4c8336486781630893508b3347ae18953fae
> [3/5] MIPS: configs: drop unused BACKLIGHT_GENERIC option
> commit: 2257682282531de45929c6006152f6e2ee881b42
Thomas did applied this one:
https://lore.kernel.org/linux-arm-kernel/20201204120632.ga10...@alpha.franken.de/
> [4/5] parisc: configs: drop unused BACKLIGHT_GENERIC option
> commit: 4e9c44b128d3eb5da129e53c7312240f838c2dbf
> [5/5] powerpc/configs: drop unused BACKLIGHT_GENERIC option
> commit: 4985c506303fb6a41a885d503a6e1f3d3126431d
>
>Arnd
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 1/5] ARM: configs: drop unused BACKLIGHT_GENERIC option
On 01/12/2020 14:40:53+, Catalin Marinas wrote:
> On Mon, Nov 30, 2020 at 07:50:25PM +, ZHIZHIKIN Andrey wrote:
> > From Krzysztof Kozlowski :
> > > On Mon, Nov 30, 2020 at 03:21:33PM +, Andrey Zhizhikin wrote:
> > > > Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> > > > unused") removed geenric_bl driver from the tree, together with
> > > > corresponding config option.
> > > >
> > > > Remove BACKLIGHT_GENERIC config item from all ARM configurations.
> > > >
> > > > Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it
> > > > is unused")
> > > > Cc: Sam Ravnborg
> > > > Signed-off-by: Andrey Zhizhikin
> > > >
> > > > ---
> > > > arch/arm/configs/at91_dt_defconfig| 1 -
> > > > arch/arm/configs/cm_x300_defconfig| 1 -
> > > > arch/arm/configs/colibri_pxa300_defconfig | 1 -
> > > > arch/arm/configs/jornada720_defconfig | 1 -
> > > > arch/arm/configs/magician_defconfig | 1 -
> > > > arch/arm/configs/mini2440_defconfig | 1 -
> > > > arch/arm/configs/omap2plus_defconfig | 1 -
> > > > arch/arm/configs/pxa3xx_defconfig | 1 -
> > > > arch/arm/configs/qcom_defconfig | 1 -
> > > > arch/arm/configs/sama5_defconfig | 1 -
> > > > arch/arm/configs/sunxi_defconfig | 1 -
> > > > arch/arm/configs/tegra_defconfig | 1 -
> > > > arch/arm/configs/u8500_defconfig | 1 -
> > > > 13 files changed, 13 deletions(-)
> > >
> > > You need to send it to arm-soc maintainers, otherwise no one might feel
> > > responsible enough to pick it up.
> >
> > Good point, thanks a lot!
> >
> > I was not aware of the fact that there is a separate ML that should
> > receive patches targeted ARM SOCs. Can you (or anyone else) please
> > share it, so I can re-send it there as well?
>
> It's not a mailing list as such (with archives etc.), just an alias to
> the arm-soc maintainers: a...@kernel.org.
>
> > > Reviewed-by: Krzysztof Kozlowski
> > >
> > > +CC Arnd and Olof,
> > >
> > > Dear Arnd and Olof,
> > >
> > > Maybe it is worth to add arm-soc entry to the MAINTAINERS file?
> > > Otherwise how one could get your email address? Not mentioning the
> > > secret-soc address. :)
>
> I tried to convince them before, it didn't work. I guess they don't like
> to be spammed ;).
The first rule of arm-soc is: you do not talk about arm@ and soc@
> Or rather, SoC-specific patches, even to defconfig,
> should go through the specific SoC maintainers. However, there are
> occasional defconfig patches which are more generic or affecting
> multiple SoCs. I just ignore them as the arm64 defconfig is usually
> handled by the arm-soc folk (when I need a defconfig change, I go for
> arch/arm64/Kconfig directly ;)).
>
IIRC, the plan was indeed to get defconfig changes through the platform
sub-trees. It is also supposed to be how multi_v5 and multi_v7 are
handled and they will take care of the merge.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 1/5] ARM: configs: drop unused BACKLIGHT_GENERIC option
On 30/11/2020 15:21:33+, Andrey Zhizhikin wrote:
> Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused") removed geenric_bl driver from the tree, together with
> corresponding config option.
>
> Remove BACKLIGHT_GENERIC config item from all ARM configurations.
>
> Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused")
> Cc: Sam Ravnborg
> Signed-off-by: Andrey Zhizhikin
Acked-by: Alexandre Belloni
> ---
> arch/arm/configs/at91_dt_defconfig| 1 -
> arch/arm/configs/cm_x300_defconfig| 1 -
> arch/arm/configs/colibri_pxa300_defconfig | 1 -
> arch/arm/configs/jornada720_defconfig | 1 -
> arch/arm/configs/magician_defconfig | 1 -
> arch/arm/configs/mini2440_defconfig | 1 -
> arch/arm/configs/omap2plus_defconfig | 1 -
> arch/arm/configs/pxa3xx_defconfig | 1 -
> arch/arm/configs/qcom_defconfig | 1 -
> arch/arm/configs/sama5_defconfig | 1 -
> arch/arm/configs/sunxi_defconfig | 1 -
> arch/arm/configs/tegra_defconfig | 1 -
> arch/arm/configs/u8500_defconfig | 1 -
> 13 files changed, 13 deletions(-)
>
> diff --git a/arch/arm/configs/at91_dt_defconfig
> b/arch/arm/configs/at91_dt_defconfig
> index 4a0ba2ae1a25..6e52c9c965e6 100644
> --- a/arch/arm/configs/at91_dt_defconfig
> +++ b/arch/arm/configs/at91_dt_defconfig
> @@ -132,7 +132,6 @@ CONFIG_DRM_ATMEL_HLCDC=y
> CONFIG_DRM_PANEL_SIMPLE=y
> CONFIG_FB_ATMEL=y
> CONFIG_BACKLIGHT_ATMEL_LCDC=y
> -# CONFIG_BACKLIGHT_GENERIC is not set
> CONFIG_BACKLIGHT_PWM=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_LOGO=y
> diff --git a/arch/arm/configs/cm_x300_defconfig
> b/arch/arm/configs/cm_x300_defconfig
> index 2f7acde2d921..502a9d870ca4 100644
> --- a/arch/arm/configs/cm_x300_defconfig
> +++ b/arch/arm/configs/cm_x300_defconfig
> @@ -87,7 +87,6 @@ CONFIG_FB=y
> CONFIG_FB_PXA=y
> CONFIG_LCD_CLASS_DEVICE=y
> CONFIG_LCD_TDO24M=y
> -# CONFIG_BACKLIGHT_GENERIC is not set
> CONFIG_BACKLIGHT_DA903X=m
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> diff --git a/arch/arm/configs/colibri_pxa300_defconfig
> b/arch/arm/configs/colibri_pxa300_defconfig
> index 0dae3b185284..26e5a67f8e2d 100644
> --- a/arch/arm/configs/colibri_pxa300_defconfig
> +++ b/arch/arm/configs/colibri_pxa300_defconfig
> @@ -34,7 +34,6 @@ CONFIG_FB=y
> CONFIG_FB_PXA=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> -# CONFIG_BACKLIGHT_GENERIC is not set
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_LOGO=y
> diff --git a/arch/arm/configs/jornada720_defconfig
> b/arch/arm/configs/jornada720_defconfig
> index 9f079be2b84b..069f60ffdcd8 100644
> --- a/arch/arm/configs/jornada720_defconfig
> +++ b/arch/arm/configs/jornada720_defconfig
> @@ -48,7 +48,6 @@ CONFIG_FB=y
> CONFIG_FB_S1D13XXX=y
> CONFIG_LCD_CLASS_DEVICE=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> -# CONFIG_BACKLIGHT_GENERIC is not set
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> diff --git a/arch/arm/configs/magician_defconfig
> b/arch/arm/configs/magician_defconfig
> index d2e684f6565a..b4670d42f378 100644
> --- a/arch/arm/configs/magician_defconfig
> +++ b/arch/arm/configs/magician_defconfig
> @@ -95,7 +95,6 @@ CONFIG_FB_PXA_OVERLAY=y
> CONFIG_FB_W100=y
> CONFIG_LCD_CLASS_DEVICE=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> -# CONFIG_BACKLIGHT_GENERIC is not set
> CONFIG_BACKLIGHT_PWM=y
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_FRAMEBUFFER_CONSOLE=y
> diff --git a/arch/arm/configs/mini2440_defconfig
> b/arch/arm/configs/mini2440_defconfig
> index 301f29a1fcc3..898490aaa39e 100644
> --- a/arch/arm/configs/mini2440_defconfig
> +++ b/arch/arm/configs/mini2440_defconfig
> @@ -158,7 +158,6 @@ CONFIG_FB_S3C2410=y
> CONFIG_LCD_CLASS_DEVICE=y
> CONFIG_LCD_PLATFORM=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> -# CONFIG_BACKLIGHT_GENERIC is not set
> CONFIG_BACKLIGHT_PWM=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> index de3b7813a1ce..7eae097a75d2 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -388,7 +388,6 @@ CONFIG_FB_TILEBLITTING=y
> CONFIG_LCD_CLASS_DEVICE=y
> CONFIG_LCD_PLATFORM=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=y
> -CONFIG_BACKLIGHT_GENERIC=m
> CONFIG_BACKLIGHT_PWM=m
> CONFIG_BACKLIGHT_PANDORA=m
> CONFIG_BACKLIGHT_GPIO=m
> diff --git a/arch/arm/configs/
Re: [PATCH 2/3] dts: ppc: t4240rdb: add uie_unsupported property to drop warning
On 08/05/2020 13:49:24+0800, Biwen Li wrote:
> From: Biwen Li
>
> This adds uie_unsupported property to drop warning as follows:
> - $ hwclock.util-linux
> hwclock.util-linux: select() to /dev/rtc0
> to wait for clock tick timed out
>
> My case:
> - RTC ds1374's INT pin is connected to VCC on T4240RDB,
> then the RTC cannot inform cpu about the alarm interrupt
>
> Signed-off-by: Biwen Li
> ---
> arch/powerpc/boot/dts/fsl/t4240rdb.dts | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t4240rdb.dts
> b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
> index a56a705d41f7..ccdd10202e56 100644
> --- a/arch/powerpc/boot/dts/fsl/t4240rdb.dts
> +++ b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
> @@ -144,7 +144,11 @@
> rtc@68 {
> compatible = "dallas,ds1374";
> reg = <0x68>;
> - interrupts = <0x1 0x1 0 0>;
removing the interrupt should be enough to solve your issue
> + // The ds1374's INT pin isn't
> + // connected to cpu's INT pin,
> + // so the rtc cannot synchronize
> + // clock tick per second.
> + uie_unsupported;
> };
> };
>
> --
> 2.17.1
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 1/3] rtc: ds1374: add uie_unsupported property to drop warning
Hi, On 08/05/2020 13:49:23+0800, Biwen Li wrote: > From: Biwen Li > > Add uie_unsupported property to drop warning as follows: > - $ hwclock.util-linux > hwclock.util-liux: select() /dev/rtc0 > to wait for clock tick timed out > > My case: > - RTC ds1374's INT pin is connected to VCC on T4240RDB, > then the RTC cannot inform cpu about the alarm > interrupt > > Signed-off-by: Biwen Li > --- > drivers/rtc/rtc-ds1374.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c > index 9c51a12cf70f..e530e887a17e 100644 > --- a/drivers/rtc/rtc-ds1374.c > +++ b/drivers/rtc/rtc-ds1374.c > @@ -651,6 +651,10 @@ static int ds1374_probe(struct i2c_client *client, > if (ret) > return ret; > > + if (of_property_read_bool(client->dev.of_node, > + "uie_unsupported")) > + ds1374->rtc->uie_unsupported = true; > + This is not how this is supposed to work, either the RTC support uie or don't, it is not board dependent and certainly doesn't require an (undocumented) DT property. > #ifdef CONFIG_RTC_DRV_DS1374_WDT > save_client = client; > ret = misc_register(_miscdev); > -- > 2.17.1 > -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH] rtc: fsl-ftm-alarm: remove select FSL_RCPM and default y from Kconfig
On 08/11/2019 16:40:56-0600, Li Yang wrote: > The Flextimer alarm is primarily used as a wakeup source for system > power management. But it shouldn't select the power management driver > as they don't really have dependency of each other. > > Also remove the default y as it is not a critical feature for the > systems. > > Signed-off-by: Li Yang > --- > drivers/rtc/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > Applied, thanks. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH -next] soc: fsl: Enable COMPILE_TEST
Hi,
On 08/11/2019 21:02:13+0800, YueHaibing wrote:
> When do COMPILE_TEST buiding for RTC_DRV_FSL_FTM_ALARM,
> we get this warning:
>
> WARNING: unmet direct dependencies detected for FSL_RCPM
> Depends on [n]: PM_SLEEP [=y] && (ARM || ARM64)
> Selected by [m]:
> - RTC_DRV_FSL_FTM_ALARM [=m] && RTC_CLASS [=y] && (ARCH_LAYERSCAPE ||
> SOC_LS1021A || COMPILE_TEST [=y])
>
> This enable COMPILE_TEST for FSL_RCPM to fix the issue.
>
> Fixes: e1c2feb1efa2 ("rtc: fsl-ftm-alarm: allow COMPILE_TEST")
I've removed that patch until the fsl maintainers apply this one.
> Signed-off-by: YueHaibing
> ---
> In commit c6c2d36bc46f ("rtc: fsl-ftm-alarm: Fix build error without
> PM_SLEEP")
> I posted a wrong kconfig warning(which PM_SLEEP is n), sorry for confusion.
> ---
> drivers/soc/fsl/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> index 4df32bc..e142662 100644
> --- a/drivers/soc/fsl/Kconfig
> +++ b/drivers/soc/fsl/Kconfig
> @@ -43,7 +43,7 @@ config DPAA2_CONSOLE
>
> config FSL_RCPM
> bool "Freescale RCPM support"
> - depends on PM_SLEEP && (ARM || ARM64)
> + depends on PM_SLEEP && (ARM || ARM64 || COMPILE_TEST)
> help
> The NXP QorIQ Processors based on ARM Core have RCPM module
> (Run Control and Power Management), which performs all device-level
> --
> 2.7.4
>
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH -next] rtc: opal: Make opal_tpo_alarm_irq_enable static
On 19/03/2019 23:25:31+0800, Yue Haibing wrote: > From: YueHaibing > > Fix sparse warning: > > drivers/rtc/rtc-opal.c:227:5: > warning: symbol 'opal_tpo_alarm_irq_enable' was not declared. Should it be > static? > > Signed-off-by: YueHaibing > --- > drivers/rtc/rtc-opal.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH] powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"
Fix a spelling mistake in a register description. Signed-off-by: Alexandre Belloni --- arch/powerpc/sysdev/fsl_rio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/fsl_rio.h b/arch/powerpc/sysdev/fsl_rio.h index 12dd18fd4795..6c13d9a7b7b2 100644 --- a/arch/powerpc/sysdev/fsl_rio.h +++ b/arch/powerpc/sysdev/fsl_rio.h @@ -41,7 +41,7 @@ #define DOORBELL_ROWAR_PCI 0x0200 /* PCI window */ #define DOORBELL_ROWAR_NREAD 0x0004 /* NREAD */ #define DOORBELL_ROWAR_MAINTRD 0x0007 /* maintenance read */ -#define DOORBELL_ROWAR_RES 0x2000 /* wrtpy: reserverd */ +#define DOORBELL_ROWAR_RES 0x2000 /* wrtpy: reserved */ #define DOORBELL_ROWAR_MAINTWD 0x7000 #define DOORBELL_ROWAR_SIZE0x000b /* window size is 4k */ -- 2.19.1
Re: [PATCH 19/36] dt-bindings: arm: Convert Atmel board/soc bindings to json-schema
Hello, On 05/10/2018 11:58:31-0500, Rob Herring wrote: > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml > b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > new file mode 100644 > index ..f788315b94fa > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > @@ -0,0 +1,132 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/atmel-at91.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Atmel AT91 device tree bindings. > + > +maintainers: > + - Alexandre Belloni > + - Jean-Christophe PLAGNIOL-VILLARD Jean-Christophe has not been active for years, I'd mention Ludovic instead. > +description: | > + Boards with a SoC of the Atmel AT91 or SMART family shall have the > following > + > +properties: > + $nodename: > +const: '/' > + compatible: > +oneOf: > + - items: > + - const: atmel,at91rm9200 > + - items: > + - enum: > + - olimex,sam9-l9260 > + - enum: > + - atmel,at91sam9260 > + - atmel,at91sam9261 > + - atmel,at91sam9263 > + - atmel,at91sam9g20 > + - atmel,at91sam9g45 > + - atmel,at91sam9n12 > + - atmel,at91sam9rl > + - atmel,at91sam9xe > + - const: atmel,at91sam9 > + > + - items: > + - enum: > + - atmel,at91sam9g15 > + - atmel,at91sam9g25 > + - atmel,at91sam9g35 > + - atmel,at91sam9x25 > + - atmel,at91sam9x35 > + - const: atmel,at91sam9x5 > + - const: atmel,at91sam9 > + > + - items: > + - const: atmel,sama5d27 > + - const: atmel,sama5d2 > + - const: atmel,sama5 > + > + - description: Nattis v2 board with Natte v2 power board > +items: > + - const: axentia,nattis-2 > + - const: axentia,natte-2 > + - const: axentia,linea Shouldn't we have the board specific compatibles in a separate file to avoid mixing everything with the SoC compatibles? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH 1/2] soc: fsl: qbman: qman_portal: defer probing when qman is not available
On 25/09/2018 21:45:56+0200, Olof Johansson wrote: > Hi, > > > On Thu, Aug 23, 2018 at 11:36 PM Alexandre Belloni > wrote: > > > > If the qman driver (qman_ccsr) doesn't probe or fail to probe before > > qman_portal, qm_ccsr_start will be either NULL or a stale pointer to an > > unmapped page. > > > > This leads to a crash when probing qman_portal as the init_pcfg function > > calls qman_liodn_fixup that tries to read qman registers. > > > > Assume that qman didn't probe when the pool mask is 0. > > > > Signed-off-by: Alexandre Belloni > > --- > > drivers/soc/fsl/qbman/qman_portal.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/soc/fsl/qbman/qman_portal.c > > b/drivers/soc/fsl/qbman/qman_portal.c > > index a120002b630e..4fc80d2c8feb 100644 > > --- a/drivers/soc/fsl/qbman/qman_portal.c > > +++ b/drivers/soc/fsl/qbman/qman_portal.c > > @@ -277,6 +277,8 @@ static int qman_portal_probe(struct platform_device > > *pdev) > > } > > > > pcfg->pools = qm_get_pools_sdqcr(); > > + if (pcfg->pools == 0) > > + return -EPROBE_DEFER; > > This is quite late in the probe, after a bunch of resources have been claimed. > > Note that the ioremaps above this are doing unwinds, and you'll end up > doing duplicate ioremaps if you come in and probe again. > > You should probably unwind those allocations, or move them to devm_* > or do this check earlier in the function. > The actual chance of having that happen is quite small (this was coming from a non working DT) and I mainly wanted to avoid a crash so the platform could still boot. I would think moving to devm_ would be the right thing to do. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH 2/2] soc: fsl: qbman: qman: avoid allocating from non existing gen_pool
If the qman driver didn't probe, calling qman_alloc_fqid_range,
qman_alloc_pool_range or qman_alloc_cgrid_range (as done in dpaa_eth) will
pass a NULL pointer to gen_pool_alloc, leading to a NULL pointer
dereference.
Signed-off-by: Alexandre Belloni
---
drivers/soc/fsl/qbman/qman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index ecb22749df0b..8cc015183043 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -2729,6 +2729,9 @@ static int qman_alloc_range(struct gen_pool *p, u32
*result, u32 cnt)
{
unsigned long addr;
+ if (!p)
+ return -ENODEV;
+
addr = gen_pool_alloc(p, cnt);
if (!addr)
return -ENOMEM;
--
2.18.0
[PATCH 1/2] soc: fsl: qbman: qman_portal: defer probing when qman is not available
If the qman driver (qman_ccsr) doesn't probe or fail to probe before qman_portal, qm_ccsr_start will be either NULL or a stale pointer to an unmapped page. This leads to a crash when probing qman_portal as the init_pcfg function calls qman_liodn_fixup that tries to read qman registers. Assume that qman didn't probe when the pool mask is 0. Signed-off-by: Alexandre Belloni --- drivers/soc/fsl/qbman/qman_portal.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c index a120002b630e..4fc80d2c8feb 100644 --- a/drivers/soc/fsl/qbman/qman_portal.c +++ b/drivers/soc/fsl/qbman/qman_portal.c @@ -277,6 +277,8 @@ static int qman_portal_probe(struct platform_device *pdev) } pcfg->pools = qm_get_pools_sdqcr(); + if (pcfg->pools == 0) + return -EPROBE_DEFER; spin_lock(_lock); cpu = cpumask_next_zero(-1, _cpus); -- 2.18.0
Re: [PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops
On 25/04/2018 13:28:27+1000, Michael Ellerman wrote:
> Alexandre Belloni <alexandre.bell...@bootlin.com> writes:
> > On 10/04/2018 23:01:36+1000, Nicholas Piggin wrote:
> >> On Tue, 10 Apr 2018 14:07:28 +0200
> >> Alexandre Belloni <alexandre.bell...@bootlin.com> wrote:
> >> > > Fixes ("powerpc/powernv: Add RTC and NVRAM support plus RTAS
> >> > > fallbacks"
> >> > > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> >> > > Cc: linux-...@vger.kernel.org
> >> > > Signed-off-by: Nicholas Piggin <npig...@gmail.com>
> >> > > ---
> >> > > arch/powerpc/platforms/powernv/opal-rtc.c | 8 +++--
> >> > > drivers/rtc/rtc-opal.c| 37
> >> > > ++-
> >> >
> >> > From what I understand, the changes in those files are fairly
> >> > independent, they should probably be separated to ease merging.
> >>
> >> I'm happy to do that. It's using the same firmware call, so I thought
> >> a single patch would be fine. But I guess the boot call can be
> >> dropped from this patch because it does not not solve the problem
> >> described in the changelog.
> >>
> >> Would you be happy for the driver change to be merged via the powerpc
> >> tree? The code being fixed here came from the same original patch as
> >> a similar issue being fixed in the OPAL NVRAM driver so it might be
> >> easier that way.
> >
> > Ok then, just add my
> >
> > Acked-by: Alexandre Belloni <alexandre.bell...@bootlin.com>
> >
> > and let it go through the powerpc tree.
>
> Thanks.
>
> It's still mostly an rtc patch by lines changed, so I changed the
> subject to:
>
> rtc: opal: Fix OPAL RTC driver OPAL_BUSY loops
>
Great, thanks!
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops
On 10/04/2018 23:01:36+1000, Nicholas Piggin wrote:
> On Tue, 10 Apr 2018 14:07:28 +0200
> Alexandre Belloni <alexandre.bell...@bootlin.com> wrote:
> > > Fixes ("powerpc/powernv: Add RTC and NVRAM support plus RTAS
> > > fallbacks"
> > > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> > > Cc: linux-...@vger.kernel.org
> > > Signed-off-by: Nicholas Piggin <npig...@gmail.com>
> > > ---
> > > arch/powerpc/platforms/powernv/opal-rtc.c | 8 +++--
> > > drivers/rtc/rtc-opal.c| 37 ++-
> >
> > From what I understand, the changes in those files are fairly
> > independent, they should probably be separated to ease merging.
>
> I'm happy to do that. It's using the same firmware call, so I thought
> a single patch would be fine. But I guess the boot call can be
> dropped from this patch because it does not not solve the problem
> described in the changelog.
>
> Would you be happy for the driver change to be merged via the powerpc
> tree? The code being fixed here came from the same original patch as
> a similar issue being fixed in the OPAL NVRAM driver so it might be
> easier that way.
>
Ok then, just add my
Acked-by: Alexandre Belloni <alexandre.bell...@bootlin.com>
and let it go through the powerpc tree.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops
S);
> + } else if (rc == OPAL_HARDWARE || rc == OPAL_INTERNAL_ERROR) {
> + if (retries--) {
> + msleep(10); /* Wait 10ms before retry */
> + rc = OPAL_BUSY; /* go around again */
> + }
> + }
> }
>
> return rc == OPAL_SUCCESS ? 0 : -EIO;
> --
> 2.17.0
>
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[PATCH] powerpc/time: stop validating rtc_time in .read_time
The RTC core is always calling rtc_valid_tm after the read_time callback.
It is not necessary to call it just before returning from the callback.
Signed-off-by: Alexandre Belloni <alexandre.bell...@bootlin.com>
---
arch/powerpc/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index a32823dcd9a4..f7d96a68ecaa 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1234,7 +1234,7 @@ void calibrate_delay(void)
static int rtc_generic_get_time(struct device *dev, struct rtc_time *tm)
{
ppc_md.get_rtc_time(tm);
- return rtc_valid_tm(tm);
+ return 0;
}
static int rtc_generic_set_time(struct device *dev, struct rtc_time *tm)
--
2.16.1
[PATCH RESEND] powerpc/5200: dts: digsy_mtc.dts: fix rv3029 compatible
The proper compatible for rv3029 is microcrystal,rv3029.
Acked-by: Anatolij Gustschin <ag...@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.bell...@bootlin.com>
---
Hi,
I'm resending that one because I prefer not taking DT patches through the RTC
tree.
arch/powerpc/boot/dts/digsy_mtc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts
b/arch/powerpc/boot/dts/digsy_mtc.dts
index c280e75c86bf..c3922fc03e0b 100644
--- a/arch/powerpc/boot/dts/digsy_mtc.dts
+++ b/arch/powerpc/boot/dts/digsy_mtc.dts
@@ -78,7 +78,7 @@
};
rtc@56 {
- compatible = "mc,rv3029c2";
+ compatible = "microcrystal,rv3029";
reg = <0x56>;
};
--
2.16.1
Re: [PATCH] char: nvram: disable on ARM
On 07/02/2018 at 16:47:00 +0100, Alexandre Belloni wrote: > > >> > I really don't think anyone is using that but I don't really know much > > >> > about x86 and the specification this may be part of. > > >> > > > >> > I see the info may be used in drivers/video/fbdev/ and > > >> > drivers/platform/x86/thinkpad_acpi.c > > >> > > >> The thinkpad_acpi driver seems to look at some other bytes > > >> in the nvram, which have a platform specific meaning. > > >> > > > > > > Yeah, I was more concerned that they need drivers/char/nvram.c for > > > nvram_read_byte so we can't simply remove the driver. > > > > Ok, so the procfs interface may be obsolete, but we still need an > > interface into the CMOS NVRAM data. > > > > Actually, I just found > https://unix.stackexchange.com/questions/331419/is-dev-nvram-dangerous-to-write-to > > So it seems to have real values for some people (even if they are > wrong). > > That also points to https://sourceforge.net/projects/nvram-wakeup/ but I > don't think it is necessary. The RTC driver should be able to wakeup an > x86 platform. > > All the other uses of /dev/nvram I could find with a simple google > search (i.e. saving and restoring CMOS settings) could just use > /sys/class/rtc/rtc0/device/nvram > Ok, the chromeos guys are using it for verified boot it seems: https://chromium.googlesource.com/chromiumos/platform/vboot_reference I'm wondering whether they really care about the checksum though. -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
Re: [PATCH] char: nvram: disable on ARM
On 07/02/2018 at 15:00:04 +0100, Arnd Bergmann wrote: > On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni > <alexandre.bell...@bootlin.com> wrote: > > On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote: > >> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni > > >> >> $ cat /proc/driver/nvram > >> >> Checksum status: valid > >> >> # floppies : 0 > >> >> Floppy 0 type : none > >> >> Floppy 1 type : none > >> >> HD 0 type : none > >> >> HD 1 type : none > >> >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0 > >> >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0 > >> >> DOS base memory: 635 kB > >> >> Extended memory: 65535 kB (configured), 65535 kB (tested) > >> >> Gfx adapter: EGA, VGA, ... (with BIOS) > >> >> FPU: not installed > >> >> > >> > > >> > I really don't think anyone is using that but I don't really know much > >> > about x86 and the specification this may be part of. > >> > > >> > I see the info may be used in drivers/video/fbdev/ and > >> > drivers/platform/x86/thinkpad_acpi.c > >> > >> The thinkpad_acpi driver seems to look at some other bytes > >> in the nvram, which have a platform specific meaning. > >> > > > > Yeah, I was more concerned that they need drivers/char/nvram.c for > > nvram_read_byte so we can't simply remove the driver. > > Ok, so the procfs interface may be obsolete, but we still need an > interface into the CMOS NVRAM data. > Actually, I just found https://unix.stackexchange.com/questions/331419/is-dev-nvram-dangerous-to-write-to So it seems to have real values for some people (even if they are wrong). That also points to https://sourceforge.net/projects/nvram-wakeup/ but I don't think it is necessary. The RTC driver should be able to wakeup an x86 platform. All the other uses of /dev/nvram I could find with a simple google search (i.e. saving and restoring CMOS settings) could just use /sys/class/rtc/rtc0/device/nvram > I see that the x86 version of nvram_read_byte is just a wrapper > around CMOS_READ(14 + addr). We also have some drivers > that call the low-level function directly: > > arch/x86/include/asm/floppy.h: val = CMOS_READ(0x10) & 15; > arch/x86/kernel/bootflag.c: v = CMOS_READ(sbf_port); > drivers/char/mwave/smapi.c: usSmapiID = CMOS_READ(0x7C); > drivers/input/misc/wistron_btns.c: qlen = > CMOS_READ(cmos_address); > > I suppose we could make the thinkpad driver do the same, > or provide a 'static inline' version of nvram_read_byte somewhere. > I guess we can do that, provided we take rtc_lock before using CMOS_READ. Thinking of it, I think this means we don't need the lock for powerpc as nvram_read_byte doesn't take it. So I guess it is only needed on x86. -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
Re: [PATCH] char: nvram: disable on ARM
On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote: > On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni > <alexandre.bell...@bootlin.com> wrote: > > On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote: > >> * arch/arm/kernel/time.c has this code > >> > >> #if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || > >> \ > >> defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE) > >> /* this needs a better home */ > >> DEFINE_SPINLOCK(rtc_lock); > >> EXPORT_SYMBOL(rtc_lock); > >> #endif /* pc-style 'CMOS' RTC support */ > >> > >> That can be adapted now, or maybe we could move all definitions into > >> a common place (that needs some more planning). > >> > > > > Yes, on arm, the rtc_lock is mostly there to please > > drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver > > x86 and PPC specific. > > > > If we can get rid of arch/powerpc/platforms/chrp/time.c and > > arch/powerpc/platforms/maple/time.c (so much duplicated code), then it > > is x86 only. > > What about these: > > arch/alpha/kernel/rtc.c:spin_lock(_lock); > arch/alpha/kernel/rtc.c:spin_unlock(_lock); > arch/alpha/kernel/time.c:DEFINE_SPINLOCK(rtc_lock); > arch/alpha/kernel/time.c:EXPORT_SYMBOL(rtc_lock); > arch/arm/kernel/time.c:DEFINE_SPINLOCK(rtc_lock); > arch/arm/kernel/time.c:EXPORT_SYMBOL(rtc_lock); > arch/m32r/kernel/time.c:DEFINE_SPINLOCK(rtc_lock); > arch/m32r/kernel/time.c:EXPORT_SYMBOL(rtc_lock); > arch/m68k/atari/time.c:DEFINE_SPINLOCK(rtc_lock); > arch/m68k/atari/time.c:EXPORT_SYMBOL_GPL(rtc_lock); > arch/mn10300/kernel/rtc.c:DEFINE_SPINLOCK(rtc_lock); > arch/mn10300/kernel/rtc.c:EXPORT_SYMBOL(rtc_lock); > arch/powerpc/kernel/time.c:DEFINE_SPINLOCK(rtc_lock); > arch/powerpc/kernel/time.c:EXPORT_SYMBOL_GPL(rtc_lock); > arch/sparc/kernel/time_32.c:DEFINE_SPINLOCK(rtc_lock); > arch/sparc/kernel/time_32.c:EXPORT_SYMBOL(rtc_lock); > arch/sparc/kernel/time_64.c:DEFINE_SPINLOCK(rtc_lock); > > Are they all obsolete? > Yes and no. For those architecture, the spinlock is only used to make the driver compile. It is probably not actually needed or at least it can be made local to the driver. For alpha, I just realized I never sent a patch removing the spinlock usage, I'll do that this cycle: https://github.com/alexandrebelloni/linux/commit/e79e2a754a3a67f2d7e906bfda0042f9dcf66a0b > >> $ cat /proc/driver/nvram > >> Checksum status: valid > >> # floppies : 0 > >> Floppy 0 type : none > >> Floppy 1 type : none > >> HD 0 type : none > >> HD 1 type : none > >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0 > >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0 > >> DOS base memory: 635 kB > >> Extended memory: 65535 kB (configured), 65535 kB (tested) > >> Gfx adapter: EGA, VGA, ... (with BIOS) > >> FPU: not installed > >> > > > > I really don't think anyone is using that but I don't really know much > > about x86 and the specification this may be part of. > > > > I see the info may be used in drivers/video/fbdev/ and > > drivers/platform/x86/thinkpad_acpi.c > > The thinkpad_acpi driver seems to look at some other bytes > in the nvram, which have a platform specific meaning. > Yeah, I was more concerned that they need drivers/char/nvram.c for nvram_read_byte so we can't simply remove the driver. > For drivers/video/fbdev/, these appear to all be for pre-x86 > Apple Macintosh (m68k or powerpc). > -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
Re: [PATCH] char: nvram: disable on ARM
On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote: > * arch/arm/kernel/time.c has this code > > #if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \ > defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE) > /* this needs a better home */ > DEFINE_SPINLOCK(rtc_lock); > EXPORT_SYMBOL(rtc_lock); > #endif /* pc-style 'CMOS' RTC support */ > > That can be adapted now, or maybe we could move all definitions into > a common place (that needs some more planning). > Yes, on arm, the rtc_lock is mostly there to please drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver x86 and PPC specific. If we can get rid of arch/powerpc/platforms/chrp/time.c and arch/powerpc/platforms/maple/time.c (so much duplicated code), then it is x86 only. > * similarly, this line in nvram.c can be simplified: > #if defined(CONFIG_ATARI) > # define MACH ATARI > #elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) /* and ?? > */ > # define MACH PC > #else > # error Cannot build nvram driver for this machine configuration. > #endif > > * GENERIC_NVRAM is not really generic, instead this seems to be the > chardev that is used for 32-bit powerpc (powermac, 85xx, 86xx), while > 64-bit powerpc (cell, maple, opal, pseries) use code from > arch/powerpc/kernel/nvram_64.c, with the same underlying arch hooks. > The nvram_64 code appears to be mostly a superset of the 32-bit > generic_nvram one. > > * The code in drivers/char/nvram is not used at all when >GENERIC_NVRAM is set, and half the code in there is different >between x86 and atari. > > * most of the external interface in include/linux/nvram.h is > unused, the rest tends to be architecture specific > > * The procfs file appears to be completely useless on any 64-bit >x86 machine, this is what I see: > > $ cat /proc/driver/nvram > Checksum status: valid > # floppies : 0 > Floppy 0 type : none > Floppy 1 type : none > HD 0 type : none > HD 1 type : none > HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0 > HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0 > DOS base memory: 635 kB > Extended memory: 65535 kB (configured), 65535 kB (tested) > Gfx adapter: EGA, VGA, ... (with BIOS) > FPU: not installed > I really don't think anyone is using that but I don't really know much about x86 and the specification this may be part of. I see the info may be used in drivers/video/fbdev/ and drivers/platform/x86/thinkpad_acpi.c -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
Re: rtc-opal: Fix handling of firmware error codes, prevent busy loops
On 06/02/2018 at 16:22:47 +1100, Michael Ellerman wrote: > > Just a note to let you know that this patch should have gone through my > > tree but it was not sent to linux-rtc or me. > > Sorry, I saw it had been languishing for a long time and assumed you'd > missed it. > > Happy to revert/rework it if you're not happy with it. > No, that's fine. It's just that the commit title stands out when using git log --oneline and that triggered my OCD ;) > > I guess what happened is that Michael cleaned up the Linux PPC patchwork > > queue. > > Yeah I did. > > In future I'll ping you if there's something that seems to have fallen > through the cracks. > Great thanks! -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
Re: rtc-opal: Fix handling of firmware error codes, prevent busy loops
Hi, On 02/08/2016 at 11:50:16 +1000, Stewart Smith wrote: > According to the OPAL docs: > https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-rtc-read-3.txt > https://github.com/open-power/skiboot/blob/skiboot-5.2.5/doc/opal-api/opal-rtc-write-4.txt > OPAL_HARDWARE may be returned from OPAL_RTC_READ or OPAL_RTC_WRITE and this > indicates either a transient or permanent error. > > Prior to this patch, Linux was not dealing with OPAL_HARDWARE being a > permanent error particularly well, in that you could end up in a busy > loop. > > This was not too hard to trigger on an AMI BMC based OpenPOWER machine > doing a continuous "ipmitool mc reset cold" to the BMC, the result of > that being that we'd get stuck in an infinite loop in opal_get_rtc_time. > > We now retry a few times before returning the error higher up the stack. > > Cc: sta...@vger.kernel.org > Signed-off-by: Stewart Smith <stew...@linux.vnet.ibm.com> > --- > drivers/rtc/rtc-opal.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > Just a note to let you know that this patch should have gone through my tree but it was not sent to linux-rtc or me. I guess what happened is that Michael cleaned up the Linux PPC patchwork queue. -- Alexandre Belloni, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering http://bootlin.com
Re: [trivial PATCH] treewide: Align function definition open/close braces
On 17/12/2017 at 16:28:44 -0800, Joe Perches wrote: > Some functions definitions have either the initial open brace and/or > the closing brace outside of column 1. > > Move those braces to column 1. > > This allows various function analyzers like gnu complexity to work > properly for these modified functions. > > Miscellanea: > > o Remove extra trailing ; and blank line from xfs_agf_verify > > Signed-off-by: Joe Perches <j...@perches.com> For RTC: Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH 3/3] powerpc/5200: dts: digsy_mtc.dts: fix rv3029 compatible
Hi, On 15/09/2017 at 09:13:26 +0200, Anatolij Gustschin wrote: > On Fri, 15 Sep 2017 04:00:04 +0200 > Alexandre Belloni alexandre.bell...@free-electrons.com wrote: > > >The proper compatible for rv3029 is microcrystal,rv3029. > > > >Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> > > Acked-by: Anatolij Gustschin <ag...@denx.de> If that is fine for you, I would prefer that goes through your tree as I'm not usually taking DT patches through the RTC tree. there is no dependency as the i2c subsystem will already match the new compatible with the i2c device_id. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH 3/3] powerpc/5200: dts: digsy_mtc.dts: fix rv3029 compatible
The proper compatible for rv3029 is microcrystal,rv3029.
Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
---
arch/powerpc/boot/dts/digsy_mtc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts
b/arch/powerpc/boot/dts/digsy_mtc.dts
index c280e75c86bf..c3922fc03e0b 100644
--- a/arch/powerpc/boot/dts/digsy_mtc.dts
+++ b/arch/powerpc/boot/dts/digsy_mtc.dts
@@ -78,7 +78,7 @@
};
rtc@56 {
- compatible = "mc,rv3029c2";
+ compatible = "microcrystal,rv3029";
reg = <0x56>;
};
--
2.14.1
[PATCH 2/3] ARM: dts: at91: usb_a9g20: fix rtc node
The rv3029 compatible is missing its vendor string, add it.
Also fix the node name to be a proper generic name.
Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
---
arch/arm/boot/dts/usb_a9g20_common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/usb_a9g20_common.dtsi
b/arch/arm/boot/dts/usb_a9g20_common.dtsi
index 088c2c3685ab..81c3fe0465d9 100644
--- a/arch/arm/boot/dts/usb_a9g20_common.dtsi
+++ b/arch/arm/boot/dts/usb_a9g20_common.dtsi
@@ -20,8 +20,8 @@
};
i2c-gpio-0 {
- rv3029c2@56 {
- compatible = "rv3029c2";
+ rtc@56 {
+ compatible = "microcrystal,rv3029";
reg = <0x56>;
};
};
--
2.14.1
[PATCH 1/3] RTC: rv3029: fix vendor string
The vendor string for Microcrystal is microcrystal.
Signed-off-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
---
Documentation/devicetree/bindings/trivial-devices.txt | 2 +-
drivers/rtc/rtc-rv3029c2.c| 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/trivial-devices.txt
b/Documentation/devicetree/bindings/trivial-devices.txt
index af284fbd4d23..aae37352c574 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt
@@ -72,7 +72,6 @@ isil,isl29030 Intersil ISL29030 Ambient Light and
Proximity Sensor
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible
Serial Interface
-mc,rv3029c2Real Time Clock Module with I2C-Bus
mcube,mc3230 mCube 3-axis 8-bit digital accelerometer
memsic,mxc6225 MEMSIC 2-axis 8-bit digital accelerometer
microchip,mcp4531-502 Microchip 7-bit Single I2C Digital Potentiometer (5k)
@@ -141,6 +140,7 @@ microchip,mcp4662-503 Microchip 8-bit Dual I2C
Digital Potentiometer with NV Mem
microchip,mcp4662-104 Microchip 8-bit Dual I2C Digital Potentiometer with NV
Memory (100k)
microchip,tc654PWM Fan Speed Controller With Fan Fault
Detection
microchip,tc655PWM Fan Speed Controller With Fan Fault
Detection
+microcrystal,rv3029Real Time Clock Module with I2C-Bus
miramems,da226 MiraMEMS DA226 2-axis 14-bit digital accelerometer
miramems,da280 MiraMEMS DA280 3-axis 14-bit digital accelerometer
miramems,da311 MiraMEMS DA311 3-axis 12-bit digital accelerometer
diff --git a/drivers/rtc/rtc-rv3029c2.c b/drivers/rtc/rtc-rv3029c2.c
index aa09771de04f..cfe3aece51d1 100644
--- a/drivers/rtc/rtc-rv3029c2.c
+++ b/drivers/rtc/rtc-rv3029c2.c
@@ -876,6 +876,8 @@ static const struct i2c_device_id rv3029_id[] = {
MODULE_DEVICE_TABLE(i2c, rv3029_id);
static const struct of_device_id rv3029_of_match[] = {
+ { .compatible = "microcrystal,rv3029" },
+ /* Backward compatibility only, do not use compatibles below: */
{ .compatible = "rv3029" },
{ .compatible = "rv3029c2" },
{ .compatible = "mc,rv3029c2" },
--
2.14.1
Re: [PATCH] rtc: rtctest: Improve support detection
Hi,
On 11/08/2017 at 11:14:55 +0200, Lukáš Doktor wrote:
> The rtc-generic and opal-rtc are failing to run this test as they do not
> support all the features. Let's treat the error returns and skip to the
> following test.
>
> Theoretically the test_DATE should be also adjusted, but as it's enabled
> on demand I think it makes sense to fail in such case.
>
> Signed-off-by: Lukáš Doktor <ldok...@redhat.com>
> ---
> tools/testing/selftests/timers/rtctest.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/timers/rtctest.c
> b/tools/testing/selftests/timers/rtctest.c
> index f61170f..6344842 100644
> --- a/tools/testing/selftests/timers/rtctest.c
> +++ b/tools/testing/selftests/timers/rtctest.c
> @@ -125,7 +125,7 @@ int main(int argc, char **argv)
> /* Turn on update interrupts (one per second) */
> retval = ioctl(fd, RTC_UIE_ON, 0);
> if (retval == -1) {
> - if (errno == EINVAL) {
> + if (errno == EINVAL || errno == EINVAL) {
Well, this needs to be fixed.
> fprintf(stderr,
> "\n...Update IRQs not supported.\n");
> goto test_READ;
> @@ -221,6 +221,11 @@ int main(int argc, char **argv)
> /* Read the current alarm settings */
> retval = ioctl(fd, RTC_ALM_READ, _tm);
> if (retval == -1) {
> + if (errno == EINVAL) {
> + fprintf(stderr,
> + "\n...EINVAL reading current alarm
> setting.\n");
> + goto test_PIE;
> + }
> perror("RTC_ALM_READ ioctl");
> exit(errno);
> }
> @@ -231,7 +236,7 @@ int main(int argc, char **argv)
> /* Enable alarm interrupts */
> retval = ioctl(fd, RTC_AIE_ON, 0);
> if (retval == -1) {
> - if (errno == EINVAL) {
> + if (errno == EINVAL || errno ==EIO) {
> fprintf(stderr,
> "\n...Alarm IRQs not supported.\n");
> goto test_PIE;
> --
> 2.9.4
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH] drivers/rtc/interface.c: Validate alarm-time before handling rollover
On 19/05/2017 at 22:18:55 +0530, Vaibhav Jain wrote: > In function __rtc_read_alarm() its possible for an alarm time-stamp to > be invalid even after replacing missing components with current > time-stamp. The condition 'alarm->time.tm_year < 70' will trigger this > case and will cause the call to 'rtc_tm_to_time64(>time)' > return a negative value for variable t_alm. > > While handling alarm rollover this negative t_alm (assumed to seconds > offset from '1970-01-01 00:00:00') is converted back to rtc_time via > rtc_time64_to_tm() which results in this error log with seemingly > garbage values: > > "rtc rtc0: invalid alarm value: -2-1--1041528741 > 200557:71582844:32" > > This error was generated when the rtc driver (rtc-opal in this case) > returned an alarm time-stamp of '00-00-00 00:00:00' to indicate that > the alarm is disabled. Though I have submitted a separate fix for the > rtc-opal driver, this issue may potentially impact other > existing/future rtc drivers. > > To fix this issue the patch validates the alarm time-stamp just after > filling up the missing datetime components and if rtc_valid_tm() still > reports it to be invalid then bails out of the function without > handling the rollover. > > Reported-by: Steve Best <sb...@redhat.com> > Signed-off-by: Vaibhav Jain <vaib...@linux.vnet.ibm.com> > --- > drivers/rtc/interface.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH] rtc/tpo: Handle disabled TPO in opal_get_tpo_time()
On 19/05/2017 at 15:35:09 +0530, Vaibhav Jain wrote: > On PowerNV platform when Timed-Power-On(TPO) is disabled, read of > stored TPO yields value with all date components set to '0' inside > opal_get_tpo_time(). The function opal_to_tm() then converts it to an > offset from year 1900 yielding alarm-time == "1900-00-01 > 00:00:00". This causes problems with __rtc_read_alarm() that > expecting an offset from "1970-00-01 00:00:00" and returned alarm-time > results in a -ve value for time64_t. Which ultimately results in this > error reported in kernel logs with a seemingly garbage value: > > "rtc rtc0: invalid alarm value: -2-1--1041528741 > 200557:71582844:32" > > We fix this by explicitly handling the case of all alarm date-time > components being '0' inside opal_get_tpo_time() and returning -ENOENT > in such a case. This signals generic rtc that no alarm is set and it > bails out from the alarm initialization flow without reporting the > above error. > > Signed-off-by: Vaibhav Jain <vaib...@linux.vnet.ibm.com> > Reported-by: Steve Best <sb...@redhat.com> > --- > drivers/rtc/rtc-opal.c | 10 ++ > 1 file changed, 10 insertions(+) > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH v4 00/16] genrtc removal
Hi, On 30/05/2016 at 20:57:48 +0200, Arnd Bergmann wrote : > This is the promised resend of the removal of the genrtc driver and some > related code, now that we are at a good time to merge this for the coming > merge window. > Thanks a lot! I'm applying the series right now so it sits in linux-next for a while before the next merge window. I would still happily take any acks, Reviewed-by or Tested-by tags. > - CONFIG_EFI_RTC is actively used on all six Itanium configurations, > though the CONFIG_RTC_DRV_EFI replacement driver is also available > there (and has been Itanium-only until ARM64 support for EFI was > merged). I suspect it's just a matter of getting an Ack from the > Itanium maintainers to remove it and change the defconfigs. > I have that one on my radar. There was an impressive number of separate drivers for EFI and CMOS... > - the last remaining legacy RTC driver after those is CONFIG_DS1302, > which has a slightly nonstandard ioctl interface and is only used > on arch/m32r. I have experimented with this a bit and think it > can be converted in a backward-compatible way as well. > That one has been converted to a standard SPI driver in v4.6. Following some discussion, driving it using gpios will be added. m32r will have to use one of those two interfaces. It is broken on that architecture for now but we never got any reply from maintainers. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 00/16] genrtc removal
Hi, On 03/05/2016 at 12:05:34 +0200, Arnd Bergmann wrote : > On Tuesday 03 May 2016 09:24:18 Alexandre Belloni wrote: > > Hi Arnd, > > > > I see you didn't copy Greg on that series (that may explain his > > confusion on the previous patch), do you expect me to take it > > through the RTC tree? That is fine but I'd like some acks from him. > > Yes, that was a mistake. I dropped Greg from one Cc list in v2 when > I split up the RTC changes into the part that was for drivers/rtc > and the other one for Greg's char-misc tree. Then I reused the first > Cc list when I sent a combined series for v3 again. I'll fix that > when I post v4. There are only very small changes in there that > I still need to pick up, so hopefully that will be the last version. > > It would be nice if you could take it through your tree then. > We are now at 4.7-rc1. Can you send v4 soon so that I can apply that series and get it in linux-next? There is a small rebase to do on patch v3. Thanks! -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 00/16] genrtc removal
Hi Arnd, I see you didn't copy Greg on that series (that may explain his confusion on the previous patch), do you expect me to take it through the RTC tree? That is fine but I'd like some acks from him. On 28/04/2016 at 00:34:14 +0200, Arnd Bergmann wrote : > I ended up stuffing the two patch series into one, as they are now > more dependent on one another. This now thoroughly removes the > genrtc driver including the asm/rtc.h headers it uses. For all > architectures that still have a meaningful asm/rtc.h, this goes > through two stages: > > 1) make the rtc-generic implementation independent of asm/rtc.h > 2) remove the asm/rtc.h header and disallow the gen_rtc driver > > As the last step, the driver itself gets removed. > > Arnd > > arch/alpha/include/asm/rtc.h | 1 - > arch/alpha/kernel/core_marvel.c | 1 - > arch/alpha/kernel/rtc.c | 6 +- > arch/frv/include/asm/mc146818rtc.h| 16 - > arch/h8300/include/asm/mc146818rtc.h | 9 - > arch/ia64/include/asm/mc146818rtc.h | 10 - > arch/m68k/amiga/config.c | 1 - > arch/m68k/apollo/config.c | 1 - > arch/m68k/bvme6000/config.c | 1 - > arch/m68k/hp300/config.c | 2 +- > arch/m68k/include/asm/rtc.h | 79 - > arch/m68k/kernel/time.c | 49 +++- > arch/m68k/mac/config.c| 3 +- > arch/m68k/mac/misc.c | 1 - > arch/m68k/mvme147/config.c| 1 - > arch/m68k/mvme16x/config.c| 1 - > arch/m68k/q40/config.c| 2 +- > arch/m68k/sun3/config.c | 1 - > arch/m68k/sun3/intersil.c | 2 +- > arch/m68k/sun3x/time.c| 2 +- > arch/mips/sni/time.c | 1 - > arch/mn10300/include/asm/rtc.h| 2 - > arch/mn10300/kernel/rtc.c | 2 +- > arch/parisc/include/asm/mc146818rtc.h | 9 - > arch/parisc/include/asm/rtc.h | 131 - > arch/parisc/kernel/time.c | 36 ++- > arch/powerpc/include/asm/rtc.h| 78 - > arch/powerpc/kernel/time.c| 29 +- > arch/powerpc/platforms/Kconfig| 11 + > arch/powerpc/platforms/ps3/time.c | 2 +- > arch/sh/include/asm/mc146818rtc.h | 7 - > arch/sh/include/asm/rtc.h | 11 - > arch/sh/kernel/time.c | 32 +- > arch/x86/include/asm/mc146818rtc.h| 1 - > arch/x86/include/asm/rtc.h| 1 - > arch/x86/kernel/hpet.c| 3 +- > arch/x86/kernel/rtc.c | 3 +- > arch/x86/platform/efi/efi.c | 1 - > drivers/acpi/acpi_cmos_rtc.c | 2 +- > drivers/base/power/trace.c| 6 +- > drivers/char/Kconfig | 26 -- > drivers/char/Makefile | 1 - > drivers/char/genrtc.c | 539 > -- > drivers/rtc/rtc-cmos.c| 12 +- > drivers/rtc/rtc-generic.c | 36 +-- > drivers/rtc/rtc-mrst.c| 2 +- > include/asm-generic/rtc.h | 247 > include/linux/mc146818rtc.h | 194 > 48 files changed, 358 insertions(+), 1256 deletions(-) > > [PATCH v3 01/16] rtc: cmos: remove empty asm/mc146818rtc.h files > [PATCH v3 02/16] rtc: cmos: move mc146818rtc code out of > [PATCH v3 03/16] char/genrtc: x86: remove remnants of asm/rtc.h > [PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly > [PATCH v3 05/16] char/genrtc: remove alpha support > [PATCH v3 06/16] char/genrtc: remove mn10300 support > [PATCH v3 07/16] rtc: parisc: provide rtc_class_ops directly > [PATCH v3 08/16] char/genrtc: remove parisc support > [PATCH v3 09/16] rtc: m68k: provide rtc_class_ops directly > [PATCH v3 10/16] rtc: m68k: provide ioctl for q40 > [PATCH v3 11/16] char/genrtc: remove m68k support > [PATCH v3 12/16] rtc: powerpc: provide rtc_class_ops directly > [PATCH v3 13/16] char/genrtc: remove powerpc support > [PATCH v3 14/16] rtc: generic: remove get_rtc_time/set_rtc_time > [PATCH v3 15/16] char/genrtc: remove asm-generic/rtc.h from mips > [PATCH v3 16/16] char/genrtc: remove the rest of the driver -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: char: legacy RTC cleanups
On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote : > I've had these patches in my tree for a while, after the first one > had a few issues that are fixed in this new version. The old-style > PC RTC driver is now also disabled on m68k (as pointed out by > Geert), ppc (it was also blacklisted), and m32r (I showed that > it did not build). > > For the genrtc driver, rearranging the headers makes it simpler > to use and reduces duplication. In case of alpha and mn10300, > I've shown that the genrtc and rtc drivers are doing the same > thing, so we don't need them both. The remaining three > architectures (m68k, parisc, powerpc) actually all support > the newer rtc-generic driver, so we could remove genrtc completely > if we want to. > Personally, I'd go for the kill and remove genrtc instead of cleaning it up. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/8] char/rtc: move mc146818rtc code out of asm-generic/rtc.h
The subject should be:
rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h
Else, you can add:
Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
On 26/04/2016 at 23:44:08 +0200, Arnd Bergmann wrote :
> Drivers should not really include stuff from asm-generic directly,
> and the PC-style cmos rtc driver does this in order to reuse the
> mc146818 implementation of get_rtc_time/set_rtc_time rather than
> the architecture specific one for the architecture it gets built for.
>
> To make it more obvious what is going on, this moves and renames the
> two functions into include/linux/mc146818rtc.h, which holds the
> other mc146818 specific code. Ideally it would be in a .c file,
> but that would require extra infrastructure as the functions are
> called by multiple drivers with conflicting dependencies.
>
> With this change, the asm-generic/rtc.h header also becomes much
> more generic, so it can be reused more easily across any architecture
> that still relies on the genrtc driver.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> drivers/rtc/rtc-cmos.c | 12 +--
> include/asm-generic/rtc.h | 206
> ++--
> include/linux/mc146818rtc.h | 194 +
> 3 files changed, 205 insertions(+), 207 deletions(-)
>
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 84fb541038be..c7993f18edfa 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -43,7 +43,7 @@
> #include
>
> /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
> -#include
> +#include
>
> struct cmos_rtc {
> struct rtc_device *rtc;
> @@ -190,10 +190,10 @@ static inline void cmos_write_bank2(unsigned char val,
> unsigned char addr)
> static int cmos_read_time(struct device *dev, struct rtc_time *t)
> {
> /* REVISIT: if the clock has a "century" register, use
> - * that instead of the heuristic in get_rtc_time().
> + * that instead of the heuristic in mc146818_get_time().
>* That'll make Y3K compatility (year > 2070) easy!
>*/
> - get_rtc_time(t);
> + mc146818_get_time(t);
> return 0;
> }
>
> @@ -205,7 +205,7 @@ static int cmos_set_time(struct device *dev, struct
> rtc_time *t)
>* takes effect exactly 500ms after we write the register.
>* (Also queueing and other delays before we get this far.)
>*/
> - return set_rtc_time(t);
> + return mc146818_set_time(t);
> }
>
> static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
> @@ -1142,14 +1142,14 @@ static __init void cmos_of_init(struct
> platform_device *pdev)
> if (val)
> CMOS_WRITE(be32_to_cpup(val), RTC_FREQ_SELECT);
>
> - get_rtc_time();
> + cmos_read_time(>dev, );
> ret = rtc_valid_tm();
> if (ret) {
> struct rtc_time def_time = {
> .tm_year = 1,
> .tm_mday = 1,
> };
> - set_rtc_time(_time);
> + cmos_set_time(>dev, _time);
> }
> }
> #else
> diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
> index 4e3b6558331e..4fcff22cd707 100644
> --- a/include/asm-generic/rtc.h
> +++ b/include/asm-generic/rtc.h
> @@ -12,12 +12,12 @@
> #ifndef __ASM_RTC_H__
> #define __ASM_RTC_H__
>
> -#include
> #include
> -#include
> -#include
> -#ifdef CONFIG_ACPI
> -#include
> +
> +#ifndef get_rtc_time
> +#include
> +#define get_rtc_time mc146818_get_time
> +#define set_rtc_time mc146818_set_time
> #endif
>
> #define RTC_PIE 0x40 /* periodic interrupt enable */
> @@ -31,202 +31,6 @@
> #define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */
> #define RTC_DST_EN 0x01 /* auto switch DST - works f. USA only
> */
>
> -/*
> - * Returns true if a clock update is in progress
> - */
> -static inline unsigned char rtc_is_updating(void)
> -{
> - unsigned char uip;
> - unsigned long flags;
> -
> - spin_lock_irqsave(_lock, flags);
> - uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
> - spin_unlock_irqrestore(_lock, flags);
> - return uip;
> -}
> -
> -static inline unsigned int __get_rtc_time(struct rtc_time *time)
> -{
> - unsigned char ctrl;
> - unsigned long flags;
> - unsigned char century = 0;
> -
> -#ifdef CONFIG_MACH_DECSTATION
> - unsigned int real_year;
> -#endif
> -
> - /*
> - * read RTC once any update in progress is done. The upda
Re: [PATCH 3/8] char/rtc: remove empty asm/mc146818rtc.h files
On 26/04/2016 at 23:44:07 +0200, Arnd Bergmann wrote : > Nothing on these architectures ever includes the asm/mc146818rtc.h > file, the drivers that used to do this have been fixed long ago, > and the remaining users are all PC-specific. > > This removes the files for good. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> > --- > arch/frv/include/asm/mc146818rtc.h| 16 > arch/h8300/include/asm/mc146818rtc.h | 9 - > arch/ia64/include/asm/mc146818rtc.h | 10 -- > arch/parisc/include/asm/mc146818rtc.h | 9 - > arch/sh/include/asm/mc146818rtc.h | 7 --- > 5 files changed, 51 deletions(-) > delete mode 100644 arch/frv/include/asm/mc146818rtc.h > delete mode 100644 arch/h8300/include/asm/mc146818rtc.h > delete mode 100644 arch/ia64/include/asm/mc146818rtc.h > delete mode 100644 arch/parisc/include/asm/mc146818rtc.h > delete mode 100644 arch/sh/include/asm/mc146818rtc.h > > diff --git a/arch/frv/include/asm/mc146818rtc.h > b/arch/frv/include/asm/mc146818rtc.h > deleted file mode 100644 > index 90dfb7a633d1.. > --- a/arch/frv/include/asm/mc146818rtc.h > +++ /dev/null > @@ -1,16 +0,0 @@ > -/* mc146818rtc.h: RTC defs > - * > - * Copyright (C) 2005 Red Hat, Inc. All Rights Reserved. > - * Written by David Howells (dhowe...@redhat.com) > - * > - * This program is free software; you can redistribute it and/or > - * modify it under the terms of the GNU General Public License > - * as published by the Free Software Foundation; either version > - * 2 of the License, or (at your option) any later version. > - */ > - > -#ifndef _ASM_MC146818RTC_H > -#define _ASM_MC146818RTC_H > - > - > -#endif /* _ASM_MC146818RTC_H */ > diff --git a/arch/h8300/include/asm/mc146818rtc.h > b/arch/h8300/include/asm/mc146818rtc.h > deleted file mode 100644 > index ab9d9646d241.. > --- a/arch/h8300/include/asm/mc146818rtc.h > +++ /dev/null > @@ -1,9 +0,0 @@ > -/* > - * Machine dependent access functions for RTC registers. > - */ > -#ifndef _H8300_MC146818RTC_H > -#define _H8300_MC146818RTC_H > - > -/* empty include file to satisfy the include in genrtc.c/ide-geometry.c */ > - > -#endif /* _H8300_MC146818RTC_H */ > diff --git a/arch/ia64/include/asm/mc146818rtc.h > b/arch/ia64/include/asm/mc146818rtc.h > deleted file mode 100644 > index 407787a237ba.. > --- a/arch/ia64/include/asm/mc146818rtc.h > +++ /dev/null > @@ -1,10 +0,0 @@ > -#ifndef _ASM_IA64_MC146818RTC_H > -#define _ASM_IA64_MC146818RTC_H > - > -/* > - * Machine dependent access functions for RTC registers. > - */ > - > -/* empty include file to satisfy the include in genrtc.c */ > - > -#endif /* _ASM_IA64_MC146818RTC_H */ > diff --git a/arch/parisc/include/asm/mc146818rtc.h > b/arch/parisc/include/asm/mc146818rtc.h > deleted file mode 100644 > index adf41631449f.. > --- a/arch/parisc/include/asm/mc146818rtc.h > +++ /dev/null > @@ -1,9 +0,0 @@ > -/* > - * Machine dependent access functions for RTC registers. > - */ > -#ifndef _ASM_MC146818RTC_H > -#define _ASM_MC146818RTC_H > - > -/* empty include file to satisfy the include in genrtc.c */ > - > -#endif /* _ASM_MC146818RTC_H */ > diff --git a/arch/sh/include/asm/mc146818rtc.h > b/arch/sh/include/asm/mc146818rtc.h > deleted file mode 100644 > index 0aee96a97330.. > --- a/arch/sh/include/asm/mc146818rtc.h > +++ /dev/null > @@ -1,7 +0,0 @@ > -/* > - * Machine dependent access functions for RTC registers. > - */ > -#ifndef _ASM_MC146818RTC_H > -#define _ASM_MC146818RTC_H > - > -#endif /* _ASM_MC146818RTC_H */ > -- > 2.7.0 > -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/8] char/rtc: legacy RTC is no longer supported on x86
On 26/04/2016 at 23:44:06 +0200, Arnd Bergmann wrote :
> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain a two older implementations of
> the CONFIG_RTC_DRV_CMOS driver.
>
> This removes x86 from the list.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com>
Two down, still four drivers for the x86 RTCs...
> ---
> drivers/char/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 66b5d48f409a..9bdb629fbaae 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -279,7 +279,7 @@ if RTC_LIB=n
>
> config RTC
> tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
> - depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300 || X86
> + depends on ALPHA || (MIPS && MACH_LOONGSON64) || MN10300
> ---help---
> If you say Y here and create a character special file /dev/rtc with
> major number 10 and minor number 135 using mknod ("man mknod"), you
> @@ -328,7 +328,7 @@ config JS_RTC
> config GEN_RTC
> tristate "Generic /dev/rtc emulation"
> depends on RTC!=y
> - depends on ALPHA || M68K || MN10300 || PARISC || PPC || X86
> + depends on ALPHA || M68K || MN10300 || PARISC || PPC
> ---help---
> If you say Y here and create a character special file /dev/rtc with
> major number 10 and minor number 135 using mknod ("man mknod"), you
> --
> 2.7.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 13/14] rtc: rtc-sa1100: DT spelling s/interrupt-name/interrupt-names/
On 20/04/2016 at 17:32:18 +0200, Geert Uytterhoeven wrote : > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> > --- > Documentation/devicetree/bindings/rtc/sa1100-rtc.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] rtc: generic: follow up for COMPILE_TEST
Hi, On 01/03/2016 at 17:59:56 +0100, Arnd Bergmann wrote : > Today's linux-next kernel allowed building the rtc-generic > driver (and most other rtc drivers) on all architectures, > but this caused some errors on architectures without asm/rtc.h. > > This series reworks that driver to avoid the dependency, > and simplifies all four implementations. My first approach > was to split the driver into four separate drivers, but > that didn't feel right when three of them have their own > multiplexors. > > The first five patches can be applied independent of one other, > while patch 6 is optional and can be applied when all others > are merged. Alternatively, they can all go in through the > rtc tree. I compile-tested only the powerpc and sh targets for > which I happened to have cross-compilers installed. > I like this approach. Maybe you can also remove the now unnecessary definitions from the various asm/rtc.h. I have a small nitpick on the parisc patch. I'll take the first patch, no need to resend that one. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/6] parisc: rtc: provide rtc_class_ops directly
On 01/03/2016 at 18:00:00 +0100, Arnd Bergmann wrote :
> - pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0);
> + pdev = platform_device_register_data(NULL, "rtc-generic", -1,
> + _generic_ops,
> + sizeof(rtc_generic_ops));
> +
> +
spurious blank line
> return PTR_ERR_OR_ZERO(pdev);
> }
> device_initcall(rtc_init);
> --
> 2.7.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove broken GregorianDay()
On 15/12/2015 at 18:09:14 +1100, Daniel Axtens wrote : > GregorianDay() is supposed to calculate the day of the week > (tm->tm_wday) for a given day/month/year. In that calcuation it > indexed into an array called MonthOffset using tm->tm_mon-1. However > tm_mon is zero-based, not one-based, so this is off-by-one. It also > means that every January, GregoiranDay() will access element -1 of > the MonthOffset array. > > It also doesn't appear to be a correct algorithm either: see in > contrast kernel/time/timeconv.c's time_to_tm function. > > It's been broken forever, which suggests no-one in userland uses > this. It looks like no-one in the kernel uses tm->tm_wday either > (see e.g. drivers/rtc/rtc-ds1305.c:319). > > tm->tm_wday is conventionally set to -1 when not available in > hardware so we can simply set it to -1 and drop the function. > (There are over a dozen other drivers in drivers/rtc that do > this.) > > Found using UBSAN. > > Cc: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Andrew Morton <a...@linux-foundation.org> # as an example of what UBSan > finds. > Cc: Alessandro Zummo <a.zu...@towertech.it> > Cc: Alexandre Belloni <alexandre.bell...@free-electrons.com> > Cc: rtc-li...@googlegroups.com > Signed-off-by: Daniel Axtens <d...@axtens.net> > Acked-by: Alexandre Belloni <alexandre.bell...@free-electrons.com> > --- > This is almost entirely a powerpc patch, but it also touches > the OPAL rtc driver. Alessandro, Alexandre, RTC folk, would > you be OK with mpe taking this through the powerpc tree? > Sure. I have a plan to actually correct tm_wday before sending it to user space when it is -1. I may as well calculate it every time but I'm not sure the extra calculation is actually worth it because as you mention it, it is not used by anybody. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] drivers/tty: make more bool drivers explicitly non-modular
On 20/10/2015 at 20:20:07 -0400, Paul Gortmaker wrote : > [Re: [PATCH 0/5] drivers/tty: make more bool drivers explicitly non-modular] > On 20/10/2015 (Tue 17:10) Alexandre Belloni wrote: > > > On 18/10/2015 at 18:21:13 -0400, Paul Gortmaker wrote : > > > The one common thread here for all the patches is that we also > > > scrap the .remove functions which would only be used for module > > > unload (impossible) and driver unbind. For the drivers here, there > > > doesn't seem to be a sensible unbind use case (vs. e.g. a multiport > > > PCI ethernet driver where one port is unbound and passed through to > > > a kvm guest or similar). Hence we just explicitly disallow any > > > driver unbind operations to help prevent root from doing something > > > illogical to the machine that they could have done previously. > > > > > > We've already done this for drivers/tty/serial/mpsc.c previously. > > > > > > Build tested for allmodconfig on ARM64 and powerpc for tty/tty-testing. > > > > > > > So, how does this actually build test atmel_serial? > > Not sure why this should be a surprise; I build test it exactly like this: > CONFIG_SERIAL_ATMEL is not selected by allmodconfig on arm64 or powerpc so this is not explaining how you build tested atmel_serial. > paul@builder-02:~/git/linux-head$ echo $ARCH > arm64 > paul@builder-02:~/git/linux-head$ echo $CROSS_COMPILE > aarch64-linux-gnu- > paul@builder-02:~/git/linux-head$ make O=../arm-build/ > drivers/tty/serial/atmel_serial.o > make[1]: Entering directory '/home/paul/git/arm-build' > arch/arm64/Makefile:25: LSE atomics not supported by binutils > CHK include/config/kernel.release > Using /home/paul/git/linux-head as source for kernel > GEN ./Makefile > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > > [...] > > HOSTCC scripts/sign-file > HOSTCC scripts/extract-cert > CC drivers/tty/serial/atmel_serial.o > make[1]: Leaving directory '/home/paul/git/arm-build' > paul@builder-02:~/git/linux-head$ > > It did build; no warning/error. Would you call it an invalid build test? > What you describe is a different test. I end up with 4 warnings when doing that on my machine. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] drivers/tty: make more bool drivers explicitly non-modular
On 18/10/2015 at 18:21:13 -0400, Paul Gortmaker wrote : > The one common thread here for all the patches is that we also > scrap the .remove functions which would only be used for module > unload (impossible) and driver unbind. For the drivers here, there > doesn't seem to be a sensible unbind use case (vs. e.g. a multiport > PCI ethernet driver where one port is unbound and passed through to > a kvm guest or similar). Hence we just explicitly disallow any > driver unbind operations to help prevent root from doing something > illogical to the machine that they could have done previously. > > We've already done this for drivers/tty/serial/mpsc.c previously. > > Build tested for allmodconfig on ARM64 and powerpc for tty/tty-testing. > So, how does this actually build test atmel_serial? A proper solution would be to actually make it a tristate and allow building as a module. I think it currently fails because of console_initcall() but that is certainly fixable. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] rtc/rtc-opal: Enable alarms only when opal supports tpo
On 14/07/2015 at 13:28:28 +0530, Vaibhav Jain wrote : rtc-opal driver provides support for rtc alarms via timed-power-on(tpo). However some Power platforms like BML use a fake rtc clock and don't support tpo. Such platforms are indicated by the missing 'has-tpo' property in the device tree. Current implementation however enables callback for rtc_class_ops.read/set alarm irrespective of the tpo support from the platform. This results in a failed opal call when kernel tries to read an existing alarms via opal_get_tpo_time during rtc device registration. This patch fixes this issue by setting opal_rtc_ops.read/set_alarm callback pointers only when tpo is supported. Acked-by: Michael Neuling mi...@neuling.org Acked-by: Neelesh Gupta neele...@linux.vnet.ibm.com Signed-off-by: Vaibhav Jain vaib...@linux.vnet.ibm.com --- drivers/rtc/rtc-opal.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) Applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
