Re: [PATCH 03/15] staging: comedi: ni_routing: Add NI signal routing info

[Spencer E Olson]

On Mon, 2017-10-09 at 12:01 -0600, Spencer E Olson wrote:
> On Mon, 2017-10-09 at 10:56 +0100, Ian Abbott wrote:
> > On 08/10/17 07:44, Spencer E Olson wrote:
> > > On Thu, 2016-11-10 at 18:16 +, Ian Abbott wrote:
> > >> On 10/11/16 17:54, Greg Kroah-Hartman wrote:
> > >>> On Thu, Nov 10, 2016 at 05:08:36PM +, Ian Abbott wrote:
> >  On 12/10/16 12:05, Spencer E. Olson wrote:
> > > See README for a thorough discussion of this content.
> > >
> > > Adds two different collections of CSV files that:
> > > 1) summarize the various register values for creating routes
> > > for a particular family of NI hardware devices;
> > > 2) summarize all possible (direct) routes that a particular device can
> > > make--in this case, one file per device (this data is currently 
> > > only
> > > known to be found by examining a screenshot of the "Available 
> > > Routes"
> > > tab of NI MAX control panel, which is only found on Windows
> > > installations of the NI driver).
> > >
> > > The collection and maintenance of this information is somewhat 
> > > tedious and
> > > requires frequent re-examination and comparison of NI-MAX and/or the 
> > > NI-MHDDK
> > > documentation (register programming information) and NI-MHDDK 
> > > examples.
> > > These CSV files are constructed so-as to allow near direct comparison
> > > to NI-MAX and NI-MHDDK.  As such, these serve to ease the task of
> > > maintaining this knowledge and more quickly enables addition of new NI
> > > devices.
> > >
> > > Signed-off-by: Spencer E. Olson 
> > >
> > > *** PLEASE FIND ACTUAL PATCH AT:
> > > http://www.umich.edu/~olsonse/patches/comedi-devglobal-v1/0003-staging-comedi-ni_routing-Add-NI-signal-routing-info.patch
> > >
> > > (This patch included some lines that were too long for email)
> > > ---
> > >   drivers/staging/comedi/drivers/ni_routing/README   | 110 
> > > +
> > >   .../ni_routing/ni_device_routes/PCI-6070E.csv  |  40 
> > >   .../ni_routing/ni_device_routes/PCI-6220.csv   |  46 +
> > >   .../ni_routing/ni_device_routes/PCI-6221.csv   |  50 ++
> > >   .../ni_routing/ni_device_routes/PCI-6251.csv   |  51 ++
> > >   .../ni_routing/ni_device_routes/PCI-6254.csv   |  47 +
> > >   .../ni_routing/ni_device_routes/PCI-6259.csv   |  51 ++
> > >   .../ni_routing/ni_device_routes/PCI-6534.csv   |  29 ++
> > >   .../ni_routing/ni_device_routes/PCI-6602.csv   |  78 
> > > +++
> > >   .../ni_routing/ni_device_routes/PCI-6713.csv   |  32 ++
> > >   .../ni_routing/ni_device_routes/PCI-6723.csv   |  32 ++
> > >   .../ni_routing/ni_device_routes/PCI-6733.csv   |  34 +++
> > >   .../ni_routing/ni_device_routes/PXI-6030E.csv  |  39 
> > >   .../ni_routing/ni_device_routes/PXI-6224.csv   |  46 +
> > >   .../ni_routing/ni_device_routes/PXI-6225.csv   |  49 +
> > >   .../ni_routing/ni_device_routes/PXI-6251.csv   |  50 ++
> > >   .../ni_routing/ni_device_routes/PXI-6733.csv   |  35 +++
> > >   .../ni_routing/ni_device_routes/PXIe-6251.csv  |  52 ++
> > >   .../drivers/ni_routing/ni_route_values/ni_660x.csv | 100 
> > > +++
> > >   .../ni_routing/ni_route_values/ni_eseries.csv  |  78 
> > > +++
> > >   .../ni_routing/ni_route_values/ni_mseries.csv  |  90 
> > > +
> > >   21 files changed, 1139 insertions(+)
> > >   create mode 100644 drivers/staging/comedi/drivers/ni_routing/README
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6070E.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6220.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6221.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6251.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6254.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6259.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6534.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6602.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6713.csv
> > >   create mode 100644 
> > > drivers/staging/comedi/drivers/ni_routing/ni_device_routes/PCI-6723.csv
> > >   create mode 

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

[Tobin C. Harding]

On Wed, Oct 11, 2017 at 06:02:47PM +0530, Shreeya Patel wrote:
> On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote:
> > On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote:
> > > 
> > > Remove NULL pointer dereference as it results in undefined
> > > behaviour, and will usually lead to a runtime error.
> > The diff does not show any pointer dereference so it is hard to
> > understand what you are trying to do
> > with this patch.
> > 
> > > 
> > > Signed-off-by: Shreeya Patel 
> > > ---
> > >  drivers/staging/rtlwifi/base.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/rtlwifi/base.c
> > > b/drivers/staging/rtlwifi/base.c
> > > index b88b0e8..5bb8f98 100644
> > > --- a/drivers/staging/rtlwifi/base.c
> > > +++ b/drivers/staging/rtlwifi/base.c
> > > @@ -781,7 +781,7 @@ static void _rtl_txrate_selectmode(struct
> > > ieee80211_hw *hw,
> > >  
> > >   struct rtl_priv *rtlpriv = rtl_priv(hw);
> > >   struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
> > > - struct rtl_sta_info *sta_entry = NULL;
> > > + struct rtl_sta_info *sta_entry;
> > Now the pointer just has garbage in it instead of the testable value
> > of NULL. If you are concerned
> > with the dereference perhaps you could add a NULL check, again it's
> > hard to say without seeing the
> > code.
> 
> Hello, 
> 
> Thanks for making me understand. 
> 
> Here is the code after declaration and initialization of sta_entry. 
> Will it be good to add a NULL check in this case? 
> 
> struct rtl_sta_info *sta_entry = NULL;
>   u8 ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);
> 
>   if (sta) {
>   sta_entry = (struct rtl_sta_info *)sta->drv_priv;
>   ratr_index = sta_entry->ratr_index;
>   }

Later in this function the macro SET_RATE_ID() is called, it relies on 
sta_entry being NULL if it
was not explicitly set.

Here is the macro;

#define SET_RATE_ID(rate_id)\
((rtlpriv->cfg->spec_ver & RTL_SPEC_NEW_RATEID) ?   \
rtl_mrate_idx_to_arfr_id(hw, rate_id,   \
(sta_entry ? sta_entry->wireless_mode : \
 WIRELESS_MODE_G)) :\
rate_id)

> If we are making a pointer point to NULL then what if any other
> variable is already pointing to NULL for some other purpose.
> Instead, removing initialization will be good right?

A pointer does not _point_ to NULL as such. A NULL pointer has a value of all 
zero bytes. Have you
read (and completed all the exercises) in KnR

https://en.wikipedia.org/wiki/The_C_Programming_Language

It is, in my opinion, one of the best tech books ever written. If you have any 
holes in your C
knowledge, this is the place to start.

Good luck,
Tobin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

[Russell King - ARM Linux]

On Thu, Oct 12, 2017 at 12:06:33AM +0100, Russell King - ARM Linux wrote:
> Now, if you mean "known" to be equivalent with "recognised by
> imx-media" then, as I've pointed out several times already, that
> statement is FALSE.  I'm not sure how many times I'm going to have to
> state this fact.  Let me re-iterate again.  On my imx219 driver, I
> have two subdevs.  Both subdevs have controls attached.  The pixel
> subdev is not "recognised" by imx-media, and without a modification
> like my or your patch, it fails.  However, with the modification,
> this "unrecognised" subdev _STILL_ has it's controls visible through
> imx-media.

If you refuse to believe what I'm saying, then read through:

http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?h=csi-v6=e3f847cd37b007d55b76282414bfcf13abb8fc9a

and look at this:

# for f in 2 3 4 5 6 7 8 9; do v4l2-ctl -L -d /dev/video$f; done
# ./cam/cam-setup.sh
# v4l2-ctl -L -d /dev/video6

User Controls

   gain (int): min=256 max=4095 step=1 default=256 
value=256
 fim_enable (bool)   : default=0 value=0
fim_num_average (int): min=1 max=64 step=1 default=8 
value=8  fim_tolerance_min (int): min=2 max=200 step=1 
default=50 value=50
  fim_tolerance_max (int): min=0 max=500 step=1 default=0 
value=0
   fim_num_skip (int): min=0 max=256 step=1 default=2 
value=2
 fim_input_capture_edge (int): min=0 max=3 step=1 default=0 value=0
  fim_input_capture_channel (int): min=0 max=1 step=1 default=0 value=0

Camera Controls

 exposure_time_absolute (int): min=1 max=399 step=1 default=399 
value=166

Image Source Controls

  vertical_blanking (int): min=32 max=64814 step=1 default=2509
value=2509 flags=read-only
horizontal_blanking (int): min=2168 max=31472 step=1 
default=2168 value=2168 flags=read-only
  analogue_gain (int): min=1000 max=8000 step=1 
default=1000 value=1000
red_pixel_value (int): min=0 max=1023 step=1 default=0 
value=0 flags=inactive
  green_red_pixel_value (int): min=0 max=1023 step=1 default=0 
value=0 flags=inactive
   blue_pixel_value (int): min=0 max=1023 step=1 default=0 
value=0 flags=inactive
 green_blue_pixel_value (int): min=0 max=1023 step=1 default=0 
value=0 flags=inactive

Image Processing Controls

 pixel_rate (int64)  : min=16000 max=27840 step=1 
default=27840 value=27840 flags=read-only
   test_pattern (menu)   : min=0 max=9 default=0 value=0
0: Disabled
1: Solid Color
2: 100% Color Bars
3: Fade to Grey Color Bar
4: PN9
5: 16 Split Color Bar
6: 16 Split Inverted Color Bar
7: Column Counter
8: Inverted Column Counter
9: PN31

Now, the pixel array subdev has these controls:
gain
vertical_blanking
horizontal_blanking
analogue_gain
pixel_rate
exposure_time_absolute

The root subdev (which is the one which connects to your code) has
these controls:
red_pixel_value
green_red_pixel_value
blue_pixel_value
green_blue_pixel_value
test_pattern

As you can see from the above output, _all_ controls from _both_ subdevs
are listed.

Now, before you spot your old patch adding v4l2_pipeline_inherit_controls()
and try to blame that for this, nothing in my kernel calls that function,
so that patch can be dropped, and so it's not responsible for this.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

[Steve Longerbeam]

On 10/11/2017 04:06 PM, Russell King - ARM Linux wrote:

On Wed, Oct 11, 2017 at 03:14:26PM -0700, Steve Longerbeam wrote:


On 10/11/2017 02:49 PM, Russell King - ARM Linux wrote:

On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote:

imx_media_link_notify() should not return error if the source subdevice
is not recognized by imx-media, that isn't an error. If the subdev has
controls they will be inherited starting from a known subdev.

What does "a known subdev" mean?

It refers to the previous sentence, "not recognized by imx-media". A
subdev that was not registered via async registration and so not in
imx-media's async subdev list. I could elaborate in the commit message
but it seems fairly obvious to me.

I don't think it's obvious, and I suspect you won't think it's obvious
in years to come (I talk from experience of some commentry I've added
in the past.)

Now, isn't it true that for a subdev to be part of a media device, it
has to be registered, and if it's part of a media device that is made
up of lots of different drivers, it has to use the async registration
code?  So, is it not also true that any subdev that is part of a
media device, it will be "known"?

Under what circumstances could a subdev be part of a media device but
not be "known" ?

Now, if you mean "known" to be equivalent with "recognised by
imx-media" then, as I've pointed out several times already, that
statement is FALSE.  I'm not sure how many times I'm going to have to
state this fact.  Let me re-iterate again.  On my imx219 driver, I
have two subdevs.  Both subdevs have controls attached.  The pixel
subdev is not "recognised" by imx-media, and without a modification
like my or your patch, it fails.  However, with the modification,
this "unrecognised" subdev _STILL_ has it's controls visible through
imx-media.


Well that's true, the controls for your pixel subdev (which was
not registered via async) still are visible to imx-media, so in that
sense the subdev is "known" to imx-media.



Hence, I believe your comment in the code and your commit message
are misleading and wrong.


Ok you convinced me, I'll fix the code comment and commit
message.

Steve

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

[Russell King - ARM Linux]

On Wed, Oct 11, 2017 at 03:14:26PM -0700, Steve Longerbeam wrote:
> 
> 
> On 10/11/2017 02:49 PM, Russell King - ARM Linux wrote:
> >On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote:
> >>imx_media_link_notify() should not return error if the source subdevice
> >>is not recognized by imx-media, that isn't an error. If the subdev has
> >>controls they will be inherited starting from a known subdev.
> >What does "a known subdev" mean?
> 
> It refers to the previous sentence, "not recognized by imx-media". A
> subdev that was not registered via async registration and so not in
> imx-media's async subdev list. I could elaborate in the commit message
> but it seems fairly obvious to me.

I don't think it's obvious, and I suspect you won't think it's obvious
in years to come (I talk from experience of some commentry I've added
in the past.)

Now, isn't it true that for a subdev to be part of a media device, it
has to be registered, and if it's part of a media device that is made
up of lots of different drivers, it has to use the async registration
code?  So, is it not also true that any subdev that is part of a
media device, it will be "known"?

Under what circumstances could a subdev be part of a media device but
not be "known" ?

Now, if you mean "known" to be equivalent with "recognised by
imx-media" then, as I've pointed out several times already, that
statement is FALSE.  I'm not sure how many times I'm going to have to
state this fact.  Let me re-iterate again.  On my imx219 driver, I
have two subdevs.  Both subdevs have controls attached.  The pixel
subdev is not "recognised" by imx-media, and without a modification
like my or your patch, it fails.  However, with the modification,
this "unrecognised" subdev _STILL_ has it's controls visible through
imx-media.

Hence, I believe your comment in the code and your commit message
are misleading and wrong.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

[Dmitry Osipenko]

On 11.10.2017 23:47, Nicolas Dufresne wrote:
> Le mercredi 11 octobre 2017 à 23:08 +0300, Dmitry Osipenko a écrit :
>> diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra-
>> vde/TODO
>> new file mode 100644
>> index ..e98bbc7b3c19
>> --- /dev/null
>> +++ b/drivers/staging/tegra-vde/TODO
>> @@ -0,0 +1,5 @@
>> +TODO:
>> +   - Figure out how generic V4L2 API could be utilized by this
>> driver,
>> + implement it.
>> +
> 
> That is a very interesting effort, I think it's the first time someone
> is proposing an upstream driver for a Tegra platform.

Thanks!

 When I look
> tegra_vde_h264_decoder_ctx, it looks like the only thing that the HW is
> not parsing is the media header (pps/sps). Is that correct ?
> 

That's correct. I think it's quite common among embedded (mobile) and
desktop-grade decoders to require some auxiliary info from the media headers.

> I wonder how acceptable it would be to parse this inside the driver. It
> is no more complex then parsing an EDID. If that was possible, wrapping
> this driver as a v4l2 mem2mem should be rather simple. As a side
> effect, you'll automatically get some userspace working, notably
> GStreamer and FFmpeg.
> 

Parsing bitstream in kernel feels a bit dirty, although it's up to media
maintainers to decide.

> For the case even parsing the headers is too much from a kernel point
> of view, then I think you should have a look at the following effort.
> It's a proposal base on yet to be merged Request API. Hugues is also
> propose a libv4l2 adapter that makes the driver looks like a normal
> v4l2 m2m, hiding all the userspace parsing and table filling. This
> though, is long term plan to integrate state-less or parser-less
> encoders into linux-media. It seems rather overkill for state-full
> driver that requires parsed headers like PPS/SPS.
> 
> https://lwn.net/Articles/720797/
> 

I'll take a look at the Request API / libv4l2 adapter, thank you very much for
pointing to it.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

[Steve Longerbeam]

On 10/11/2017 02:49 PM, Russell King - ARM Linux wrote:

On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote:

imx_media_link_notify() should not return error if the source subdevice
is not recognized by imx-media, that isn't an error. If the subdev has
controls they will be inherited starting from a known subdev.

What does "a known subdev" mean?


It refers to the previous sentence, "not recognized by imx-media". A
subdev that was not registered via async registration and so not in
imx-media's async subdev list. I could elaborate in the commit message
but it seems fairly obvious to me.

Steve

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] media: staging/imx: do not return error in link_notify for unknown sources

[Russell King - ARM Linux]

On Tue, Oct 03, 2017 at 12:09:13PM -0700, Steve Longerbeam wrote:
> imx_media_link_notify() should not return error if the source subdevice
> is not recognized by imx-media, that isn't an error. If the subdev has
> controls they will be inherited starting from a known subdev.

What does "a known subdev" mean?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

[Nicolas Dufresne]

Le mercredi 11 octobre 2017 à 23:08 +0300, Dmitry Osipenko a écrit :
> diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra-
> vde/TODO
> new file mode 100644
> index ..e98bbc7b3c19
> --- /dev/null
> +++ b/drivers/staging/tegra-vde/TODO
> @@ -0,0 +1,5 @@
> +TODO:
> +   - Figure out how generic V4L2 API could be utilized by this
> driver,
> + implement it.
> +

That is a very interesting effort, I think it's the first time someone
is proposing an upstream driver for a Tegra platform. When I look
tegra_vde_h264_decoder_ctx, it looks like the only thing that the HW is
not parsing is the media header (pps/sps). Is that correct ?

I wonder how acceptable it would be to parse this inside the driver. It
is no more complex then parsing an EDID. If that was possible, wrapping
this driver as a v4l2 mem2mem should be rather simple. As a side
effect, you'll automatically get some userspace working, notably
GStreamer and FFmpeg.

For the case even parsing the headers is too much from a kernel point
of view, then I think you should have a look at the following effort.
It's a proposal base on yet to be merged Request API. Hugues is also
propose a libv4l2 adapter that makes the driver looks like a normal
v4l2 m2m, hiding all the userspace parsing and table filling. This
though, is long term plan to integrate state-less or parser-less
encoders into linux-media. It seems rather overkill for state-full
driver that requires parsed headers like PPS/SPS.

https://lwn.net/Articles/720797/

regards,
Nicolas

signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3 2/2] ARM: dts: tegra20: Add video decoder node

[Dmitry Osipenko]

Add a device node for the video decoder engine found on Tegra20.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 7c85f97f72ea..1b5d54b6c0cb 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -249,6 +249,23 @@
*/
};
 
+   vde@6001a000 {
+   compatible = "nvidia,tegra20-vde";
+   reg = <0x6001a000 0x3D00/* VDE registers */
+  0x4400 0x3FC00>; /* IRAM region */
+   reg-names = "regs", "iram";
+   interrupts = , /* UCQ error 
interrupt */
+, /* Sync token 
interrupt */
+, /* BSE-V 
interrupt */
+, /* BSE-A 
interrupt */
+; /* SXE interrupt 
*/
+   interrupt-names = "ucq-error", "sync-token", "bsev", "bsea", 
"sxe";
+   clocks = <_car TEGRA20_CLK_VDE>;
+   clock-names = "vde";
+   resets = <_car 61>;
+   reset-names = "vde";
+   };
+
apbmisc@7800 {
compatible = "nvidia,tegra20-apbmisc";
reg = <0x7800 0x64   /* Chip revision */
-- 
2.14.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3 0/2] NVIDIA Tegra20 video decoder driver

[Dmitry Osipenko]

This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's,
it is a result of reverse-engineering efforts. Driver has been tested on
Toshiba AC100 and Acer A500, it should work on any Tegra20 device.

In userspace this driver is utilized by libvdpau-tegra [0] that implements
VDPAU interface, so any video player that supports VDPAU can provide
accelerated video decoding on Tegra20 on Linux.

[0] https://github.com/grate-driver/libvdpau-tegra

Change log:
v3:
- Suppressed compilation warnings reported by 'kbuild test robot'

v2:
- Addressed v1 review comments from Stephen Warren and Dan Carpenter
- Implemented runtime PM
- Miscellaneous code cleanups
- Changed 'TODO'
- CC'd media maintainers for the review as per Greg K-H request,
  v1 can be viewed at https://lkml.org/lkml/2017/9/25/606

Dmitry Osipenko (2):
  staging: Introduce NVIDIA Tegra20 video decoder driver
  ARM: dts: tegra20: Add video decoder node

 .../bindings/arm/tegra/nvidia,tegra20-vde.txt  |   44 +
 arch/arm/boot/dts/tegra20.dtsi |   17 +
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/tegra-vde/Kconfig  |6 +
 drivers/staging/tegra-vde/Makefile |1 +
 drivers/staging/tegra-vde/TODO |5 +
 drivers/staging/tegra-vde/uapi.h   |  101 ++
 drivers/staging/tegra-vde/vde.c| 1109 
 9 files changed, 1286 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
 create mode 100644 drivers/staging/tegra-vde/Kconfig
 create mode 100644 drivers/staging/tegra-vde/Makefile
 create mode 100644 drivers/staging/tegra-vde/TODO
 create mode 100644 drivers/staging/tegra-vde/uapi.h
 create mode 100644 drivers/staging/tegra-vde/vde.c

-- 
2.14.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v3 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver

[Dmitry Osipenko]

Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of
video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports
decoding of CAVLC H.264 only.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/arm/tegra/nvidia,tegra20-vde.txt  |   44 +
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/tegra-vde/Kconfig  |6 +
 drivers/staging/tegra-vde/Makefile |1 +
 drivers/staging/tegra-vde/TODO |5 +
 drivers/staging/tegra-vde/uapi.h   |  101 ++
 drivers/staging/tegra-vde/vde.c| 1109 
 8 files changed, 1269 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
 create mode 100644 drivers/staging/tegra-vde/Kconfig
 create mode 100644 drivers/staging/tegra-vde/Makefile
 create mode 100644 drivers/staging/tegra-vde/TODO
 create mode 100644 drivers/staging/tegra-vde/uapi.h
 create mode 100644 drivers/staging/tegra-vde/vde.c

diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt 
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
new file mode 100644
index ..c3f847db8167
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
@@ -0,0 +1,44 @@
+NVIDIA Tegra Video Decoder Engine
+
+Required properties:
+- compatible : "nvidia,tegra20-vde"
+- reg : Must contain 2 register ranges: registers and IRAM region that
+VDE uses for its internal needs and for passing some of decoding
+parameters.
+- reg-names : Must include the following entries:
+  - regs
+  - iram
+- interrupts : Must contain an entry for each entry in interrupt-names.
+- interrupt-names : Must include the following entries:
+  - ucq-error
+  - sync-token
+  - bsev
+  - bsea
+  - sxe
+- clocks : Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+  - vde
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - vde
+
+Example:
+
+vde@6001a000 {
+   compatible = "nvidia,tegra20-vde";
+   reg = <0x6001a000 0x3D00/* VDE registers */
+   0x4400 0x3FC00>; /* IRAM region */
+   reg-names = "regs", "iram";
+   interrupts = , /* UCQ error interrupt */
+   , /* Sync token 
interrupt */
+   , /* BSE-V interrupt */
+   , /* BSE-A interrupt */
+   ; /* SXE interrupt */
+   interrupt-names = "ucq-error", "sync-token", "bsev", "bsea", "sxe";
+   clocks = <_car TEGRA20_CLK_VDE>;
+   clock-names = "vde";
+   resets = <_car 61>;
+   reset-names = "vde";
+};
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 554683912cff..10c982811093 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -118,4 +118,6 @@ source "drivers/staging/vboxvideo/Kconfig"
 
 source "drivers/staging/pi433/Kconfig"
 
+source "drivers/staging/tegra-vde/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 8951c37d8d80..c5ef39767f22 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -49,3 +49,4 @@ obj-$(CONFIG_BCM2835_VCHIQ)   += vc04_services/
 obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/
 obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/
 obj-$(CONFIG_PI433)+= pi433/
+obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
diff --git a/drivers/staging/tegra-vde/Kconfig 
b/drivers/staging/tegra-vde/Kconfig
new file mode 100644
index ..730ee006de66
--- /dev/null
+++ b/drivers/staging/tegra-vde/Kconfig
@@ -0,0 +1,6 @@
+config TEGRA_VDE
+   tristate "NVIDIA Tegra Video Decoder Engine driver"
+   depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
+   help
+   Say Y here to enable support for the NVIDIA Tegra video decoder
+   driver.
diff --git a/drivers/staging/tegra-vde/Makefile 
b/drivers/staging/tegra-vde/Makefile
new file mode 100644
index ..e7c0df1174bf
--- /dev/null
+++ b/drivers/staging/tegra-vde/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TEGRA_VDE)+= vde.o
diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra-vde/TODO
new file mode 100644
index ..e98bbc7b3c19
--- /dev/null
+++ b/drivers/staging/tegra-vde/TODO
@@ -0,0 +1,5 @@
+TODO:
+   - Figure out how generic V4L2 API could be utilized by this driver,
+ implement it.
+
+Contact: Dmitry Osipenko 
diff --git a/drivers/staging/tegra-vde/uapi.h b/drivers/staging/tegra-vde/uapi.h
new file mode 100644
index ..36d76278d27c
--- /dev/null
+++ b/drivers/staging/tegra-vde/uapi.h
@@ -0,0 +1,101 @@
+/*
+ * Copyright 

[PATCH 5/5] staging: pi433: rf69.c style fix - space before asterisk

[Marcin Ciupak]

This patch fixes the following checkpatch.pl error:

ERROR: "(foo*)" should be "(foo *)"

in rf69.c file as requested by TODO file.

Additionally some style warnings remain valid here and could be fixed by
another patch.

Signed-off-by: Marcin Ciupak 
---
 drivers/staging/pi433/rf69.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 6420d1b67ccc..e69a2153c999 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -919,7 +919,7 @@ int rf69_set_fifo_threshold(struct spi_device *spi, u8 
threshold)
return retval;
 
// access the fifo to activate new threshold
-   return rf69_read_fifo (spi, (u8*) , 1); // retval used as buffer
+   return rf69_read_fifo(spi, (u8 *), 1); // retval used as buffer
 }
 
 int rf69_set_dagc(struct spi_device *spi, enum dagc dagc)
-- 
2.14.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/5] staging: pi433: rf69.c style fix - code indent should use tabs

[Marcin Ciupak]

This patch fixes the following checkpatch.pl error:

ERROR: code indent should use tabs where possible

in rf69.c file as requested by TODO file.

Additionally some style warnings remain valid here and could be fixed by
another patch.

Signed-off-by: Marcin Ciupak 
---
 drivers/staging/pi433/rf69.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 23d609474836..6420d1b67ccc 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -959,8 +959,8 @@ int rf69_read_fifo (struct spi_device *spi, u8 *buffer, 
unsigned int size)
/* prepare a bidirectional transfer */
local_buffer[0] = REG_FIFO;
memset(, 0, sizeof(transfer));
-   transfer.tx_buf = local_buffer;
-   transfer.rx_buf = local_buffer;
+   transfer.tx_buf = local_buffer;
+   transfer.rx_buf = local_buffer;
transfer.len= size+1;
 
retval = spi_sync_transfer(spi, , 1);
-- 
2.14.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/5] staging: pi433: rf69.c style fix - spaces before/after

[Marcin Ciupak]

his patch fixes the following checkpatch.pl errors:

ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that ',' (ctx:WxV)
ERROR: space prohibited before that close parenthesis ')'
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required before the open parenthesis '('

in rf69.c file as requested by TODO file.

Additionally some style warnings remain valid here and could be fixed by
another patch.

Signed-off-by: Marcin Ciupak 
---
 drivers/staging/pi433/rf69.c | 154 +--
 1 file changed, 77 insertions(+), 77 deletions(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 7a79973641c9..23d609474836 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -34,7 +34,7 @@
 /*-*/
 
 #define READ_REG(x)rf69_read_reg (spi, x)
-#define WRITE_REG(x,y) rf69_write_reg(spi, x, y)
+#define WRITE_REG(x, y)rf69_write_reg(spi, x, y)
 
 /*-*/
 
@@ -199,7 +199,7 @@ int rf69_set_deviation(struct spi_device *spi, u32 
deviation)
 
// calculate register settings
f_reg = deviation * factor;
-   do_div(f_reg  , f_step);
+   do_div(f_reg, f_step);
 
msb = (f_reg&0xff00)   >>  8;
lsb = (f_reg&0xff);
@@ -250,7 +250,7 @@ int rf69_set_frequency(struct spi_device *spi, u32 
frequency)
 
// calculate reg settings
f_reg = frequency * factor;
-   do_div(f_reg  , f_step);
+   do_div(f_reg, f_step);
 
msb = (f_reg&0xff) >> 16;
mid = (f_reg&0xff00)   >>  8;
@@ -278,9 +278,9 @@ int rf69_set_amplifier_0(struct spi_device *spi, enum 
optionOnOff optionOnOff)
dev_dbg(>dev, "set: amp #0");
#endif
 
-   switch(optionOnOff) {
-   case optionOn:  return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) |  
MASK_PALEVEL_PA0) );
-   case optionOff: return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) & 
~MASK_PALEVEL_PA0) );
+   switch (optionOnOff) {
+   case optionOn:  return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) |  
MASK_PALEVEL_PA0));
+   case optionOff: return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) & 
~MASK_PALEVEL_PA0));
default:
dev_dbg(>dev, "set: illegal input param");
return -EINVAL;
@@ -293,9 +293,9 @@ int rf69_set_amplifier_1(struct spi_device *spi, enum 
optionOnOff optionOnOff)
dev_dbg(>dev, "set: amp #1");
#endif
 
-   switch(optionOnOff) {
-   case optionOn:  return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) |  
MASK_PALEVEL_PA1) );
-   case optionOff: return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) & 
~MASK_PALEVEL_PA1) );
+   switch (optionOnOff) {
+   case optionOn:  return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) |  
MASK_PALEVEL_PA1));
+   case optionOff: return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) & 
~MASK_PALEVEL_PA1));
default:
dev_dbg(>dev, "set: illegal input param");
return -EINVAL;
@@ -308,9 +308,9 @@ int rf69_set_amplifier_2(struct spi_device *spi, enum 
optionOnOff optionOnOff)
dev_dbg(>dev, "set: amp #2");
#endif
 
-   switch(optionOnOff) {
-   case optionOn:  return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) |  
MASK_PALEVEL_PA2) );
-   case optionOff: return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) & 
~MASK_PALEVEL_PA2) );
+   switch (optionOnOff) {
+   case optionOn:  return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) |  
MASK_PALEVEL_PA2));
+   case optionOff: return WRITE_REG(REG_PALEVEL, (READ_REG(REG_PALEVEL) & 
~MASK_PALEVEL_PA2));
default:
dev_dbg(>dev, "set: illegal input param");
return -EINVAL;
@@ -341,7 +341,7 @@ int rf69_set_pa_ramp(struct spi_device *spi, enum paRamp 
paRamp)
dev_dbg(>dev, "set: pa ramp");
#endif
 
-   switch(paRamp) {
+   switch (paRamp) {
case ramp3400:  return WRITE_REG(REG_PARAMP, PARAMP_3400);
case ramp2000:  return WRITE_REG(REG_PARAMP, PARAMP_2000);
case ramp1000:  return WRITE_REG(REG_PARAMP, PARAMP_1000);
@@ -370,9 +370,9 @@ int rf69_set_antenna_impedance(struct spi_device *spi, enum 
antennaImpedance ant
dev_dbg(>dev, "set: antenna impedance");
#endif
 
-   switch(antennaImpedance) {
-   case fiftyOhm:  return WRITE_REG(REG_LNA, (READ_REG(REG_LNA) & 
~MASK_LNA_ZIN) );
-   case twohundretOhm: return WRITE_REG(REG_LNA, (READ_REG(REG_LNA) |  
MASK_LNA_ZIN) );
+   switch (antennaImpedance) {
+   case fiftyOhm:  return WRITE_REG(REG_LNA, (READ_REG(REG_LNA) & 
~MASK_LNA_ZIN));
+   case twohundretOhm: return WRITE_REG(REG_LNA, (READ_REG(REG_LNA) |  
MASK_LNA_ZIN));

[PATCH 2/5] staging: pi433: rf69.c style fix - spaces required around

[Marcin Ciupak]

This patch fixes the following checkpatch.pl errors:

ERROR: spaces required around that '+=' (ctx:WxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: spaces required around that '<' (ctx:VxV)

in rf69.c file as requested by TODO file.

Additionally some style warnings remain valid here and could be fixed by
another patch.

Signed-off-by: Marcin Ciupak 
---
 drivers/staging/pi433/rf69.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 3d9cf2cac4ef..7a79973641c9 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -323,7 +323,7 @@ int rf69_set_output_power_level(struct spi_device *spi, u8 
powerLevel)
dev_dbg(>dev, "set: power level");
#endif
 
-   powerLevel +=18; // TODO Abh�ngigkeit von PA0,1,2 setting
+   powerLevel += 18; // TODO Abh�ngigkeit von PA0,1,2 setting
 
// check input value
if (powerLevel > 0x1f) {
@@ -589,24 +589,30 @@ int rf69_set_dio_mapping(struct spi_device *spi, u8 
DIONumber, u8 value)
 
switch (DIONumber) {
case 0:
-   mask=MASK_DIO0; shift=SHIFT_DIO0; regaddr=REG_DIOMAPPING1; 
break;
+   mask = MASK_DIO0; shift = SHIFT_DIO0; regaddr = REG_DIOMAPPING1;
+   break;
case 1:
-   mask=MASK_DIO1; shift=SHIFT_DIO1; regaddr=REG_DIOMAPPING1; 
break;
+   mask = MASK_DIO1; shift = SHIFT_DIO1; regaddr = REG_DIOMAPPING1;
+   break;
case 2:
-   mask=MASK_DIO2; shift=SHIFT_DIO2; regaddr=REG_DIOMAPPING1; 
break;
+   mask = MASK_DIO2; shift = SHIFT_DIO2; regaddr = REG_DIOMAPPING1;
+   break;
case 3:
-   mask=MASK_DIO3; shift=SHIFT_DIO3; regaddr=REG_DIOMAPPING1; 
break;
+   mask = MASK_DIO3; shift = SHIFT_DIO3; regaddr = REG_DIOMAPPING1;
+   break;
case 4:
-   mask=MASK_DIO4; shift=SHIFT_DIO4; regaddr=REG_DIOMAPPING2; 
break;
+   mask = MASK_DIO4; shift = SHIFT_DIO4; regaddr = REG_DIOMAPPING2;
+   break;
case 5:
-   mask=MASK_DIO5; shift=SHIFT_DIO5; regaddr=REG_DIOMAPPING2; 
break;
+   mask = MASK_DIO5; shift = SHIFT_DIO5; regaddr = REG_DIOMAPPING2;
+   break;
default:
dev_dbg(>dev, "set: illegal input param");
return -EINVAL;
}
 
// read reg
-   regValue=READ_REG(regaddr);
+   regValue = READ_REG(regaddr);
// delete old value
regValue = regValue & ~mask;
// add new value
@@ -960,7 +966,7 @@ int rf69_read_fifo (struct spi_device *spi, u8 *buffer, 
unsigned int size)
retval = spi_sync_transfer(spi, , 1);
 
#ifdef DEBUG_FIFO_ACCESS
-   for (i=0; idev, "%d - 0x%x\n", i, local_buffer[i+1]);
#endif
 
@@ -988,7 +994,7 @@ int rf69_write_fifo(struct spi_device *spi, u8 *buffer, 
unsigned int size)
memcpy(_buffer[1], buffer, size);  // TODO: ohne memcopy w�re 
sch�ner
 
#ifdef DEBUG_FIFO_ACCESS
-   for (i=0; idev, "0x%x\n",buffer[i]);
#endif
 
-- 
2.14.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/5] staging: pi433: rf69.c style fix - trailing statements

[Marcin Ciupak]

This patch fixes the following checkpatch.pl error:

ERROR: trailing statements should be on next line

in rf69.c file as requested by TODO file.

Note:
ERROR: spaces required around that '=' (ctx:VxV)
remains valid here and is going to be fixed by the next patch in set.

Additionally some style warnings remain valid here and could be fixed by
another patch.

Signed-off-by: Marcin Ciupak 
---
 drivers/staging/pi433/rf69.c | 58 +++-
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 0305edc16861..3d9cf2cac4ef 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -164,9 +164,12 @@ int rf69_set_bit_rate(struct spi_device *spi, u16 bitRate)
 
// transmit to RF 69
retval = WRITE_REG(REG_BITRATE_MSB, msb);
-   if (retval)  return retval;
+   if (retval)
+   return retval;
+
retval = WRITE_REG(REG_BITRATE_LSB, lsb);
-   if (retval)  return retval;
+   if (retval)
+   return retval;
 
return 0;
 }
@@ -209,9 +212,12 @@ int rf69_set_deviation(struct spi_device *spi, u32 
deviation)
 
// write to chip
retval = WRITE_REG(REG_FDEV_MSB, msb);
-   if (retval)  return retval;
+   if (retval)
+   return retval;
+
retval = WRITE_REG(REG_FDEV_LSB, lsb);
-   if (retval)  return retval;
+   if (retval)
+   return retval;
 
return 0;
 }
@@ -252,11 +258,16 @@ int rf69_set_frequency(struct spi_device *spi, u32 
frequency)
 
// write to chip
retval = WRITE_REG(REG_FRF_MSB, msb);
-   if (retval)  return retval;
+   if (retval)
+   return retval;
+
retval = WRITE_REG(REG_FRF_MID, mid);
-   if (retval)  return retval;
+   if (retval)
+   return retval;
+
retval = WRITE_REG(REG_FRF_LSB, lsb);
-   if (retval)  return retval;
+   if (retval)
+   return retval;
 
return 0;
 }
@@ -471,9 +482,15 @@ static int rf69_set_bandwidth_intern(struct spi_device 
*spi, u8 reg,
 
// add new mantisse
switch(mantisse) {
-   case mantisse16: newValue = newValue | BW_MANT_16;  break;
-   case mantisse20: newValue = newValue | BW_MANT_20;  break;
-   case mantisse24: newValue = newValue | BW_MANT_24;  break;
+   case mantisse16:
+   newValue = newValue | BW_MANT_16;
+   break;
+   case mantisse20:
+   newValue = newValue | BW_MANT_20;
+   break;
+   case mantisse24:
+   newValue = newValue | BW_MANT_24;
+   break;
}
 
// add new exponent
@@ -571,12 +588,18 @@ int rf69_set_dio_mapping(struct spi_device *spi, u8 
DIONumber, u8 value)
#endif
 
switch (DIONumber) {
-   case 0: mask=MASK_DIO0; shift=SHIFT_DIO0; regaddr=REG_DIOMAPPING1; 
break;
-   case 1: mask=MASK_DIO1; shift=SHIFT_DIO1; regaddr=REG_DIOMAPPING1; 
break;
-   case 2: mask=MASK_DIO2; shift=SHIFT_DIO2; regaddr=REG_DIOMAPPING1; 
break;
-   case 3: mask=MASK_DIO3; shift=SHIFT_DIO3; regaddr=REG_DIOMAPPING1; 
break;
-   case 4: mask=MASK_DIO4; shift=SHIFT_DIO4; regaddr=REG_DIOMAPPING2; 
break;
-   case 5: mask=MASK_DIO5; shift=SHIFT_DIO5; regaddr=REG_DIOMAPPING2; 
break;
+   case 0:
+   mask=MASK_DIO0; shift=SHIFT_DIO0; regaddr=REG_DIOMAPPING1; 
break;
+   case 1:
+   mask=MASK_DIO1; shift=SHIFT_DIO1; regaddr=REG_DIOMAPPING1; 
break;
+   case 2:
+   mask=MASK_DIO2; shift=SHIFT_DIO2; regaddr=REG_DIOMAPPING1; 
break;
+   case 3:
+   mask=MASK_DIO3; shift=SHIFT_DIO3; regaddr=REG_DIOMAPPING1; 
break;
+   case 4:
+   mask=MASK_DIO4; shift=SHIFT_DIO4; regaddr=REG_DIOMAPPING2; 
break;
+   case 5:
+   mask=MASK_DIO5; shift=SHIFT_DIO5; regaddr=REG_DIOMAPPING2; 
break;
default:
dev_dbg(>dev, "set: illegal input param");
return -EINVAL;
@@ -686,7 +709,8 @@ int rf69_set_preamble_length(struct spi_device *spi, u16 
preambleLength)
 
/* transmit to chip */
retval = WRITE_REG(REG_PREAMBLE_MSB, msb);
-   if (retval) return retval;
+   if (retval)
+   return retval;
return WRITE_REG(REG_PREAMBLE_LSB, lsb);
 }
 
-- 
2.14.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/5] staging: pi433: rf69.c coding style errors cleanup

[Marcin Ciupak]

This set of patches is intended to fix coding style errors in rf69.c file
in order to comply with kernel coding style guide as requested by TODO
file.

The following errors were fixed:
ERROR: trailing statements should be on next line
ERROR: spaces required around that '+=' (ctx:WxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that ',' (ctx:WxV)
ERROR: space prohibited before that close parenthesis ')'
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required before the open parenthesis '('
ERROR: code indent should use tabs where possible
ERROR: "(foo*)" should be "(foo *)"

Marcin Ciupak (5):
  staging: pi433: rf69.c style fix - trailing statements
  staging: pi433: rf69.c style fix - spaces required around
  staging: pi433: rf69.c style fix - spaces before/after
  staging: pi433: rf69.c style fix - code indent should use tabs
  staging: pi433: rf69.c style fix - space before asterisk

 drivers/staging/pi433/rf69.c | 232 ---
 1 file changed, 131 insertions(+), 101 deletions(-)

-- 
2.14.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

[kbuild test robot]

Hi Shreeya,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.14-rc4 next-20171009]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Shreeya-Patel/Staging-rtlwifi-Remove-NULL-pointer-dereference/20171012-021213
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/staging//rtlwifi/base.c: In function 'rtl_get_tcb_desc':
>> drivers/staging//rtlwifi/base.c:778:26: warning: 'sta_entry' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
   (sta_entry ? sta_entry->wireless_mode : \
 ^~
   drivers/staging//rtlwifi/base.c:784:23: note: 'sta_entry' was declared here
 struct rtl_sta_info *sta_entry;
  ^

vim +/sta_entry +778 drivers/staging//rtlwifi/base.c

56bde846 Ping-Ke Shih  2017-08-17  770  
56bde846 Ping-Ke Shih  2017-08-17  771  static void 
_rtl_txrate_selectmode(struct ieee80211_hw *hw,
56bde846 Ping-Ke Shih  2017-08-17  772 
struct ieee80211_sta *sta,
56bde846 Ping-Ke Shih  2017-08-17  773 
struct rtl_tcb_desc *tcb_desc)
56bde846 Ping-Ke Shih  2017-08-17  774  {
56bde846 Ping-Ke Shih  2017-08-17  775  #define SET_RATE_ID(rate_id)
\
56bde846 Ping-Ke Shih  2017-08-17  776  ((rtlpriv->cfg->spec_ver & 
RTL_SPEC_NEW_RATEID) ?   \
56bde846 Ping-Ke Shih  2017-08-17  777  
rtl_mrate_idx_to_arfr_id(hw, rate_id,   \
56bde846 Ping-Ke Shih  2017-08-17 @778  (sta_entry ? 
sta_entry->wireless_mode : \
56bde846 Ping-Ke Shih  2017-08-17  779   
WIRELESS_MODE_G)) :\
56bde846 Ping-Ke Shih  2017-08-17  780  rate_id)
56bde846 Ping-Ke Shih  2017-08-17  781  
56bde846 Ping-Ke Shih  2017-08-17  782  struct rtl_priv *rtlpriv = 
rtl_priv(hw);
56bde846 Ping-Ke Shih  2017-08-17  783  struct rtl_mac *mac = 
rtl_mac(rtl_priv(hw));
f651dc66 Shreeya Patel 2017-10-10  784  struct rtl_sta_info *sta_entry;
56bde846 Ping-Ke Shih  2017-08-17  785  u8 ratr_index = 
SET_RATE_ID(RATR_INX_WIRELESS_MC);
56bde846 Ping-Ke Shih  2017-08-17  786  
56bde846 Ping-Ke Shih  2017-08-17  787  if (sta) {
56bde846 Ping-Ke Shih  2017-08-17  788  sta_entry = (struct 
rtl_sta_info *)sta->drv_priv;
56bde846 Ping-Ke Shih  2017-08-17  789  ratr_index = 
sta_entry->ratr_index;
56bde846 Ping-Ke Shih  2017-08-17  790  }
56bde846 Ping-Ke Shih  2017-08-17  791  if 
(!tcb_desc->disable_ratefallback || !tcb_desc->use_driver_rate) {
56bde846 Ping-Ke Shih  2017-08-17  792  if (mac->opmode == 
NL80211_IFTYPE_STATION) {
56bde846 Ping-Ke Shih  2017-08-17  793  
tcb_desc->ratr_index = 0;
56bde846 Ping-Ke Shih  2017-08-17  794  } else if (mac->opmode 
== NL80211_IFTYPE_ADHOC ||
56bde846 Ping-Ke Shih  2017-08-17  795  
mac->opmode == NL80211_IFTYPE_MESH_POINT) {
56bde846 Ping-Ke Shih  2017-08-17  796  if 
(tcb_desc->multicast || tcb_desc->broadcast) {
56bde846 Ping-Ke Shih  2017-08-17  797  
tcb_desc->hw_rate =
56bde846 Ping-Ke Shih  2017-08-17  798  
rtlpriv->cfg->maps[RTL_RC_CCK_RATE2M];
56bde846 Ping-Ke Shih  2017-08-17  799  
tcb_desc->use_driver_rate = 1;
56bde846 Ping-Ke Shih  2017-08-17  800  
tcb_desc->ratr_index =
56bde846 Ping-Ke Shih  2017-08-17  801  
SET_RATE_ID(RATR_INX_WIRELESS_MC);
56bde846 Ping-Ke Shih  2017-08-17  802  } else {
56bde846 Ping-Ke Shih  2017-08-17  803  
tcb_desc->ratr_index = ratr_index;
56bde846 Ping-Ke Shih  2017-08-17  804  }
56bde846 Ping-Ke Shih  2017-08-17  805  } else if (mac->opmode 
== NL80211_IFTYPE_AP) {
56bde846 Ping-Ke Shih  2017-08-17  806  
tcb_desc->ratr_index = ratr_index;
56bde846 Ping-Ke Shih  2017-08-17  807  }
56bde846 Ping-Ke Shih  2017-08-17  808  }
56bde846 Ping-Ke Shih  2017-08-17  809  
56bde846 Ping-Ke Shih  2017-08-17  810  if (rtlpriv->dm.useramask) {
56bde846 Ping-Ke Shih  2017-08-17 

Re: Two rtlwifi drivers?

[Larry Finger]

On 10/11/2017 08:13 AM, Greg Kroah-Hartman wrote:

On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote:

(Sorry for taking so long with the reply, I wanted first to check what
the rtlwifi in staging contains.)

Larry Finger  writes:


On 08/24/2017 07:14 AM, Kalle Valo wrote:

Dan Carpenter  writes:


Smatch is distrustful of the "capab" value and marks it as user
controlled.  I think it actually comes from the firmware?  Anyway, I
looked at other drivers and they added a bounds check and it seems like
a harmless thing to have so I have added it here as well.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
index f7f207cbaee3..a30b928d5ee1 100644
--- a/drivers/staging/rtlwifi/base.c
+++ b/drivers/staging/rtlwifi/base.c


I'm getting slightly annoyed that we now apparently have two duplicate
rtlwifi drivers (with the same name!) and I'm being spammed by staging
patches. Was this really a smart thing to do? And what will be the
future of these two drivers?

(Of course this is not directed to Dan, he is just fixing bugs found by
smatch, but more like a general question.)


That was the decision that you and Greg made. The version in
wireless-drivers needs many patches to handle the new device. The
progress in applying these to wireless-drivers was very slow for many
reasons. Keeping a single version of that code would have required
coordination between you and Greg, which was discouraged.


I don't recall deciding anything, all I did was asking for more info
about the new code. I was against the idea since I first saw your mail
but I tried to be diplomatic and not shot it down immeadiately. Shows
that diplomacy is not really my thing...

We always take extra measures to avoid forking code, why is it now all
of sudden ok? Also this gives the wrong message to Realtek, and other
vendors, that they can just fork the driver and push all sort of crap to
staging.

So just to make clear to everyone: I think forking drivers like this is
a HORRIBLE idea and I do not want to have anything to do with that. If
schedule goes over quality then a much better approach is to move to the
whole driver to staging than to have duplicated drivers like we have
now.


I think it's horrid too.  But, if no one is able to do the real work
here, we hurt users who just need to use their hardware to get things
done.

And it seems like the company isn't willing to do the real work, so
dumping this in staging is the best we can do at the moment.

However, if this causes you problems, that's not good at all either.
Getting "real" support for this hardware is key, and hopefully can
happen somehow.  But fixing up the staging driver is almost never the
way to do it, as you know :)

So what to do?  Any ideas?  What makes your life easier?  You can just
ignore the staging tree, as it should not affect your portion of the
kernel at all, right?


Greg and Kalle,

We can all agree that this situation is bad; however, several of the points made 
in your E-mails need to be addressed.


First of all, I am not an employee of Realtek, and I have no knowledge of the 
internals of any of their chips. I have never signed a non-disclosure agreement, 
and the only thing that I have received from them are sample chips for testing. 
My main interest is in helping the user experience. As there are a number of 
users with the new RTL8822BE device, that meant getting an in-kernel driver to 
them as soon as possible. As stated earlier, adding this particular device to 
the rtlwifi family involved roughly 120K lines of new code. Given our recent 
experience in getting code accepted into the wireless tree meant that this 
additional code would not have been accepted for many months. For that reason, 
we chose the staging route. It is important that we get this right as Realtek 
tells me that there will be two additional new drivers in the coming 6 months.


As to the convergence of the rtlwifi code between staging and wireless, I 
applied the 40 or 50 patches in my queue to the wireless version to create the 
version that went into staging. If any of the current patches to wireless do not 
seem to be in the staging version, sometimes temporary changes are necessary so 
that the intermediate drivers will build and work. Yes, it is code churn, but 
necessary to keep patches small. In keeping with Kalle's requests, only a 
fraction of those patches have been submitted to him.


My intent is to have the RTL8822BE driver moved from staging to mainline no 
later than 4.17. The affected drivers rtl_pci, rtlwifi and becoex will be moved 
in that order. Of course, the required changes will need to be in wireless 
before staging is changed, which will slow the process. As I see it, the switch 
can only occur with a new version.


My opinion is that the company has gone a long ways toward meeting the 
requirements of the Linux 

RE: [PATCH 1/1] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

[KY Srinivasan]

Thanks Dan. Will do.

K. Y

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Wednesday, October 11, 2017 2:42 AM
> To: KY Srinivasan 
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; jasow...@redhat.com;
> leann.ogasaw...@canonical.com; marcelo.ce...@canonical.com; Stephen
> Hemminger ; Haiyang Zhang
> 
> Subject: Re: [PATCH 1/1] vmbus: hvsock: add proper sync for
> vmbus_hvsock_device_unregister()
> 
> On Tue, Oct 10, 2017 at 10:38:51PM -0700, k...@exchange.microsoft.com
> wrote:
> > From: Dexuan Cui 
> >
> > Without the patch, vmbus_hvsock_device_unregister() can destroy the
> device
> > prematurely when close() is called, and can cause NULl dereferencing or
> > potential data loss (the last portion of the data stream may be dropped
> > prematurely).
> >
> > Please consider this for 4.14.
> 
> Put these meta comments under the --- cut off line.  They don't add
> any value to the final upstream git log.
> 
> >
> > Signed-off-by: Dexuan Cui 
> > Cc: Haiyang Zhang 
> > Cc: Stephen Hemminger 
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  drivers/hv/channel_mgmt.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> 
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Two rtlwifi drivers?

[Dan Carpenter]

On Wed, Oct 11, 2017 at 03:13:10PM +0200, Greg Kroah-Hartman wrote:
> And it seems like the company isn't willing to do the real work, so
> dumping this in staging is the best we can do at the moment.

I'm more optimistic.  There are a lot of @realtek.com addresses in the
CC list and that's a new thing.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state

[Dan Carpenter]

On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote:
> I assume it's easy to produce an actual failure here?  Why haven't we
> seen bug reports about this?

The bug was detected with static analysis.  You have to enable a debug
feature in the .config if you want sleeping with spinlock held warnings.
Otherwise you'd have to hit the deadlock and you have to be pretty
unlucky to hit it so these bugs sometimes do go unreported for a long
time.

regards,
dan carpenter


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 7/9] staging: fsl-dpaa2/eth: Use implicit clear of link interrupt

[Ioana Radulescu]

dpni_get_irq_status() also looks at the input value of its
status parameter, and if not null it automatically clears
from pending state the bits that are set there.

Use this feature to avoid a separate MC command for clearing
the interrupt event bits after reading the status.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 6540ab0..3a8bad1 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -2332,7 +2332,7 @@ static irqreturn_t dpni_irq0_handler(int irq_num, void 
*arg)
 
 static irqreturn_t dpni_irq0_handler_thread(int irq_num, void *arg)
 {
-   u32 status = 0, clear = 0;
+   u32 status = ~0;
struct device *dev = (struct device *)arg;
struct fsl_mc_device *dpni_dev = to_fsl_mc_device(dev);
struct net_device *net_dev = dev_get_drvdata(dev);
@@ -2342,18 +2342,12 @@ static irqreturn_t dpni_irq0_handler_thread(int 
irq_num, void *arg)
  DPNI_IRQ_INDEX, );
if (unlikely(err)) {
netdev_err(net_dev, "Can't get irq status (err %d)\n", err);
-   clear = 0x;
-   goto out;
+   return IRQ_HANDLED;
}
 
-   if (status & DPNI_IRQ_EVENT_LINK_CHANGED) {
-   clear |= DPNI_IRQ_EVENT_LINK_CHANGED;
+   if (status & DPNI_IRQ_EVENT_LINK_CHANGED)
link_state_update(netdev_priv(net_dev));
-   }
 
-out:
-   dpni_clear_irq_status(dpni_dev->mc_io, 0, dpni_dev->mc_handle,
- DPNI_IRQ_INDEX, clear);
return IRQ_HANDLED;
 }
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 9/9] staging: fsl-dpaa2/eth: Add firmware version

[Ioana Radulescu]

Include firmware version in the driver information exported
through ethtool.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-ethtool.c | 14 +-
 drivers/staging/fsl-dpaa2/ethernet/dpni-cmd.h  |  5 
 drivers/staging/fsl-dpaa2/ethernet/dpni.c  | 32 ++
 drivers/staging/fsl-dpaa2/ethernet/dpni.h  |  5 
 4 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-ethtool.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-ethtool.c
index 031179a..ebe8fd6 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-ethtool.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-ethtool.c
@@ -76,10 +76,22 @@ static char dpaa2_ethtool_extras[][ETH_GSTRING_LEN] = {
 static void dpaa2_eth_get_drvinfo(struct net_device *net_dev,
  struct ethtool_drvinfo *drvinfo)
 {
+   struct dpaa2_eth_priv *priv = netdev_priv(net_dev);
+   u16 fw_major, fw_minor;
+   int err;
+
strlcpy(drvinfo->driver, KBUILD_MODNAME, sizeof(drvinfo->driver));
strlcpy(drvinfo->version, dpaa2_eth_drv_version,
sizeof(drvinfo->version));
-   strlcpy(drvinfo->fw_version, "N/A", sizeof(drvinfo->fw_version));
+
+   err =  dpni_get_api_version(priv->mc_io, 0, _major, _minor);
+   if (!err)
+   snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+"%u.%u", fw_major, fw_minor);
+   else
+   strlcpy(drvinfo->fw_version, "N/A",
+   sizeof(drvinfo->fw_version));
+
strlcpy(drvinfo->bus_info, dev_name(net_dev->dev.parent->parent),
sizeof(drvinfo->bus_info));
 }
diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpni-cmd.h 
b/drivers/staging/fsl-dpaa2/ethernet/dpni-cmd.h
index 57df222..3120e22 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpni-cmd.h
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpni-cmd.h
@@ -538,4 +538,9 @@ struct dpni_rsp_get_taildrop {
__le32 threshold;
 };
 
+struct dpni_rsp_get_api_version {
+   u16 major;
+   u16 minor;
+};
+
 #endif /* _FSL_DPNI_CMD_H */
diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpni.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpni.c
index 04a5b14..e8be761 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpni.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpni.c
@@ -1594,3 +1594,35 @@ int dpni_get_taildrop(struct fsl_mc_io *mc_io,
 
return 0;
 }
+
+/**
+ * dpni_get_api_version() - Get Data Path Network Interface API version
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @major_ver: Major version of data path network interface API
+ * @minor_ver: Minor version of data path network interface API
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpni_get_api_version(struct fsl_mc_io *mc_io,
+u32 cmd_flags,
+u16 *major_ver,
+u16 *minor_ver)
+{
+   struct dpni_rsp_get_api_version *rsp_params;
+   struct mc_command cmd = { 0 };
+   int err;
+
+   cmd.header = mc_encode_cmd_header(DPNI_CMDID_GET_API_VERSION,
+ cmd_flags, 0);
+
+   err = mc_send_command(mc_io, );
+   if (err)
+   return err;
+
+   rsp_params = (struct dpni_rsp_get_api_version *)cmd.params;
+   *major_ver = le16_to_cpu(rsp_params->major);
+   *minor_ver = le16_to_cpu(rsp_params->minor);
+
+   return 0;
+}
diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpni.h 
b/drivers/staging/fsl-dpaa2/ethernet/dpni.h
index 282e5e8..ce86a81 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpni.h
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpni.h
@@ -829,4 +829,9 @@ struct dpni_rule_cfg {
u8  key_size;
 };
 
+int dpni_get_api_version(struct fsl_mc_io *mc_io,
+u32 cmd_flags,
+u16 *major_ver,
+u16 *minor_ver);
+
 #endif /* __FSL_DPNI_H */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/9] staging: fsl-dpaa2/eth: Fix potential endless loop

[Ioana Radulescu]

We incorrectly assumed that dpaa2_io_release() can only
return -EBUSY as an error code, when in fact it can also
fail in case some of its arguments don't have valid values.

Make sure we only retry the operation while the portal is
busy and abort for all other error cases, otherwise we risk
entering an endless loop.

Signed-off-by: Ioana Radulescu 
Signed-off-by: Bogdan Purcareata 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 58 --
 1 file changed, 35 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 26017fe..801ba07 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -718,6 +718,23 @@ static int set_tx_csum(struct dpaa2_eth_priv *priv, bool 
enable)
return 0;
 }
 
+/* Free buffers acquired from the buffer pool or which were meant to
+ * be released in the pool
+ */
+static void free_bufs(struct dpaa2_eth_priv *priv, u64 *buf_array, int count)
+{
+   struct device *dev = priv->net_dev->dev.parent;
+   void *vaddr;
+   int i;
+
+   for (i = 0; i < count; i++) {
+   vaddr = dpaa2_iova_to_virt(priv->iommu_domain, buf_array[i]);
+   dma_unmap_single(dev, buf_array[i], DPAA2_ETH_RX_BUF_SIZE,
+DMA_BIDIRECTIONAL);
+   skb_free_frag(vaddr);
+   }
+}
+
 /* Perform a single release command to add buffers
  * to the specified buffer pool
  */
@@ -727,7 +744,7 @@ static int add_bufs(struct dpaa2_eth_priv *priv, u16 bpid)
u64 buf_array[DPAA2_ETH_BUFS_PER_CMD];
void *buf;
dma_addr_t addr;
-   int i;
+   int i, err;
 
for (i = 0; i < DPAA2_ETH_BUFS_PER_CMD; i++) {
/* Allocate buffer visible to WRIOP + skb shared info +
@@ -754,22 +771,27 @@ static int add_bufs(struct dpaa2_eth_priv *priv, u16 bpid)
}
 
 release_bufs:
-   /* In case the portal is busy, retry until successful.
-* The buffer release function would only fail if the QBMan portal
-* was busy, which implies portal contention (i.e. more CPUs than
-* portals, i.e. GPPs w/o affine DPIOs). For all practical purposes,
-* there is little we can realistically do, short of giving up -
-* in which case we'd risk depleting the buffer pool and never again
-* receiving the Rx interrupt which would kick-start the refill logic.
-* So just keep retrying, at the risk of being moved to ksoftirqd.
-*/
-   while (dpaa2_io_service_release(NULL, bpid, buf_array, i))
+   /* In case the portal is busy, retry until successful */
+   while ((err = dpaa2_io_service_release(NULL, bpid,
+  buf_array, i)) == -EBUSY)
cpu_relax();
+
+   /* If release command failed, clean up and bail out;
+* not much else we can do about it
+*/
+   if (err) {
+   free_bufs(priv, buf_array, i);
+   return 0;
+   }
+
return i;
 
 err_map:
skb_free_frag(buf);
 err_alloc:
+   /* If we managed to allocate at least some buffers,
+* release them to hardware
+*/
if (i)
goto release_bufs;
 
@@ -811,10 +833,8 @@ static int seed_pool(struct dpaa2_eth_priv *priv, u16 bpid)
  */
 static void drain_bufs(struct dpaa2_eth_priv *priv, int count)
 {
-   struct device *dev = priv->net_dev->dev.parent;
u64 buf_array[DPAA2_ETH_BUFS_PER_CMD];
-   void *vaddr;
-   int ret, i;
+   int ret;
 
do {
ret = dpaa2_io_service_acquire(NULL, priv->bpid,
@@ -823,15 +843,7 @@ static void drain_bufs(struct dpaa2_eth_priv *priv, int 
count)
netdev_err(priv->net_dev, "dpaa2_io_service_acquire() 
failed\n");
return;
}
-   for (i = 0; i < ret; i++) {
-   /* Same logic as on regular Rx path */
-   vaddr = dpaa2_iova_to_virt(priv->iommu_domain,
-  buf_array[i]);
-   dma_unmap_single(dev, buf_array[i],
-DPAA2_ETH_RX_BUF_SIZE,
-DMA_FROM_DEVICE);
-   skb_free_frag(vaddr);
-   }
+   free_bufs(priv, buf_array, ret);
} while (ret);
 }
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/9] staging: fsl-dpaa2/eth: Account for Rx FD buffers on error path

[Ioana Radulescu]

On Rx path, if we fail to build an skb from the incoming FD,
we still need to update the channel buffer count accordingly,
otherwise we risk depleting the pool while the software counter
still sees available buffers.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 801ba07..e9fe1c9 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -131,6 +131,8 @@ static struct sk_buff *build_linear_skb(struct 
dpaa2_eth_priv *priv,
u16 fd_offset = dpaa2_fd_get_offset(fd);
u32 fd_length = dpaa2_fd_get_len(fd);
 
+   ch->buf_count--;
+
skb = build_skb(fd_vaddr, DPAA2_ETH_RX_BUF_SIZE +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
if (unlikely(!skb))
@@ -139,8 +141,6 @@ static struct sk_buff *build_linear_skb(struct 
dpaa2_eth_priv *priv,
skb_reserve(skb, fd_offset);
skb_put(skb, fd_length);
 
-   ch->buf_count--;
-
return skb;
 }
 
@@ -178,8 +178,15 @@ static struct sk_buff *build_frag_skb(struct 
dpaa2_eth_priv *priv,
/* We build the skb around the first data buffer */
skb = build_skb(sg_vaddr, DPAA2_ETH_RX_BUF_SIZE +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
-   if (unlikely(!skb))
-   return NULL;
+   if (unlikely(!skb)) {
+   /* We still need to subtract the buffers used
+* by this FD from our software counter
+*/
+   while (!dpaa2_sg_is_final([i]) &&
+  i < DPAA2_ETH_MAX_SG_ENTRIES)
+   i++;
+   break;
+   }
 
sg_offset = dpaa2_sg_get_offset(sge);
skb_reserve(skb, sg_offset);
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/9] staging: fsl-dpaa2/eth: Refactor interrupt arming in NAPI poll

[Ioana Radulescu]

Take into consideration the return value of napi_complete_done(),
since there might be an indication that it's not suitable to
enable driver interrupts yet.

Signed-off-by: Bogdan Purcareata 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index f390de6..a0be9ab 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -948,8 +948,7 @@ static int dpaa2_eth_poll(struct napi_struct *napi, int 
budget)
break;
}
 
-   if (cleaned < budget) {
-   napi_complete_done(napi, cleaned);
+   if (cleaned < budget && napi_complete_done(napi, cleaned)) {
/* Re-enable data available notifications */
do {
err = dpaa2_io_service_rearm(NULL, >nctx);
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/9] staging: fsl-dpaa2/eth: Check SGT final bit is present

[Ioana Radulescu]

For scatter-gather ingress frames, we expect to receive
a list of fragments from the hardware, last of which is
marked with a "final" bit.

Add a check to make sure the Rx frame has this bit set
correctly; there's not much we can do in case of a
malformed frame, but at least issue a warning.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index e9fe1c9..6f009d1 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -213,6 +213,8 @@ static struct sk_buff *build_frag_skb(struct dpaa2_eth_priv 
*priv,
break;
}
 
+   WARN_ONCE(i == DPAA2_ETH_MAX_SG_ENTRIES, "Final bit not set in SGT");
+
/* Count all data buffers + SG table buffer */
ch->buf_count -= i + 2;
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/9] staging: fsl-dpaa2/eth: Check if notification rearm is successful

[Ioana Radulescu]

In case dpaa2_io_service_rearm() fails with an error other then
EBUSY, it will do so silently; add a check for this and a warning
message, as a failure here means we're unable to receive any
more traffic on the current cpu.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 6f009d1..f390de6 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -955,6 +955,8 @@ static int dpaa2_eth_poll(struct napi_struct *napi, int 
budget)
err = dpaa2_io_service_rearm(NULL, >nctx);
cpu_relax();
} while (err == -EBUSY);
+   WARN_ONCE(err, "CDAN notifications rearm failed on core %d",
+ ch->nctx.desired_cpu);
}
 
ch->stats.frames += cleaned;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 8/9] staging: fsl-dpaa2/eth: Don't use netdev_err too early

[Ioana Radulescu]

Early during probe the netdevice name is not initialized yet,
so use dev_err instead of netdev_err when printing error
messages.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 3a8bad1..9fbc0ee 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -2114,7 +2114,7 @@ static int bind_dpni(struct dpaa2_eth_priv *priv)
 */
err = dpaa2_eth_set_hash(net_dev, DPAA2_RXH_SUPPORTED);
if (err)
-   netdev_err(net_dev, "Failed to configure hashing\n");
+   dev_err(dev, "Failed to configure hashing\n");
 
/* Configure handling of error frames */
err_cfg.errors = DPAA2_FAS_RX_ERR_MASK;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 6/9] staging: fsl-dpaa2/eth: Fix double DMA unmap

[Ioana Radulescu]

In case we fail to allocate a skb for a fragmented ingress
frame, the cleanup function will attempt to unmap again the
first frame fragment, which had already been unmapped during
early Rx processing.

Avoid this by freeing the first buffer immediately in case
we hit an error, leaving the cleanup function to free only
the subsequent buffers.

Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index a0be9ab..6540ab0 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -104,9 +104,11 @@ static void free_rx_fd(struct dpaa2_eth_priv *priv,
/* We don't support any other format */
return;
 
-   /* For S/G frames, we first need to free all SG entries */
+   /* For S/G frames, we first need to free all SG entries
+* except the first one, which was taken care of already
+*/
sgt = vaddr + dpaa2_fd_get_offset(fd);
-   for (i = 0; i < DPAA2_ETH_MAX_SG_ENTRIES; i++) {
+   for (i = 1; i < DPAA2_ETH_MAX_SG_ENTRIES; i++) {
addr = dpaa2_sg_get_addr([i]);
sg_vaddr = dpaa2_iova_to_virt(priv->iommu_domain, addr);
dma_unmap_single(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
@@ -179,6 +181,11 @@ static struct sk_buff *build_frag_skb(struct 
dpaa2_eth_priv *priv,
skb = build_skb(sg_vaddr, DPAA2_ETH_RX_BUF_SIZE +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
if (unlikely(!skb)) {
+   /* Free the first SG entry now, since we already
+* unmapped it and obtained the virtual address
+*/
+   skb_free_frag(sg_vaddr);
+
/* We still need to subtract the buffers used
 * by this FD from our software counter
 */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Two rtlwifi drivers?

[Greg Kroah-Hartman]

On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote:
> (Sorry for taking so long with the reply, I wanted first to check what
> the rtlwifi in staging contains.)
> 
> Larry Finger  writes:
> 
> > On 08/24/2017 07:14 AM, Kalle Valo wrote:
> >> Dan Carpenter  writes:
> >>
> >>> Smatch is distrustful of the "capab" value and marks it as user
> >>> controlled.  I think it actually comes from the firmware?  Anyway, I
> >>> looked at other drivers and they added a bounds check and it seems like
> >>> a harmless thing to have so I have added it here as well.
> >>>
> >>> Signed-off-by: Dan Carpenter 
> >>>
> >>> diff --git a/drivers/staging/rtlwifi/base.c 
> >>> b/drivers/staging/rtlwifi/base.c
> >>> index f7f207cbaee3..a30b928d5ee1 100644
> >>> --- a/drivers/staging/rtlwifi/base.c
> >>> +++ b/drivers/staging/rtlwifi/base.c
> >>
> >> I'm getting slightly annoyed that we now apparently have two duplicate
> >> rtlwifi drivers (with the same name!) and I'm being spammed by staging
> >> patches. Was this really a smart thing to do? And what will be the
> >> future of these two drivers?
> >>
> >> (Of course this is not directed to Dan, he is just fixing bugs found by
> >> smatch, but more like a general question.)
> >
> > That was the decision that you and Greg made. The version in
> > wireless-drivers needs many patches to handle the new device. The
> > progress in applying these to wireless-drivers was very slow for many
> > reasons. Keeping a single version of that code would have required
> > coordination between you and Greg, which was discouraged.
> 
> I don't recall deciding anything, all I did was asking for more info
> about the new code. I was against the idea since I first saw your mail
> but I tried to be diplomatic and not shot it down immeadiately. Shows
> that diplomacy is not really my thing...
> 
> We always take extra measures to avoid forking code, why is it now all
> of sudden ok? Also this gives the wrong message to Realtek, and other
> vendors, that they can just fork the driver and push all sort of crap to
> staging.
> 
> So just to make clear to everyone: I think forking drivers like this is
> a HORRIBLE idea and I do not want to have anything to do with that. If
> schedule goes over quality then a much better approach is to move to the
> whole driver to staging than to have duplicated drivers like we have
> now.

I think it's horrid too.  But, if no one is able to do the real work
here, we hurt users who just need to use their hardware to get things
done.

And it seems like the company isn't willing to do the real work, so
dumping this in staging is the best we can do at the moment.

However, if this causes you problems, that's not good at all either.
Getting "real" support for this hardware is key, and hopefully can
happen somehow.  But fixing up the staging driver is almost never the
way to do it, as you know :)

So what to do?  Any ideas?  What makes your life easier?  You can just
ignore the staging tree, as it should not affect your portion of the
kernel at all, right?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

[Shreeya Patel]

On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote:
> On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote:
> > 
> > Remove NULL pointer dereference as it results in undefined
> > behaviour, and will usually lead to a runtime error.
> The diff does not show any pointer dereference so it is hard to
> understand what you are trying to do
> with this patch.
> 
> > 
> > Signed-off-by: Shreeya Patel 
> > ---
> >  drivers/staging/rtlwifi/base.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/rtlwifi/base.c
> > b/drivers/staging/rtlwifi/base.c
> > index b88b0e8..5bb8f98 100644
> > --- a/drivers/staging/rtlwifi/base.c
> > +++ b/drivers/staging/rtlwifi/base.c
> > @@ -781,7 +781,7 @@ static void _rtl_txrate_selectmode(struct
> > ieee80211_hw *hw,
> >  
> >     struct rtl_priv *rtlpriv = rtl_priv(hw);
> >     struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
> > -   struct rtl_sta_info *sta_entry = NULL;
> > +   struct rtl_sta_info *sta_entry;
> Now the pointer just has garbage in it instead of the testable value
> of NULL. If you are concerned
> with the dereference perhaps you could add a NULL check, again it's
> hard to say without seeing the
> code.

Hello, 

Thanks for making me understand. 

Here is the code after declaration and initialization of sta_entry. 
Will it be good to add a NULL check in this case? 

struct rtl_sta_info *sta_entry = NULL;
u8 ratr_index = SET_RATE_ID(RATR_INX_WIRELESS_MC);

if (sta) {
sta_entry = (struct rtl_sta_info *)sta->drv_priv;
ratr_index = sta_entry->ratr_index;
}

If we are making a pointer point to NULL then what if any other
variable is already pointing to NULL for some other purpose.
Instead, removing initialization will be good right?


> 
> It is hard to see how this patch is correct though.
> 
> Hope this helps,
> Tobin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

[Dan Carpenter]

On Tue, Oct 10, 2017 at 10:38:51PM -0700, k...@exchange.microsoft.com wrote:
> From: Dexuan Cui 
> 
> Without the patch, vmbus_hvsock_device_unregister() can destroy the device
> prematurely when close() is called, and can cause NULl dereferencing or
> potential data loss (the last portion of the data stream may be dropped
> prematurely).
> 
> Please consider this for 4.14.

Put these meta comments under the --- cut off line.  They don't add
any value to the final upstream git log.

> 
> Signed-off-by: Dexuan Cui 
> Cc: Haiyang Zhang 
> Cc: Stephen Hemminger 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/hv/channel_mgmt.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)


regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Two rtlwifi drivers?

[Kalle Valo]

(Sorry for taking so long with the reply, I wanted first to check what
the rtlwifi in staging contains.)

Larry Finger  writes:

> On 08/24/2017 07:14 AM, Kalle Valo wrote:
>> Dan Carpenter  writes:
>>
>>> Smatch is distrustful of the "capab" value and marks it as user
>>> controlled.  I think it actually comes from the firmware?  Anyway, I
>>> looked at other drivers and they added a bounds check and it seems like
>>> a harmless thing to have so I have added it here as well.
>>>
>>> Signed-off-by: Dan Carpenter 
>>>
>>> diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
>>> index f7f207cbaee3..a30b928d5ee1 100644
>>> --- a/drivers/staging/rtlwifi/base.c
>>> +++ b/drivers/staging/rtlwifi/base.c
>>
>> I'm getting slightly annoyed that we now apparently have two duplicate
>> rtlwifi drivers (with the same name!) and I'm being spammed by staging
>> patches. Was this really a smart thing to do? And what will be the
>> future of these two drivers?
>>
>> (Of course this is not directed to Dan, he is just fixing bugs found by
>> smatch, but more like a general question.)
>
> That was the decision that you and Greg made. The version in
> wireless-drivers needs many patches to handle the new device. The
> progress in applying these to wireless-drivers was very slow for many
> reasons. Keeping a single version of that code would have required
> coordination between you and Greg, which was discouraged.

I don't recall deciding anything, all I did was asking for more info
about the new code. I was against the idea since I first saw your mail
but I tried to be diplomatic and not shot it down immeadiately. Shows
that diplomacy is not really my thing...

We always take extra measures to avoid forking code, why is it now all
of sudden ok? Also this gives the wrong message to Realtek, and other
vendors, that they can just fork the driver and push all sort of crap to
staging.

So just to make clear to everyone: I think forking drivers like this is
a HORRIBLE idea and I do not want to have anything to do with that. If
schedule goes over quality then a much better approach is to move to the
whole driver to staging than to have duplicated drivers like we have
now.

> The future, as stated in the TODO in staging, is to merge all the
> changes in the support drivers into wireless-drivers, and then move
> the new RTL8822BE driver out of staging.

And how many years will that take? (If that will ever happen) Also I see
that multiple patches are applied to staging version of rtlwifi which is
not in net version of rtlwifi. That all should be synced somehow, the
bigger the delta becomes the more difficult everything is.

> I'm sorry about the fallout affecting you, and I probably should have
> changed the directory names. In any case, ignore any patches that
> belong in staging. If I see any that do not include GregKH in the "To"
> list, I will NACK them and request proper routing.

Thanks, but that doesn't really help as I apply patches from patchwork
and it doesn't show the To field. I'll try to be extra careful and not
apply patches the staging version of rtlwifi patches, but mistakes
always happen.

-- 
Kalle Valo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel