On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 16:30, Russell King - ARM Linux
> wrote:
> > I typically see one or two, maybe five maximum on the platforms I have
> > here, but normally zero.
>
> Hmm, I have given a look at our l
On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> I don't know that there *is* a coherent plan here to address it all.
>
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and pr
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - p
On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> > It's a bit ironic that you've chosen GPIO as an example there. The
> > "new" GPIO API (the gpiod_
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - p
On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> >> Hi Russell,
> >>
> >> On Mon, Oct 19, 2015 at 5:35 PM,
On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
> > The above is currently the last point for probe to succeed or defer
> > (until possibly, as you mentioned, module loading resolves the defer).
> > If a probe defers above, it will de
On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
> But I worry a bit (and that my main point) about these few additional
> rounds of deferred device probing which I have right now and which allows
> some of drivers to finish, finally, their probes successfully.
> With proposed cha
On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>
> < snip >
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
>
>
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to
On Wed, Jan 28, 2015 at 10:47:18PM +0100, Arnd Bergmann wrote:
> The renesas usbhs driver calls extcon_get_edev_by_phandle(), which
> is defined in drivers/extcon/extcon-class.c, and that can be a
> loadable module. If the extcon-class support is disabled, usbhs
> will work correctly for all device
On Tue, Sep 26, 2017 at 10:35:23AM -0400, Alan Stern wrote:
> On Tue, 26 Sep 2017, Russell King wrote:
> > Convert the shutdown method to use the device_driver shutdown function
> > pointer rather than a private bus-type shutdown. This is the only user
> > for SA bus
On Tue, Sep 26, 2017 at 11:35:32AM -0400, Alan Stern wrote:
> On Tue, 26 Sep 2017, Russell King - ARM Linux wrote:
>
> > On Tue, Sep 26, 2017 at 10:35:23AM -0400, Alan Stern wrote:
> > > On Tue, 26 Sep 2017, Russell King wrote:
> > > > Convert the shutdown method
On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote:
> For dove, the patches are basically what I had proposed back in
> 2015 when all other ARMv6/ARMv7 machines became part of a single
> kernel build. I don't know what the state is mach-dove support is,
> compared to the DT based support
On Thu, Aug 08, 2019 at 10:58:11AM +0200, Greg KH wrote:
> But the main issue here is what exactly is this "fixing"? What is wrong
> with the existing code that non-x86 systems have such a problem with?
> Shouldn't all of these dma issues be handled by the platform with the
> remap_pfn_range() cal
On Thu, Aug 08, 2019 at 09:10:15AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f...@hashmail.org
> wrote:
> > --- a/drivers/usb/core/devio.c
> > +++ b/drivers/usb/core/devio.c
> > @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct
>
201 - 216 of 216 matches
Mail list logo
