hat some other driver has claimed these GPIO lines? If so, how do
I determine which one?
Thanks!
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 02/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart wrote:
>
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
>
> Yes I think that could be it, the driver would need to call
&
On 02/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart wrote:
>
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
>
> Yes I think that could be it, the driver would need to call
&
On 02/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart wrote:
>
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
>
> Yes I think that could be it, the driver would need to call
&
On 02/07/2013 08:40 PM, Darren Hart wrote:
>
>
> On 02/07/2013 02:09 AM, Linus Walleij wrote:
>> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart wrote:
>>
>>> Is it that some other driver has claimed these GPIO lines? If so, how do
>>> I determine which one?
On 02/08/2013 12:49 AM, Samuel Ortiz wrote:
> Hi Darren,
>
> On Thu, Feb 07, 2013 at 11:08:03PM -0800, Darren Hart wrote:
>> On 02/07/2013 08:40 PM, Darren Hart wrote:
>>>
>>>
>>> On 02/07/2013 02:09 AM, Linus Walleij wrote:
>>>> On Thu, Feb
On 02/08/2013 03:07 AM, Samuel Ortiz wrote:
> On Fri, Feb 08, 2013 at 02:36:16AM -0800, Darren Hart wrote:
>> On 02/08/2013 12:49 AM, Samuel Ortiz wrote:
>>>> Well, this happens when the driver in question gets removed by another
>>>> driver.
>>>
cells array
and combining some of the add/remove logic.
Signed-off-by: Darren Hart
Cc: Grant Likely ,
Cc: Denis Turischev ,
Cc: Greg Kroah-Hartman ,
Cc: Linus Walleij
Cc: Samuel Ortiz
Signed-off-by: Darren Hart
---
drivers/mfd/lpc_sch.c | 148 --
1
On 02/08/2013 03:20 PM, Darren Hart wrote:
> The current probe aborts if any of the 3 base address registers are
> disabled. On a TunnelCreek system I am working on, this resulted in the
> SMBIOS and GPIO devices being removed when it couldn't read the base
> address for t
Cc: Viresh Kumar
> Cc: Michal Marek
> Cc: Bruce Ashfield
> Cc: Darren Hart
> Reported-by: Viresh Kumar
> Tested-by: Viresh Kumar
> Signed-off-by: John Stultz
Thanks John!
Acked-by: Darren Hart
> ---
> scripts/kconfig/merge_config.sh | 10 +-
))) {
> /* Keep the OWNER_DIED bit */
> newval = (curval & ~FUTEX_TID_MASK) | vpid;
> ownerdied = 0;
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
To unsubscribe from this list: send
On 10/23/2012 01:29 PM, Thomas Gleixner wrote:
> Darren, Siddhesh,
>
> On Tue, 23 Oct 2012, Darren Hart wrote:
>
>> Hi Siddesh,
>>
>> Thanks for the patch and your work to isolate it in the glibc bug 14076.
>>
>> On 10/21/2012 08:20 PM, Siddhesh Poyare
vous. I'd feel better if we could get Siddhesh's and this stale
waiters covered in futextest.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
84 02 01 00 00 <49> 8b 07 ba 01
> 00 00 00 48 3d c0 81 06 82 44 0f 44 e2 83 fb 01
> > RIP [] __lock_acquire+0x5e/0x1ba0
> > RSP
> > CR2: 0018
>
> It looks like we got all the way to lock_acquire with a NULL 'lock' somehow.
>
> Darre
On 10/25/2012 01:14 AM, Thomas Gleixner wrote:
> On Wed, 24 Oct 2012, Darren Hart wrote:
>> On 10/23/2012 01:29 PM, Thomas Gleixner wrote:
> Nah. I'm just too paranoid to apply any futex patch w/o understanding
> the root cause of it. Darn, if I only could remember how that
PHYLIB and making sure we can wake the
PHY at the necessary times rather than permanently disabling it.
Signed-off-by: Darren Hart
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: net...@vger.kernel.org
Cc: # 3.8.x: 5829e9b mfd:
Avoid using magic numbers when we have perfectly good defines just lying
around.
Signed-off-by: Darren Hart
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_m
Use the DMI interface rather than manually matching DMI strings.
Signed-off-by: Darren Hart
Cc: Michael Brunner
Cc: Greg Kroah-Hartman
---
drivers/tty/serial/pch_uart.c | 71 +--
1 file changed, 49 insertions(+), 22 deletions(-)
diff --git a/drivers
Use the DMI interface to detect the board for UART_CLOCK selection
per Greg K-H.
Resend PCH_GBE_PHY_REGS_LEN define cleanup.
Rewrite of PCH_GBE MinnowBoard support to be completely independent from any
platform or board files. It requests the GPIO line in the pch_gbe driver and
minimizes the pch_
On Fri, 2013-07-12 at 18:17 -0700, Greg KH wrote:
> On Fri, Jul 12, 2013 at 05:58:07PM -0700, Darren Hart wrote:
> > The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> > special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> > and add a pci_
On Fri, 2013-07-12 at 18:10 -0700, Joe Perches wrote:
> On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
> > The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> > special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> > and add a pci_
On Fri, 2013-07-12 at 23:26 -0700, Greg KH wrote:
> On Fri, Jul 12, 2013 at 10:46:21PM -0700, Darren Hart wrote:
> > On Fri, 2013-07-12 at 18:17 -0700, Greg KH wrote:
> > > On Fri, Jul 12, 2013 at 05:58:07PM -0700, Darren Hart wrote:
> > > > The MinnowBoard uses
On Sat, 2013-07-13 at 10:09 -0700, Greg KH wrote:
> On Sat, Jul 13, 2013 at 09:08:01AM -0700, Darren Hart wrote:
...
> > I was looking at it as a quirk:
> >
> > " - New device IDs and quirks are also accepted."
> >
> > I even considered implemen
On Fri, 2013-04-19 at 08:50 +0100, Matt Fleming wrote:
> On 04/19/2013 01:18 AM, Darren Hart wrote:
> > On 04/18/2013 09:19 AM, Matt Fleming wrote:
> >>
> >> Could you give it a spin on your MinnowBoard?
> >
> > I've removed the patch I reference
On Thu, 2013-09-12 at 08:55 +0100, Matt Fleming wrote:
> On Tue, 10 Sep, at 10:43:27AM, Darren Hart wrote:
> > Josh OK'd this, but as far as I can tell, it hasn't made it upstream
> > yet. Matt was there an alternate fixed pushed?
>
> Nope, this one slipped
failure scenario is that you
are trying to address with this patch. I only replied the once as I
pointed out the corner-case and expected you to follow up with that.
This region of code is very fragile to modifications as it has become
more corner-cases than core logic in some places :-)
For st
a different patch earlier this year that didn't appear to get
any review:
https://lkml.org/lkml/2013/4/8/65
This one woke all the waiters and let them sort it out.
It seems we've hashed through this already, but I'm not finding the
email logs and I don't recall off the top of m
On Fri, 2013-09-27 at 14:45 +0800, zhang.y...@zte.com.cn wrote:
>
> Darren Hart wrote on 2013/09/27 02:15:17:
>
>
> > Re: [PATCH] futex: Remove the owner check when waking task in
> > handle_futex_death
> >
> > On Thu, 2013-09-26 at 09:09 +0800, zhang
lines provided by the GPIO chip.
Is there a best practice for dealing with this kind of configuration?
If not, would it make sense to add optional gpiochip-level lock/unlock
and lockless direction and value operations to the gpiochip function
block?
Thanks,
--
Darren Hart
Intel Open Source Techn
ill hang
on a recursive spinlock on the private lock. The oops case is
handled by using a trylock in the oops_in_progress case.
Signed-off-by: Darren Hart
CC: Tomoya MORINAGA
CC: Feng Tang
CC: Alexander Stein
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/serial
On 09/05/2012 05:18 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 05, 2012 at 05:14:48PM -0700, Greg Kroah-Hartman wrote:
>> On Wed, Sep 05, 2012 at 05:04:07PM -0700, Darren Hart wrote:
>>> The following patch has been included in linux-next
>>> (fe89def79c48e2149abdd1
On 09/05/2012 05:25 PM, Darren Hart wrote:
>
>
> On 09/05/2012 05:18 PM, Greg Kroah-Hartman wrote:
>> On Wed, Sep 05, 2012 at 05:14:48PM -0700, Greg Kroah-Hartman wrote:
>>> On Wed, Sep 05, 2012 at 05:04:07PM -0700, Darren Hart wrote:
>>>> The following p
handled by using a trylock in the oops_in_progress case.
Signed-off-by: Darren Hart
CC: Tomoya MORINAGA
CC: Feng Tang
CC: Alexander Stein
Acked-by: Alan Cox
Signed-off-by: Greg Kroah-Hartman
Cc: sta...@vger.kernel.org # 3.4.x
---
drivers/tty/serial/pch_uart.c | 38 ++
On 11/20/2012 08:46 AM, Dave Jones wrote:
> On Wed, Oct 24, 2012 at 09:44:07PM -0700, Darren Hart wrote:
>
> > > I've been able to trigger this for the last week or so.
> > > Unclear whether this is a new bug, or my fuzzer got smarter, but I see
> the
>
eliminating all changes to the MM other than this accessor function
- which if not needed there could be added to futex.c, or even replaced with
"page_head - page" in get_futex_key() right?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
T
On 04/17/2013 02:55 AM, zhang.y...@zte.com.cn wrote:
> Darren Hart wrote on 2013/04/17 01:57:10:
>
>> Again, a functional testcase in futextest would be a good idea. This
>> helps validate the patch and also can be used to identify regressions in
>> the future.
>
On 04/17/2013 08:26 AM, Dave Hansen wrote:
> On 04/17/2013 07:18 AM, Darren Hart wrote:
>>>> This also needs a comment in futex.h describing the usage of the offset
>>>> field in union futex_key as well as above get_futex_key describing the
>>>> key for sha
On 04/17/2013 03:40 AM, zhang.y...@zte.com.cn wrote:
> Darren Hart wrote on 2013/04/17 01:05:28:
>
>
>>
>> Performance isn't an issue here as this is an error path. The question
>> is if the
>> changed behavior will constitute a problem for exis
On 04/18/2013 01:05 AM, zhang.y...@zte.com.cn wrote:
> Darren Hart wrote on 2013/04/17 23:51:36:
>
>> On 04/17/2013 08:26 AM, Dave Hansen wrote:
>>> On 04/17/2013 07:18 AM, Darren Hart wrote:
>>>>>> This also needs a comment in futex.h describing the us
address this
> properly if we ever start seeing i386 machines with bgrt pointers that
> reference highmem.
I don't believe I have seen a 32-bit EFI system with a BGRT, but then
again, I had to look it up today! That said, I suspect the MinnowBoard
would benefit from such a thing, so we shou
On 04/17/2013 06:47 PM, zhang.y...@zte.com.cn wrote:
>
>
> Darren Hart wrote on 2013/04/18 03:42:07:
>
>>
>>
>> On 04/17/2013 03:40 AM, zhang.y...@zte.com.cn wrote:
>> > Darren Hart wrote on 2013/04/17 01:05:28:
>> >
>> >
>&g
e we sit below that barrier on the MinnowBoard. We
can also speak with the Intel UEFI firmware development teams to see
about making that a requirement. I don't know if we'll be successful,
but Matt, Peter, and I have recently coaxed some changes of that nature in.
--
Darren Hart
I
On 04/18/2013 01:13 PM, H. Peter Anvin wrote:
> On 04/18/2013 01:11 PM, Darren Hart wrote:
>>>
>>> I would expect that if there are any 32-bit UEFI systems that ship with
>>> BGRT support (and Darren makes it sound like that's a possibility),
>>> ther
On 04/18/2013 09:19 AM, Matt Fleming wrote:
> On 18/04/13 15:51, Darren Hart wrote:
>> I don't believe I have seen a 32-bit EFI system with a BGRT, but then
>> again, I had to look it up today! That said, I suspect the MinnowBoard
>> would benefit from such a thing, so we
On 04/18/2013 07:13 PM, zhang.y...@zte.com.cn wrote:
> Darren Hart wrote on 2013/04/18 22:34:29:
>
>> On 04/18/2013 01:05 AM, zhang.y...@zte.com.cn wrote:
>>>
>>> I have run futextest/performance/futex_wait for testing,
>>> 5 times before make it l
>
> BTW, have you seen the testcase in my other mail? It seems to be rejected
> by LKML.
>
I did not receive it, did you also CC me?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
To unsubscribe from this list: send the line
On Thu, 2013-05-16 at 10:00 +0800, zhang.y...@zte.com.cn wrote:
>
> Darren Hart wrote on 2013/05/16 09:30:31:
>
> >
> > pgoff_t is an unsigned long, and page_to_pfn() returns an unsigned long.
> > Since compound_idx can be assigned from page_to_pfn() and it is added
&
th
commit message corrections or do you prefer to integrate those
yourself?
With the above fixes:
Acked-by: Darren Hart
> diff -uprN linux-3.10-rc7.org/include/linux/hugetlb.h
> linux-3.10-rc7/include/linux/hugetlb.h
> --- linux-3.10-rc7.org/include/linux/hugetlb.h2013-06
Add CircuitCo's newly created VENDOR ID and their first board subsystem
ID for the MinnowBoard.
Signed-off-by: Darren Hart
Cc: Bjorn Helgaas
Cc: David Anders
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: linux-...@vger.kernel.org
---
include/linux/pci_i
Use DMI_BOARD_NAME to determine if we are running on a MinnowBoard and
set the uart clock to 50MHz if so. This removes the need to pass the
user_uartclk to the kernel at boot time.
Signed-off-by: Darren Hart
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: "H. Peter Anvin"
Cc: Peter Wask
it.infradead.org/srv/git/users/dvhart/linux-2.6.git minnow/platform-v1
http://git.infradead.org/users/dvhart/linux-2.6.git/shortlog/refs/heads/minnow/platform-v1
Darren Hart (8):
pch_gbe: Use PCH_GBE_PHY_REGS_LEN instead of 32
pch_uart: Add uart_clk selection for the MinnowB
own devices using these GPIO
lines.
Signed-off-by: Darren Hart
Cc: Matthew Garrett
Cc: Grant Likely
Cc: Linus Walleij
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: platform-driver-...@vger.kernel.org
---
drivers/platform/x86/Kconfig| 18
them accordingly.
Provide a minimal public interface:
minnow_detect()
minnow_lvds_detect()
minnow_hwid()
minnow_phy_reset()
Signed-off-by: Darren Hart
Cc: Matthew Garrett
Cc: Grant Likely
Cc: Linus Walleij
Cc: Richard Purdie
Cc: "H. Peter Anvin"
flexibility to write kernel drivers for their own devices using these GPIO
lines.
Signed-off-by: Darren Hart
Cc: Matthew Garrett
Cc: Grant Likely
Cc: Linus Walleij
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: platform-driver-...@vger.kernel.org
---
drivers/platform/x
appropriate callbacks in a new pci_id driver_data structure.
Signed-off-by: Darren Hart
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/oki-semi/pch_gbe/Kconfig | 1 +
drivers/n
GPIO is board specific and may not be available to the gpio-sch
driver at probe time.
Signed-off-by: Darren Hart
Cc: Grant Likely
Cc: Linus Walleij
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
---
drivers/gpio/gpio-sch.c | 24
include/linux/
Avoid using magic numbers when we have perfectly good defines just lying
around.
Signed-off-by: Darren Hart
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_m
On Tue, 2013-06-25 at 20:35 -0600, Bjorn Helgaas wrote:
> On Tue, Jun 25, 2013 at 7:53 PM, Darren Hart wrote:
> > static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
> > {.vendor = PCI_VENDOR_ID_INTEL,
> > .device = PCI_DEVICE_ID_INTEL_IOH1_GBE,
&g
On Tue, 2013-06-25 at 19:31 -0700, Greg Kroah-Hartman wrote:
> On Tue, Jun 25, 2013 at 06:53:22PM -0700, Darren Hart wrote:
>
> > struct pch_uart_buffer {
> > unsigned char *buf;
> > @@ -398,6 +399,10 @@ static int pch_uart_get_uartclk(void)
> >
On Tue, 2013-06-25 at 20:39 -0700, Greg Kroah-Hartman wrote:
> On Tue, Jun 25, 2013 at 08:16:18PM -0700, Darren Hart wrote:
> > On Tue, 2013-06-25 at 19:31 -0700, Greg Kroah-Hartman wrote:
> > > On Tue, Jun 25, 2013 at 06:53:22PM -0700, Darren Hart wrote:
> > >
>
On Tue, 2013-06-25 at 21:00 -0700, Olof Johansson wrote:
> Hi,
Hey Olof, thanks for the review!
David M, search for "minnow_phy_reset" for your bit :-)
>
> On Tue, Jun 25, 2013 at 06:53:24PM -0700, Darren Hart wrote:
> > The MinnowBoard (http://www.minnowboard.org) is
On Wed, 2013-06-26 at 04:52 +, Matthew Garrett wrote:
> On Tue, 2013-06-25 at 21:43 -0700, Darren Hart wrote:
>
> > 1) I need time, possibly a couple of months, to get proper ACPI support
> > for these drivers into the firmware. Then I can rewrite these as ACPI
> > dri
On Wed, 2013-06-26 at 05:36 +, Matthew Garrett wrote:
> On Tue, 2013-06-25 at 22:32 -0700, Darren Hart wrote:
>
> > are all board-specific. They map GPIO to their fixed functions and
> > provide an API for board-specific queries (minnowboard.c), they provide
> > exampl
On Wed, 2013-06-26 at 08:43 +0200, Jiri Slaby wrote:
> On 06/26/2013 05:58 AM, Darren Hart wrote:
> > Subject: [PATCH] pch_uart: Use DMI interface for board detection
> >
> > Use the DMI interface rather than manually matching DMI strings.
> >
> > Signed-off-by:
On Wed, 2013-06-26 at 10:55 +0300, Andy Shevchenko wrote:
> On Tue, 2013-06-25 at 18:53 -0700, Darren Hart wrote:
> > Request and export the user-configurable GPIO lines to sysfs. This provides
> > a
> > label readable in /debugfs/gpio and a simple interface for experimenti
On Wed, 2013-06-26 at 09:25 +0200, Jiri Slaby wrote:
> On 06/26/2013 09:19 AM, Darren Hart wrote:
> > You can't actually use this driver on 64 bit as there is no hardware,
>
> Oh, so is this another candidate for adding dependson (X86_32 ||
> COMPILE_TEST) as well as the o
On Wed, 2013-06-26 at 11:46 +0300, Andy Shevchenko wrote:
> On Tue, 2013-06-25 at 18:53 -0700, Darren Hart wrote:
> > Configure the four buttons tied to the E6XX GPIO lines on the
> > MinnowBoard as keys using the gpio-keys-polled platform driver. From
> > left to right, bi
On Wed, 2013-06-26 at 10:32 -0600, Bjorn Helgaas wrote:
> On Tue, Jun 25, 2013 at 06:53:27PM -0700, Darren Hart wrote:
> > Add CircuitCo's newly created VENDOR ID and their first board subsystem
> > ID for the MinnowBoard.
> >
> > Signed-off-by: Darren Hart
>
On Wed, 2013-06-26 at 10:16 -0700, Greg Kroah-Hartman wrote:
> On Wed, Jun 26, 2013 at 09:28:07AM -0700, Darren Hart wrote:
> > On Wed, 2013-06-26 at 11:46 +0300, Andy Shevchenko wrote:
> > > On Tue, 2013-06-25 at 18:53 -0700, Darren Hart wrote:
> > > > Configure the
On Wed, 2013-06-26 at 13:37 -0600, Bjorn Helgaas wrote:
> On Wed, Jun 26, 2013 at 11:15 AM, Darren Hart wrote:
> > On Wed, 2013-06-26 at 10:32 -0600, Bjorn Helgaas wrote:
>
> >> +#define PCI_VENDOR_ID_CIRCUITCO 0x1cc8
> >> +
> >> #def
On Wed, 2013-06-26 at 21:57 +0200, Linus Walleij wrote:
> On Wed, Jun 26, 2013 at 7:23 PM, Darren Hart wrote:
> > On Wed, 2013-06-26 at 10:16 -0700, Greg Kroah-Hartman wrote:
> >> On Wed, Jun 26, 2013 at 09:28:07AM -0700, Darren Hart wrote:
>
> >> > The
On Tue, 2013-06-25 at 18:53 -0700, Darren Hart wrote:
> Allow for enabling and disabling of the resume well GPIOs. The E6xx Atom
> CPUs multiplex the resume GPIO 2:0 lines with LVDS and individual board
> drivers need to be able to enable or disable the lines appropriately.
>
> Unf
On Thu, 2013-06-27 at 11:18 +0300, Andy Shevchenko wrote:
> On Wed, 2013-06-26 at 09:21 -0700, Darren Hart wrote:
> > On Wed, 2013-06-26 at 10:55 +0300, Andy Shevchenko wrote:
>
> > > > + out:
> > > > + return err;
> > >
> > >
On Tue, 2013-06-25 at 18:53 -0700, Darren Hart wrote:
> The MinnowBoard uses an AR803x PHY with the PCH GBE.
>
> It does not implement the RGMII 2ns TX clock delay in the trace routing
> nor via strapping. Add a detection method for the board and the PHY and
> enable the tx cloc
On Thu, 2013-06-27 at 11:14 +0200, Linus Walleij wrote:
> On Wed, Jun 26, 2013 at 3:53 AM, Darren Hart wrote:
>
> > Provide a minimal public interface:
> > minnow_detect()
> > minnow_lvds_detect()
> > minnow_hwid()
> > minnow_
The E6xx (TunnelCreek) CPUs have 9 GPIO lines in the resume well. Update
the resume functions to allow for more than 8 GPIO lines, using the core
functions as a template.
Cc: # 3.4.x
Cc: # 3.8.x
Cc: Grant Likely
Cc: Linus Walleij
Signed-off-by: Darren Hart
---
drivers/gpio/gpio-sch.c | 37
with /net rules (which I had just
unwittingly violated in the patch mentioned above). I wonder if we
could somehow merge policies where possible, and document those that
should be different in a place where people are likely to find them -
perhaps associated with get_maintainer.pl since anyone
On Mon, 2013-07-15 at 11:34 +0300, Andy Shevchenko wrote:
> On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
...
> > +/* The AR803X PHY on the MinnowBoard requires a physical pin to be toggled
> > to
> > + * ensure it is awake for probe and init. Request the line a
On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
> The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> and add a pci_device_id.driver_data structure and functions to handle
> platform set
Professional behavior should be the default.
> > >
> > > Bullshit.
> > >
> >
> > Can we please make this into a Kernel Summit discussion. I highly doubt
> > we would solve anything, but it certainly would be a fun segment to
> > watch :-)
>
>
wever, I can also understand being fed up with lots of little
things like this and not having the patience or the desire to treat each
one as a mentoring opportunity. The difference tends to be I rant to my
close friends and Linus does so in public he's the more honest of
the two of us I think :-
case? How many are we talking about? 10/day?
10/year? Is it truly only the lieutenants getting public lashings?
I understand that it is the environment itself, the accepted norms, the
"standard you walk past" (as Sarah has quoted) that is the real focus.
So yes, let's not get hung u
sometimes caustic environment of Linux kernel development: "survivor's
bias". There is a great article on the subject I read recently here:
http://youarenotsosmart.com/2013/05/23/survivorship-bias/
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kerne
umentation." This adds some burden on the broader audience to point
people at the docs, because even RTFM has to get annoying to repeat too
often.
And with that, I'll sign out of this thread unless anyone wants to
discuss documentation - but those should probably happen on LKML (or
maybe
thanks to Sarah's comments. Talk about having a thick skin -
> trust me when I tell you that I get as well as I give out.
That's awful. People suck. I stopped reading slashdot years ago for the
quality of the content and commentary, apparently it has not improved.
--
Darren Hart
Intel
On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
> The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> and add a pci_device_id.driver_data structure and functions to handle
> platform set
On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
> Use the DMI interface rather than manually matching DMI strings.
Greg,
The rest of this series is either being dropped or has moved on to
netdev. This patch however remains unchanged. Would you like me to
resend individually or can you p
pch_uart_init_port() to the variable
.init.data:pch_uart_dmi_table
Signed-off-by: Darren Hart
Reported-by: kbuild test robot
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
---
drivers/tty/serial/pch_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
the baud and uartclk types throughout the
driver.
Signed-off-by: Darren Hart
Reported-by: kbuild test robot
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ser...@vger.kernel.org
---
drivers/tty/serial/pch_uart.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a
* If it acquired the lock, clear -ETIMEDOUT or -EINTR.
> + */
> + if (res)
> + ret = (res < 0) ? res : 0;
>
> - /* Unqueue and drop the lock. */
> - unqueue_me_pi(&q);
> +
le to obtain the same information from
> either source.
>
> In any case, it seems like this is something that should be discussed. A
> bunch of people in the earlier discussion mentioned that they were going
> to be in New Orleans, so I'd suggest that we arrange a time for
&
On Tue, 2013-08-20 at 21:57 +0100, Matthew Garrett wrote:
> On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote:
>
> > It seems to me that the only way to end up in a situation where the data
> > is reused by other OSes, is to go through a standards body. What about
ery low volume boards, possibly just shipped as a binary
to be loaded (with source available of course).
It appears that Matthew, at least, would prefer this latter scenario
just used DT instead. However, that seems to leave a gap in the
transition to incorporating the table into the board firmware
On Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote:
> On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:
>
> > It had been my hope at the start of this project to open the creation of
> > SSDTs up to inventors and hackers who want to create Lures for the
> &g
(resending as the original appears not to have made it past my sent box)
On Mon, 2013-07-15 at 11:34 +0300, Andy Shevchenko wrote:
> On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
> > The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> > special ha
On Mon, 2013-07-22 at 01:09 +0100, Grant Likely wrote:
> On Thu, Jul 4, 2013 at 5:26 PM, Mark Brown wrote:
> > On Thu, Jun 27, 2013 at 10:43:38PM -0700, Darren Hart wrote:
> >
> >> minnow_hwid() just returns an int that the minnowboard platform driver
> >> read
not reproduce on an Core Duo U1400 and cannot reproduce on
> an i7 M 620.
>
> Are the sysreq backtraces still wanted? If so, any tip, how I could get
> them saved?
Typically by setting up a serial console or a netconsole and saving the
log from the attached terminal emulator (su
mutex.
>>> 5. The 1st thread unlock the 2nd mutex, the 3rd thread cannot take
>>> the 2nd mutex, and may block forever.
>>>
>>>
>>> Signed-off-by: Zhang Yi
>>> Tested-by: Ma Chenggong
>>> Reviewed-by: Thomas Gleixner
>>> Rev
task or a kernel driver
>> during suspend, and is a common site where idle userspace tasks are
>> blocked.
>>
>> Signed-off-by: Colin Cross
>
> Acked-by: Thomas Gleixner
Beat me to it :-) Also agreed.
Acked-by: Darren Hart
>
>> ---
>> kernel/futex
>task)
> - schedule();
> + freezable_schedule();
> }
> __set_current_state(TASK_RUNNING);
> }
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
To unsubscribe from this list: send the li
1 - 100 of 1672 matches
Mail list logo
