Hi all,
Changes since 20201207:
The v4l-dvb tree gained a conflict against the arm-soc tree.
The wireless-drivers-next tree gained a build failure for which I applied
a patch.
The nand tree gained a build failure so I used the version from
next-20201207.
The drm tree gained a conflict against
Hi all,
Changes since 20171207:
The printk tree lost its build failure.
The net-next tree gained a conflict against the vfs tree.
The wireless-drivers-next tree gained a conflict the wireless-drivers
tree.
The tpmdd tree gained a conflict against Linus' tree.
The scsi-mkp tree lost its build
Hi all,
Changes since 20161207:
The powerpc allyesconfig build seems to be fixed again.
The sunxi tree gained a conflict against the arm-soc tree.
The tip tree lost its perf build failure.
The pinctrl tree lost its build failure.
I dropped 2 patches from the akpm tree that no longer apply.
N
On Wed, Dec 09, 2015 at 11:57:05AM -0600, Scott Wood wrote:
> I recall at the time suggesting that the PCIe controller driver instantiate a
> platform device for the EDAC driver to bind to -- it looks like that's what
> we'll need to do.
Sounds better. Let me know if there's anything I can help wi
On Wed, 2015-12-09 at 18:38 +0100, Borislav Petkov wrote:
> On Wed, Dec 09, 2015 at 10:50:09AM -0600, Scott Wood wrote:
> > It's not "a driver's probe function". There is no driver whose .probe()
> > is
> > mpc85xx_pci_err_probe() -- the name is historical.
>
> From looking at it, it behaves a lo
On Wed, Dec 09, 2015 at 10:50:09AM -0600, Scott Wood wrote:
> It's not "a driver's probe function". There is no driver whose .probe() is
> mpc85xx_pci_err_probe() -- the name is historical.
>From looking at it, it behaves a lot like a probe function. Irrespective
of what it is or it isn't, callin
On Wed, 2015-12-09 at 17:03 +0100, Borislav Petkov wrote:
> On Wed, Dec 09, 2015 at 12:17:47PM +0100, Borislav Petkov wrote:
> > On Wed, Dec 09, 2015 at 09:32:47PM +1100, Michael Ellerman wrote:
> > > Presumably caused by the fact that edac_init() is subsys_initcall(),
> > > whereas
> > > corenet_g
On Wed, Dec 09, 2015 at 12:17:47PM +0100, Borislav Petkov wrote:
> On Wed, Dec 09, 2015 at 09:32:47PM +1100, Michael Ellerman wrote:
> > Presumably caused by the fact that edac_init() is subsys_initcall(), whereas
> > corenet_gen_publish_devices() is arch_initcall().
>
> Thanks for the report!
>
On Wed, Dec 09, 2015 at 09:32:47PM +1100, Michael Ellerman wrote:
> Presumably caused by the fact that edac_init() is subsys_initcall(), whereas
> corenet_gen_publish_devices() is arch_initcall().
Thanks for the report!
Hmm, interesting, can you send .config please?
I need to fix this dependency
On my p5020ds (powerpc e5500) I'm seeing the following oops with next-20151208:
Unable to handle kernel paging request for data at address 0x0048
Faulting instruction address: 0xc0366f78
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=24 CoreNet Generic
Modules link
Hi all,
Changes since 20151207:
Undropped tree: cgroup
The vfs tree gained a conflict against the s390 tree and a build failure
so I used the version from next-20151207.
The drm-misc tree gained a build failure so I used the version from
next-20151207.
The gpio tree still had its build failure
Hi all,
Changes since 20141205:
New tree: luto-misc
Dropped tree: access_once
The bcm2835 tree gained a conflict against the arm-soc tree.
The kvm tree gained a conflict against the rcu tree.
The xen-tip tree gained a conflict against the arm-soc tree.
The spi tree gained 2 build failures fo
12 matches
Mail list logo
