| Message ID | 1547250238-17181-1-git-send-email-andrew@lunn.ch |
|---|---|
| Headers | show |
| Series | i2c-ocores: Add IO mapped polled support | expand |
On Sat, Jan 12, 2019 at 12:43:55AM +0100, Andrew Lunn wrote: > TQ-Systems incorporates an ocores I2C bus master into there IO > controller for x86 systems. The registers are Intel IO mapped, and the > interrupt line is not tied to the CPU, so needs to be polled. The bus > can also be clocked at higher speed than the i2c default, so the > requested speed needs to be passed in the platform data. > > v2: > Rebased on 5.0-rc1 Hi Peter Are you still maintaining the ocores driver? Looking in patchworks, there are two patchsets waiting for review: https://patchwork.ozlabs.org/patch/990284/ from the end of October, and this set, first sent the beginning of December. Mine and Federico Vaga patchset are going to clash, but before we spend time sorting that out, it would be good to know somebody is actually going to review patches for this driver. Thanks Andrew
On Sat, Jan 12, 2019 at 12:43:55AM +0100, Andrew Lunn wrote: > TQ-Systems incorporates an ocores I2C bus master into there IO > controller for x86 systems. The registers are Intel IO mapped, and the > interrupt line is not tied to the CPU, so needs to be polled. The bus > can also be clocked at higher speed than the i2c default, so the > requested speed needs to be passed in the platform data. > > v2: > Rebased on 5.0-rc1 Hi Wolfram Peter never replied to my email asking him if he was still maintaining the ocores driver. Looking at the email lists, it looks like he has not responded to any review requests for this driver for over 4 months. So i think we have to assume this driver no longer has its maintainer. Would you be willing to review these patches? Thanks Andrew
Hi Andrew, > Peter never replied to my email asking him if he was still maintaining > the ocores driver. Looking at the email lists, it looks like he has > not responded to any review requests for this driver for over 4 > months. So i think we have to assume this driver no longer has its > maintainer. Thanks for your initiative. I agree, I haven't heard from Peter for some time now. > Would you be willing to review these patches? Counter-question: Would you be willing in (co)-maintaining the driver? :) Happy hacking, Wolfram
On Thu, Feb 07, 2019 at 01:03:01PM +0100, Wolfram Sang wrote: > Hi Andrew, > > > Peter never replied to my email asking him if he was still maintaining > > the ocores driver. Looking at the email lists, it looks like he has > > not responded to any review requests for this driver for over 4 > > months. So i think we have to assume this driver no longer has its > > maintainer. > > Thanks for your initiative. I agree, I haven't heard from Peter for some > time now. > > > Would you be willing to review these patches? > > Counter-question: Would you be willing in (co)-maintaining the driver? > :) Hi Wolfram I thought that might be coming :-) I only have one instance of this devices, and an odd one at that, in that it is x86 IO mapped, not the typical MMIO. Nor does it have a completion interrupt. And i'm not an FPGA programmer. As a result, i cannot do too much testing of patches. But i suppose i can be a co-maintainer. I will submit a patch for MAINTAINERS. I would prefer somebody else reviews my patches though. Andrew
Hi Andrew, > I thought that might be coming :-) :) > I only have one instance of this devices, and an odd one at that, in > that it is x86 IO mapped, not the typical MMIO. I see. Well, odd devices are ususally a good regression test case. > Nor does it have a completion interrupt. Interesting. Don't you need this polling series then? http://patchwork.ozlabs.org/project/linux-i2c/list/?series=73033 > And i'm not an FPGA programmer. That's not a problem. It is all about the Linux driver code. I am not an IP designer and still maintain the driver for some IP cores ;) > As a result, i cannot do too much testing of patches. Well, if you can check them to the best of your knowledge, this is already *much* appreciated. That's all I can do in most cases as well. > But i suppose i can be a co-maintainer. I will submit a patch for > MAINTAINERS. Cool, thank you very much! > I would prefer somebody else reviews my patches though. Sure thing! I will always have a look at patches before I apply them. Looking forward to your patch, Wolfram
> > Nor does it have a completion interrupt. > > Interesting. Don't you need this polling series then? Yes, my bad. I did not check if somebody else had already implemented this, and it was stuck waiting for review. My patchset adds polling support, amongst other things. Andrew
On Thu, Feb 07, 2019 at 05:12:07PM +0100, Andrew Lunn wrote: > > > Nor does it have a completion interrupt. > > > > Interesting. Don't you need this polling series then? > > Yes, my bad. I did not check if somebody else had already implemented > this, and it was stuck waiting for review. My patchset adds polling > support, amongst other things. Ah, I see now. Well, your solution seems to be less intrusive. So, this is a good thing?