On 02/23/2015 05:15 PM, Bjorn Helgaas wrote:
On Mon, Feb 23, 2015 at 4:08 PM, Murali Karicheri<m-karicheri2@xxxxxx> wrote:
On 02/11/2015 11:58 AM, Murali Karicheri wrote:
On 02/11/2015 11:54 AM, Murali Karicheri wrote:
On 02/06/2015 01:36 PM, Murali Karicheri wrote:
On 02/06/2015 12:53 PM, Bjorn Helgaas wrote:
On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri<m-karicheri2@xxxxxx>
wrote:
On 02/06/2015 10:15 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:52PM +0000, Murali Karicheri wrote:
This patch add an important capability to PCI driver on Keystone. I
hope
to
have this merged to the upstream branch so that it is available for
v3.20.
It's very late for 3.20 and the code hasn't been in linux-next at all
(but it's not me who's merging this code), unless you can squeeze
it in
as a bug-fix.
This is in fact a bug fix as PCI on Keystone is broken without this.
Oh, sorry, I didn't realize that this was so urgent. I guess I read
"this adds an important capability" in the cover letter and concluded
that it was new functionality.
Bjorn,
Thanks for responding.
Let me give you some context on this without which my explanation won't
be complete. For using PCI driver on Keystone, I had submitted patches
related to machine and DTS to the arm mailing list to enable the driver
on Keystone. Subsequenty one of the patch from my series was Nack-ed and
I was asked to implememented in a different way and started this series.
You can refer to the discussion of this at
http://www.gossamer-threads.com/lists/linux/kernel/2024591
The PCI driver enablement on Keystone is still a working in progress and
I am trying to get it fully functional on the upstream. Another missing
piece is the SerDes phy driver patch. We have started working on the
other part (SerDes phy driver) already as the initial one was not
accepted. So it is fine if we are too late for the v3.20 merge window to
merge this series and this can be applied to the next branch for v3.21.
Anyway, if it's broken, presumably PCI on Keystone *did* work at one
point. Can you identify the commit that broke it and requires these
fixes, so we can figure out how far the fixes need to be backported?
I am trying to get this driver enabled on Keystone by adding the missing
pieces as described above. So I guess we don't have to back port
anything here.
If I merge it, I would like to get into my for-linus branch and get a
little time in -next before asking Linus to pull it. The merge window
is a little wrinkle there -- I don't like to add new things to the mix
during the window. But if it's an important fix we can still get it
in before the final v3.20.
Please apply this to next branch for v3.21. It currently apply cleanly
to v3.19-rc7. If you want me rebase to another branch, let me know I can
apply and send you an updated patch.
Bjorn, Arnd,
I am assuming, Bjorn is going to merge this to his next branch for
v3.21. If not, it might have to be merged through the arm soc? There are
a couple of Tested-by and Acked-by received after v7. Do you want me to
post v8 with these updated in the patches?
FYI.
These are the updates.
Series was
1) Tested-by: Suravee Suthikulpanit<Suravee.Suthikulpanit@xxxxxxx>
(on AMD Seattle platform w/ PCI Generic Host controller)
2) Acked-by: Will Deacon<will.deacon@xxxxxxx>
3) Reviewed-by: Catalin Marinas<catalin.marinas@xxxxxxx>
Bjorn,
I haven't seen a reply from my above email. As soon as you are ready to pull
this to v4.1 next (originally requested for v3.21 as per above email)branch,
please let me know and I can send you an updated version rebased to your
next branch and with the above acks.
My "next" and "for-linus" branches will be based on v4.0-rc1, so
that's the ideal base for patches. I don't expect any significant
changes that would require a rebase, so unless something in your
patches themselves has changed since you last posted them, you don't
need to repost them just for a rebase.
Bjorn,
Thanks for the response.
Nothing from my side except for the above acks/tested-by/reviewed-by
Murali
Bjorn
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
