NAK: [PATCH 0/2][SRU][J] Add ODM driver rtc-pcf85263
Anthony Wong
anthony.wong at canonical.com
Fri Jan 5 08:55:08 UTC 2024
On Thu, Jan 4, 2024 at 1:20 AM Tim Gardner <tim.gardner at canonical.com> wrote:
>
> On 12/27/23 8:18 PM, AceLan Kao wrote:
> > From: "Chia-Lin Kao (AceLan)" <acelan.kao at canonical.com>
> >
> > BugLink: https://bugs.launchpad.net/bugs/2045385
> >
> > [ Impact ]
> > rtc-pcf85263 driver is needed for ODM partner
> >
> > [ Test Plan ]
> > Load the driver setting the timestamp level to 0 (default to 1) :
> > modprobe rtc-pcf85263 tsl=0
> >
> > export the rtc device:
> > echo "pcf85263 0x51" > /sys/bus/i2c/devices/i2c-1/new_device
> >
> > RTC device should act as a standard RTC,
> > hwclock -r -f /dev/rtc1 #for reading
> > hwclock -w -f /dev/rtc1 #for writing
> >
> > This driver has anti-tampering function.
> > Get the current tamper timestamp:
> > cat /sys/class/rtc/rtc1/device/timestamp1
> >
> > unmount the bottom metal panel, unscrewing the 6x T-10 screws and let the anti-tampering goes in open state.
> > The timestamp should be updated to the current time.
> >
> > [ Where problems could occur ]
> > Events could occur on the I2C bus communication.
> >
> > Chia-Lin Kao (AceLan) (1):
> > UBUNTU: [Config] updateconfigs for ODM drivers CONFIG_RTC_DRV_PCF85263
> >
> > Filippo Copetti (1):
> > UBUNTU: SAUCE: ODM: rtc: add PCF85263 RTC driver
> >
> > MAINTAINERS | 6 +
> > debian.master/config/annotations | 1 +
> > drivers/rtc/Kconfig | 10 +
> > drivers/rtc/Makefile | 1 +
> > drivers/rtc/rtc-pcf85263.c | 1784 ++++++++++++++++++++++++++++++
> > drivers/rtc/rtc-pcf85263.h | 387 +++++++
> > 6 files changed, 2189 insertions(+)
> > create mode 100644 drivers/rtc/rtc-pcf85263.c
> > create mode 100644 drivers/rtc/rtc-pcf85263.h
> >
>
> I'm not keen to add an out of tree driver with sketchy provenance to a
> stable kernel. Besides, this driver should be added to newer kernels
> first. What happens when users of this Jammy kernel with this driver
> perform an upgrade to a newer kernel ?
Understand that these are our general guidelines but this pertain to
the ODM program in which Acelan has worked directly with Eurotech's
engineer on refining the details of this driver until he was satisfied
with the quality that deems it good enough to submit, so in this case
the Eurotech engineer who signed off this driver is our primary
contact, it's not something we randomly discovered and tried to
incorporate into our kernel. Meanwhile, we are also working with them
to push the drivers upstream. Hope this helps clarify the situation.
Thanks,
Anthony
More information about the kernel-team
mailing list