From nobody Sun Nov 07 15:42:21 2021 X-Original-To: arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 47525184D92D for ; Sun, 7 Nov 2021 15:42:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1f.ore.mailhop.org (outbound1f.ore.mailhop.org [52.26.49.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HnJQv6hdgz3kRw for ; Sun, 7 Nov 2021 15:42:31 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1636299745; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=BgHeG5nuER8Wx010CLan/+3vk7ou2nu+6unfcKEZknpYRtPPkgY3sfdQT1Qs2KtEawal7W5NLQndk 8tRqV0RgAsEYCQGfqpaWsyzxlQf4+CSoVp+bQ1aqc70ip7CeKSGiQSMpX/JxGKQrtjNKB4Fhict9IW 4pkCtajYolhV9ONPF9gpSdWyoUT7jIGvVDFsQQ1+d8RwekDtX8OgMGeM58Yy6QcYOOrSxKfW1AFVxm 3QwOdULY6nXhVJUAB+FRD+GA5GhUPp/eMx/rYODK2YYsNSSSeIh/k6IuGPSzZxFePEe69dUSKAtnDC 9x2dJKL8IfIdHVfiXW1pByz7jB4M9vQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=hgcAF55tDXMl3XGb1poVO3z3wd0P9NfOVt1AbwDmpgg=; b=BKVNk8p9osYjBDAflWPHjWXs/lzY2ZOsDwLS+3reuTTrykEgbSJkJJ0HNXuRcJ9soAw04AsXzB8fX 4LeSutde+PDNO4KMIQGt2zB5PAzNl1vgXLYan0a0hIF6wf13jyF+uV/JunOCO3OYgiWhSS/0aEjKqA zXxLTLqGHzUYfn7PfYtNrPQa3QM5wPobaesQnqxRqVkRjGhScqxVIOVBqepkNGkvvHlvrK+rPG8o71 atHWxtrIanIjLCwFmOVkRIskPjDB4KCM7wckDTEMBbVRZdykAnxS3q4kvexvqYRUU3+0usafMF5EJ+ stgD5fd11QoU13foOa9V8gYtRcHkA+g== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=71.205.159.158; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-low; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=hgcAF55tDXMl3XGb1poVO3z3wd0P9NfOVt1AbwDmpgg=; b=oDe7YZ9PmaG9bjYta+LHR/OTs07nje9o2Wfb1/QGovKGdgMBD5ovWVNSFf8f+xQIjKbOgKOI+RJEI YFy22X1QmGSXwIv2aqibnB506ueyZemjCyCWvr0KtbdSmIG3guhSDOQioPNQQkQMyuPiNsDROPNj7S lSAxiaY3UR5RpS+MApCnce+T+8XkpgAiJpQwu9vkM3JlPXALoYH1wY+Fgr2RkNJlHW9f5PrnCPXW3O gh3AzwB9dJ0j5JjD+bc0ExFgbr15HRYa0MHC4ct3InVdexnE6WlBSrZb9NM+Yjulm9UkMlyVOnIRsv jelOl999v54TiUxEd+ORwtnWAlZcREQ== X-Originating-IP: 71.205.159.158 X-MHO-RoutePath: aGlwcGll X-MHO-User: 4c429c3f-3fe1-11ec-a87a-bf9d68d023b6 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-71-205-159-158.hsd1.co.comcast.net [71.205.159.158]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 4c429c3f-3fe1-11ec-a87a-bf9d68d023b6; Sun, 07 Nov 2021 15:42:24 +0000 (UTC) Received: from [172.22.42.84] (rev2.hippie.lan [172.22.42.84]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 1A7FgLRm012738; Sun, 7 Nov 2021 08:42:21 -0700 (MST) (envelope-from ian@freebsd.org) X-Authentication-Warning: paranoia.hippie.lan: Host rev2.hippie.lan [172.22.42.84] claimed to be [172.22.42.84] Message-ID: Subject: Re: DS3231 v. MAX77620 From: Ian Lepore To: Brian Scott , arm@FreeBSD.org Date: Sun, 07 Nov 2021 08:42:21 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.40.3 FreeBSD GNOME Team List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HnJQv6hdgz3kRw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 2021-11-07 at 12:30 +1100, Brian Scott wrote: > Hi All, > > I just plugged a DS3231 (RTC) into a RPi4 running 13.0 Release. Not > strictly necessary but I had one on my desk and it's a weekend. Added > an > appropriate dtb overlay and loaded the ds3231.ko via loader.conf. > Done > this a few times before on other boards and not expecting any drama. > > Instead of showing up during boot as a DS3231, it appears to be > probed > as a MAX77620 (which fails) and  leaves the real device unavailable > to > the ds3231 driver. > > > Nov  5 17:23:00 427269616e-60 kernel: iic0: on > iicbus0 > Nov  5 17:23:00 427269616e-60 kernel: rtc0: at addr > 0xd0 > on iicbus0 > > Nov  5 17:23:00 427269616e-60 kernel: rtc0: Error when reading reg > 0x02, > rv: 35 > Nov  5 17:23:00 427269616e-60 kernel: rtc0: Failed to configure RTC > Nov  5 17:23:00 427269616e-60 kernel: device_attach: rtc0 attach > returned 5 > > After some investigation I have found that all I need to provoke > these > messages is the dtb overlay loaded. Exactly the same messages are > generated without the ds3231.ko module and even when no physical > device > is present. > > Looking at max77620_rtc_probe in > sys/arm64/nvidia/tegra210/max77620_rtc.c shows: > > static int > max77620_rtc_probe(device_t dev) > { > struct iicbus_ivar *dinfo; > dinfo = device_get_ivars(dev); > if (dinfo == NULL) > return (ENXIO); > if (dinfo->addr != MAX77620_RTC_I2C_ADDR << 1) > return (ENXIO); > device_set_desc(dev, "MAX77620 RTC"); > return (BUS_PROBE_DEFAULT); > } > > This device will attempt to attach to anything with address == > MAX77620_RTC_I2C_ADDR (0x68) that is found in the device tree. > However, > https://learn.adafruit.com/i2c-addresses/the-list lists: > > 0x68 This address is really popular with real time clocks, almost all > of > them use 0x68! AMG8833 IR Thermal Camera Breakout (0x68 or 0x69) > DS1307 > RTC (0x68 only) DS3231 RTC (0x68 only) ICM-20649 Accel+Gyro (0x68 or > 0x69) ITG3200 Gyro (0x68 or 0x69) MPU-9250 9-DoF IMU (0x68 or 0x69) > MPU-60X0 Accel+Gyro (0x68 or 0x69) PCF8523 RTC (0x68 only) > > A seven bit device address is clearly not enough to uniquely identify > a > type of device and so shouldn't be used like this in the driver. > > Either the driver should use ofw_bus_search_compatible (although I > believe there is no entry for the rtc in the linux device tree) or at > least made conditional on the parent device (the MAX77620) being in > the > device tree. > > As I said earlier, this doesn't matter a huge amount for me at this > stage because in my current application time will be configured by > ntp. > In the future it will matter more. While it may well be that the > target > device cannot be identified any other way, this doesn't belong in > GENERIC. > > Thanks for reading, > > Brian Scott > You're right, the max77620 driver must use additional data (fdt, acpi, hints, whatever) to decide whether to attach. A very quick fix should be to change the existing driver to return BUS_PROBE_NOWILDCARD instead of BUS_PROBE_DEFAULT; that will give the proper driver a chance to outbid the errant driver for control. -- Ian