On Wed, Apr 29, 2020 at 07:50:10AM -0700, Randy Dunlap wrote:
> On 4/29/20 1:33 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20200428:
> >
>
> on x86_64:
>
> kernel/trace/trace_branch.o: warning: objtool: ftrace_likely_update()+0x3c4:
> call to __stack_chk_fail() with UACCESS
Hi all,
Changes since 20200428:
The qcom tree still had its build failure for which I reverted a commit.
The hwmon-staging tree lost its build failure.
The jc_docs tree gained a conflict against the arm64 tree.
The mlx5-next tree gained a conflict against the kspp-gustavo tree.
The mac80211-n
On Mon, 29 Apr 2019 20:49:59 +0200
"Enrico Weigelt, metux IT consult" wrote:
> On 29.04.19 20:12, Pavel Machek wrote:
>
> >> Is that controller only built-in into some SoCs, or also available
> >> as a separate chip ?
> >
> > AFAIU.. separate chip, but runs firmware not likely to be available
On 29.04.19 20:12, Pavel Machek wrote:
>> Is that controller only built-in into some SoCs, or also available
>> as a separate chip ?
>
> AFAIU.. separate chip, but runs firmware not likely to be available
> outside Turris routers.
hmm, if it's a separate chip, IMHO it should be selectable, so th
On Mon 2019-04-29 19:51:40, Enrico Weigelt, metux IT consult wrote:
> On 29.04.19 18:53, Pavel Machek wrote:
> >>> Theoretically. But we both now that probability of that is very low,
> >>> and that likely driver would need other updates, too... right?
> >>
> >> What would be the benefit to add ARM
On 29.04.19 18:53, Pavel Machek wrote:
>>> Theoretically. But we both now that probability of that is very low,
>>> and that likely driver would need other updates, too... right?
>>
>> What would be the benefit to add ARM dependency? So that distro
>> compilations don't ship the turris_omnia driver
On Mon 2019-04-29 18:44:39, Marek Behun wrote:
> On Mon, 29 Apr 2019 18:37:53 +0200
> Pavel Machek wrote:
>
> > On Mon 2019-04-29 17:38:42, Marek Behun wrote:
> > > I am sending patch only adding the I2C dep. Theoretically it is
> > > possible that someone uses the same I2C API in their microcont
On Mon, 29 Apr 2019 18:37:53 +0200
Pavel Machek wrote:
> On Mon 2019-04-29 17:38:42, Marek Behun wrote:
> > I am sending patch only adding the I2C dep. Theoretically it is
> > possible that someone uses the same I2C API in their microcontroller on
> > another architecture.
>
> Theoretically. B
On Mon 2019-04-29 17:38:42, Marek Behun wrote:
> I am sending patch only adding the I2C dep. Theoretically it is
> possible that someone uses the same I2C API in their microcontroller on
> another architecture.
Theoretically. But we both now that probability of that is very low,
and that likely dr
I am sending patch only adding the I2C dep. Theoretically it is
possible that someone uses the same I2C API in their microcontroller on
another architecture.
On Mon, 29 Apr 2019 17:32:00 +0200
Pavel Machek wrote:
> On Mon 2019-04-29 08:03:02, Randy Dunlap wrote:
> > On 4/29/19 2:03 AM, Stephen R
On Mon 2019-04-29 08:03:02, Randy Dunlap wrote:
> On 4/29/19 2:03 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190426:
> >
>
> on i386:
>
> when CONFIG_LEDS_TURRIS_OMNIA=y and CONFIG_I2C=m:
>
> Probably should also depend on I2C.
>
>
> ld: drivers/leds/leds-turris-omnia.o:
On 4/29/19 2:03 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190426:
>
on i386:
when CONFIG_LEDS_TURRIS_OMNIA=y and CONFIG_I2C=m:
Probably should also depend on I2C.
ld: drivers/leds/leds-turris-omnia.o: in function `omnia_leds_remove':
leds-turris-omnia.c:(.text+0xb): undefined
Hi all,
Changes since 20190426:
The net-next tree gained a conflict against the wireless-drivers tree.
The driver-core tree gained a conflict against the block tree.
Non-merge commits (relative to Linus' tree): 9525
9333 files changed, 377625 insertions(+), 167578 deletions(-)
---
On 04/29/16 00:13, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160428:
>
on i386:
fs/built-in.o: In function `scrub_raid56_parity':
scrub.c:(.text+0x2d06fb): undefined reference to `__udivdi3'
--
~Randy
Hi all,
Changes since 20160428:
The arm64 tree gained a conflict against Linus' tree.
The pm tree gained a conflict against the arm-soc tree.
The tpmdd tree still had its build failure for which I added a fix patch.
The tip tree gained a conflict against the arm64 tree.
The xen-tip tree gaine
Hi all,
Changes since 20150428:
Removed tree: arm64-acpi (merged)
The drm-intel tree gained a conflict against Linus' tree.
Non-merge commits (relative to Linus' tree): 1043
966 files changed, 68943 insertions(+), 18138 deletions(-)
Hi all,
This tree still fails (more than usual) the powerpc allyesconfig build.
Changes since 20140428:
The powerpc tree still had its build failure.
The vfs tree gained a conflict against the f2fs tree.
The mfd-lj tree still had its build failure so I used the version from
next-20140423.
The
On 04/29/13 13:05, Randy Dunlap wrote:
> On 04/29/13 02:17, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20130426:
>>
>
>
> (who is responsible for MEM_SOFT_DIRTY?)
>
>
> on x86_64:
>
> warning: (HWPOISON_INJECT && MEM_SOFT_DIRTY) selects PROC_PAGE_MONITOR which
> has unmet direct d
On 04/29/13 02:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130426:
>
(who is responsible for MEM_SOFT_DIRTY?)
on x86_64:
warning: (HWPOISON_INJECT && MEM_SOFT_DIRTY) selects PROC_PAGE_MONITOR which
has unmet direct dependencies (PROC_FS && MMU)
because MEM_SOFT_DIRTY selects
Randy, All,
On Mon, Apr 29, 2013 at 09:25:54AM -0700, Randy Dunlap wrote:
> make ARCH=x86_64 O=X64 xconfig &
> GEN /local/lnx/next/linux-next-20130429/X64/Makefile
> HOSTCXX scripts/kconfig/qconf.o
> In file included from scripts/kconfig/expr.h:15:0,
> from scripts/kconfig
On 04/29/13 02:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130426:
>
Many build errors happen when CONFIG_PROC_FS is not enabled.
This is not new -- I also saw it about 2 weeks ago but did not analyze or
report it.
use of PDE_DATA() (from ):
drivers/net/wireless/hostap/hostap_
On Mon, 2013-04-29 at 18:46 +0200, Paolo Bonzini wrote:
> Il 29/04/2013 18:31, Gleb Natapov ha scritto:
> >> > arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension':
> >> > arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use
> >> > in this function)
> >> >
> >> >
>
On 04/29/13 02:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130426:
>
on i386:
CONFIG_I2C=m
sound/built-in.o: In function `snd_soc_codec_set_cache_io':
(.text+0x1ebe4): undefined reference to `regmap_init_i2c'
make[1]: *** [vmlinux] Error 1
--
~Randy
--
To unsubscribe from th
On Mon, 2013-04-29 at 19:31 +0300, Gleb Natapov wrote:
> On Mon, Apr 29, 2013 at 08:52:56AM -0700, Randy Dunlap wrote:
> > On 04/29/13 02:17, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20130426:
> > >
> >
> >
> > on x86_64:
> >
> > arch/x86/kvm/x86.c: In function 'kvm_dev_
Il 29/04/2013 18:31, Gleb Natapov ha scritto:
>> > arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension':
>> > arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in
>> > this function)
>> >
>> >
>> > Oops, CONFIG_PCI is not enabled.
> Alex, can you look at this ple
On 04/29/13 02:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130426:
>
on x86_64:
when CONFIG_MMC=m and
CONFIG_WIMAX_GDM72XX_SDIO=y (because it is boolean, not tristate):
gdm_sdio.c:(.text+0x147093): undefined reference to `sdio_claim_host'
gdm_sdio.c:(.text+0x1470a2): undefined re
On Mon, Apr 29, 2013 at 08:52:56AM -0700, Randy Dunlap wrote:
> On 04/29/13 02:17, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20130426:
> >
>
>
> on x86_64:
>
> arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension':
> arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' u
On 04/29/13 02:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130426:
>
> make ARCH=x86_64 O=X64 xconfig &
GEN /local/lnx/next/linux-next-20130429/X64/Makefile
HOSTCXX scripts/kconfig/qconf.o
In file included from scripts/kconfig/expr.h:15:0,
from scripts/kco
On 04/29/13 02:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130426:
>
when CONFIG_PROC_FS is not enabled:
CC init/main.o
In file included from init/main.c:16:0:
include/linux/proc_fs.h: In function 'proc_net_mkdir':
include/linux/proc_fs.h:69:2: error: implicit declaration o
On 04/29/13 02:17, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130426:
>
on x86_64:
arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension':
arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in this
function)
Oops, CONFIG_PCI is not enabled.
Full ran
30 matches
Mail list logo