linux-kernel - RE: [PATCH net-next] ptp: clockmatrix: use rsmu driver to access i2c/spi bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 23 Sep 2021 21:05:20 +0000
From:   Min Li <min.li.xe@...esas.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     "richardcochran@...il.com" <richardcochran@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>
Subject: RE: [PATCH net-next] ptp: clockmatrix: use rsmu driver to access
 i2c/spi bus



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: September 23, 2021 4:05 PM
> To: Min Li <min.li.xe@...esas.com>
> Cc: richardcochran@...il.com; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org; lee.jones@...aro.org
> Subject: Re: [PATCH net-next] ptp: clockmatrix: use rsmu driver to access
> i2c/spi bus
> 
> On Thu, 23 Sep 2021 19:49:56 +0000 Min Li wrote:
> > > > I did build it through 32 bit arm and didn't get the problem.
> > > >
> > > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
> > >
> > > We're testing x86, maybe arm32 can handle 64bit divisions natively?
> > >
> > > ERROR: modpost: "__divdi3" [drivers/ptp/ptp_clockmatrix.ko]
> undefined!
> > > ERROR: modpost: "__udivdi3" [drivers/ptp/ptp_clockmatrix.ko]
> undefined!
> >
> > Hi Jakub
> >
> > I tried "make ARCH=i386" but it also passed on my machine. Can you
> > tell me how to reproduce this? Thanks
> 
> Hm, are you sure the config does not have CONFIG_64BIT=y ? Getting this
> right can be tricky, here is the script which patchwork runs, FWIW:
> 
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Fkuba-
> moo%2Fnipa%2Fblob%2Fmaster%2Ftests%2Fpatch%2Fbuild_32bit%2Fbuild
> _32bit.sh&amp;data=04%7C01%7Cmin.li.xe%40renesas.com%7Ce1d5e4e5
> e09d4307e05008d97ecd6cc8%7C53d82571da1947e49cb4625a166a4a2a
> %7C0%7C0%7C637680243028908142%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000&amp;sdata=9%2B0prRldYzfKpw%2F5zW1uhhiQyCsCW%2FU23W4v
> w2nGvkI%3D&amp;reserved=0
> 
> There is a small chance it's a glitch in the test system, but seems unlikely, this
> looks like a 64b divide:
> 
> +static u32 idtcm_get_dco_delay(struct idtcm_channel *channel)
> ...
> +	u64 m;
> +	u16 n;
> ...
> +	fodFreq = m / n;
> ...
> +		return 18 * (u64)NSEC_PER_SEC / fodFreq;

Hi Jakub

Attached is my config and it doesn't have CONFIG_64BIT set. But I still cannot reproduce this issue on my machine.

I will correct the possible 64 div and resubmit.

Min

View attachment "config.txt" of type "text/plain" (69380 bytes)