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

From: Lee Jones
Date: Fri Jun 12 2020 - 07:17:27 EST


On Fri, 12 Jun 2020, Gene Chen wrote:

> Lee Jones <lee.jones@xxxxxxxxxx> æ 2020å6æ9æ éä äå8:53åéï
> >
> > On Tue, 09 Jun 2020, Gene Chen wrote:
> >
> > > Lee Jones <lee.jones@xxxxxxxxxx> æ 2020å6æ9æ éä äå3:28åéï
> > > >
> > > > On Mon, 08 Jun 2020, Gene Chen wrote:
> > > >
> > > > > From: Gene Chen <gene_chen@xxxxxxxxxxx>
> > > > >
> > > > > 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?

--
Lee Jones [æçæ]
Senior Technical Lead - Developer Services
Linaro.org â Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog