Re: [PATCH 5/7] usb: phy: tegra: get ULPI reset GPIO info using DT.

[Sergei Shtylyov]

Hello.

On 18-03-2013 16:29, Venu Byravarasu wrote:


As GPIO information is avail through DT, used it to get Tegra ULPI
reset GPIO number. Added a new member to tegra_usb_phy structure to
store this number.



Signed-off-by: Venu Byravarasu 
---
  drivers/usb/phy/tegra_usb_phy.c   |   25 +++--
  include/linux/usb/tegra_usb_phy.h |1 +
  2 files changed, 12 insertions(+), 14 deletions(-)



diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
index b5b2037..29c5ac4 100644
--- a/drivers/usb/phy/tegra_usb_phy.c
+++ b/drivers/usb/phy/tegra_usb_phy.c

[...]

@@ -622,18 +619,18 @@ static inttegra_phy_init(struct usb_phy *x)

[...]

-   gpio_request(ulpi_config->reset_gpio, "ulpi_phy_reset_b");
-   gpio_direction_output(ulpi_config->reset_gpio, 0);
+   gpio_request(phy->reset_gpio, "ulpi_phy_reset_b");
+   gpio_direction_output(phy->reset_gpio, 0);


   Why not use goio_request_one() instead of these two? Thought maybe it's a 
material of another patch...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 1/4] ARM: tegra: dalmore: add cpu regulator node

[Sergei Shtylyov]

Hello.

On 21-03-2013 17:47, Laxman Dewangan wrote:


Dalmore uses the TPS51632 as CPU regulator. The device is connected
on I2C5.



Add DT node for TPS51632.



Signed-off-by: Laxman Dewangan 
---
  arch/arm/boot/dts/tegra114-dalmore.dts |   15 +++
  1 files changed, 15 insertions(+), 0 deletions(-)



diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
b/arch/arm/boot/dts/tegra114-dalmore.dts
index a61974e..6be9434 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -718,6 +718,21 @@
clock-frequency = <40800>;
};

+   i2c@7000d000 {
+   status = "okay";
+   clock-frequency = <40>;
+
+   tps51632 {


   Should be named "tps51632@43" I think.


+   compatible = "ti,tps51632";
+   reg = <0x43>;


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 16:17, Russell King - ARM Linux wrote:


good point, do you wanna send some patches ?



  I have already sent them countless times and even stuck CPPI 4.1 support 
(in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.



 Any chance to bring it back to life? :-)
 Although... drivers/usb/musb/cppi41.c would need to be somewhat
reworked for at least AM35x and I don't have time. But that may change,
of course.



Right, I've just looked back at the various meeting minutes from December
2010 when the CPPI stuff was discussed.  Yes, I archive these things and
all email discussions for referencing in cases like this.



Thanks.


   Thanks again for taking your time to rummage thru the mail archives. I 
also did it, however not thru all threads (it turned out that the placement of 
CPPI 4.1 code was discussed also in the MUSB DMA driver related threads). 
Anyway, I was not a position to do extensive searching as it was already dead 
of the night in Moscow.



Unfortunately, they do not contain any useful information other than the
topic having been brought up.  At that point, the CPPI stuff was in
mach-davinci, and I had suggested moving it into drivers/dma.



I don't remember that, probably was out of the loop again.



Here you go - this goes back even _further_ - November 2009 - on the
mailing list.  The entire thread:



http://lists.arm.linux.org.uk/lurker/thread/20091102.105759.a54cf3f5.en.html



And selected emails from it:



http://lists.arm.linux.org.uk/lurker/message/20091102.103706.38c029b5.en.html
On Mon, Nov 02, 2009 at 10:37:06AM +, I wrote:
| On Mon, Nov 02, 2009 at 04:27:59PM +0530, Gupta, Ajay Kumar wrote:
| > Another option is to create arch/arm/ti-common to place all TI platform's
| > common software, such as CPPI4.1 used both in DA8xx and AM3517.
|
| No thanks.  I really don't see why we should allow TI to have yet more
| directories scattered throughout the tree that are out of place with
| existing conventions.
|
| And what is this CPPI thing anyway?
|
| http://acronyms.thefreedictionary.com/CPPI
|
| "Communications Port Programming Interface" seems to be about the best
| applicable one from that list!
|
| If it's a USB DMA device (from the patches I can find, that seems to be
| the case) then why can't it live in drivers/usb or drivers/dma ?



And again:



http://lists.arm.linux.org.uk/lurker/message/20091102.115458.61cde450.en.html
On Mon, Nov 02, 2009 at 11:54:58AM +, I wrote:
| On Mon, Nov 02, 2009 at 04:27:59PM +0530, Gupta, Ajay Kumar wrote:
| > CPPI4.1 DMA engine can be used either by USB or by Ethernet interface though
| > currently only USB is using it but in future even Ethernet devices may use 
it.
|
| drivers/dma does seem to be the right place for this.



http://lists.arm.linux.org.uk/lurker/message/20091102.110217.adec3ca7.en.html
Even Felipe Balbi said so:
| you might want to provide support for it via drivers/dma and for the
| musb stuff, you just add the wrappers musb uses. See how tusb6010_omap.c
| uses OMAP's system dma which is also used by any other driver which
| requests a dma channel.



And it seems that _YOU_ did get the message - see your quoted text in:
http://lists.arm.linux.org.uk/lurker/message/20091230.132240.ecd56b3d.en.html

We're currently having it there but the matter is it should be shred
between different platforms, so arch/arm/common/ seems like the right
place (which Russell didn't like, suggesting ill suited for that
drivers/dma/ instead).



See - you acknowledge here that I don't like it.  So you _KNOW_ my views
on it in December 2009, contary to what you're saying in this thread.


   OK, now it seems I misremembered.


Yet, you persisted with putting it in arch/arm/common:


   Being unable to fit it into drivers/dma/, and loating to place it into 
drivers/usb/, I had no other option. :-)



http://lists.arm.linux.org.uk/lurker/message/20100515.181453.472c7c10.en.html
| Changes since the previous version:
| - moved everything from arch/arm/mach-davinci/ to arch/arm/common/;
| - s/CONFIG_CPPI41/CONFIG_TI_CPPI41/, made that option invisible;
| - added #include  for kzalloc();
| - switched alloc_queue() and cppi41_queue_free() to using bit operations;
| - replaced 'static' linking_ram[] by local variable in 
cppi41_queue_mgr_init();
| - fixed pr_debug() in cppi41_dma_ctrlr_init() to print the real queue manager 
#.



So, see, I had already objected to it being in arch/arm well before
you stuck your patch into the patch system.  And somehow you think
that ignoring my previous comments and doing it anyway will result in
progress?


   I probably did that out of hopelessness partly.


So, let's recap.  The timeline behind this is:



+ 2 Nov 2009: Question asked about put

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 20:45, Russell King - ARM Linux wrote:


There are two people on this thread CC list who were also involved or
CC'd on the mails from the thread in 2010...  Tony and Felipe.
Unfortunately, the person who agreed to do the work is no longer in the
land of the living.  Yes I know it's inconvenient for people to die
when they've still got lots of important work to do but that's what can
happen...



Hm... wasn't it David Brownell? He's the only person who I know has
died recently who has dealt with DaVinci, MUSB and the releated stuff.



Actually, it wasn't David who was going to do it - that's where the email
thread gets messy because the mailer David was using makes no distinction
in text format between what bits of text make up the original email being
replied to, and which bits of text are written by David.


   Hm, strange...


It might have been Felipe; there appears to be an email from Felipe saying
that as the immediate parent to David's email.  But that's not really the
point here.  The point is that _someone_ agreed to put the work in, and
_that_ agreement is what caused the patch to be discarded.



And, as I've already explained, you brought up the subject of it being
discarded shortly after, and it got discussed there _again_, and the
same things were said _again_ by at least two people about it being in
drivers/dma.


   It wasn't said that somebody concrete was going to work on it. I had to 
explcitly write an email laying all further responsibility on CPPI 4.1 support 
on TI back then.



But anyway, that's all past history.  What was said back then about it
being elsewhere in the tree is just as relevant today as it was back
then.  The only difference is that because that message wasn't received,
it's now two years later with no progress on that.  And that's got
*nothing* what so ever to do with me.


   Yes, of course. In my original mail that started the discussion I said 
that we have to wait indefinitely for TI to write the new DMA driver. I just 
wondered wouldn't it be better to use the same approach as for EDMA with 
transitioning to drivers/dma/ step by step.



I know people like to blame me just because I'm apparantly the focus of
the blame culture, but really this is getting beyond a joke.



So, I want an apology from you for your insistance that I'm to blame
for this.


   OK, I apologise if you consider yourself the target of my blame. My aim 
was rather to establish the truth about that decision taken back in Dec 2010 
-- which we seem to have achieved.



Moreover, _I_ want to know what is going to happen in the
future with this so that I don't end up being blamed anymore for the
lack of progress on this issue.


   Nothing. My blame for the lack of progress has long been laid on TI, after 
I explictly passed the responsibility for the driver to them. My intent with 
the mail that started the discussion was to probe whether we still have 
another opportunity of having MUSB DMA support for OMAP-L1x and Sitara. I just 
thought that you might have changed your mind somehow on the matter.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 16:45, Russell King - ARM Linux wrote:


Now, CPPI is brand new code to arch/arm - always has been.  It post-dates
the DMA engine API.  And it's been said many times about moving it to
drivers/dma.  The problem is Sergei doesn't want to do it - he's anti the


   I *can't* do it, and I have denied all further responibility for it.


DMA engine API for whatever reasons he can dream up.  He professes no


   I'm not dreaming anything up. Please understand that CPPI 4.1 is not just 
a normal DMA controller -- it's a complex of several devices with DMA 
controller being only one of them, and one that can't work autonomously but 
only thru the proxy of the queue manager. That queue manager stuff I found 
hard to fit into drivers/dma/ infrastructure. Myabe it was a honest mistake, 
of course.



knowledge of my dislike for having it in arch/arm, yet there's emails
from years back showing that he knew about it.  TI knows about it; Ajay
about it.  Yet... well... history speaks volumes about this.


   Some details have slipped rom my memory after that many years. Im sorry 
for that.



Now, there may be a new problem with CPPI.  That being we're now requiring
DT support.  _Had_ this been done prior to the push for DT, then it would
not have been a concern, because then the problem becomes one for DT.
But now that OMAP is being converted to DT, and DT is The Way To Go now,
that's an additional problem that needs to be grappled with - or it may
make things easier.


   DaVinci is also being converted to device tree. However, that support 
remains optional for now. Not sure it will make things easier, as we still 
have two distinct devices to declare in the device tree: DMA controller and 
queue manager, and we'll have to describe the interconnect between them too 
(as a props of DMA controller I guess)...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 22:07, Matt Porter wrote:


Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.



I think this should rather go to drivers/dma/?



No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in plat-omap/dma.c. The actual
dmaengine driver is in drivers/dma/edma.c as a wrapper around
this...same way OMAP DMA engine conversion is being done.



Keeps me wondering why we couldn't have the same with CPPI 4.1 when I 
proposed
that, instead of waiting indefinitely for TI to convert it to drivers/dma/
directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... 
Sigh.



That is a shame. Yeah, I've pointed out that I was doing this exactly
the same way as was acceptable for the OMAP DMA conversion since it was
in RFC. The reasons are sound since in both cases, we have many drivers
to convert that need to continue using the private DMA APIs.



 In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other
in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is
sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't
know them well).



Well, it's pretty clear to me now that there's good reason for it not
landing in arch/arm/ so the obvious path is to do the dmaengine
conversion and put it in drivers/dma/ if it's really a generic dma engine.
I'm not sure why you express concern over the dma engine api not fitting
with CPPI 4.1?


   It's not a DMA controller only, it's 3 distinct devices, with the DMA 
controller being one among them and using another one, the queue manager, as 
some sort of proxy. The third device doesn't exist on OMAP-L1x SoCs -- it's 
the buffer manager.



If it doesn't work, work with Vinod to fix the api. It's
expected, I'm working on dmaengine API changes right now to deal with a
limitation of EDMA that needs to be abstracted.


   Sorry, now it's TI's task. I no longer have time to work on this (my 
internal project to push OMAP-L1x support upstream has expired at Sep 2010) 
and my future in MV is very uncertain at this moment. Most probably I'll leave 
it (or be forced to leave).



As pointed out, edma.c is already here in arch/arm/, so moving it doesn't
add something new. It does let us regression test all platforms that use it
(both Davinci and AM33xx) as I go through the conversion process.


   Could have been the same with CPPI 4.1 in theory if it was added to 
mach-davinci/ back in 2009... we'd then only have to move it. EDMA code is 
much older of course, so it's probably more justified.



-Matt


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 23:55, Matt Porter wrote:


Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.



I think this should rather go to drivers/dma/?



No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in plat-omap/dma.c. The actual
dmaengine driver is in drivers/dma/edma.c as a wrapper around
this...same way OMAP DMA engine conversion is being done.



 Keeps me wondering why we couldn't have the same with CPPI 4.1 when I 
proposed
that, instead of waiting indefinitely for TI to convert it to drivers/dma/
directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... 
Sigh.



That is a shame. Yeah, I've pointed out that I was doing this exactly
the same way as was acceptable for the OMAP DMA conversion since it was
in RFC. The reasons are sound since in both cases, we have many drivers
to convert that need to continue using the private DMA APIs.



  In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other
in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is
sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't
know them well).



Well, it's pretty clear to me now that there's good reason for it not
landing in arch/arm/ so the obvious path is to do the dmaengine
conversion and put it in drivers/dma/ if it's really a generic dma engine.
I'm not sure why you express concern over the dma engine api not fitting
with CPPI 4.1?



 It's not a DMA controller only, it's 3 distinct devices, with the DMA
controller being one among them and using another one, the queue manager, as
some sort of proxy. The third device doesn't exist on OMAP-L1x SoCs -- it's
the buffer manager.



Interesting, and you don't see a way to have this split between
dmaengine and the musb driver?


   This can't be split into the MUSB DMA driver, as the neither of CPPI 4.1 
devices are really MUSB specific. The support should be generic.



This all assumes there's even a match as
RMK did raise concerns elsewhere in this thread.


   Didn't quite get this sentence.


If it doesn't work, work with Vinod to fix the api. It's
expected, I'm working on dmaengine API changes right now to deal with a
limitation of EDMA that needs to be abstracted.



 Sorry, now it's TI's task. I no longer have time to work on this (my
internal project to push OMAP-L1x support upstream has expired at Sep 2010)


   If not somewhat earlier... anyway, I wasn't able to spent much time on 
this project in 2010.



and my future in MV is very uncertain at this moment. Most probably I'll leave
it (or be forced to leave).



Too bad, it's certainly "somebody's task". The people employed by TI
have names too. ;) I suspect it falls to Felipe or Kishon these days,
but I try to avoid USB as it's generally a source of pain.


   I'm probably masochistic then since I'm still sending MUSB patches, eben 
though I wasn't working on it at MV until I switched to Kontron boards 2 weeks 
ago. Now my task is fixing USB bugs on real Sitara with dual MUSB. :-)



As pointed out, edma.c is already here in arch/arm/, so moving it doesn't
add something new. It does let us regression test all platforms that use it
(both Davinci and AM33xx) as I go through the conversion process.



 Could have been the same with CPPI 4.1 in theory if it was added to
mach-davinci/ back in 2009... we'd then only have to move it. EDMA code is


   I don't know why Kevin didn't merge it then. I remembere he didn't like 
that it was not a proper platform driver and was tied with the platform code 
thru some variables, and I refused to change that...



much older of course, so it's probably more justified.



Absolutely, timing is everything. I can assure you I've flamed enough
people "internally" about leaving this EDMA dmaengine conversion for so
long. As you might have guessed, AM33xx is a bit of a driver for it, but
all of this would have been quite a bit simpler had somebody taken a
little effort and moved edma to dmaengine years ago when slave dma
support was added to dmaengine. ;)


   Hm, it seems to have happened back in 2008 when I was working on CPPI 4.1 
code. Too bad I only knew that drivers/dma/ are for accelerating RAIDs back 
then (if actually noot later than that).
   TI seems to put more efforts into its Arago project than in supoporting 
the cutting edge (or not) CPUs in mainline -- at lest things seem go there 
first. Many Arago patches never reached mainline (not that they can be applied 
without cleanup though).



-Matt


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] ARM: davinci: da850: add wdt OF_DEV_AUXDATA entry

[Sergei Shtylyov]

Hello.

On 04-02-2013 15:50, Sekhar Nori wrote:


Auxdata is not evm specific. This can instead be called da850_auxdata_lookup[].



Also, I dont think it is necessary to add auxdata in a separate patch
from dt nodes. So, I fixed these issues and came up with below patch. I
tested basic wdt reboot. reboot command is still broken (with or
without this patch). Can you please look at that?



Thanks,
Sekhar



8<
From: "Kumar, Anil" 
Date: Thu, 24 Jan 2013 14:08:14 +0530
Subject: [PATCH 1/1] ARM: davinci: da850: add wdt DT node



Add da850 wdt DT node.



Signed-off-by: Kumar, Anil 
Signed-off-by: Sekhar Nori 

[...]


diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 8dd15c0..2800090 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -88,6 +88,11 @@
  19>;
status = "disabled";
};
+   wdt: wdt@1c21000 {
+   compatible = "ti,davinci-wdt";
+   reg = <0x21000 0xfff>;


   Not 0x1000? This is region size, not upper limit.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02/04/2013 06:41 PM, Felipe Balbi wrote:

> I guess to make the MUSB side simpler we would need musb-dma-engine glue
> to map dmaengine to the private MUSB API. Then we would have some
> starting point to also move inventra (and anybody else) to dmaengine
> API.

Why? Inventra is a dedicated device's private DMA controller, why make
 universal DMA driver for it?

>>> because it doesn't make sense to support multiple DMA APIs. We can check
>>> from MUSB's registers if it was configured with Inventra DMA support and
>>> based on that we can register MUSB's own DMA Engine to dmaengine API.

>> Hang on.  This is one of the DMA implementations which is closely
>> coupled with the USB and only the USB?  If it is...

>> I thought this had been discussed _extensively_ before.  I thought the
>> resolution on it was:
>> 1. It would not use the DMA engine API.
>> 2. It would not live in arch/arm.
>> 3. It would be placed nearby the USB driver it's associated with.

>> (1) because we don't use APIs just for the hell of it - think.  Do we
>> use the DMA engine API for PCI bus mastering ethernet controllers?  No.
>> Do we use it for PCI bus mastering SCSI controllers?  No.  Because the
>> DMA is integral to the rest of the device.

> that's not really a fair comparison, however. MUSB is used with several
> DMA engines.

> The only DMA engine which is really coupled with MUSB is the Inventra
> DMA engine which comes as an optional feature to the IP. Many users have

   That's not quite true. At least CPPI 3.0 is coupled with MUSB as well. The
programming interface is MUSB specific, and differs from that of the EMAC driver
which also uses CPPI 3.0 (however, the DMA descriptor format is the same between
both, IIRC).

> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
> Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

> Granted, CPPI 4.1 makes some assumptions about the fact that it's
> handling USB tranfers,

   What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just
natural. Generic CPPI 4.1 support code (as was posted for both mach-dacinci/ or
common/ placement) made no such assumptions.

> but nevertheless, the IP can be, and in fact is,
> used with many different DMA engines and driver needs to cope with it.

   What IP, CPPI 4.1 or MUSB?

> Current DMA abstraction is quite poor, for example there's no way to
> compile support for multiple DMA engines. Code also makes certain, IMO
> unnecessary, assumptions about the underlying DMA engine (abstraction is
> poor, as said above but it we could follow MUSB's programming guide when
> it comes to programming DMA transfers).

   Don't know, I was quite content with the abstraction when writing CPPI 4.1
driver for MUSB...

> Considering all of the above, it's far better to use DMA engine and get
> rid of all the mess.

   In my eyes, getting rid of the mess doesn't justify breaking the rules that
Russell formulated above.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02/04/2013 07:47 PM, Felipe Balbi wrote:

> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
>>> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
>>> Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

>>> Granted, CPPI 4.1 makes some assumptions about the fact that it's
>>> handling USB tranfers,

>>What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just

> HW makes the asumptions

   Not true at all. There is a separate set of registers (at offset 0) which
copes with USB specifics, but CPPI 4.1 itself doesn't know about USB anything.
It's just the way the driver was written that it used both sets of registers but
this needs to be changed into more abstacted accesses to the USB-specific part,
to cope with it being different on different platfroms, like AM35x. The driver
as it was last posted, just needs rework now.

>>> but nevertheless, the IP can be, and in fact is,
>>> used with many different DMA engines and driver needs to cope with it.

>>What IP, CPPI 4.1 or MUSB?

> MUSB

>>> Current DMA abstraction is quite poor, for example there's no way to
>>> compile support for multiple DMA engines. Code also makes certain, IMO
>>> unnecessary, assumptions about the underlying DMA engine (abstraction is
>>> poor, as said above but it we could follow MUSB's programming guide when
>>> it comes to programming DMA transfers).

>>Don't know, I was quite content with the abstraction when writing CPPI 4.1
>> driver for MUSB...

> look closer. The whole:

> if (is_cppi())
>   foo();
> else if (is_inventra())
>   bar();
> else if (is_omap_sdma())
>   baz();

> is bogus.

   That part -- yes. There were attempt to get rid of this, but without changing
the DMA API. It was left halfway done after my only critical comment, IIRC. Will
we ever see the continuation of this effort?

>>> Considering all of the above, it's far better to use DMA engine and get
>>> rid of all the mess.

>>In my eyes, getting rid of the mess doesn't justify breaking the rules 
>> that
>> Russell formulated above.

> MUSB is no PCI, there is no single, standard interface to the DMA
> engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA
> engine), every DMA engine comes with its own set of registers, its own
> programming model and so forth.

   Same can be said about PCI where each bus master has its own programming i/f
-- so I didn't really dig this example.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02/04/2013 08:02 PM, Felipe Balbi wrote:

>>> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
>>>>> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
>>>>> Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

>>>>> Granted, CPPI 4.1 makes some assumptions about the fact that it's
>>>>> handling USB tranfers,

>>>>What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's 
>>>> just

>>> HW makes the asumptions

>>Not true at all. There is a separate set of registers (at offset 0) which
>> copes with USB specifics, but CPPI 4.1 itself doesn't know about USB 
>> anything.

> CPPI 4.1 was made for USB transfers.

   Utter nonsense, CPPI 4.1 is hardware abstract DMA engine. It's used for
Ethernet transfers on out-of-tree platforms like mach-avalanche/.

>> It's just the way the driver was written that it used both sets of registers 
>> but
>> this needs to be changed into more abstacted accesses to the USB-specific 
>> part,
>> to cope with it being different on different platfroms, like AM35x. The 
>> driver
>> as it was last posted, just needs rework now.

> are you saying you will do the work ?

   My efforts stopped to be funded by MV back in 2010. Hell, I'm not even
working in MV as I used to, hanging on the verge of my current contract being
terminated.

>>>>Don't know, I was quite content with the abstraction when writing CPPI 
>>>> 4.1
>>>> driver for MUSB...

>>> look closer. The whole:

>>> if (is_cppi())
>>> foo();
>>> else if (is_inventra())
>>> bar();
>>> else if (is_omap_sdma())
>>> baz();

>>> is bogus.

>>That part -- yes. There were attempt to get rid of this, but without 
>> changing
>> the DMA API. It was left halfway done after my only critical comment, IIRC. 
>> Will
>> we ever see the continuation of this effort?

> patches are welcome

   There was a patch, it only needed comments addressed. I think the author was
Heikki Krogerus. As for me, my time is very limited, so be thankful even for
those scarce patches I'm sending out now -- I'm doing them in my copious free 
time.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] i2c: davinci: update to devm_* API

[Sergei Shtylyov]

Hello.

On 06-02-2013 15:22, Vishwanathrao Badarkhe, Manish wrote:


Update the code to use devm_* API so that driver
core will manage resources.



Signed-off-by: Vishwanathrao Badarkhe, Manish 
---
Changes since V1:
   - Rebase on top of v3.8-rc6 of linus tree.
   - Apply devm operation on clk_get.



:100644 100644 6a0a553... da4e218... M  drivers/i2c/busses/i2c-davinci.c
  drivers/i2c/busses/i2c-davinci.c |   45 +++---
  1 files changed, 13 insertions(+), 32 deletions(-)



diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 6a0a553..da4e218 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c

[...]

@@ -699,22 +693,24 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev->pdata = &davinci_i2c_platform_data_default;
}

-   dev->clk = clk_get(&pdev->dev, NULL);
+   dev->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(dev->clk)) {
r = -ENODEV;
goto err_free_mem;
}
clk_prepare_enable(dev->clk);

-   dev->base = ioremap(mem->start, resource_size(mem));
+   dev->base = devm_request_and_ioremap(&pdev->dev, mem);
if (!dev->base) {
r = -EBUSY;


   Comment to devm_request_and_ioremap() suggests returning -EADDRNOTAVAIL on 
failure. -EBUSY wasn't the right code even before this change, should have 
been -ENOMEM.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] ARM: OMAP: devices: create device for usb part of control module

[Sergei Shtylyov]

Hello.

On 06-02-2013 9:58, Kishon Vijay Abraham I wrote:


A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.



Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
  arch/arm/mach-omap2/devices.c |   45 +
  1 file changed, 45 insertions(+)



diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 626f3ea..6cda103 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@

[...]

@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)

[...]

+static struct platform_device omap4_control_usb = {
+   .name   = "omap-control-usb",
+   .id = -1,
+   .dev = {
+   .platform_data = &omap4_control_usb_pdata,
+   },
+   .num_resources = 2,
+   .resource = omap4_control_usb_res,


   Either align = or not, not both at once.


+};


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] watchdog: davinci_wdt: update to devm_* API

[Sergei Shtylyov]

Hello.

On 07-02-2013 7:32, Kumar, Anil wrote:


Update the code to use devm_* API so that driver
core will manage resources.



Signed-off-by: Kumar, Anil 
---
This patch applies on top of v3.8-rc6.



Tested on da850 EVM.



:100644 100644 e8e8724... 6ad76a3... M  drivers/watchdog/davinci_wdt.c
  drivers/watchdog/davinci_wdt.c |   34 +-
  1 files changed, 9 insertions(+), 25 deletions(-)



diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index e8e8724..6ad76a3 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c

[...]

@@ -213,49 +212,34 @@ static int davinci_wdt_probe(struct platform_device *pdev)

[...]

-   size = resource_size(wdt_mem);
-   if (!request_mem_region(wdt_mem->start, size, pdev->name)) {
-   dev_err(dev, "failed to get memory region\n");
-   return -ENOENT;
-   }
-
-   wdt_base = ioremap(wdt_mem->start, size);
+   wdt_base = devm_request_and_ioremap(&pdev->dev, wdt_mem);
if (!wdt_base) {
-   dev_err(dev, "failed to map memory region\n");
-   release_mem_region(wdt_mem->start, size);
-   wdt_mem = NULL;
+   dev_err(&pdev->dev, "ioremap failed\n");
return -ENOMEM;


   Comment to devm_request_and_ioremap() suggest returning -EADDRNOTAVAIL 
instead.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1]linux-usb: fix the idProduct value to be compatible with current CPU in initializers.c

[Sergei Shtylyov]

Hello.

On 07-02-2013 11:32, fangxiaozhi 00110321 wrote:


From: fangxiaozhi 



1. The idProduct is little endian, so make sure its value to be compatible with 
the current CPU. Make no break on big endian processors.


   Wrap your lines reasonable at 80 columns at last (better somewht less). 
And why "1." here? Where is "2."?



Signed-off-by: fangxiaozhi 



   Either use --- tearline, or no tearline at all.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH resend] testusb: remove all mentions of 'usbfs'

[Sergei Shtylyov]

Commit 8a424bf40d772fedacc91862ecc86f10541fabb3 (tools/usb: remove last USBFS
user) removed 'usbfs' files from the source but retained mentions of 'usbfs'
all over the place, most importantly in the misleading error messages printed
in case USB device files are not there.  Remove all the  mentions of 'usbfs'
for good now!

Signed-off-by: Sergei Shtylyov 

---
This patch is atop of 'usb-next' branch of Greg's tree...

Yes, I got that "usbfs files are missing" message on DaVinci recently, and it
sent me on the wrong trail for some time, so I'd like to egt this sorted out...

Resending as I messed out with KMail config. and not seeing the message in the
list archives...

 tools/usb/testusb.c |   27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

Index: usb/tools/usb/testusb.c
===
--- usb.orig/tools/usb/testusb.c
+++ usb/tools/usb/testusb.c
@@ -279,8 +279,7 @@ nomem:
 
entry->ifnum = ifnum;
 
-   /* FIXME ask usbfs what speed; update USBDEVFS_CONNECTINFO so
-* it tells about high speed etc */
+   /* FIXME update USBDEVFS_CONNECTINFO so it tells about high speed etc */
 
fprintf(stderr, "%s speed\t%s\t%u\n",
speed(entry->speed), entry->name, entry->ifnum);
@@ -351,7 +350,7 @@ restart:
return arg;
 }
 
-static const char *usbfs_dir_find(void)
+static const char *usb_dir_find(void)
 {
static char udev_usb_path[] = "/dev/bus/usb";
 
@@ -380,7 +379,7 @@ int main (int argc, char **argv)
int c;
struct testdev  *entry;
char*device;
-   const char  *usbfs_dir = NULL;
+   const char  *usb_dir = NULL;
int all = 0, forever = 0, not = 0;
int test = -1 /* all */;
struct usbtest_paramparam;
@@ -407,8 +406,8 @@ int main (int argc, char **argv)
case 'D':   /* device, if only one */
device = optarg;
continue;
-   case 'A':   /* use all devices with specified usbfs dir */
-   usbfs_dir = optarg;
+   case 'A':   /* use all devices with specified USB dir */
+   usb_dir = optarg;
/* FALL THROUGH */
case 'a':   /* use all devices */
device = NULL;
@@ -449,7 +448,7 @@ usage:
"usage: %s [options]\n"
"Options:\n"
"\t-D dev   only test specific device\n"
-   "\t-A usbfs-dir\n"
+   "\t-A usb-dir\n"
"\t-a   test all recognized devices\n"
"\t-l   loop forever(for stress test)\n"
"\t-t testnum   only run specified case\n"
@@ -470,18 +469,18 @@ usage:
goto usage;
}
 
-   /* Find usbfs mount point */
-   if (!usbfs_dir) {
-   usbfs_dir = usbfs_dir_find();
-   if (!usbfs_dir) {
-   fputs ("usbfs files are missing\n", stderr);
+   /* Find usb device subdirectory */
+   if (!usb_dir) {
+   usb_dir = usb_dir_find();
+   if (!usb_dir) {
+   fputs ("USB device files are missing\n", stderr);
return -1;
}
}
 
/* collect and list the test devices */
-   if (ftw (usbfs_dir, find_testdev, 3) != 0) {
-   fputs ("ftw failed; is usbfs missing?\n", stderr);
+   if (ftw (usb_dir, find_testdev, 3) != 0) {
+   fputs ("ftw failed; are USB device files missing?\n", stderr);
return -1;
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] testusb: remove all mentions of 'usbfs'

[Sergei Shtylyov]

Commit 8a424bf40d772fedacc91862ecc86f10541fabb3 (tools/usb: remove last USBFS
user) removed 'usbfs' files from the source but retained mentions of 'usbfs'
all over the place, most importantly in the misleading error messages printed
in case USB device files are not there.  Remove all the  mentions of 'usbfs'
for good now!

Signed-off-by: Sergei Shtylyov 

---
This patch is atop of 'usb-next' branch of Greg's tree...

Yes, I got that "usbfs files are missing" message on DaVinci recently, and it
sent me on the wrong trail for some time, so I'd like to egt this sorted out...

 tools/usb/testusb.c |   27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

Index: usb/tools/usb/testusb.c
===
--- usb.orig/tools/usb/testusb.c
+++ usb/tools/usb/testusb.c
@@ -279,8 +279,7 @@ nomem:
 
entry->ifnum = ifnum;
 
-   /* FIXME ask usbfs what speed; update USBDEVFS_CONNECTINFO so
-* it tells about high speed etc */
+   /* FIXME update USBDEVFS_CONNECTINFO so it tells about high speed etc */
 
fprintf(stderr, "%s speed\t%s\t%u\n",
speed(entry->speed), entry->name, entry->ifnum);
@@ -351,7 +350,7 @@ restart:
return arg;
 }
 
-static const char *usbfs_dir_find(void)
+static const char *usb_dir_find(void)
 {
static char udev_usb_path[] = "/dev/bus/usb";
 
@@ -380,7 +379,7 @@ int main (int argc, char **argv)
int c;
struct testdev  *entry;
char*device;
-   const char  *usbfs_dir = NULL;
+   const char  *usb_dir = NULL;
int all = 0, forever = 0, not = 0;
int test = -1 /* all */;
struct usbtest_paramparam;
@@ -407,8 +406,8 @@ int main (int argc, char **argv)
case 'D':   /* device, if only one */
device = optarg;
continue;
-   case 'A':   /* use all devices with specified usbfs dir */
-   usbfs_dir = optarg;
+   case 'A':   /* use all devices with specified USB dir */
+   usb_dir = optarg;
/* FALL THROUGH */
case 'a':   /* use all devices */
device = NULL;
@@ -449,7 +448,7 @@ usage:
"usage: %s [options]\n"
"Options:\n"
"\t-D dev   only test specific device\n"
-   "\t-A usbfs-dir\n"
+   "\t-A usb-dir\n"
"\t-a   test all recognized devices\n"
"\t-l   loop forever(for stress test)\n"
"\t-t testnum   only run specified case\n"
@@ -470,18 +469,18 @@ usage:
goto usage;
}
 
-   /* Find usbfs mount point */
-   if (!usbfs_dir) {
-   usbfs_dir = usbfs_dir_find();
-   if (!usbfs_dir) {
-   fputs ("usbfs files are missing\n", stderr);
+   /* Find usb device subdirectory */
+   if (!usb_dir) {
+   usb_dir = usb_dir_find();
+   if (!usb_dir) {
+   fputs ("USB device files are missing\n", stderr);
return -1;
}
}
 
/* collect and list the test devices */
-   if (ftw (usbfs_dir, find_testdev, 3) != 0) {
-   fputs ("ftw failed; is usbfs missing?\n", stderr);
+   if (ftw (usb_dir, find_testdev, 3) != 0) {
+   fputs ("ftw failed; are USB device files missing?\n", stderr);
return -1;
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] mac802154: Use netif flow control

[Sergei Shtylyov]

Hello.

On 04/02/2013 10:47 PM, Alan Ott wrote:


Use netif_stop_queue() and netif_wake_queue() to control the flow of
packets to mac802154 devices.  Since many IEEE 802.15.4 devices have no
output buffer, and since the mac802154 xmit() function is designed to
block, netif_stop_queue() is called after each packet.

Signed-off-by: Alan Ott 
---
  net/mac802154/tx.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index a248246..fe3e02c 100644
--- a/net/mac802154/tx.c
+++ b/net/mac802154/tx.c

[...]

@@ -71,6 +73,12 @@ static void mac802154_xmit_worker(struct work_struct *work)
  out:
mutex_unlock(&xw->priv->phy->pib_lock);
  
+	/* Restart the netif queue on each sub_if_data object. */

+   rcu_read_lock();
+   list_for_each_entry_rcu(sdata, &xw->priv->slaves, list) {
+   netif_wake_queue(sdata->dev);
+   }



   Are {} really necessary here?


@@ -108,6 +117,13 @@ netdev_tx_t mac802154_tx(struct mac802154_priv *priv, 
struct sk_buff *skb,
return NETDEV_TX_BUSY;
}
  
+	/* Stop the netif queue on each sub_if_data object. */

+   rcu_read_lock();
+   list_for_each_entry_rcu(sdata, &priv->slaves, list) {
+   netif_stop_queue(sdata->dev);
+   }


   And here?

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: Alchemy: Fix typo "CONFIG_DEBUG_PCI"

[Sergei Shtylyov]

Hello.

On 04-04-2013 15:25, Paul Bolle wrote:


Also add a newline to a debugging printk that this fix enables.



Signed-off-by: Paul Bolle 
---
0) Entirely untested. Adding the newline adds a checkpatch warning for
over 80 characters lines.



1) Typo was added in v3.2, through commit
7517de348663b08a808aff44b5300e817157a568 ("MIPS: Alchemy: Redo PCI as
platform driver").


This is the information for the changelog.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] USB: option: add support for Telit LE920

[Sergei Shtylyov]

Hello.

On 28-01-2013 19:47, Daniele Palmas wrote:


From: danielepa 


   Name/email should preferrably be the same as the one in your signoff. 
Besides, the email address is not valid here.



Add PID and special handling for Telit LE920



Signed-off-by: Daniele Palmas 


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ata: Fix DVD not dectected at some Haswell platforms

[Sergei Shtylyov]

Hello.

On 30-01-2013 21:19, Youquan Song wrote:


There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d


  Please also specify the summary of that patch in parens.


fix the 4 ports


   s/fix/fixing/


IDE controller 32bit PIO mode.
Recently, the problem was showed


   s/showed/shown/


at Haswell platform which includes 2 ports IDE controller.



So introduce a qurik


   Quirk.


patch to disable 32bit PIO at this IDE controller.


   s/at/on/


Signed-off-by: Youquan Song 


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ata: Fix DVD not dectected at some Haswell platforms

[Sergei Shtylyov]

Hello.

On 30-01-2013 21:19, Youquan Song wrote:


There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d fix the 4 ports
IDE controller 32bit PIO mode.
Recently, the problem was showed at Haswell platform which includes 2 ports
IDE controller.



So introduce a qurik patch to disable 32bit PIO at this IDE controller.



Signed-off-by: Youquan Song 
---
  drivers/ata/ata_piix.c |   14 +-
  1 files changed, 13 insertions(+), 1 deletions(-)



diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index ef773e1..1993e52 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c

[...]

@@ -326,7 +327,7 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
/* SATA Controller IDE (Lynx Point) */
-   { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+   { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },


   Also, are you sure this one and the following Lynx Point controllers are 
not affected?



/* SATA Controller IDE (Lynx Point-LP) */


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02/01/2013 09:49 PM, Matt Porter wrote:

>>> Move mach-davinci/dma.c to common/edma.c so it can be used
>>> by OMAP (specifically AM33xx) as well.

>> I think this should rather go to drivers/dma/?

> No, this is the private EDMA API. It's the analogous thing to
> the private OMAP dma API that is in plat-omap/dma.c. The actual
> dmaengine driver is in drivers/dma/edma.c as a wrapper around
> this...same way OMAP DMA engine conversion is being done.

  Keeps me wondering why we couldn't have the same with CPPI 4.1 when I proposed
that, instead of waiting indefinitely for TI to convert it to drivers/dma/
directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... 
Sigh.

> -Matt

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02/01/2013 09:58 PM, Felipe Balbi wrote:

> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx) as well.

 I think this should rather go to drivers/dma/?

>>> No, this is the private EDMA API. It's the analogous thing to
>>> the private OMAP dma API that is in plat-omap/dma.c. The actual
>>> dmaengine driver is in drivers/dma/edma.c as a wrapper around
>>> this...same way OMAP DMA engine conversion is being done.

>>   Keeps me wondering why we couldn't have the same with CPPI 4.1 when I 
>> proposed
>> that, instead of waiting indefinitely for TI to convert it to drivers/dma/
>> directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... 
>> Sigh.

> good point, do you wanna send some patches ?

   I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(

> I guess to make the MUSB side simpler we would need musb-dma-engine glue
> to map dmaengine to the private MUSB API. Then we would have some
> starting point to also move inventra (and anybody else) to dmaengine
> API.

   Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?

> Once that's done, we drop MUSB's private API.

   Don't think it's a good idea.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 0:56, Felipe Balbi wrote:


good point, do you wanna send some patches ?



I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move.


   Like with EDMA we have nothing else to do with CPPI 4.1 being shared by 
DaVinci-like and OMAP-like SOCs. Thank TI for creatring this mess. And 
actually even that is not a good place since I think I know of a MIPS SoC 
having CPPI 4.1 as well, just out of tree.


> But then again, so
> wasn't asking for the patch to be removed :-s

   Unfortunately, Russell has done it -- all that was discuseed without me in 
the loop even. :-/



I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.



Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?



because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register MUSB's own DMA Engine to dmaengine API.


I still disagree. IMO drivers/dma/ is for standalone DMA engines. Else we 
could stick every bus mastering device's DMA engines there. CPPI 4.1 is in 
design standlone DMA engine, despite all in-tree implementations having it as 
subblock of MUSB and serving only MUSB.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 01-02-2013 22:59, Matt Porter wrote:


Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.



I think this should rather go to drivers/dma/?



No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in plat-omap/dma.c. The actual
dmaengine driver is in drivers/dma/edma.c as a wrapper around
this...same way OMAP DMA engine conversion is being done.



   Keeps me wondering why we couldn't have the same with CPPI 4.1 when I 
proposed
that, instead of waiting indefinitely for TI to convert it to drivers/dma/
directly. We could have working MUSB DMA on OMAP-L1x/Sitara all this time... 
Sigh.



That is a shame. Yeah, I've pointed out that I was doing this exactly
the same way as was acceptable for the OMAP DMA conversion since it was
in RFC. The reasons are sound since in both cases, we have many drivers
to convert that need to continue using the private DMA APIs.


   In case of CPPI 4.1, we'd only have to convert MUSB DMA driver. Other 
in-tree CPPI 4.1 having SoCs don't use it for anything but MUSB -- it even is 
sub-block of their MUSB device, AFAIK (I maybe wrong about Sitaras -- I don't 
know them well).



-Matt


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 1:30, Russell King - ARM Linux wrote:


On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:

good point, do you wanna send some patches ?



I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.


   Any chance to bring it back to life? :-)
   Although... drivers/usb/musb/cppi41.c would need to be somewhat reworked 
for at least AM35x and I don't have time. But that may change, of course.



I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.



Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?



because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register MUSB's own DMA Engine to dmaengine API.



Hang on.  This is one of the DMA implementations which is closely
coupled with the USB and only the USB?  If it is...



I thought this had been discussed _extensively_ before.  I thought the
resolution on it was:
1. It would not use the DMA engine API.
2. It would not live in arch/arm.
3. It would be placed nearby the USB driver it's associated with.



(1) because we don't use APIs just for the hell of it - think.  Do we
use the DMA engine API for PCI bus mastering ethernet controllers?  No.
Do we use it for PCI bus mastering SCSI controllers?  No.  Because the
DMA is integral to the rest of the device.



The DMA engine API only makes sense if the DMA engine is a shared
system resource.


   Thanks for such extensive wording in the support of my point. :-)

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 1:30, Russell King - ARM Linux wrote:


On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:

good point, do you wanna send some patches ?



I have already sent them countless times and even stuck CPPI 4.1 support (in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.



I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.



Why? Inventra is a dedicated device's private DMA controller, why make
universal DMA driver for it?



because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register MUSB's own DMA Engine to dmaengine API.



Hang on.  This is one of the DMA implementations which is closely
coupled with the USB and only the USB?  If it is...



I thought this had been discussed _extensively_ before.  I thought the
resolution on it was:
1. It would not use the DMA engine API.
2. It would not live in arch/arm.
3. It would be placed nearby the USB driver it's associated with.


   Note that all this doesn't apply to CPPI 4.1 controller (as contrasted to 
CPPI 3.0 support in MUSB aand EMAC drivers) -- it's shared by design. Just the 
implementations that are in tree have it as MUSB's sub-block, serving only MUSB.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 4:44, Russell King - ARM Linux wrote:


On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:

good point, do you wanna send some patches ?



 I have already sent them countless times and even stuck CPPI 4.1 support 
(in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.



Any chance to bring it back to life? :-)
Although... drivers/usb/musb/cppi41.c would need to be somewhat
reworked for at least AM35x and I don't have time. But that may change,
of course.



Right, I've just looked back at the various meeting minutes from December
2010 when the CPPI stuff was discussed.  Yes, I archive these things and
all email discussions for referencing in cases like this.


   Thanks.


Unfortunately, they do not contain any useful information other than the
topic having been brought up.  At that point, the CPPI stuff was in
mach-davinci, and I had suggested moving it into drivers/dma.


   I don't remember that, probably was out of the loop again.


The result of that was to say that it doesn't fit the DMA engine APIs.


   I remember this as a discussion happening post me sending the patch to the 
patch system and it being discarded...



So someone came up with the idea of putting it in arch/arm/common - which


   Probably was me. There was also idea of putting it into drivers/usb/musb/ 
-- which TI indeed followed in its Arago prject. I firmly denied that suggestion.



I frankly ignored by email (how long have we been saying "no drivers in
arch/arm" ?)


   But there *are* drivers there! And look at edma.c which is about to be 
moved there... Anyway, I haven't seen such warnings, probably was too late in 
the game.



Now, it would've been discussed in that meeting, but unfortunately no
record exists of that.  What does follow that meeting is a discussion
trail.  From what I can see there, but it looks to me like the decision
was taken to move it to the DMA engine API, and work on sorting out MUSB
was going to commence.



The last email in that says "I'll get to that soon"... and that is also
the final email I have on this topic.  I guess if nothing has happened...
Shrug, that's someone elses problem.


   Well, as usual... :-(


Anyway, the answer for putting it in arch/arm/common hasn't changed,
and really, where we are now, post Linus having a moan about the size
of arch/arm, that answer is even more concrete in the negative.  It's
54K of code which should not be under arch/arm at all.



Anyway, if you need to look at the patch, it's 6305/1.  Typing into the
summary search box 'cppi' found it in one go.


   Thanks, I remember this variant was under arch/arm/common/.
   Now however, I see what happened to that variant in somewhat different 
light. Looks like it was entirely your decision to discard the patch, without 
TI's request...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

[Sergei Shtylyov]

Hello.

On 02-02-2013 14:18, Russell King - ARM Linux wrote:


On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:

good point, do you wanna send some patches ?



  I have already sent them countless times and even stuck CPPI 4.1 support 
(in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(



sticking into arch/arm/common/ wasn't a nice move. But then again, so
wasn't asking for the patch to be removed :-s



Err, patches don't get removed, they get moved to 'discarded'.



 Any chance to bring it back to life? :-)
 Although... drivers/usb/musb/cppi41.c would need to be somewhat
reworked for at least AM35x and I don't have time. But that may change,
of course.



Right, I've just looked back at the various meeting minutes from December
2010 when the CPPI stuff was discussed.  Yes, I archive these things and
all email discussions for referencing in cases like this.



Thanks.



Unfortunately, they do not contain any useful information other than the
topic having been brought up.  At that point, the CPPI stuff was in
mach-davinci, and I had suggested moving it into drivers/dma.



I don't remember that, probably was out of the loop again.


   I looked back at the history of CPPI 4.1 driver related threads, and found 
that Kevin Hilman gas suggested it too while the driver was in mach-davinci/ 
still...



The result of that was to say that it doesn't fit the DMA engine APIs.


   Right, I tried to fit it (in my thought only though) in and it didn't work 
out.



I remember this as a discussion happening post me sending the patch to
the patch system and it being discarded...


   Well, actually before doing this too...


So someone came up with the idea of putting it in arch/arm/common - which



Probably was me.


   No, it was someone from TI.


There was also idea of putting it into
drivers/usb/musb/ -- which TI indeed followed in its Arago prject. I
firmly denied that suggestion.


   Moving it to drivers/usb/ is probably the reason TI has been quite content 
with the situation -- their clients kept receiving MUSB DMA support on both 
OMAP-L1x and then Sitara, so all looked well for them.



I frankly ignored by email (how long have we been saying "no drivers in
arch/arm" ?)


   Well, maybe you should have said it one more time for those who were late 
in the game like me.



But there *are* drivers there! And look at edma.c which is about to be
moved there... Anyway, I haven't seen such warnings, probably was too
late in the game.



I've already objected about the header moving to some random place in
arch/arm/include.  Really, edma.c needs to find another home too - but
there's a difference here.  edma.c is already present under arch/arm.
CPPI is _not_.  CPPI is new code appearing under arch/arm (you can see
that for yourself by looking at the diffstat of 6305/1... it doesn't
move files, it adds new code.)


   Yes, of course, that's clear.


Now, it would've been discussed in that meeting, but unfortunately no
record exists of that.  What does follow that meeting is a discussion
trail.  From what I can see there, but it looks to me like the decision
was taken to move it to the DMA engine API, and work on sorting out MUSB
was going to commence.



The last email in that says "I'll get to that soon"... and that is also
the final email I have on this topic.  I guess if nothing has happened...
Shrug, that's someone elses problem.



Well, as usual... :-(



Anyway, the answer for putting it in arch/arm/common hasn't changed,
and really, where we are now, post Linus having a moan about the size
of arch/arm, that answer is even more concrete in the negative.  It's
54K of code which should not be under arch/arm at all.



Anyway, if you need to look at the patch, it's 6305/1.  Typing into the
summary search box 'cppi' found it in one go.



Thanks, I remember this variant was under arch/arm/common/.
Now however, I see what happened to that variant in somewhat different
light. Looks like it was entirely your decision to discard the patch,
without TI's request...



Firstly, it is *my* perogative to say no to anything in arch/arm, and I
really don't have to give reasons for it if I choose to.


   That's clear. You're the ARM King. :-)


Secondly, it *was* discussed with TI, and the following thread of
discussion (threaded to the minutes email) shows that *something* was
going to happen _as a result of that meeting_ to address the problem of
it being under arch/arm.  And *therefore* it was discarded from the patch
system - because there was expectation that it was going to get fixed.



For christ sake, someone even agreed to do it.  Even a target was mentioned,
of 2.6.39.  That was mentioned on 7th December 2010.  And 6305/1 was
discarded on 8t

Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match rules

[Sergei Shtylyov]

Hello.

On 25-01-2013 6:44, fangxiaozhi 00110321 wrote:


From: fangxiaozhi 



1. Define a new macro for USB storage match rules:
 matching with Vendor ID and interface descriptors.



Signed-off-by: fangxiaozhi 


  diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c 
linux-3.8-rc4/drivers/usb/storage/usb.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c 2013-01-22 14:12:42.595238727 
+0800
+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22 14:16:01.398250305 +0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, "supplemental l
   .useTransport = use_transport, \
  }

+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+ vendor_name, product_name, use_protocol, use_transport, \
+ init_function, Flags) \
+{ \
+ .vendorName = vendor_name, \
+ .productName = product_name, \
+ .useProtocol = use_protocol, \
+ .useTransport = use_transport, \
+ .initFunction = init_function, \
+}


  Shouldn't the field initilaizers be indented with tab, not space?


diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usual-tables.c 
linux-3.8-rc4/drivers/usb/storage/usual-tables.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usual-tables.c 2013-01-22 
14:12:42.594238726 +0800
+++ linux-3.8-rc4/drivers/usb/storage/usual-tables.c 2013-01-22 
14:16:01.426250199 +0800
@@ -41,6 +41,19 @@
  #define USUAL_DEV(useProto, useTrans) \
  { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans) }

+/* Define the device is matched with Vendor ID and interface descriptors */
+#define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
+ vendorName, productName, useProtocol, useTransport, \
+ initFunction, flags) \
+{ \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+ | USB_DEVICE_ID_MATCH_VENDOR, \
+ .idVendor= (id_vendor), \
+ .bInterfaceClass = (cl), \
+ .bInterfaceSubClass = (sc), \
+ .bInterfaceProtocol = (pr), \
+ .driver_info = (flags) }


   Same question. And trailing '}' should be on a separate line.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 11/11] usb: dwc3: core: stray statements are removed

[Sergei Shtylyov]

Hello.

On 25-01-2013 7:00, Kishon Vijay Abraham I wrote:


No functional change. Stray statements where removed from dwc3 core.


   s/where/are/


Signed-off-by: Kishon Vijay Abraham I 
---
  drivers/usb/dwc3/core.c |3 ---
  1 file changed, 3 deletions(-)


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/6] ARM: dts: omap5: add dwc3 omap dt data

[Sergei Shtylyov]

Hello.

On 25-01-2013 15:11, Kishon Vijay Abraham I wrote:


Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt



Signed-off-by: Kishon Vijay Abraham I 
---
  arch/arm/boot/dts/omap5.dtsi |   11 +++
  1 file changed, 11 insertions(+)



diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5f59bf2..1703a72 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,17 @@
ti,type = <2>;
};

+   omap_dwc3@4a02 {
+   compatible = "ti,dwc3";
+   ti,hwmods = "usb_otg_ss";
+   reg = <0x4a02 0x1ff>;


   Shoudn't the "reg" length be 0x200 here? It's length, not limit.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/6] ARM: dts: omap5: add dwc3 core dt data

[Sergei Shtylyov]

On 25-01-2013 15:11, Kishon Vijay Abraham I wrote:


Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt



Signed-off-by: Kishon Vijay Abraham I 
---
  arch/arm/boot/dts/omap5.dtsi |7 +++
  1 file changed, 7 insertions(+)



diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1703a72..58118c4 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -522,6 +522,13 @@
#size-cells = <1>;
utmi-mode = <2>;
ranges;
+   dwc3@4a03 {
+   compatible = "synopsys,dwc3";
+   reg = <0x4a03 0xcfff>;


   Same question here.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] : fix compilation warnings with DT disabled

[Sergei Shtylyov]

Fix the following compilation warnings (in Simon Horman's renesas.git repo):

In file included from arch/arm/mach-shmobile/setup-r8a7779.c:24:0:
include/linux/of_platform.h:107:13: warning: ‘struct of_device_id’ declared
inside parameter list [enabled by default]
include/linux/of_platform.h:107:13: warning: its scope is only this definition
or declaration, which is probably not what you want [enabled by default]
include/linux/of_platform.h:107:13: warning: ‘struct device_node’ declared
inside parameter list [enabled by default]

 only #include's headers with definitions of the above
mentioned structures if CONFIG_OF_DEVICE=y but uses them even if not. One
solution is to move some #include's out of #ifdef CONFIG_OF_DEVICE and use
incomplete declarations for the rest of the structures where the #ifdef move
doesn't help...

Reported-by: Vladimir Barinov 
Signed-off-by: Sergei Shtylyov 

---
Actually, it compiles eve without 'struct device_node' declared, I haven't
found the reason of this, so left it there...

 include/linux/of_platform.h |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux/include/linux/of_platform.h
===
--- linux.orig/include/linux/of_platform.h
+++ linux/include/linux/of_platform.h
@@ -11,9 +11,10 @@
  *
  */
 
-#ifdef CONFIG_OF_DEVICE
 #include 
 #include 
+
+#ifdef CONFIG_OF_DEVICE
 #include 
 #include 
 #include 
@@ -100,7 +101,7 @@ extern int of_platform_populate(struct d
 
 #if !defined(CONFIG_OF_ADDRESS)
 struct of_dev_auxdata;
-struct device;
+struct device_node;
 static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ata_piix: Add MODULE_PARM_DESC to prefer_ms_hyperv

[Sergei Shtylyov]

Hello.

On 02/21/2013 08:43 PM, Rado Vrbovsky wrote:


From: Andrew Brownfield
   


   Hm, I don't see his signoff...


In reference to the commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c
   


   Please also specify that commit's summary in parens (or however you 
like).



this trivial patch adds a description to prefer_ms_hyperv.

[rvrbo...@redhat.com: MODULE_PARM_DESC() string formatting modified]

Signed-off-by: Radomir Vrbovsky
   


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ata_piix: Add MODULE_PARM_DESC to prefer_ms_hyperv

[Sergei Shtylyov]

Hello.

On 21-02-2013 23:01, Rado Vrbovsky wrote:


From: Andrew Brownfield 



In reference to the commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c
"ata_piix: defer disks to the Hyper-V drivers by default",
this trivial patch adds a description to prefer_ms_hyperv.



[rvrbo...@redhat.com: MODULE_PARM_DESC() string formatting modified]



Signed-off-by: Andrew Brownfield 


   Note that you can't jus mechanically add Andrew's signoff to the patch, 
you have to ask him to sign it off... I hope you did.



Signed-off-by: Radomir Vrbovsky 


MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] pci: convert to devm_ioremap_resource()

[Sergei Shtylyov]

Hello.

On 12-03-2013 11:28, Silviu-Mihai Popescu wrote:


Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.



devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.


   There were no error messages as far as I could see, so this passage seems 
superfluous...



Signed-off-by: Silviu-Mihai Popescu 
---
  arch/mips/pci/pci-ar71xx.c |6 +++---
  arch/mips/pci/pci-ar724x.c |   18 +-
  2 files changed, 12 insertions(+), 12 deletions(-)



diff --git a/arch/mips/pci/pci-ar71xx.c b/arch/mips/pci/pci-ar71xx.c
index 412ec02..18517dd 100644
--- a/arch/mips/pci/pci-ar71xx.c
+++ b/arch/mips/pci/pci-ar71xx.c
@@ -366,9 +366,9 @@ static int ar71xx_pci_probe(struct platform_device *pdev)
if (!res)
return -EINVAL;

-   apc->cfg_base = devm_request_and_ioremap(&pdev->dev, res);
-   if (!apc->cfg_base)
-   return -ENOMEM;
+   apc->cfg_base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(apc->cfg_base))
+   return PTR_ERR(apc->cfg_base);

apc->irq = platform_get_irq(pdev, 0);
if (apc->irq < 0)
diff --git a/arch/mips/pci/pci-ar724x.c b/arch/mips/pci/pci-ar724x.c
index 8a0700d..65ec032 100644
--- a/arch/mips/pci/pci-ar724x.c
+++ b/arch/mips/pci/pci-ar724x.c
@@ -365,25 +365,25 @@ static int ar724x_pci_probe(struct platform_device *pdev)
if (!res)
return -EINVAL;

-   apc->ctrl_base = devm_request_and_ioremap(&pdev->dev, res);
-   if (apc->ctrl_base == NULL)
-   return -EBUSY;
+   apc->ctrl_base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(apc->ctrl_base))
+   return PTR_ERR(apc->ctrl_base);

res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg_base");
if (!res)
return -EINVAL;

-   apc->devcfg_base = devm_request_and_ioremap(&pdev->dev, res);
-   if (!apc->devcfg_base)
-   return -EBUSY;
+   apc->devcfg_base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(apc->devcfg_base))
+   return PTR_ERR(apc->devcfg_base);

res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "crp_base");
if (!res)
return -EINVAL;

-   apc->crp_base = devm_request_and_ioremap(&pdev->dev, res);
-   if (apc->crp_base == NULL)
-   return -EBUSY;
+   apc->crp_base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(apc->crp_base))
+   return PTR_ERR(apc->crp_base);

apc->irq = platform_get_irq(pdev, 0);
if (apc->irq < 0)


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] ARM: sunxi: dt: Add uart3 dt node

[Sergei Shtylyov]

Hello.

On 03/15/2013 11:06 PM, Maxime Ripard wrote:


Both A10 and A13 Allwinner SoCs have a Synopsys APB uart3 device
available, so add it to the sunxi.dtsi file

Signed-off-by: Maxime Ripard 
Acked-by: Emilio López 
---
  arch/arm/boot/dts/sunxi.dtsi |   10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi.dtsi b/arch/arm/boot/dts/sunxi.dtsi
index 4f78ef7..324da45 100644
--- a/arch/arm/boot/dts/sunxi.dtsi
+++ b/arch/arm/boot/dts/sunxi.dtsi
@@ -68,5 +68,15 @@
clocks = <&osc>;
status = "disabled";
};
+
+   uart3: uart@01c28c00 {


   IIRC, historically, the property name should be "serial", not "uart".

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] mfd: add syscon driver based on regmap

[Sergei Shtylyov]

Hello.

On 04-09-2012 15:35, Andi Shyti wrote:


+static int __devinit syscon_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;



Do we really need this variable? Anyway you are using it only
once in the dev_info.


   But Dong definitely could use it more than once, so it seems useful.


+   struct device_node *np = dev->of_node;
+   struct syscon *syscon;
+   struct resource res;
+   int ret;
+
+   if (!np)
+   return -ENOENT;
+
+   syscon = devm_kzalloc(&pdev->dev, sizeof(struct syscon),
+   GFP_KERNEL);
+   if (!syscon)
+   return -ENOMEM;
+
+   syscon->base = of_iomap(np, 0);
+   if (!syscon->base)
+   return -EADDRNOTAVAIL;
+
+   ret = of_address_to_resource(np, 0, &res);
+   if (ret)
+   return ret;
+
+   syscon_regmap_config.max_register = res.end - res.start - 3;
+   syscon->regmap = devm_regmap_init_mmio(&pdev->dev, syscon->base,
+   &syscon_regmap_config);
+   if (IS_ERR(syscon->regmap)) {
+   dev_err(&pdev->dev, "regmap init failed\n");
+   return PTR_ERR(syscon->regmap);
+   }
+
+   syscon->dev = &pdev->dev;
+   platform_set_drvdata(pdev, syscon);
+
+   dev_info(dev, "syscon regmap start 0x%x end 0x%x registered\n",
+   res.start, res.end);
+
+   return 0;



in case of error you are not freeing syscon.


   It's allocated using devm_kzalloc(), so is freed automaticelly upon probe 
error.



Moreover, in my opinion, some dev_err more should not heart


   Hurt, you mean?


Andi


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: usbip: stub_dev: Fixed oops during removal of usbip_host

[Sergei Shtylyov]

Hello.

On 14-09-2012 13:53, navin patidar wrote:


stub_device_reset should set kernel thread pointers to NULL.
so that at the time of usbip_host removal stub_shoutdown_connection
doesn't try to kill kernel threads which are already killed.



Signed-off-by: navin patidar 
---
  drivers/staging/usbip/stub_dev.c |   14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)



diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index 92ced35..f584af8 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -192,16 +192,13 @@ static void stub_shutdown_connection(struct usbip_device 
*ud)
if (ud->tcp_tx)
kthread_stop_put(ud->tcp_tx);

-   /*
-* 2. close the socket
+   /* 2. close the socket


   It's the preferred comment style -- why modify it?


 *
 * tcp_socket is freed after threads are killed so that usbip_xmit does
 * not touch NULL socket.
 */
-   if (ud->tcp_socket) {
+   if (ud->tcp_socket)
sock_release(ud->tcp_socket);
-   ud->tcp_socket = NULL;
-   }

/* 3. free used data */
stub_device_cleanup_urbs(sdev);
@@ -233,6 +230,13 @@ static void stub_device_reset(struct usbip_device *ud)

dev_dbg(&udev->dev, "device reset");

+   /*reset tcp socket*/


   Add spaces after /* and before */, please.


+   ud->tcp_socket = NULL;
+
+   /*reset kernel thread pointers */


   Here too.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] davinci: vpif: capture/display: fix race condition

[Sergei Shtylyov]

Hello.

On 09/14/2012 05:53 PM, Prabhakar Lad wrote:

> From: Lad, Prabhakar 

> channel_first_int[][] variable is used as a flag for the ISR,
> This flag was being set after enabling the interrupts, There
> where suitaions when the isr ocuurend even before the flag was set

   s/suitaions/situations/, s/ocuurend/occured/

> dues to which it was causing the applicaiotn hang.

   Application.

> This patch sets  channel_first_int[][] flag just before enabling the
> interrupt.

> Reported-by: David Oleszkiewicz 
> Signed-off-by: Lad, Prabhakar 
> Signed-off-by: Manjunath Hadli 
> Cc: Hans Verkuil 

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: usbip: stub_dev: Fixed oops during removal of usbip_host

[Sergei Shtylyov]

Hello.

On 09/14/2012 04:36 PM, navin patidar wrote:

> hi Sergei,
> checkpatch.pl  didn't complain any thing about patch
> coding style.

   checkpatch.pl only complains about // comments, IIRC. But see
Documentation/CodingStyle chapter 8 about multi-line comments. As for adding
spaces, it's more for aesthetic reasons...

> Anyway  thanks for reviewing the patch.
> i will send this patch again with corrections.

  Thanks you.

> --navin-patidar

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/8] gpio: pl061 depends on ARM

[Sergei Shtylyov]

Hello.

On 09/14/2012 08:23 PM, Davide Ciminaghi wrote:

> From: Alessandro Rubini 

> Patch dece904d itroduced chained_irq_enter/exit, which is only

  Rather commit dece904d. And you need to also specify its summary in parens.

> available for arch/arm and the driver won't compile elsewhere.

> The dependency is thus made explicit, because AMBA is used in the x86
> world by a PCI-to-AMBA bridge, to be submitted.

> Signed-off-by: Alessandro Rubini 
> Acked-by: Giancarlo Asnaghi 

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM

[Sergei Shtylyov]

Hello.

On 09/14/2012 03:13 PM, Stefano Stabellini wrote:

> Changes in v2:

> - mark Xen guest support on ARM as EXPERIMENTAL.

> Signed-off-by: Stefano Stabellini 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
>  arch/arm/Kconfig |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2f88d8d..e92518d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> This was deprecated in 2001 and announced to live on for 5 years.
> Some old boot loaders still use this way.
>  
> +config XEN_DOM0
> + def_bool y
> +
> +config XEN
> + bool "Xen guest support on ARM (EXPERIMENTAL)"
> + depends on EXPERIMENTAL && ARM && OF
> + select XEN_DOM0

   What's the point of selecting it if it's always "y"?

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Kgdb-bugreport] [PATCH 4/5] KGDB-8250: refactor configuration

[Sergei Shtylyov]

Hello.

Jan Kiszka wrote:


Sorry, previous version was missing some __init[data] attributes which
were dropped in an intermediate stage. Here comes an updated patch:



<---snip--->



This major refactoring of the quite complex kgdb8250 configuration does
the following:



 - ensures that static configurations according to SERIAL_PORT_DFNS are
   always loaded first
 - tries to pull more accurate configuration via serial8250_get_port_def
   if simple-config is used
 - detects empty/invalid simple-configs
 - enforces KGDB_PORT_NUM <= SERIAL_8250_NR_UARTS at kconfig level
 - removes kgdb8250_add_port and its hook in serial_core (calling
   serial8250_get_port_def in demand should provide us the same
   information)


   You left powerpc-lite.patch broken with this change as it has multiple 
calls to kgdb8250_add_port()...



Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>



Index: b/drivers/serial/serial_core.c
===
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c

[...]

@@ -2370,12 +2369,6 @@ int uart_add_one_port(struct uart_driver
 */
port->flags &= ~UPF_DEAD;
 
-#if defined(CONFIG_KGDB_8250)

-   /* Add any 8250-like ports we find later. */
-   if (port->type <= PORT_MAX_8250)
-   kgdb8250_add_port(port->line, port);
-#endif
-


   I'm afraid this wasn't correct from the very start since this can add 
ports with .iotype that 8250_kgdb.c does not support. So, nothing to regret 
here...


WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] ide: remove write-only ->sata_misc[] from ide_hwif_t

[Sergei Shtylyov]

Hello.

Bartlomiej Zolnierkiewicz wrote:


* Remove write-only ->sata_misc[] from ide_hwif_t.



* Remove no longer used SATA_{MISC,PHY,IEN}_OFFSET defines.


Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ide-tape: dump gcw fields on error in idetape_identify_device()

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:


Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>


Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>


Index: b/drivers/ide/ide-tape.c
===
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -3852,16 +3852,17 @@ static int idetape_identify_device (ide_
 
 	/* Check that we can support this device */
 
-	if (gcw.protocol !=2 )

-   printk(KERN_ERR "ide-tape: Protocol is not ATAPI\n");
+   if (gcw.protocol != 2)
+   printk(KERN_ERR "ide-tape: Protocol (0x%02x) is not ATAPI\n",
+   gcw.protocol);
else if (gcw.device_type != 1)
-   printk(KERN_ERR "ide-tape: Device type is not set to tape\n");
+   printk(KERN_ERR "ide-tape: Device type (0x%02x) is not set "
+   "to tape\n", gcw.device_type);
else if (!gcw.removable)
printk(KERN_ERR "ide-tape: The removable flag is not set\n");
else if (gcw.packet_size != 0) {
-   printk(KERN_ERR "ide-tape: Packet size is not 12 bytes long\n");
-   if (gcw.packet_size == 1)
-   printk(KERN_ERR "ide-tape: Sorry, padding to 16 bytes is 
still not supported\n");
+   printk(KERN_ERR "ide-tape: Packet size (0x%02x) is not 12 "
+   "bytes long\n", gcw.packet_size);


   Shouldn't it be either "packet size is not 12 byted" or "packet is not 12 
bytes long"?


MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] ide: add ide_read_error() inline helper

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:


Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>


Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] ide: add ide_read_[alt]status() inline helpers

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:


Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>


Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'

[Sergei Shtylyov]

Hello.

Andrew Morton wrote:


This is from ppc32:



 CC  arch/powerpc/mm/mem.o
arch/powerpc/mm/mem.c: In function 'do_init_bootmem':
arch/powerpc/mm/mem.c:256: error: too few arguments to function 
'reserve_bootmem'
arch/powerpc/mm/mem.c:261: error: too few arguments to function 
'reserve_bootmem'



Leftover from introduce-flags-for-reserve_bootmem.patch?



Yes, I've had to fix that patch many times.



--- a/arch/powerpc/mm/mem.c~introduce-flags-for-reserve_bootmem-powerpc-fix
+++ a/arch/powerpc/mm/mem.c
@@ -253,12 +253,13 @@ void __init do_init_bootmem(void)
 lmb_size_bytes(&lmb.reserved, i) - 1;
if (addr < total_lowmem)
reserve_bootmem(lmb.reserved.region[i].base,
-   lmb_size_bytes(&lmb.reserved, i));
+   lmb_size_bytes(&lmb.reserved, i),
+   BOOTMEM_DEFAULT);
else if (lmb.reserved.region[i].base < total_lowmem) {
unsigned long adjusted_size = total_lowmem -
  lmb.reserved.region[i].base;
reserve_bootmem(lmb.reserved.region[i].base,
-   adjusted_size);
+   adjusted_size, BOOTMEM_DWEFAULT);


   BOOTMEM_DWEFAULT, are you sure? :-)

WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS

[Sergei Shtylyov]

Hello.

On 22-10-2012 16:12, Prabhakar Lad wrote:


From: Lad, Prabhakar 



This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.



Signed-off-by: Lad, Prabhakar 
Signed-off-by: Manjunath Hadli 
Cc: Sekhar Nori 
---
  Resending the patch since, it didn't reach the DLOS mailing list.



  This patch is based on the following patch series,
  ARM: davinci: dm365 EVM: add support for VPBE display
  (https://patchwork.kernel.org/patch/1295071/)



  arch/arm/mach-davinci/board-dm365-evm.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index 2924d61..771abb5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
.index  = 1,
.name   = "Component",
.type   = V4L2_OUTPUT_TYPE_ANALOG,
-   .capabilities   = V4L2_OUT_CAP_CUSTOM_TIMINGS,
+   .capabilities   =  V4L2_OUT_CAP_DV_TIMINGS,


   Why this extra space after '='?

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS

[Sergei Shtylyov]

On 24.10.2012 15:19, Sekhar Nori wrote:


This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.



Signed-off-by: Lad, Prabhakar 
Signed-off-by: Manjunath Hadli 
Cc: Sekhar Nori 
Cc: Sergei Shtylyov 



Patches for mach-davinci should have a 'davinci:' prefix after 'ARM:'.
Can you please resend with that fixed?


   Also, the patch is for DM365 EVM board, not DM365 SoC.


Thanks,
Sekhar


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ide: remove stale comment from ide-lib.c

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:


Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>


Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pci_get_device_reverse(), why does Calgary need this?

[Sergei Shtylyov]

From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: [PATCH] ide: mark "ide=reverse" option as obsolete



- it is valid only if "Probe IDE PCI devices in the PCI bus order
  (DEPRECATED)" config option is used



- Greg needs to remove pci_get_device_reverse() for PCI core changes



Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>


Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>

MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: gadget: ncm: correct endianess conversion

[Sergei Shtylyov]

Hello.

On 01-11-2012 19:16, Dmytro Milinevskyy wrote:


Convert USB descriptor's fields to CPU byte order before using locally in USB
NCM gadget driver.
Tested on MIPS32 big-endian device.



Signed-off-by: Dmytro Milinevskyy 
---
  drivers/usb/gadget/f_ncm.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)



diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index b651b52..a7cdd47 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c

[...]

@@ -869,15 +869,19 @@ static struct sk_buff *ncm_wrap_ntb(struct gether *port,
  struct sk_buff*skb2;
  intncb_len = 0;
  __le16*tmp;
-intdiv = ntb_parameters.wNdpInDivisor;
-intrem = ntb_parameters.wNdpInPayloadRemainder;
+intdiv;
+intrem;
  intpad;
-intndp_align = ntb_parameters.wNdpInAlignment;
+intndp_align;
  intndp_pad;
  unsignedmax_size = ncm->port.fixed_in_len;
  struct ndp_parser_opts *opts = ncm->parser_opts;
  unsignedcrc_len = ncm->is_crc ? sizeof(uint32_t) : 0;
  +div = le16_to_cpu(ntb_parameters.wNdpInDivisor);


Probably corrupt patch -- there shouldn't be spaces before '+'.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 6/7] scsi: sr: balance sr disk events block depth

[Sergei Shtylyov]

Hello.

On 26-07-2012 14:05, Aaron Lu wrote:


When the ODD is resumed, disk_unblock_events should be called when:
1 The ODD is runtime resumed;
2 System is resuming from S3 and the ODD is runtime suspended before S3;
But not when the system is resuming from S3 and the ODD is runtime
active before S3.



So seperate the resume calls, one for system resume and one for runtime
resume to do different things accordingly.



Signed-off-by: Aaron Lu 
---
  drivers/scsi/sr.c | 21 +
  1 file changed, 21 insertions(+)



diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index fd1c2f6..b8c2f9d 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c

[...]

@@ -211,6 +217,21 @@ static int sr_suspend(struct device *dev, pm_message_t msg)

  static int sr_resume(struct device *dev)
  {
+   struct scsi_cd *cd = dev_get_drvdata(dev);
+
+   /*
+* If ODD is runtime suspended before system pm, unblock disk
+* events now since on system resume, we will fully resume it


   Comma not needed.


+* and set its rumtime status to active.


   s/rumtime/runtime/. Nice typo. %-)

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]staging: usbip: Fix typos.

[Sergei Shtylyov]

Hello.

On 07/30/2012 06:23 PM, Justin P. Mattock wrote:

> From: "Justin P. Mattock" 

> Signed-off-by: Justin P. Mattock 

> ---

> The below patch fixes typos found while reading through staging: usbip

   Unfortunately, it introduces some new instead. :-)

> diff --git a/drivers/staging/usbip/vhci_hcd.c 
> b/drivers/staging/usbip/vhci_hcd.c
> index 12a9a5f..dd15dc0 100644
> --- a/drivers/staging/usbip/vhci_hcd.c
> +++ b/drivers/staging/usbip/vhci_hcd.c
> @@ -828,11 +828,11 @@ static void vhci_shutdown_connection(struct 
> usbip_device *ud)
>*  disable endpoints. pending urbs are unlinked(dequeued).
>*
>* NOTE: After calling rh_port_disconnect(), the USB device drivers of a
> -  * deteched device should release used urbs in a cleanup function(i.e.
> +  * detached device should release used urbs in a cleanup function(i.e.

   Space is needed before "(i.e.".

>* xxx_disconnect()). Therefore, vhci_hcd does not need to release
>* pushed urbs and their private data in this function.
>*
> -  * NOTE: vhci_dequeue() must be considered carefully. When shutdowning
> +  * NOTE: vhci_dequeue() must be considered carefully. When shuting down

   Shutting.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/6] ARM: ux500: Fix merge error, so such struct 'snd_soc_u8500'

[Sergei Shtylyov]

Hello.

On 07/31/2012 05:31 PM, Lee Jones wrote:

  Subject doesn't parse for me...

> The platform attempts to register platform device 'snd_soc_u8500'
> which doesn't actually exist. Here we change the reference to the
> correct one 'snd_soc_mop500'.

> Signed-off-by: Lee Jones 

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/16] treewide: Convert dev_printk(KERN_ to dev_(

[Sergei Shtylyov]

Hello.

On 28-10-2012 12:05, Joe Perches wrote:


dev_ create smaller objects than dev_printk(KERN_.
Convert non-debug calls to this form.



Joe Perches (16):
   tile: Convert dev_printk(KERN_ to dev_(

[...]

   tile: Convert dev_printk(KERN_ to dev_(

[...]

   tile: Convert dev_printk(KERN_ to dev_(


   Hm, somehow this patch is repeated thrice?

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xhci: fix null-pointer dereference when destroying half-built segment rings

[Sergei Shtylyov]

Hello.

On 10/29/2012 08:00 PM, Julius Werner wrote:

> xhci_alloc_segments_for_ring() builds a list of xhci_segments and links
> the tail to head at the end (forming a ring). When it bails out for OOM
> reasons half-way through, it tries to destroy its half-built list with
> xhci_free_segments_for_ring(), even though it is not a ring yet. This
> causes a null-pointer dereference upon hitting the last element.

> Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes
> the output parameters to be valid upon this kind of OOM failure, and
> calls xhci_ring_free() on them. Since the (incomplete) list/ring should
> already be destroyed in that case, this would lead to a use after free.

> This patch fixes those issues by having xhci_alloc_segments_for_ring()
> destroy its half-built, non-circular list manually and destroying the
> invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().

> Signed-off-by: Julius Werner 
> ---
>  drivers/usb/host/xhci-mem.c |8 ++--
>  1 files changed, 6 insertions(+), 2 deletions(-)

> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 487bc08..420ba37 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -205,7 +205,11 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd 
> *xhci,
>  
>   next = xhci_segment_alloc(xhci, cycle_state, flags);
>   if (!next) {
> - xhci_free_segments_for_ring(xhci, *first);
> + prev = *first;
> + do {
> + next = prev->next;
> + xhci_segment_free(xhci, prev);
> + } while ((prev = next));

   It's preferred that the assignments are done outside the *if* and *while*
statements. In fact, at least for the *if* statements scripts/checkpatch.pl
gives a warning (it was silent in this case).

>   return -ENOMEM;
>   }
>   xhci_link_segments(xhci, prev, next, type);
> @@ -258,7 +262,7 @@ static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd 
> *xhci,
>   return ring;
>  
>  fail:
> - xhci_ring_free(xhci, ring);
> + kfree(ring);
>   return NULL;
>  }

[headless@wasted linux]$ scripts/checkpatch.pl
patches/xhci-fix-null-pointer-dereference-when-destroying-half-built-segment-rings.patch

ERROR: DOS line endings
#30: FILE: drivers/usb/host/xhci-mem.c:208:
+^I^I^Iprev = *first;^M$

ERROR: DOS line endings
#31: FILE: drivers/usb/host/xhci-mem.c:209:
+^I^I^Ido {^M$

ERROR: DOS line endings
#32: FILE: drivers/usb/host/xhci-mem.c:210:
+^I^I^I^Inext = prev->next;^M$

ERROR: DOS line endings
#33: FILE: drivers/usb/host/xhci-mem.c:211:
+^I^I^I^Ixhci_segment_free(xhci, prev);^M$

ERROR: DOS line endings
#34: FILE: drivers/usb/host/xhci-mem.c:212:
+^I^I^I} while ((prev = next));^M$

ERROR: DOS line endings
#43: FILE: drivers/usb/host/xhci-mem.c:265:
+^Ikfree(ring);^M$

total: 6 errors, 0 warnings, 20 lines checked

patches/xhci-fix-null-pointer-dereference-when-destroying-half-built-segment-rings.patch
has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.

   I have noticed that the patch description has DOS line endings as well.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] ARM: at91/dt: define phy available on sama5d3 mother board

[Sergei Shtylyov]

Hello.

On 26-08-2013 16:35, Boris BREZILLON wrote:


This patch describe the phy used on atmel sama5d3 mother board:
  - phy address
  - phy interrupt pin



Signed-off-by: Boris BREZILLON 
---
  arch/arm/boot/dts/sama5d3xmb.dtsi |8 
  1 file changed, 8 insertions(+)



diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi 
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 8a9e05d..e9521d5 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -81,6 +81,14 @@

macb1: ethernet@f802c000 {
phy-mode = "rmii";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   phy0: ethernet-phy@0 {


   Address part of the node name doesn't match the "reg" property.


+   interrupt-parent = <&pioE>;
+   interrupts = <30 IRQ_TYPE_EDGE_FALLING>;
+   reg = <1>;
+   };


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: pinctrl-single: Convert to devm_ioremap_resource()

[Sergei Shtylyov]

Hello.

On 27-08-2013 11:05, Vishwanathrao Badarkhe, Manish wrote:


From: "Vishwanathrao Badarkhe, Manish" 



Convert devm_request_mem_region() and devm_ioremap() to
devm_ioremap_resource() which provides more consistent
error handling to manage resource.



Signed-off-by: Vishwanathrao Badarkhe, Manish 
---
:100644 100644 7323cca... b0fef18... M  drivers/pinctrl/pinctrl-single.c
  drivers/pinctrl/pinctrl-single.c |   21 +++--
  1 file changed, 3 insertions(+), 18 deletions(-)



diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 7323cca..b0fef18 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1556,24 +1556,9 @@ static int pcs_probe(struct platform_device *pdev)
  "pinctrl-single,bit-per-mux");

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(pcs->dev, "could not get resource\n");
-   return -ENODEV;
-   }
-
-   pcs->res = devm_request_mem_region(pcs->dev, res->start,
-   resource_size(res), DRIVER_NAME);
-   if (!pcs->res) {


   Is pcs->res used anywhere else?


-   dev_err(pcs->dev, "could not get mem_region\n");
-   return -EBUSY;
-   }
-
-   pcs->size = resource_size(pcs->res);


   Is pcs->size used anywhere else?


-   pcs->base = devm_ioremap(pcs->dev, pcs->res->start, pcs->size);
-   if (!pcs->base) {
-   dev_err(pcs->dev, "could not ioremap\n");
-   return -ENODEV;
-   }
+   pcs->base = devm_ioremap_resource(pcs->dev, res);
+   if (IS_ERR(pcs->base))
+   return PTR_ERR(pcs->base);


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] staging: ozwpan: Return error, if PD is not connected.

[Sergei Shtylyov]

Hello.

On 08/27/2013 07:53 PM, Rupesh Gujare wrote:


Return error if we receive write(), while PD is not connected.



Signed-off-by: Rupesh Gujare 
---
  drivers/staging/ozwpan/ozcdev.c |2 ++
  1 file changed, 2 insertions(+)



diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 03b41ee..22cb2ae 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -162,6 +162,8 @@ static ssize_t oz_cdev_write(struct file *filp, const char 
__user *buf,
spin_unlock_bh(&g_cdev.lock);
if (pd == NULL)
return -1;


   Note that returning -EPERM here is hardly correct.


+   if (!(pd->state & OZ_PD_S_CONNECTED))
+   return -ENXIO;


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[Sergei Shtylyov]

Hello.

On 08/28/2013 05:59 PM, George Cherian wrote:


Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.



Signed-off-by: George Cherian 
---
  arch/arm/boot/dts/dra7-evm.dts | 52 +-
  1 file changed, 51 insertions(+), 1 deletion(-)



diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..9ee97c0 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,6 +17,17 @@
device_type = "memory";
reg = <0x8000 0x6000>; /* 1536 MB */
};
+
+   extcon1: gpio_usbvid_extcon1 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&pcf_21 1 0>;
+   };
+
+   extcon2: gpio_usbvid_extcon2 {
+   compatible = "ti,gpio-usb-id";
+   gpios = <&pcf_21 2 0>;
+   };
+
  };

  &dra7_pmx_core {
@@ -33,10 +44,49 @@
  };
  };

+&i2c1 {
+   clock-frequency = <40>;
+
+   pcf_20: pcf8575@20 {


   Acorrding to the ePAPR spec [1], "the name of a node should be somewhat 
generic, reflecting the function of the device and not its precise 
programming model. If appropriate, the name should be one of the following 
choices:


[...]
- gpio
[...]"


+   compatible = "ti,pcf8575";
+   reg = <0x20>;
+   n_latch = <0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   pcf_21: pcf8575@21 {


   Same comment here.


+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   n_latch = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&pcf_20>;
+   interrupts = <14 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+};
+


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/3] ARM: dts: dra7-evm: Add extcon nodes for USB ID pin detection

[Sergei Shtylyov]

On 08/28/2013 09:33 PM, George Cherian wrote:


Add
-extcon nodes for USB ID pin detection.
-i2c nodes.
-pcf nodes to which USB ID pin is connected.



Signed-off-by: George Cherian 
---
  arch/arm/boot/dts/dra7-evm.dts | 50 +-
  1 file changed, 49 insertions(+), 1 deletion(-)



diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index acd3c09..8b0738a 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts

[...]

@@ -33,10 +44,47 @@
  };
  };

+&i2c1 {
+   clock-frequency = <40>;
+
+   gpio20: pcf8575@20 {


ePAPR was talking about the node naming, not about labelling. Back to the 
drawing board. ;-)



+   compatible = "ti,pcf8575";
+   reg = <0x20>;
+   n_latch = <0x4000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <11 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpio21: pcf8575@21 {
+   compatible = "ti,pcf8575";
+   reg = <0x21>;
+   n_latch = <0x1408>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-parent = <&pcf_20>;
+   interrupts = <14 2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+};
+


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ARM: Dove: Add the audio devices in DT

[Sergei Shtylyov]

Hello.

On 08/28/2013 01:34 PM, Jean-Francois Moine wrote:


This patch adds the nodes to instantiate the audio devices of the Dove
boards.



Signed-off-by: Jean-Francois Moine 
---
  arch/arm/boot/dts/dove.dtsi  | 18 ++
  1 file changed, 18 insertions(+)



diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 499abad..78227e2 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -573,6 +573,24 @@
phy-handle = <ðphy>;
};
};
+
+   i2s0: audio-controller@b {


According to ePAPR [1] the node should be called "sound", not 
"audio-controller".



+   compatible = "marvell,mvebu-audio";
+   reg = <0xb 0x2210>;
+   interrupts = <19>, <20>;
+   clocks = <&gate_clk 12>;
+   clock-names = "internal";
+   status = "disabled";
+   };
+
+   i2s1: audio-controller@b4000 {


   Same comment.


+   compatible = "marvell,mvebu-audio";
+   reg = <0xb4000 0x2210>;
+   interrupts = <21>, <22>;
+   clocks = <&gate_clk 13>;
+   clock-names = "internal";
+   status = "disabled";
+   };


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ARM: Dove: Add the audio devices in DT

[Sergei Shtylyov]

Hello.

On 29-08-2013 13:38, Jean-Francois Moine wrote:


diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 499abad..78227e2 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -573,6 +573,24 @@
phy-handle = <ðphy>;
};
};
+
+   i2s0: audio-controller@b {



  According to ePAPR [1] the node should be called "sound", not
"audio-controller".



+   compatible = "marvell,mvebu-audio";
+   reg = <0xb 0x2210>;
+   interrupts = <19>, <20>;
+   clocks = <&gate_clk 12>;
+   clock-names = "internal";
+   status = "disabled";
+   };



AFAIK, "sound" describes the global audio subsystem. For the Cubox,
this will be done by something like:



sound {
compatible = "simple-audio";
audio-controller = <&i2s1>;
audio-codec = <&spdif>;
codec-dai-name = "dit-hifi";
};


   Well, then "sound-controller" sounds somewhat more appropriate.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] drivers: usb: core: hcd: moved asterix to variable

[Sergei Shtylyov]

Hello.

On 05-10-2013 18:02, Matthias Beyer wrote:

   s/asterix/asterisk/. Asterix is a hero of the infamous French movies, 
asterisk is *.



instead of type


   Don't continue the subject this way in he changelog.


Signed-off-by: Matthias Beyer 


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] usb: g_ffs: fix compilation warning

[Sergei Shtylyov]

Hello.

On 05-10-2013 0:30, David Cohen wrote:


If USB_FUNCTIONFS is selected without USB_FUNCTIONFS_ETH and
USB_FUNCTIONFS_RNIS, u_ether.h won't be included and then
USB_ETHERNET_MODULE_PARAMAETERS macro won't be available causing the
following warning compilation:



drivers/usb/gadget/g_ffs.c:81:1: warning: data definition has no type or
storage class [enabled by default]
drivers/usb/gadget/g_ffs.c:81:1: warning: type defaults to ‘int’ in
declaration of ‘USB_ETHERNET_MODULE_PARAMETERS’ [-Wimplicit-int]
drivers/usb/gadget/g_ffs.c:81:1: warning: function declaration isn’t a
prototype [-Wstrict-prototypes]



This patch fixes the warning by making USB_ETHERNET_MODULE_PARAMETERS to
be used iff u_ether.h is included, otherwise it is not needed.



Signed-off-by: David Cohen 
---
  drivers/usb/gadget/g_ffs.c | 2 ++
  1 file changed, 2 insertions(+)



diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c
index 5327c82..2344efe 100644
--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -76,7 +76,9 @@ struct gfs_ffs_obj {

  USB_GADGET_COMPOSITE_OPTIONS();

+#if defined CONFIG_USB_FUNCTIONFS_ETH || defined CONFIG_USB_FUNCTIONFS_RNDIS


   I thought the 'defined' operator requires ()?

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/2] usb/musb dma: add cppi41 dma driver

[Sergei Shtylyov]

On 08.07.2013 12:52, Sebastian Andrzej Siewior wrote:

On 07/07/2013 04:55 PM, Sergei Shtylyov wrote:

Hello.


Hello Sergei,


On 05-07-2013 20:12, Sebastian Andrzej Siewior wrote:


This is a first shot of the cppi41 DMA driver.


Where have you been when I submitted my drivers back in 2009? :-)


Not here it seems :) There is a driver I got which seem to work but it
is not using the dma engine and is not really in shape so I'm doing
this.



And the current musb's cppi dma engine (3.1, different logic etc.) is


   3.0 I think.


not using dmaengine and the network driver (cpsw) which is also using
cppi 3.1 is having its own implementation of the cppi-dma part. So I
think dma enggine implementation is a must here.


   Not at all. I'm not familiar with CPSW but DaVinci EMAC uses CPPI 
3.0 too but it's completely regisyter incompatible with USB. CPPI 3.0 
doesn't seem to be universal DMA engine, hence drivers/dma/ driver 
doesn't seem feasible.



diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
index bb2298c..fc29b54 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -349,6 +349,18 @@

[...]


+compatible = "ti,am3359-cppi41";
+reg =  <0x4740 0x1000/* usbss */



USB register are not a part of CPPI 4.1 DMA. They are not generic and
are different on e.g. DA8xx/OMAP-L1x. Besides this range is conflicting
with the next node.



I will shorten them for the range conflict. usbss is only used for
interrupt mask on/off. If there are different, a different compatible
string will carry the difference.


   You don't quite understand. CPPI 4.1 specification as such (which I 
guess you haven't seen) doesn't include any interrupt registers.



I think I will also add the usb
string to it since a possible network engine will look different in
terms of the queue used (which I plan to move away from DT).


   There are out of tree platform which uses CPPI 4.1 not only for USB 
but e.g. for Ethernet.



diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c

new file mode 100644
index 000..80dcb56
--- /dev/null
+++ b/drivers/dma/cppi41.c
@@ -0,0 +1,777 @@

[...]


+struct cppi41_dd {
+struct dma_device ddev;
+
+void *qmgr_scratch;
+dma_addr_t scratch_phys;
+
+struct cppi41_desc *cd;
+dma_addr_t descs_phys;
+struct cppi41_channel *chan_busy[ALLOC_DECS_NUM];
+
+void __iomem *usbss_mem;



Shouldn't be here.



+void __iomem *ctrl_mem;
+void __iomem *sched_mem;
+void __iomem *qmgr_mem;
+unsigned int irq;



Shouldn't be here either.



What is wrong with the four mem pointer here?


   I meant only IRQ (interrupt registers are not part of CPPI 4.1 spec).


+static void cppi_writel(u32 val, void *__iomem *mem)
+{
+writel(val, mem);
+}
+
+static u32 cppi_readl(void *__iomem *mem)
+{
+u32 val;
+val = readl(mem);
+return val;
+}



I don't see much sense in these functions. Besides, they should
probably be using __raw_{read|write}().



I had printk() before posting for debugging. Using raw would require an
explicit cache flush before triggering the engine, right?


   Don't think so -- I wasn't using it.


+static irqreturn_t cppi41_irq(int irq, void *data)
+{
+struct cppi41_dd *cdd = data;
+struct cppi41_channel *c;
+u32 status;
+int i;
+
+status = cppi_readl(cdd->usbss_mem + USBSS_IRQ_STATUS);
+if (!(status & USBSS_IRQ_PD_COMP))
+return IRQ_NONE;



No, this can't be here.



again. Why not?


   This register is not part of CPPI 4.1 spec.


+static u32 get_host_pd0(u32 length)
+{
+u32 reg;
+
+reg = DESC_TYPE_HOST << DESC_TYPE;
+reg |= length;
+
+return reg;
+}
+
+static u32 get_host_pd1(struct cppi41_channel *c)
+{
+u32 reg;
+
+reg = 0;
+
+return reg;
+}
+
+static u32 get_host_pd2(struct cppi41_channel *c)
+{
+u32 reg;
+
+reg = 5 << 26; /* USB TYPE */



The driver shouldn't be tied to USB at all.



For now it is USB only. Once we git different types we will have
different compatible strings for that. But that shift could by hidden
behind a define so to comment could vanish as well.


   I repeat: CPPI 4.1 is universal DMA engine. It's a pity that it's 
implemented as a part of USB peripheral on all in-tree platforms but 
it's implemented as an autonomous module on out-of-tree platforms.



+static int cppi41_dma_probe(struct platform_device *pdev)
+{

[...]

+irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+if (!irq)
+goto err_irq;
+
+cppi_writel(USBSS_IRQ_PD_COMP, cdd->usbss_mem + USBSS_IRQ_ENABLER);



 Shouldn't be here.



[...]

+static const struct of_device_id cppi41_dma_ids[] = {
+{ .compatible = "ti,am3359-cppi41", },



 CPPI 4.1 driver should be generic, not SoC specific.



So

Re: [PATCH] musb: omap: Fix: pass all the resources to musb core

[Sergei Shtylyov]

Hello.

On 08-07-2013 14:55, Kishon Vijay Abraham I wrote:


commit 09fc7d (usb: musb: fix incorrect usage of resource pointer)
assumes musb core will always have only 2 resources. But for OMAP
platforms there can be 3 resources (2 irq resource and 1 iomem
resource). Fixed it here.



Signed-off-by: Kishon Vijay Abraham I 
---
  drivers/usb/musb/omap2430.c |   18 --
  1 file changed, 8 insertions(+), 10 deletions(-)



diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5b6113a..5bbef78 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c

[...]

@@ -489,6 +489,7 @@ static int omap2430_probe(struct platform_device *pdev)
struct device_node  *np = pdev->dev.of_node;
struct musb_hdrc_config *config;
int ret = -ENOMEM;
+   int i = 0;


   Redundant initialization.


glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -571,15 +572,12 @@ static int omap2430_probe(struct platform_device *pdev)
memset(musb_resources, 0x00, sizeof(*musb_resources) *
ARRAY_SIZE(musb_resources));

-   musb_resources[0].name = pdev->resource[0].name;
-   musb_resources[0].start = pdev->resource[0].start;
-   musb_resources[0].end = pdev->resource[0].end;
-   musb_resources[0].flags = pdev->resource[0].flags;
-
-   musb_resources[1].name = pdev->resource[1].name;
-   musb_resources[1].start = pdev->resource[1].start;
-   musb_resources[1].end = pdev->resource[1].end;
-   musb_resources[1].flags = pdev->resource[1].flags;
+   for (i = 0; i < ARRAY_SIZE(musb_resources); i++) {
+   musb_resources[i].name = pdev->resource[i].name;
+   musb_resources[i].start = pdev->resource[i].start;
+   musb_resources[i].end = pdev->resource[i].end;
+   musb_resources[i].flags = pdev->resource[i].flags;
+   }


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] virtio_net: fix race in RX VQ processing

[Sergei Shtylyov]

Hello.

On 08-07-2013 13:04, Michael S. Tsirkin wrote:


virtio net called virtqueue_enable_cq on RX path after napi_complete, so
with NAPI_STATE_SCHED clear - outside the implicit napi lock.
This violates the requirement to synchronize virtqueue_enable_cq wrt
virtqueue_add_buf.  In particular, used event can move backwards,
causing us to lose interrupts.
In a debug build, this can trigger panic within START_USE.



Jason Wang reports that he can trigger the races artificially,
by adding udelay() in virtqueue_enable_cb() after virtio_mb().



However, we must call napi_complete to clear NAPI_STATE_SCHED before
polling the virtqueue for used buffers, otherwise napi_schedule_prep in
a callback will fail, causing us to lose RX events.



To fix, call virtqueue_enable_cb_prepare with NAPI_STATE_SCHED
set (under napi lock), later call virtqueue_poll with
NAPI_STATE_SCHED clear (outside the lock).



Reported-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
---
  drivers/net/virtio_net.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)



diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5305bd1..fbdd79a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -622,8 +622,9 @@ again:

/* Out of packets? */
if (received < budget) {
+   unsigned r = virtqueue_enable_cb_prepare(rq->vq);


   Empty line wouldn't hurt here, after declaration.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/2] usb/musb dma: add cppi41 dma driver

[Sergei Shtylyov]

Hello.

On 08-07-2013 16:38, Sebastian Andrzej Siewior wrote:


not using dmaengine and the network driver (cpsw) which is also using
cppi 3.1 is having its own implementation of the cppi-dma part. So I
think dma enggine implementation is a must here.



Not at all. I'm not familiar with CPSW but DaVinci EMAC uses CPPI 3.0
too but it's completely regisyter incompatible with USB. CPPI 3.0
doesn't seem to be universal DMA engine, hence drivers/dma/ driver
doesn't seem feasible.



So you suggest to avoid drivers/dma and create drivers/usb
/musb/cpp41-dma.c instead?


   Where I was suggesting that? I was replying about CPPI 3.0 only.


cpsw is using davinci_cpdma.c and you say it is completely different
from what musb is using? I just browsed over the spec it looked very
familiar.


   Yes, the register interface is incompatible -- I too compared it 
some time ago. The only things compatible are the DMA descriptors.



I will shorten them for the range conflict. usbss is only used for
interrupt mask on/off. If there are different, a different compatible
string will carry the difference.



You don't quite understand. CPPI 4.1 specification as such (which I
guess you haven't seen) doesn't include any interrupt registers.



Yes but you do have them somewhere. So all its needs is just the SoC
type which brings the register specification.


   Well, it can be viewed this way...


I think I will also add the usb
string to it since a possible network engine will look different in
terms of the queue used (which I plan to move away from DT).



There are out of tree platform which uses CPPI 4.1 not only for USB
but e.g. for Ethernet.



So what? The binding will be different, you get a different register
for interrupt. I'm still not buying that part where you want skip the
dmaengine framework and introduce custom callbacks for this kind of
things.


   I'm just not sure drivers/dma/ needs IRQs. To be honest, I'm not 
very familiar with its APIs.



diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c

new file mode 100644
index 000..80dcb56
--- /dev/null
+++ b/drivers/dma/cppi41.c
@@ -0,0 +1,777 @@

[...]



+static u32 get_host_pd2(struct cppi41_channel *c)
+{
+u32 reg;
+
+reg = 5 << 26; /* USB TYPE */



 The driver shouldn't be tied to USB at all.



For now it is USB only. Once we git different types we will have
different compatible strings for that. But that shift could by hidden
behind a define so to comment could vanish as well.



I repeat: CPPI 4.1 is universal DMA engine. It's a pity that it's
implemented as a part of USB peripheral on all in-tree platforms but
it's implemented as an autonomous module on out-of-tree platforms.



It can be still extended to use normal/generic memcpy() operation if
this is supported somewhere.


No, it can't. CPPI 4.1 spec simply has no support for such thing.
It can't be implemented "somewhare" because then that hardware stops to 
be CPPI 4.1 compatible.



That one here tight to USB and can't do
anything else. I do not start to include a bunch of function pointer if
there is no need it for it. I didn't do anything that it made
impossible to do so, right?


   I'd like to see universal driver in the end, not tied to USB in any 
way.



[...]

+static const struct of_device_id cppi41_dma_ids[] = {
+{ .compatible = "ti,am3359-cppi41", },



  CPPI 4.1 driver should be generic, not SoC specific.



So you want another driver around it to handle the SoC specific stuff?



This can be handled as part of MUSB DMA driver in our case.



The glue layer you say. Okay. This does not look that bad. I will
try to push it there. But then I need to pass pointers somehow between
cppi41 which is behind dma-engine and this glue layer.


   I think that's enough to export a output queue polling function from 
the DMA engine.



Sebastian



PS: Are you aware that TI has written CPPI 4.2 DMA engine driver in
their Arago project?


   They actually had plans to write CPPI 4.1 DMA engine support too but 
that seems to have lead nowhere so far. They seem still content with 
what I wrote based on their CPPI 4.1 code back in 2008 (only moved it 
into drivers/usb/musb/).



http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2013-February/026345.html



No I wasn't. They could bring their code upstream…


   Oh, they are usually in no hurry to do so. BTW, if you read the 
mail, they weren't quite content with the DMA engine framework, and 
developed 2 alternate solutions as far as I could understand.



Sebastian


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node

[Sergei Shtylyov]

Hello.

On 09-07-2013 13:17, George Cherian wrote:


Adds device node for HS USB Host module for AM437x



changes from v1



renamed synopsis to snps
removed flag tx-fifo-resize



Signed-off-by: George Cherian 
---
  arch/arm/boot/dts/am4372.dtsi | 18 ++
  1 file changed, 18 insertions(+)



diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
compatible = 
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
};
+
+   usb_otg_hs1: am4372_dwc3@4838 {


   See http://www.devicetree.org/Device_Tree_Usage, "Node Names" section.


+   compatible = "ti,am437x-dwc3";
+   reg = <0x4838 0x1ff>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   utmi-mode = <1>;
+   ranges;
+
+   dwc3@4839 {


   The same comment.


+   compatible = "snps,dwc3";
+   reg = <0x4839 0xcfff>;
+   interrupts = ;
+   };
+
+   };
+   


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] arm: dts: AM43x: Add usb_otg_hs node

[Sergei Shtylyov]

Hello.

On 07/09/2013 06:07 PM, Sergei Shtylyov wrote:


Adds device node for HS USB Host module for AM437x



changes from v1



renamed synopsis to snps
removed flag tx-fifo-resize



Signed-off-by: George Cherian 
---
  arch/arm/boot/dts/am4372.dtsi | 18 ++
  1 file changed, 18 insertions(+)



diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index ddc1df7..c9e0da8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -64,5 +64,23 @@
  compatible = "ti,am4372-counter32k","ti,omap-counter32k";
  reg = <0x44e86000 0x40>;
  };
+
+usb_otg_hs1: am4372_dwc3@4838 {


See http://www.devicetree.org/Device_Tree_Usage, "Node Names" section.


+compatible = "ti,am437x-dwc3";
+reg = <0x4838 0x1ff>;


   And I bet this should be 0x200, not 0x1ff. This is length, not upper 
limit.



+interrupts = ;
+#address-cells = <1>;
+#size-cells = <1>;
+utmi-mode = <1>;
+ranges;
+
+dwc3@4839 {



The same comment.



+compatible = "snps,dwc3";
+reg = <0x4839 0xcfff>;


   The same, this should be 0xd000, not 0xcfff.


+interrupts = ;
+};
+
+};
+


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: gadget: fotg210-udc: Remove bogus __init/__exit annotations

[Sergei Shtylyov]

On 07/11/2013 01:45 AM, Geert Uytterhoeven wrote:


When builtin (CONFIG_USB_FOTG210_UDC=y):



   LD  drivers/usb/gadget/built-in.o
WARNING: drivers/usb/gadget/built-in.o(.data+0xbf8): Section mismatch in 
reference from the variable fotg210_driver to the function 
.init.text:fotg210_udc_probe()
The variable fotg210_driver references
the function __init fotg210_udc_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console



   LD  drivers/usb/built-in.o
WARNING: drivers/usb/built-in.o(.data+0x14684): Section mismatch in reference 
from the variable fotg210_driver to the function .init.text:fotg210_udc_probe()
The variable fotg210_driver references
the function __init fotg210_udc_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console



   LD  drivers/built-in.o
WARNING: drivers/built-in.o(.data+0x8b0c8): Section mismatch in reference from 
the variable fotg210_driver to the function .init.text:fotg210_udc_probe()
The variable fotg210_driver references
the function __init fotg210_udc_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console



   CHK include/generated/uapi/linux/version.h
   LINKvmlinux
   LD  vmlinux.o
   MODPOST vmlinux.o
WARNING: vmlinux.o(.data+0xc6730): Section mismatch in reference from the 
variable fotg210_driver to the function .init.text:fotg210_udc_probe()
The variable fotg210_driver references
the function __init fotg210_udc_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console



   GEN .version
   CHK include/generated/compile.h
   UPD include/generated/compile.h
   CC  init/version.o
   LD  init/built-in.o
`.exit.text' referenced in section `.data' of drivers/built-in.o: defined in 
discarded section `.exit.text' of drivers/built-in.o
make[3]: *** [vmlinux] Error 1



Signed-off-by: Geert Uytterhoeven 
---
  drivers/usb/gadget/fotg210-udc.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/drivers/usb/gadget/fotg210-udc.c b/drivers/usb/gadget/fotg210-udc.c
index cce5535..10cd18d 100644
--- a/drivers/usb/gadget/fotg210-udc.c
+++ b/drivers/usb/gadget/fotg210-udc.c
@@ -1074,7 +1074,7 @@ static struct usb_gadget_ops fotg210_gadget_ops = {
.udc_stop   = fotg210_udc_stop,
  };

-static int __exit fotg210_udc_remove(struct platform_device *pdev)
+static int fotg210_udc_remove(struct platform_device *pdev)


   I think you can leave __exit annotation here, if you enclose the 
reference in the driver structure in __exit_p()...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] strict_strtoul in (obsolete) changed to kstrtoul

[Sergei Shtylyov]

Hello.

On 11-07-2013 10:52, “Cosmin wrote:


Signed-off-by: “Cosmin <“cosmin90stane...@gmail.com”>


   Real name is required in signoff. Quotes are not necessary.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/8] ARM: shmobile: r8a7740: add DT nodes and clock aliases for three DMAC instances

[Sergei Shtylyov]

Hello.

On 07/12/2013 05:43 PM, Guennadi Liakhovetski wrote:


This patch adds Device Tree support for the three generic DMA controller
instances on r8a7740 in a DMA multiplexer node.



Signed-off-by: Guennadi Liakhovetski 
---
  arch/arm/boot/dts/r8a7740.dtsi |   61 
  arch/arm/mach-shmobile/clock-r8a7740.c |3 ++
  2 files changed, 64 insertions(+), 0 deletions(-)



diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 25dc930..39b596f 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -112,6 +112,67 @@
  0 149 0x4>;
};

+   dmac: dma-mux0 {
+   compatible = "renesas,shdma-mux";
+   #dma-cells = <1>;
+   dma-channels = <6>;
+   dma-requests = <256>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   dma0: shdma@fe008020 {
+   compatible = "renesas,shdma-r8a7740";
+   reg = <0xfe008020 0x270>,
+   <0xfe009000 0xc>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 34 4
+   0 28 4
+   0 29 4
+   0 30 4
+   0 31 4
+   0 32 4
+   0 33 4>;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5";
+   };
+
+   dma1: shdma@fe018020 {
+   compatible = "renesas,shdma-r8a7740";
+   reg = <0xfe018020 0x270>,
+   <0xfe019000 0xc>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 41 4
+   0 35 4
+   0 36 4
+   0 37 4
+   0 38 4
+   0 39 4
+   0 40 4>;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5";
+   };
+
+   dma2: shdma@fe028020 {
+   compatible = "renesas,shdma-r8a7740";
+   reg = <0xfe028020 0x270>,
+   <0xfe029000 0xc>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 48 4
+   0 42 4
+   0 43 4
+   0 44 4
+   0 45 4
+   0 46 4
+   0 47 4>;
+   interrupt-names = "error",
+   "ch0", "ch1", "ch2", "ch3",
+   "ch4", "ch5";
+   };
+   };
+


   According to ePAPR [1] section 2.2.2, "the name of the node should 
be somewhat generic, reflecting the function of the device and not its
precise programming model. If appropriate, the name should be one of the 
following choices:

[...]
- dma-controller;
[...]"

[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/8] DMA: shdma: pass SoC-specific configuration to the driver via OF matching

[Sergei Shtylyov]

Hello.

On 07/12/2013 05:43 PM, Guennadi Liakhovetski wrote:


Similar to the non-DT case, this patch passes SoC-specific configuration
to the driver via device ID matching, instead of platform data.



Signed-off-by: Guennadi Liakhovetski 

[...]


diff --git a/drivers/dma/sh/shdmac.c b/drivers/dma/sh/shdmac.c
index a6d53fa..b095d74 100644
--- a/drivers/dma/sh/shdmac.c
+++ b/drivers/dma/sh/shdmac.c

[...]

@@ -665,6 +666,14 @@ static const struct shdma_ops sh_dmae_shdma_ops = {
.get_partial = sh_dmae_get_partial,
  };

+static const struct of_device_id sh_dmae_of_match[] = {
+   {.compatible = "renesas,shdma",},
+   {.compatible = "renesas,shdma-r8a73a4", .data = r8a73a4_shdma_devid,},
+   {.compatible = "renesas,shdma-r8a7740", .data = r8a7740_shdma_devid,},


   Previously used style assumed spaced after { and before }. Indeed, 
that would be more consistent with the following line.



+   { }
+};
+MODULE_DEVICE_TABLE(of, sh_dmae_of_match);
+
  static int sh_dmae_probe(struct platform_device *pdev)
  {
struct sh_dmae_pdata *pdata;

[...]

@@ -915,12 +928,6 @@ static int sh_dmae_remove(struct platform_device *pdev)
return 0;
  }

-static const struct of_device_id sh_dmae_of_match[] = {
-   { .compatible = "renesas,shdma", },
-   { }
-};
-MODULE_DEVICE_TABLE(of, sh_dmae_of_match);
-


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: gadget: fotg210-udc: Remove bogus __init/__exit annotations

[Sergei Shtylyov]

Hello.

On 07/11/2013 11:25 AM, Geert Uytterhoeven wrote:


When builtin (CONFIG_USB_FOTG210_UDC=y):



LD  drivers/usb/gadget/built-in.o
WARNING: drivers/usb/gadget/built-in.o(.data+0xbf8): Section mismatch in
reference from the variable fotg210_driver to the function
.init.text:fotg210_udc_probe()
The variable fotg210_driver references
the function __init fotg210_udc_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console



diff --git a/drivers/usb/gadget/fotg210-udc.c
b/drivers/usb/gadget/fotg210-udc.c
index cce5535..10cd18d 100644
--- a/drivers/usb/gadget/fotg210-udc.c
+++ b/drivers/usb/gadget/fotg210-udc.c
@@ -1074,7 +1074,7 @@ static struct usb_gadget_ops fotg210_gadget_ops = {
 .udc_stop   = fotg210_udc_stop,
   };

-static int __exit fotg210_udc_remove(struct platform_device *pdev)
+static int fotg210_udc_remove(struct platform_device *pdev)



I think you can leave __exit annotation here, if you enclose the
reference in the driver structure in __exit_p()...



The driver is using module_platform_driver(), not
module_platform_driver_probe(),
so it expects the platform device to show up or disappear anytime.


   Well, I don't think it actually does. Perhaps the reason was that 
the latter function wasn't available yet at the time of conversion to 
the former (IIRC it appeared later).


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

Hello.

On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:


DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.



Cc: Russell King 
Cc: linux-s...@vger.kernel.org



Signed-off-by: Santosh Shilimkar 
---
  drivers/scsi/scsi_lib.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 86d5220..e8275fa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)

host_dev = scsi_get_device(shost);
if (host_dev && host_dev->dma_mask)
-   bounce_limit = *host_dev->dma_mask;
+   bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;


   You definitely forgot -1 here.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

Hello.

On 07/13/2013 02:25 AM, Russell King - ARM Linux wrote:


DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.



Cc: Russell King 
Cc: linux-s...@vger.kernel.org



Signed-off-by: Santosh Shilimkar 
---
   drivers/scsi/scsi_lib.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 86d5220..e8275fa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost)

host_dev = scsi_get_device(shost);
if (host_dev && host_dev->dma_mask)
-   bounce_limit = *host_dev->dma_mask;
+   bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;



You definitely forgot -1 here.



Please explain your point.


   Previously, 'bounce_limit' would look like 0x (unless I'm 
mistaken), now it would look like 0xf000 which is hardly what we're 
looking for, no?


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

[Sergei Shtylyov]

On 07/13/2013 03:08 AM, Sergei Shtylyov wrote:


DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected to return the DMAable maximum pfn
value across architectures.



Cc: Russell King 
Cc: linux-s...@vger.kernel.org



Signed-off-by: Santosh Shilimkar 
---
   drivers/scsi/scsi_lib.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)



diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 86d5220..e8275fa 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct
Scsi_Host *shost)

   host_dev = scsi_get_device(shost);
   if (host_dev && host_dev->dma_mask)
-bounce_limit = *host_dev->dma_mask;
+bounce_limit = dma_max_pfn(host_dev) << PAGE_SHIFT;



You definitely forgot -1 here.



Please explain your point.



Previously, 'bounce_limit' would look like 0x (unless I'm
mistaken), now it would look like 0xf000 which is hardly what we're
looking for, no?


   Although, -1 won't give us the correct result in this case, it's 
more like + PAGE_SIZE - 1.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] misc: add driver for Renesas R-Car Gyro-ADC/speed-pulse interfaces

[Sergei Shtylyov]

Add the driver for Gyro-ADC/speed-pulse interfaces found in Renesas R-Car SoCs.
Though  being two separate devices, they have to be driven together because of
the shared start/stop register (located in Gyro-ADC still). At this time, only
speed-pulse interface is fully supported, the Gyro-ADC is just initialized and
started/stopped synchronously with the speed-pulse interface.  A user interface
is implemented via several sysfs files which allow to read and reset the speed-
pulse interface's registers.

Signed-off-by: Sergei Shtylyov 

---
This patch is againt the 'char-misc-next' barnch of Greg KH's 'char-misc.git'.

 drivers/misc/Kconfig |   10 +
 drivers/misc/Makefile|1 
 drivers/misc/rcar-gyro-adc-speed-pulse.c |  231 +++
 3 files changed, 242 insertions(+)

Index: char-misc/drivers/misc/Kconfig
===
--- char-misc.orig/drivers/misc/Kconfig
+++ char-misc/drivers/misc/Kconfig
@@ -528,6 +528,16 @@ config SRAM
  the genalloc API. It is supposed to be used for small on-chip SRAM
  areas found on many SoCs.
 
+config RCAR_GYRO_ADC_SPEED_PULSE
+   tristate "Renesas R-Car Gyro-ADC and speed-pulse interfaces driver"
+   depends on HAS_IOMEM
+   help
+ This driver allows you to read speed pulse signal characteristics via
+ sysfs. The Gyro-ADC interface is not currently supported.
+
+ This driver can also be built as a module. If so, the module
+ will be called rcar_gyro_adc_speed_pulse.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
Index: char-misc/drivers/misc/Makefile
===
--- char-misc.orig/drivers/misc/Makefile
+++ char-misc/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_INTEL_MEI)   += mei/
 obj-$(CONFIG_VMWARE_VMCI)  += vmw_vmci/
 obj-$(CONFIG_LATTICE_ECP3_CONFIG)  += lattice-ecp3-config.o
 obj-$(CONFIG_SRAM) += sram.o
+obj-$(CONFIG_RCAR_GYRO_ADC_SPEED_PULSE)+= rcar-gyro-adc-speed-pulse.o
Index: char-misc/drivers/misc/rcar-gyro-adc-speed-pulse.c
===
--- /dev/null
+++ char-misc/drivers/misc/rcar-gyro-adc-speed-pulse.c
@@ -0,0 +1,231 @@
+/*
+ * Renesas R-Car Gyro-ADC and speed-pulse interfaces driver
+ *
+ * Copyright (C) 2013  Renesas Solutions Corp.
+ * Copyright (C) 2013  Cogent Embedded, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation; of the License.
+ *
+ * NOTE: Gyro-ADC interface is not really supported yet, just initialized
+ * and started/stopped synchronously with the speed-pulse interface.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Gyro-ADC interface registers */
+#defineADC_MODE_SELECT 0x00
+#defineADC_SPEED_START_STOP0x04
+#defineADC_CLOCK_LENGTH_COUNT  0x08
+#define_1_25_MS_LENGTH_COUNT   0x0C
+#defineAD_CH_REAL_DATA(n)  (0x10 + (n) * 4)
+#defineAD_CH_ADD_DATA(n)   (0x30 + (n) * 4)
+#defineAD_CH_10MS_DATA_FIFO(n) (0x50 + (n) * 4)
+#defineAD_FIFO_STATUS  0x70
+
+/* Speed-pulse interface registers */
+#defineSPEED_PULSE_COUNT_DATA  0x000
+#defineSPEED_PULSE_FILTER_SETTING  0x004
+#defineSPEED_PULSE_COUNT_CLEARING  0x008
+#defineSPEED_PULSE_100MS_LATCH_DATA0x00C
+#define_100_MS_INT_COUNT   0x010
+#defineINT_STATUS_AND_CLEAR0x018
+#define_500_KHZ_FREQ_COUNT_SETTING 0x01C
+#defineSPEED_PULSE_OFFSET_A0x100
+#defineSPEED_PULSE_OFFSET_B0x104
+#defineSPEED_PULSE_WIDTH   0x108
+#defineSPEED_PULSE_OBSERVE_A   0x10C
+#defineSPEED_PULSE_OBSERVE_B   0x110
+#defineSPEED_PULSE_WIDTH_CLEARING  0x114
+#defineSPEED_PULSE_WIDTH_TEST  0x118
+
+struct rcar_adc_sp_priv {
+   void __iomem *adc_base;
+   void __iomem *sp_base;
+   struct clk *adc_clk;
+   struct clk *sp_clk;
+};
+
+static u16 filter_time_const;
+module_param_named(filter, filter_time_const, ushort, S_IRUGO);
+MODULE_PARM_DESC(filter,
+"Low-pass filter time constant in microseconds (default=0)");
+
+static ssize_t rcar_adc_sp_show_pulse_count(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{

Re: [PATCH] misc: add driver for Renesas R-Car Gyro-ADC/speed-pulse interfaces

[Sergei Shtylyov]

Hello.

   Can't get to sleep, sigh...

On 07/13/2013 04:57 AM, Greg KH wrote:


Add the driver for Gyro-ADC/speed-pulse interfaces found in Renesas R-Car SoCs.
Though  being two separate devices, they have to be driven together because of
the shared start/stop register (located in Gyro-ADC still). At this time, only
speed-pulse interface is fully supported, the Gyro-ADC is just initialized and
started/stopped synchronously with the speed-pulse interface.  A user interface
is implemented via several sysfs files which allow to read and reset the speed-
pulse interface's registers.



If you modify/create/remove sysfs files, you also have to document them
in Documentation/ABI/ which is missing from this patch.


   I've looked there and didn't find the documentation for my closest
model driver, drivers/misc/ti_dac7512.c (or for many other drivers), so 
I thought I too can do without it.



Your sysfs files are also being created in a "racy" way, i.e. after
userspace is told about the device, please fix that as well.


   Not sure I understand you. Could you elaborate?


And are you sure you want to control this through sysfs?  There's no
other better user/kernel apis for it?


   I found none, besides ioctl(), as the device driven is rather 
unique. But I thought that sysfs is "ioctl() today", so I went with it...



thanks,



greg k-h


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] misc: add driver for Renesas R-Car Gyro-ADC/speed-pulse interfaces

[Sergei Shtylyov]

Hello.

On 07/13/2013 11:58 AM, Arnd Bergmann wrote:


And are you sure you want to control this through sysfs?  There's no
other better user/kernel apis for it?



 I found none, besides ioctl(), as the device driven is rather
unique. But I thought that sysfs is "ioctl() today", so I went with it...



It does sound like it would fit better into IIO than just a misc driver,
even if it's the only hardware of its kind.


   I got somewhat familiarized myself with drivers/iio/ infrastructure 
and I have found a place only the for ADC device in which the customer 
currently has no interest.
   The other trouble is that I'll have to backport this driver to 3.4 
which doesn't contain the IIO infrastructure at all. :-(



Arnd


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] misc: add driver for Renesas R-Car Gyro-ADC/speed-pulse interfaces

[Sergei Shtylyov]

Hello.

On 07/13/2013 05:30 AM, Greg KH wrote:


Add the driver for Gyro-ADC/speed-pulse interfaces found in Renesas R-Car SoCs.
Though  being two separate devices, they have to be driven together because of
the shared start/stop register (located in Gyro-ADC still). At this time, only
speed-pulse interface is fully supported, the Gyro-ADC is just initialized and
started/stopped synchronously with the speed-pulse interface.  A user interface
is implemented via several sysfs files which allow to read and reset the speed-
pulse interface's registers.



If you modify/create/remove sysfs files, you also have to document them
in Documentation/ABI/ which is missing from this patch.



I've looked there and didn't find the documentation for my closest
model driver, drivers/misc/ti_dac7512.c (or for many other drivers),
so I thought I too can do without it.



Nope, that driver should be fixed as well, care to do so?


   Sorry, I don't. The driver has an author, which I'm CCing.


Your sysfs files are also being created in a "racy" way, i.e. after
userspace is told about the device, please fix that as well.



Not sure I understand you. Could you elaborate?



Please read the driver model documentation, it goes into the details of
how to do this properly.  As does this post from me a week or so ago:

http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/


   Thank you. Probably a good read for ti_dac7512 driver too.


greg k-h


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] USB : serial : call handle_dcd_change in ftdi driver.

[Sergei Shtylyov]

Hello.

On 09/13/2013 07:35 PM, Paul Chavent wrote:


Signed-off-by: Paul Chavent 
---
  drivers/usb/serial/ftdi_sio.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)



diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index c45f9c0..df66495 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1966,8 +1966,14 @@ static int ftdi_process_packet(struct usb_serial_port 
*port,
port->icount.dsr++;
if (diff_status & FTDI_RS0_RI)
port->icount.rng++;
-   if (diff_status & FTDI_RS0_RLSD)
+   if (diff_status & FTDI_RS0_RLSD) {
port->icount.dcd++;
+   struct tty_struct *tty = tty_port_tty_get(&port->port);


   Don't mix declaration and code. And add an empty line between them please.


+   if (tty)
+   usb_serial_handle_dcd_change(port, tty,
+   status & FTDI_RS0_RLSD);
+   tty_kref_put(tty);
+   }


WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] USB : serial : invoke dcd_change ldisc's handler.

[Sergei Shtylyov]

Hello.

On 09/13/2013 07:35 PM, Paul Chavent wrote:


Signed-off-by: Paul Chavent 
---
  Documentation/pps/pps.txt| 15 +++
  drivers/usb/serial/generic.c |  9 +
  2 files changed, 24 insertions(+)



diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt
index d35dcdd..67b9a94 100644
--- a/Documentation/pps/pps.txt
+++ b/Documentation/pps/pps.txt
@@ -66,6 +66,21 @@ In LinuxPPS the PPS sources are simply char devices usually 
mapped
  into files /dev/pps0, /dev/pps1, etc..


+PPS with USB to serial devices
+--
+
+It is possible to grab the PPS from an USB to serial device. However,
+you should take into account the latencies and jitter introduced by
+the USB stack. Users has reported clock instability around +-1ms when
+synchronized with PPS through USB. This isn't suited for time server
+synchronisation.


   Thunderbird spellchecker underlines this word -- "synchronization" is 
probably better.


[...]

diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 1f31e6b..877d6e0 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -568,6 +568,15 @@ void usb_serial_handle_dcd_change(struct usb_serial_port 
*usb_port,
  {
struct tty_port *port = &usb_port->port;

+   if (tty) {
+   struct tty_ldisc *ld = tty_ldisc_ref(tty);


   Insert an empty line after declaration as above -- keep the style 
consistent, please.



+   if (ld) {
+   if (ld->ops->dcd_change)
+   ld->ops->dcd_change(tty, status);
+   tty_ldisc_deref(ld);
+   }
+   }
+


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] dma: add driver for R-Car HPB-DMAC

[Sergei Shtylyov]

Hello.

On 09/14/2013 10:33 PM, Guennadi Liakhovetski wrote:


From: Max Filippov 



Add support for HPB-DMAC found in Renesas R-Car SoCs, using 'shdma-base' DMA
driver framework.



Based on the original patch by Phil Edworthy .



Signed-off-by: Max Filippov 
[Sergei: removed useless #include, sorted #include's, fixed HPB_DMA_TCR_MAX,
fixed formats and removed line breaks in the dev_dbg() calls, rephrased and
added IRQ # to the shdma_request_irq() failure message, added MODULE_AUTHOR(),
removed '__init'/'__exit' annotations from the probe()/remove() methods, removed
'__initdata' annotation from 'hpb_dmae_driver', fixed guard macro name in the
header file, fixed #define ASYNCRSTR_ASRST20, added #define ASYNCRSTR_ASRST24,
added the necessary runtime PM calls to the probe() and remove() methods,
handled errors returned by dma_async_device_register(), beautified comments
and #define's.]
Signed-off-by: Sergei Shtylyov 



---



[snip]



Index: slave-dma/drivers/dma/sh/rcar-hpbdma.c
===
--- /dev/null
+++ slave-dma/drivers/dma/sh/rcar-hpbdma.c
@@ -0,0 +1,655 @@



[snip]



+static int hpb_dmae_chan_probe(struct hpb_dmae_device *hpbdev, int id)
+{
+   struct shdma_dev *sdev = &hpbdev->shdma_dev;
+   struct platform_device *pdev =
+   to_platform_device(hpbdev->shdma_dev.dma_dev.dev);
+   struct hpb_dmae_chan *new_hpb_chan;
+   struct shdma_chan *schan;
+
+   /* Alloc channel */
+   new_hpb_chan = devm_kzalloc(&pdev->dev,
+   sizeof(struct hpb_dmae_chan), GFP_KERNEL);
+   if (!new_hpb_chan) {
+   dev_err(hpbdev->shdma_dev.dma_dev.dev,
+   "No free memory for allocating DMA channels!\n");
+   return -ENOMEM;
+   }
+
+   schan = &new_hpb_chan->shdma_chan;



A suggestion for an incremental patch - you might want to initialise the
max_xfer_len field like



schan->max_xfer_len = 64 * 1024 * 1024 - 1;


   IIRC, the HPB-DMAC's maximum transfer length is 16 MiB, without -1. You 
probably mixed it with LBSC-DMAC which is indeed capable of 64 MiB.



because if it isn't initialised your max transfer length will be 4k,
which will hurt your performance. I think you should get a better
throughput after that


   OK, note taken. We'll look into it.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ptp: measure the time offset between PHC and system clock

[Sergei Shtylyov]

Hello.

On 09/14/2013 12:03 PM, Dong Zhu wrote:


This patch add a method into testptp.c to measure the time offset
between phc and system clock through the ioctl PTP_SYS_OFFSET.



Signed-off-by: Dong Zhu 
---
  Documentation/ptp/testptp.c | 40 ++--
  1 file changed, 38 insertions(+), 2 deletions(-)



diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index f59ded0..72bb030 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c

[...]

@@ -376,6 +387,31 @@ int main(int argc, char *argv[])
}
}

+   if (offset) {
+   sysoff = calloc(1, sizeof(*sysoff));
+   if (!sysoff) {
+   perror("calloc");
+   return -1;
+   }
+   sysoff->n_samples = n_samples;
+
+   if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
+   perror("PTP_SYS_OFFSET");
+   else
+   puts("time offset between PHC and
+system clock request okay");


   Don't break the string constant that way, there'll be all spaces between 
"and" and "system" included in it. Do it like this:


puts("time offset between PHC and "
 "system clock request okay");

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] vhost/scsi: use vmalloc for order-10 allocation

[Sergei Shtylyov]

Hello.

On 09/17/2013 11:21 AM, Michael S. Tsirkin wrote:


As vhost scsi device struct is large, if the device is
created on a busy system, kzalloc() might fail, so this patch does a
fallback to vzalloc().



As vmalloc() adds overhead on data-path, add __GFP_REPEAT
to kzalloc() flags to do this fallback only when really needed.



Reported-by: Dan Aloni 
Signed-off-by: Michael S. Tsirkin 
---



I put this on my vhost fixes branch, intend to merge for 3.12.
Dan, could you please confirm this works for you?



  drivers/vhost/scsi.c | 41 +++--
  1 file changed, 27 insertions(+), 14 deletions(-)



diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 4b79a1f..2c30bb0 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1373,21 +1373,30 @@ static int vhost_scsi_set_features(struct vhost_scsi 
*vs, u64 features)
return 0;
  }

+static void vhost_scsi_free(struct vhost_scsi *vs)
+{
+if (is_vmalloc_addr(vs))
+vfree(vs);
+else
+kfree(vs);


   Indent with the tabs ISO spaces, please.


+}
+
  static int vhost_scsi_open(struct inode *inode, struct file *f)
  {
struct vhost_scsi *vs;
struct vhost_virtqueue **vqs;
-   int r, i;
+   int r = -ENOMEM, i;

-   vs = kzalloc(sizeof(*vs), GFP_KERNEL);
-   if (!vs)
-   return -ENOMEM;
+vs = kzalloc(sizeof(*vs), GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);


   Indent here with a tab, please.


+   if (!vs) {
+   vs = vzalloc(sizeof(*vs));
+   if (!vs)
+   goto err_vs;
+   }


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 15/15] arm: dts: dra7: add sata node

[Sergei Shtylyov]

Hello.

On 09/19/2013 05:24 PM, Roger Quadros wrote:


From: Balaji T K 



Add support for sata controller.



[Roger Q] Clean up.



CC: Benoit Cousson 
Signed-off-by: Balaji T K 
Signed-off-by: Roger Quadros 
---
  arch/arm/boot/dts/dra7.dtsi |   49 +++
  1 files changed, 49 insertions(+), 0 deletions(-)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..545545d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -426,6 +426,55 @@
dma-names = "tx", "rx";
};

+   omap_control_sata: control-phy@4a002374 {
+   compatible = "ti,control-phy-pipe3";
+   reg = <0x4a002374 0x4>;
+   reg-names = "power";
+   clocks = <&sys_clkin1>;
+   clock-names = "sysclk";
+   };
+
+   ocp2scp3: ocp2scp3@4a09 {
+   compatible = "ti,omap-ocp2scp";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   ti,hwmods = "ocp2scp3";
+   reg = <0x4a09 0x1f>; /* ocp2scp3 */
+   reg-names = "ocp2scp3";
+   sata_phy: sataphy@4A096000 {


   It's better to name the PHY nodes uniformly after already standard 
"ethernet-phy" and your "control-phy".



+   compatible = "ti,phy-pipe3-sata";
+   reg = <0x4A096000 0x80>, /* phy_rx */
+ <0x4A096400 0x64>, /* phy_tx */
+ <0x4A096800 0x40>; /* pll_ctrl */
+   reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+   ctrl-module = <&omap_control_sata>;
+   clocks = <&sata_ref_clk>,
+<&sys_clkin1>;
+   clock-names = "optclk", "sysclk";
+   #phy-cells = <0>;
+   };
+   };
+
+   sata: sata@4a141100 {
+   compatible = "ti,sata";
+   ti,hwmods = "sata";
+   reg = <0x4a141100 0x7>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   dwc-ahci@4a14 {


   Hm, ePAPR spec. [1] says that "the name of a node should be somewhat 
generic, reflecting the function of the device and not its precise programming 
model", so it looks like the name should be "sata" as well. I'm a bit at a 
loss here, not sure why you had to use the nested device nodes.



+ compatible = "snps,dwc-ahci";
+ reg = <0x4a14 0x1100>;
+ interrupts = <0 54 0x4>;
+ phys = <&sata_phy>;


   Hm, it's the third PHY related generic property I'm encountering. First, 
there was "phy-handle", then "phy", now "phys"... Seems like a bit too much. :-)



+ phy-names = "sata-phy";
+ clocks = <&sata_ref_clk>;
+ clock-names = "optclk";
+   };
+   };


[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 12/15] ARM: dts: omap5: add ocp2scp1 address resource

[Sergei Shtylyov]

On 09/19/2013 05:23 PM, Roger Quadros wrote:


Add OCP2SCP1 module address space.



CC: Benoit Cousson 
Signed-off-by: Roger Quadros 
---
  arch/arm/boot/dts/omap5.dtsi |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)



diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 06aa665..8a88a94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -663,6 +663,7 @@
#size-cells = <1>;
ranges;
ti,hwmods = "ocp2scp1";
+   reg = <0x4a08 0x1f>;


   Are you sure length is not 0x20?

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next 2/2] tuntap: orphan frags before trying to set tx timestamp

[Sergei Shtylyov]

Hello.

On 04-09-2013 8:33, Jason Wang wrote:


sock_tx_timestamp() will clear all zerocopy flags of skb which may lead the
frags never to be orphaned. This will break guest to guest traffic when zerocopy
is enabled. Fix this by orphaning the frags before trying to set tx time stamp.



The issue were introduced by commit eda297729171fe16bf34fe5b0419dfb69060f623
(tun: Support software transmit time stamping).



Cc: Richard Cochran 
Signed-off-by: Jason Wang 
---
  drivers/net/tun.c |9 +
  1 files changed, 5 insertions(+), 4 deletions(-)



diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2dddb1b..af9a096 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -749,15 +749,16 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, 
struct net_device *dev)
  >= dev->tx_queue_len / tun->numqueues)
goto drop;

+   /* Orphan the skb - required as we might hang on to it
+* for indefinite time. */


   You could fix the comment style to the networking code default, while at: it:

/* bla
 * bla
 */


+   if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
+   goto drop;
+
if (skb->sk) {
sock_tx_timestamp(skb->sk, &skb_shinfo(skb)->tx_flags);
sw_tx_timestamp(skb);
}

-   /* Orphan the skb - required as we might hang on to it
-* for indefinite time. */
-   if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
-   goto drop;


WBR, Sergei



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/6] AHCI: Check MRSM bit when multiple MSIs enabled

[Sergei Shtylyov]

Hello.

On 09/05/2013 04:54 PM, Alexander Gordeev wrote:


Do not trust the hardware and always check if MSI
Revert to Single Message mode was enforced. Fall
back to the single MSI mode in case it did. Not
doing so might screw up the interrupt handling.



Signed-off-by: Alexander Gordeev 
---
  drivers/ata/ahci.c |   16 
  drivers/ata/ahci.h |1 +
  2 files changed, 17 insertions(+), 0 deletions(-)



diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index a6bb618..af5d535 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1091,6 +1091,14 @@ static inline void ahci_gtf_filter_workaround(struct 
ata_host *host)
  {}
  #endif

+static int ahci_get_mrsm(struct ahci_host_priv *hpriv)
+{
+   void __iomem *mmio = hpriv->mmio;
+   u32 ctl = readl(mmio + HOST_CTL);
+
+   return (ctl & HOST_MRSM);


   Parens not needed here, in case you'll respin this once more.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Sergei Shtylyov]

Hello.

On 09/06/2013 12:44 AM, David Miller wrote:


Several bug fixes (from Kirill Tkhai, Geery Uytterhoeven, and Alexey
Dobriyan) and some support for Fujitsu sparc64x chips (from Allen
Pais).



Please pull, thanks a lot!


   You meant that for 'linux-sparc', not 'linux-ide', right? :-)

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] USB : serial : get protected tty in handle_dcd_change.

[Sergei Shtylyov]

Hello.

On 09/09/2013 08:01 PM, Paul Chavent wrote:


This patch depends on 72df17e... (PATCH 1).


   You don't need to say that when you publish the patches as a series. It's 
assumed.



It restores the retreiving
of a protected instance of tty.  As opposed to the serialcore.c
dcd_change implementation, the callers of dcd_change used to
get protected tty instance.



Signed-off-by: Paul Chavent 


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/9] PCI/MSI/s390: Make return values only 0/-errno when MSIs allocated

[Sergei Shtylyov]

Hello.

On 09-09-2013 19:26, Alexander Gordeev wrote:


Signed-off-by: Alexander Gordeev 
---
  arch/s390/pci/pci.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)



diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index f17a834..c79c6e4 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -427,6 +427,8 @@ int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int 
type)
pr_debug("%s: requesting %d MSI-X interrupts...", __func__, nvec);
if (type != PCI_CAP_ID_MSIX && type != PCI_CAP_ID_MSI)
return -EINVAL;
+   if (type == PCI_CAP_ID_MSI && nvec > 1)
+   return 1;


   This contradicts to the patch subject.

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/