[PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines

: error: 'MV643XX_ETH_BASE_ADDR_ENABLE_REG' undeclared (first use in this function) make[2]: *** [arch/powerpc/platforms/chrp/pegasos_eth.o] Error 1 make[1]: *** [arch/powerpc/platforms/chrp] Error 2 make: *** [arch/powerpc/platforms] Error 2 Signed-off-by: Luis R. Rodriguez [EMAIL PROTECTED

Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines

On 10/29/07, Dale Farnsworth [EMAIL PROTECTED] wrote: On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote: This commit made an incorrect assumption: -- Author: Lennert Buytenhek [EMAIL PROTECTED] Date: Fri Oct 19 04:10:10 2007 +0200 mv643xx_eth: Move ethernet

Re: [PATCH 00/15] change default_llseek action

On Wed, Sep 15, 2010 at 2:39 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Arnd, On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann a...@arndb.de wrote: Stephen, please add git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek Added from today. Thanks for adding

RFC: default ioremap_*() variant defintions

The 0-day build bot detected a build issue on a patch not upstream yet that makes a driver use iorempa_uc(), this call is now upstream but we have no drivers yet using it, the patch in question makes the atyfb framebuffer driver use it. The build issue was the lack of the ioremap_uc() call being

Re: RFC: default ioremap_*() variant defintions

On Sat, Jul 04, 2015 at 06:54:40AM -0700, Dan Williams wrote: On Fri, Jul 3, 2015 at 11:17 AM, Luis R. Rodriguez mcg...@suse.com wrote: I have no idea why its not picking up asm-generic ioremap_uc() for x86, x86 does not use include/asm-generic/io.h. That's a helper-include for archs

Re: RFC: default ioremap_*() variant defintions

On Fri, Jul 03, 2015 at 08:09:24PM +0100, Russell King - ARM Linux wrote: On Fri, Jul 03, 2015 at 08:17:09PM +0200, Luis R. Rodriguez wrote: The 0-day build bot detected a build issue on a patch not upstream yet that makes a driver use iorempa_uc(), this call is now upstream but we have

[PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

.@systeme.lip6.fr Cc: Alessandro Rubini <rub...@gnudd.com> Cc: Kevin Cernekee <cerne...@gmail.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Jiri Slaby <jsl...@suse.com> Cc: linux-ser...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ser...@vger.kernel.o

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Tue, Aug 02, 2016 at 02:58:39PM -0700, Guenter Roeck wrote: > On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote: > > Are linux-next builds being tested for powerpc with allyesconfig and > > allmodconfig ? I have some changes I'm making and while debugging my >

linker tables on powerpc - build issues

I've run into a few compilation issues with linker tables support [0] [1] on only a few architectures: blackfin - compiler issue it seems, I have a work around now in place arm - some alignment issue - still need to iron this out powerpc - issue with including on The issue with powerpc can be

powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

Are linux-next builds being tested for powerpc with allyesconfig and allmodconfig ? I have some changes I'm making and while debugging my build issues I decided to give a clean build a shot and see linux-next next-20160729 up to next-20160729 all have build failures without my changes. I get:

Re: [PATCH v3 2/5] firmware: annotate thou shalt not request fw on init or probe

On Wed, Aug 24, 2016 at 10:17:38AM +0200, Gabriel Paubert wrote: > On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote: > > [snip] > > --- > > Documentation/firmware_class/README| 20 > > drivers/base/Kconfig | 2 +- > >

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

On Thu, Aug 25, 2016 at 09:41:33PM +0200, Luis R. Rodriguez wrote: > On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote: > > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez <mcg...@kernel.org> > > wrote: > > Some users want a fully running gfx stack

[RFC] fs: add userspace critical mounts event support

the kernel-parameters using critical_mounts_timeout_ms=T where T is in ms. cat /sys/kernel/critical_mounts_timeout_ms the current system value. When userspace is ready it can simply: echo 1 > /sys/kernel/critical_mounts_ready Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- Note, t

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 06, 2016 at 03:28:47PM -0700, Bjorn Andersson wrote: > On Tue 06 Sep 14:52 PDT 2016, Luis R. Rodriguez wrote: > > > We already have MODULE_FIRMWARE(), we could have MODULE_FIRMWARE_REQ() or > > something like it to help annotate the the driver w

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 06, 2016 at 11:32:05AM -0700, Linus Torvalds wrote: > On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson > wrote: > > > > Linus, I reversed the order of your questions/answers to fit my answer > > better. > > Nobody has actually answered the "why don't we

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 06, 2016 at 02:50:51PM -0700, Linus Torvalds wrote: > On Tue, Sep 6, 2016 at 2:11 PM, Bjorn Andersson > wrote: > > On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: > > > >> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson > >> Nobody has actually

Re: [RFC] fs: add userspace critical mounts event support

On Sat, Sep 03, 2016 at 11:10:02AM -0700, Dmitry Torokhov wrote: > On Sat, Sep 3, 2016 at 11:01 AM, Linus Torvalds > wrote: > > On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov > > wrote: > >> > >> Unfortunately module loading and

[PATCH v4 2/5] firmware: annotate thou shalt not request fw on init or probe

gt; Cc: Jiri Slaby <jsl...@suse.com> Cc: linux-ser...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ser...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> --- Documentation/firmware_class/README| 22 dri

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 04, 2016 at 05:32:22PM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:24 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > > > > Note that the races are beyond firmware, so all > > kernel_read_file_from_path() users, as such re-using suc

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote: > > kernel_read_file_from_path() can try to read a file from > > the system's filesystem. This is typically done for firmware > > for instance, which lives in /li

Re: [RFC] fs: add userspace critical mounts event support

On Sat, Sep 24, 2016 at 10:41:46AM -0700, Dmitry Torokhov wrote: > On Fri, Sep 23, 2016 at 6:37 PM, Herbert, Marc wrote: > > On 03/09/2016 11:10, Dmitry Torokhov wrote: > >> I was thinking if we kernel could post > >> "conditions" (maybe simple stings) that it waits for,

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 4, 2016 at 5:12 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: >> >> I am not sure how/why a firmware loading daemon would be a better >> idea now. What

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > > > >> I did some shuffling around of those co

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

Summoning Felix for the embedded aspect on initramfs below. Jörg might be interested in the async facilities you speak of as well. On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote: > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > >

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

37 Thanks more reading.. :) > On Thu, Aug 25, 2016 at 9:41 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > >> > So .. I agree, let's avoid the hacks. Patches welcomed. > >> > >> Hm, this is a definite change of tack - back when I discussed this &

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

On Wed, Aug 24, 2016 at 08:55:55AM +0200, Daniel Vetter wrote: > On Fri, Jun 17, 2016 at 12:54 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > > Thou shalt not make firmware calls early on init or probe. <-- snip --> > > There are 4 offenders at this time: > &

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Oct 05, 2016 at 09:46:33PM +0200, Luis R. Rodriguez wrote: > On Wed, Oct 05, 2016 at 11:08:06AM -0700, Linus Torvalds wrote: > > On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez <mcg...@kernel.org> > > wrote: > > > On Tue, Sep 13, 2016 at 09:38

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Nov 9, 2016 at 3:21 AM, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner > wrote: >> [CC: added Harald] >> >> As Harald pointed out over a beer yesterday evening, there is at least >> one more reason why UMH isn't

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Nov 8, 2016 at 2:47 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > Whatever the outcome of this discussion is -- Johannes seemed to *want* > to further use the UMH by default on *all* async alls... even if the > driver did not explicitly requested it -- I'm concerned a

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Nov 29, 2016 at 10:10:56PM +0100, Tom Gundersen wrote: > On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg > wrote: > > My argument basically goes like this: > > > > First, given good drivers (i.e. using request_firmware_nowait()) > > putting firmware even for a

Re: [RFC] fs: add userspace critical mounts event support

On Wed, Nov 09, 2016 at 03:21:07AM -0800, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner > wrote: > > [CC: added Harald] > > > > As Harald pointed out over a beer yesterday evening, there is at least > > one more reason why UMH isn't obsolete.