linux-kernel - Re: [PATCH] mfd: mt6360: Fix register driver NULL pointer by add driver name

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE+NS34gf+my16b8dGCBWy0rXjT-5ObcvQiMVWHqsGehb_yR4Q@mail.gmail.com>
Date:   Mon, 15 Jun 2020 14:57:19 +0800
From:   Gene Chen <gene.chen.richtek@...il.com>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     matthias.bgg@...il.com, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Gene Chen <gene_chen@...htek.com>, Wilma.Wu@...iatek.com,
        shufan_lee@...htek.com, cy_huang@...htek.com
Subject: Re: [PATCH] mfd: mt6360: Fix register driver NULL pointer by add
 driver name

Lee Jones <lee.jones@...aro.org> 於 2020年6月12日 週五 下午7:17寫道：
>
> On Fri, 12 Jun 2020, Gene Chen wrote:
>
> > Lee Jones <lee.jones@...aro.org> 於 2020年6月9日 週二 下午8:53寫道：
> > >
> > > On Tue, 09 Jun 2020, Gene Chen wrote:
> > >
> > > > Lee Jones <lee.jones@...aro.org> 於 2020年6月9日 週二 上午3:28寫道：
> > > > >
> > > > > On Mon, 08 Jun 2020, Gene Chen wrote:
> > > > >
> > > > > > From: Gene Chen <gene_chen@...htek.com>
> > > > > >
> > > > > > accidentally remove driver name when
> > > > > > replace probe by probe_new in add mt6360 mfd driver patch v4
> > > > > >
> > > > > > [  121.243012] EAX: c2a8bc64 EBX: 00000000 ECX: 00000000 EDX: 00000000
> > > > > > [  121.243012] ESI: c2a8bc79 EDI: 00000000 EBP: e54bdea8 ESP: e54bdea0
> > > > > > [  121.243012] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010286
> > > > > > [  121.243012] CR0: 80050033 CR2: 00000000 CR3: 02ec3000 CR4: 000006b0
> > > > > > [  121.243012] Call Trace:
> > > > > > [  121.243012]  kset_find_obj+0x3d/0xc0
> > > > > > [  121.243012]  driver_find+0x16/0x40
> > > > > > [  121.243012]  driver_register+0x49/0x100
> > > > > > [  121.243012]  ? i2c_for_each_dev+0x39/0x50
> > > > > > [  121.243012]  ? __process_new_adapter+0x20/0x20
> > > > > > [  121.243012]  ? cht_wc_driver_init+0x11/0x11
> > > > > > [  121.243012]  i2c_register_driver+0x30/0x80
> > > > > > [  121.243012]  ? intel_lpss_pci_driver_init+0x16/0x16
> > > > > > [  121.243012]  mt6360_pmu_driver_init+0xf/0x11
> > > > > > [  121.243012]  do_one_initcall+0x33/0x1a0
> > > > > > [  121.243012]  ? parse_args+0x1eb/0x3d0
> > > > > > [  121.243012]  ? __might_sleep+0x31/0x90
> > > > > > [  121.243012]  ? kernel_init_freeable+0x10a/0x17f
> > > > > > [  121.243012]  kernel_init_freeable+0x12c/0x17f
> > > > > > [  121.243012]  ? rest_init+0x110/0x110
> > > > > > [  121.243012]  kernel_init+0xb/0x100
> > > > > > [  121.243012]  ? schedule_tail_wrapper+0x9/0xc
> > > > > > [  121.243012]  ret_from_fork+0x19/0x24
> > > > > > [  121.243012] Modules linked in:
> > > > > > [  121.243012] CR2: 0000000000000000
> > > > > > [  121.243012] random: get_random_bytes called from init_oops_id+0x3a/0x40 with crng_init=0
> > > > > > [  121.243012] ---[ end trace 38a803400f1a2bee ]---
> > > > > > [  121.243012] EIP: strcmp+0x11/0x30
> > > > >
> > > > > How did this driver ever work for you?
> > > >
> > > > i ask my coworker help me verify.
> > > > i will check the patch myself, sincerely apologies for this.
> > >
> > > What does this mean?
> > >
> > > Are you saying that for all 10 versions of this patch submission, it
> > > has never been tested?  And despite being authored by you and
> > > submitted by you, you have never actually boot tested the driver
> > > yourself?  Relying instead on your co-worker to conduct the testing,
> > > who failed to do so.  Is that really correct?
> > >
> >
> > On carefully reading to the document how to upstream, I find that I
> > had full duty for verify patch i sent.
> > The fault is entirely mine and I deeply regret that it should have occurred.
> > I will always verify patch by meself before sending it.
> > I have already verfied sub-device adc/led/regulator done in Mediatek
> > phone and Hikey960 development board
>
> I'm not looking for someone to blame.  Instead, I would like to
> ascertain how this happened.  How was this driver ever
> tested/verified?  If you're not going to run/use it, does it even need
> to exist?
>

There is difference between upstream and commerical driver.
We will sync upstream version after upstream done, in order to become
common driver everyone can easy to use

> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog