[powerpc:merge] BUILD SUCCESS eddc90ea2af5933249ea1a78119f2c8ef8d07156

2023-10-01 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
merge
branch HEAD: eddc90ea2af5933249ea1a78119f2c8ef8d07156  Automatic merge of 
'fixes' into merge (2023-09-30 21:56)

elapsed time: 1446m

configs tested: 119
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha allnoconfig   gcc  
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
arc  allmodconfig   gcc  
arc   allnoconfig   gcc  
arc  allyesconfig   gcc  
arc defconfig   gcc  
arc   randconfig-001-20230930   gcc  
arc   randconfig-001-20231001   gcc  
arm  allmodconfig   gcc  
arm   allnoconfig   gcc  
arm  allyesconfig   gcc  
arm defconfig   gcc  
arm   randconfig-001-20231001   gcc  
arm64 allnoconfig   gcc  
arm64   defconfig   gcc  
csky allmodconfig   gcc  
csky  allnoconfig   gcc  
csky allyesconfig   gcc  
cskydefconfig   gcc  
i386 allmodconfig   gcc  
i386  allnoconfig   gcc  
i386 allyesconfig   gcc  
i386 buildonly-randconfig-001-20230930   gcc  
i386 buildonly-randconfig-001-20231001   gcc  
i386 buildonly-randconfig-002-20230930   gcc  
i386 buildonly-randconfig-002-20231001   gcc  
i386 buildonly-randconfig-003-20230930   gcc  
i386 buildonly-randconfig-003-20231001   gcc  
i386 buildonly-randconfig-004-20230930   gcc  
i386 buildonly-randconfig-004-20231001   gcc  
i386 buildonly-randconfig-005-20230930   gcc  
i386 buildonly-randconfig-005-20231001   gcc  
i386 buildonly-randconfig-006-20230930   gcc  
i386 buildonly-randconfig-006-20231001   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386  randconfig-001-20230930   gcc  
i386  randconfig-001-20231001   gcc  
i386  randconfig-002-20230930   gcc  
i386  randconfig-002-20231001   gcc  
i386  randconfig-003-20230930   gcc  
i386  randconfig-003-20231001   gcc  
i386  randconfig-004-20230930   gcc  
i386  randconfig-004-20231001   gcc  
i386  randconfig-005-20230930   gcc  
i386  randconfig-005-20231001   gcc  
i386  randconfig-006-20230930   gcc  
i386  randconfig-006-20231001   gcc  
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarchallyesconfig   gcc  
loongarch   defconfig   gcc  
loongarch randconfig-001-20230930   gcc  
loongarch randconfig-001-20231001   gcc  
m68k allmodconfig   gcc  
m68k  allnoconfig   gcc  
m68k allyesconfig   gcc  
m68kdefconfig   gcc  
microblaze   allmodconfig   gcc  
microblazeallnoconfig   gcc  
microblaze   allyesconfig   gcc  
microblaze  defconfig   gcc  
mips allmodconfig   gcc  
mips  allnoconfig   gcc  
mips allyesconfig   gcc  
nios2allmodconfig   gcc  
nios2 allnoconfig   gcc  
nios2allyesconfig   gcc  
nios2   defconfig   gcc  
openrisc allmodconfig   gcc  
openrisc  allnoconfig   gcc  
openrisc allyesconfig   gcc  
openriscdefconfig   gcc  
parisc   allmodconfig   gcc  
pariscallnoconfig   gcc  
parisc   allyesconfig   gcc  
parisc  defconfig   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
powerpc  allyesconfig   gcc  
riscvallmodconfig   gcc  
riscv allnoconfig   gcc  
riscvallyesconfig   gcc  
riscv

Re: [PATCH v4] powerpc: Use shared font data

2023-10-01 Thread Michael Ellerman
"Dr. David Alan Gilbert"  writes:
> * li...@treblig.org (li...@treblig.org) wrote:
>> From: "Dr. David Alan Gilbert" 
>> 
>> PowerPC has a 'btext' font used for the console which is almost identical
>> to the shared font_sun8x16, so use it rather than duplicating the data.
>
> Hi Michael,
>   Are you going to pick this up for 6.7?

Yes I will.

cheers


[OT] Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

2023-10-01 Thread Gabriel Paubert
On Sat, Sep 30, 2023 at 09:50:41AM -0500, Steve French wrote:
> On Fri, Sep 29, 2023 at 3:06 AM David Howells via samba-technical
>  wrote:
> >
> >
> > Jeff Layton  wrote:
> >
> > > Correct. We'd lose some fidelity in currently stored timestamps, but as
> > > Linus and Ted pointed out, anything below ~100ns granularity is
> > > effectively just noise, as that's the floor overhead for calling into
> > > the kernel. It's hard to argue that any application needs that sort of
> > > timestamp resolution, at least with contemporary hardware.
> >
> > Albeit with the danger of making Steve French very happy;-), would it make
> > sense to switch internally to Microsoft-style 64-bit timestamps with their
> > 100ns granularity?
> 
> 100ns granularity does seem to make sense and IIRC was used by various
> DCE standards in the 90s and 2000s (not just used for SMB2/SMB3 protocol and
> various Windows filesystems)

Historically it probably comes from VMS, where system time and file
timestamps were a 64 bit integer counting in 100ns units starting on MJD
240.5 (Nov 17th 1858).

Gabriel

> 
> 
> -- 
> Thanks,
> 
> Steve