Re: [PATCH] bcm2835-audio: Fix checkpatch errors

[Man Choy]

On Mon, Feb 13, 2017 at 8:03 PM, Greg Kroah-Hartman
 wrote:
> On Mon, Feb 13, 2017 at 08:49:06AM +0800, Man Choy wrote:
>> A quick question, I just updated my linux-next tree last night,
>> checkout tag "next-20170210" and working on the cleanup. How do I
>> double check my current working file already been updated by someone
>> else to avoid the duplicate work? As of now, the latest linux-next
>> tree tag is still "next-20170210"
>
> linux-next is usually a day or so behind my tree, due to the time
> differences when it is created and why I usually do work.
>
> You can work off of my staging-next branch in my staging.git tree on
> git.kernel.org, that is the most up-to-date branch that ends up in
> linux-next.  I also use staging-testing, to test things, but I would not
> recommend that for you as it can be rebased and would be a pain to work
> against.
>
> It's ok that conflicts happen, that's how kernel development works,
> sometimes people send in the same change minutes from each other, so I
> have to take the one that was sent first.  It's ok, just move on and
> work on something else if you really want to.
>
>> I am on eudyptula challenge and this is my first attempt to send
>> kernel patch, sorry about the silly question ;)
>
> It's not silly, it comes up all the time.
>
> good luck!
>
> greg k-h

Thanks for the kind advice.

I will look up your staging-next branch and do something about it.

Talk to you soon.

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

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Steve Longerbeam]

(#!##* Thunderbird! resending text only)

Hi Philipp,


On 02/13/2017 01:20 AM, Philipp Zabel wrote:

Hi Steve,

On Thu, 2017-02-09 at 15:51 -0800, Steve Longerbeam wrote:

On 02/09/2017 03:49 PM, Steve Longerbeam wrote:

On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:

On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:

Actually, this exact function already exists as
dw_mipi_dsi_phy_write in
drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY
register 0x44 might contain a field called HSFREQRANGE_SEL.

Thanks for pointing out drivers/gpu/drm/rockchip/dw-mipi-dsi.c.
It's clear from that driver that there probably needs to be a fuller
treatment of the D-PHY programming here, but I don't know where
to find the MIPI CSI-2 D-PHY documentation for the i.MX6. The code
in imxcsi2_reset() was also pulled from FSL, and that's all I really
have
to go on for the D-PHY programming. I assume the D-PHY is also a
Synopsys core, like the host controller, but the i.MX6 manual doesn't
cover it.

Why exactly?  What problems are you seeing that would necessitate a
more detailed programming of the D-PHY?  From my testing, I can wind
a 2-lane MIPI bus on iMX6D from 912Mbps per lane down to (eg) 308Mbps
per lane with your existing code without any issues.

That's good to hear.

Just from my experience with struggles to get the CSI2 receiver
up and running with an active clock lane, and my suspicions that
some of that could be due to my lack of understanding of the D-PHY
programming.

But I should add that after a re-org of the sequence, it looks more stable
now. Tested on both the SabreSD and SabreLite with the OV5640.

It seems the OV5640 driver never puts its the CSI-2 lanes into stop
state while not streaming.


Yes I found that as well.

But good news, I finally managed to coax the OV5640's clock lane
into LP-11 state! It was accomplished by setting bit 5 in OV5640 register
0x4800. The datasheet describes this bit as "Gate clock lane when no
packet to transmit". But I may have also got this to work with the 
additional

write 1 to bits 4-6 in register 0x3019 ("MIPI CLK/data lane state in sleep
mode" - setting 1 to these bits selects LP-11 for sleep mode).

So I am now finally able to call csi2_dphy_wait_stopstate() in
csi2_s_stream(ON).

So for the TC35874, you shouldn't see a timeout in csi2_s_stream(ON)
any longer.

I have updated both ov5640.c and imx6-mipi-csi2.c in the wip branch.
Can you try again? I have not applied your patch below, because I
don't think that is needed anymore.

And speaking of the TC35874, I received this module for the SabreLite
from Boundary Devices (thanks BD!). So I can finally help you with
debug/test. Are there any patches you need to send to me (against
wip branch) for this support, or can I use what exists now in media
tree? Also any scripts or help with running.



  With the recent s_stream reordering,
streaming from TC358743 does not work anymore, since imx6-mipi-csi2
s_stream is called before tc358743 s_stream, while all lanes are still
in stop state. Then it waits for the clock lane to become active and
fails. I have applied the following patch to revert the reordering
locally to get it to work again.

The initialization order, as Russell pointed out, should be:

1. reset the D-PHY.
2. place MIPI sensor in LP-11 state
3. perform D-PHY initialisation
4. configure CSI2 lanes and de-assert resets and shutdown signals

So csi2_s_stream should wait for stop state on all lanes (the result of
2.) before dphy_init (3.), not wait for active clock afterwards. That
should happen only after sensor_s_stream was called. So unless we are
allowed to reorder steps 1. and 2., we might need the prepare_stream
callback after all.


Agreed!

See my new FIXME comment in imx6-mipi-csi2.c.

I agree we might need a new subdev op .prepare_stream(). This
op would be implemented by imx6-mipi-csi2.c, and would carry
out steps 3, 4, 5 (instead of currently by csi2_s_stream()). Then
step 6 would finally become available as csi2_s_stream().

And then we must re-order stream on to start sensor first, then
csi2, as in your patch below.

Steve


More specifically, the chapter 40.3.1 "Startup Sequence" in the i.MX6DQ
reference manual states:

1. Deassert presetn signal (global reset)
- This is probably the APB global reset, so not something we have to
  care about.
2. Configure MIPI Camera Sensor to put all Tx lanes in PL-11 state
3. D-PHY initialization (write 0x14 to address 0x44)
4. CSI2 Controller programming
- Set N_LANES
- Deassert PHY_SHUTDOWNZ
- Deassert PHY_RSTZ
- Deassert CSI2_RESETN
5. Read the PHY status register (PHY_STATE) to confirm that all data and
clock lanes of the D-PHY are in Stop State
6. Configure the MIPI Camera Sensor to start transmitting a clock on the
D-PHY clock lane
7. CSI2 Controller programming - Read the PHY status register
(PHY_STATE) to confirm that the D-PHY is receiving a clock on the
D-PHY clock lane

2. 

[PATCH 04/15] staging: rtl8192u: blank lines aren't necessary before a close brace '}'

[simran singhal]

Fix checkpatch issues: "CHECK: Blank lines aren't necessary before a
close brace '}'".

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index 814ab5a..2481c21 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -623,7 +623,6 @@ int ieee80211_wx_set_encode_ext(struct ieee80211_device 
*ieee,
goto done;
}
*crypt = new_crypt;
-
}
 
if (ext->key_len > 0 && (*crypt)->ops->set_key &&
@@ -725,7 +724,6 @@ int ieee80211_wx_get_encode_ext(struct ieee80211_device 
*ieee,
(ext->alg == IW_ENCODE_ALG_TKIP ||
 ext->alg == IW_ENCODE_ALG_CCMP))
ext->ext_flags |= IW_ENCODE_EXT_TX_SEQ_VALID;
-
}
 
return 0;
@@ -839,6 +837,5 @@ int ieee80211_wx_set_gen_ie(struct ieee80211_device *ieee, 
u8 *ie, size_t len)
ieee->wpa_ie_len = 0;
}
return 0;
-
 }
 EXPORT_SYMBOL(ieee80211_wx_set_gen_ie);
-- 
2.7.4

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

[PATCH 03/15] staging: rtl8192u: Adding space after enum and struct definition

[simran singhal]

Fixes checkpatch.pl warning:
WARNING: missing space after struct definition
WARNING: missing space after enum definition

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 38 -
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
index c3aabba..5f54d93 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
@@ -35,7 +35,7 @@
 #define HT_SUPPORTED_MCS_1SS_2SS_BITMAP
HT_MCS_1SS_BITMAP|HT_MCS_1SS_2SS_BITMAP
 
 
-typedef enum _HT_MCS_RATE{
+typedef enum _HT_MCS_RATE {
HT_MCS0   = 0x0001,
HT_MCS1   = 0x0002,
HT_MCS2   = 0x0004,
@@ -58,7 +58,7 @@ typedef enum _HT_MCS_RATE{
 //
 // Represent Channel Width in HT Capabilities
 //
-typedef enum _HT_CHANNEL_WIDTH{
+typedef enum _HT_CHANNEL_WIDTH {
HT_CHANNEL_WIDTH_20 = 0,
HT_CHANNEL_WIDTH_20_40 = 1,
 }HT_CHANNEL_WIDTH, *PHT_CHANNEL_WIDTH;
@@ -67,14 +67,14 @@ typedef enum _HT_CHANNEL_WIDTH{
 // Represent Extension Channel Offset in HT Capabilities
 // This is available only in 40Mhz mode.
 //
-typedef enum _HT_EXTCHNL_OFFSET{
+typedef enum _HT_EXTCHNL_OFFSET {
HT_EXTCHNL_OFFSET_NO_EXT = 0,
HT_EXTCHNL_OFFSET_UPPER = 1,
HT_EXTCHNL_OFFSET_NO_DEF = 2,
HT_EXTCHNL_OFFSET_LOWER = 3,
 }HT_EXTCHNL_OFFSET, *PHT_EXTCHNL_OFFSET;
 
-typedef enum _CHNLOP{
+typedef enum _CHNLOP {
CHNLOP_NONE = 0, // No Action now
CHNLOP_SCAN = 1, // Scan in progress
CHNLOP_SWBW = 2, // Bandwidth switching in progress
@@ -119,7 +119,7 @@ typedef union _HT_CAPABILITY_MACPARA{
 }HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
 */
 
-typedef enum _HT_ACTION{
+typedef enum _HT_ACTION {
ACT_RECOMMAND_WIDTH = 0,
ACT_MIMO_PWR_SAVE   = 1,
ACT_PSMP= 2,
@@ -134,14 +134,14 @@ typedef enum _HT_ACTION{
 
 
 /* 2007/06/07 MH Define sub-carrier mode for 40MHZ. */
-typedef enum _HT_Bandwidth_40MHZ_Sub_Carrier{
+typedef enum _HT_Bandwidth_40MHZ_Sub_Carrier {
SC_MODE_DUPLICATE = 0,
SC_MODE_LOWER = 1,
SC_MODE_UPPER = 2,
SC_MODE_FULL40MHZ = 3,
 }HT_BW40_SC_E;
 
-typedefstruct _HT_CAPABILITY_ELE{
+typedefstruct _HT_CAPABILITY_ELE {
 
//HT capability info
u8  AdvCoding:1;
@@ -184,7 +184,7 @@ typedef struct _HT_CAPABILITY_ELE{
 // Only AP is required to include this element
 //
 
-typedef struct _HT_INFORMATION_ELE{
+typedef struct _HT_INFORMATION_ELE {
u8  ControlChl;
 
u8  ExtChlOffset:2;
@@ -215,18 +215,18 @@ typedef struct _HT_INFORMATION_ELE{
 // MIMO Power Save control field.
 // This is appear in MIMO Power Save Action Frame
 //
-typedef struct _MIMOPS_CTRL{
+typedef struct _MIMOPS_CTRL {
u8  MimoPsEnable:1;
u8  MimoPsMode:1;
u8  Reserved:6;
 } MIMOPS_CTRL, *PMIMOPS_CTRL;
 
-typedef enum _HT_SPEC_VER{
+typedef enum _HT_SPEC_VER {
HT_SPEC_VER_IEEE = 0,
HT_SPEC_VER_EWC = 1,
 }HT_SPEC_VER, *PHT_SPEC_VER;
 
-typedef enum _HT_AGGRE_MODE_E{
+typedef enum _HT_AGGRE_MODE_E {
HT_AGG_AUTO = 0,
HT_AGG_FORCE_ENABLE = 1,
HT_AGG_FORCE_DISABLE = 2,
@@ -238,7 +238,7 @@ typedef enum _HT_AGGRE_MODE_E{
 // to default value in HTInitializeHTInfo()
 //
 
-typedef struct _RT_HIGH_THROUGHPUT{
+typedef struct _RT_HIGH_THROUGHPUT {
u8  bEnableHT;
u8  bCurrentHTSupport;
 
@@ -347,7 +347,7 @@ typedef struct _RT_HIGH_THROUGHPUT{
 // when card is configured as "AP mode"
 //
 
-typedef struct _RT_HTINFO_STA_ENTRY{
+typedef struct _RT_HTINFO_STA_ENTRY {
u8  bEnableHT;
 
u8  bSupportCck;
@@ -377,7 +377,7 @@ typedef struct _RT_HTINFO_STA_ENTRY{
 // when card is configured as "STA mode"
 //
 
-typedef struct _BSS_HT{
+typedef struct _BSS_HT {
 
u8  bdSupportHT;
 
@@ -395,7 +395,7 @@ typedef struct _BSS_HT{
u8  bdRT2RTLongSlotTime;
 } __attribute__ ((packed)) BSS_HT, *PBSS_HT;
 
-typedef struct _MIMO_RSSI{
+typedef struct _MIMO_RSSI {
u32 EnableAntenna;
u32 AntennaA;
u32 AntennaB;
@@ -404,12 +404,12 @@ typedef struct _MIMO_RSSI{
u32 Average;
 }MIMO_RSSI, *PMIMO_RSSI;
 
-typedef struct _MIMO_EVM{
+typedef struct _MIMO_EVM {
u32 EVM1;
u32EVM2;
 }MIMO_EVM, *PMIMO_EVM;
 
-typedef struct 

[PATCH 02/15] staging: rtl8192u: Adding space after struct definition

[simran singhal]

Fixes checkpatch.pl warning:
WARNING: missing space after struct definition

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h
index a54dfad..7c4959a 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h
@@ -14,7 +14,7 @@ typedef enum _TR_SELECT {
RX_DIR = 1,
 } TR_SELECT, *PTR_SELECT;
 
-typedef struct _TS_COMMON_INFO{
+typedef struct _TS_COMMON_INFO {
struct list_headList;
struct timer_list   SetupTimer;
struct timer_list   InactTimer;
@@ -25,7 +25,7 @@ typedef struct _TS_COMMON_INFO{
u8  TClasNum;
 } TS_COMMON_INFO, *PTS_COMMON_INFO;
 
-typedef struct _TX_TS_RECORD{
+typedef struct _TX_TS_RECORD {
TS_COMMON_INFO  TsCommonInfo;
u16 TxCurSeq;
BA_RECORD   TxPendingBARecord;  /*  For BA 
Originator */
-- 
2.7.4

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

[PATCH 01/15] staging: rtl8192u: fixing white space issue

[simran singhal]

Fix the following checkpatch.pl error and warnings:
WARNING: please, no space before tabs

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h
index 873969c..a54dfad 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TS.h
@@ -30,7 +30,7 @@ typedef struct _TX_TS_RECORD{
u16 TxCurSeq;
BA_RECORD   TxPendingBARecord;  /*  For BA 
Originator */
BA_RECORD   TxAdmittedBARecord; /*  For BA 
Originator */
-/* QOS_DL_RECORD   DLRecord; */
+/* QOS_DL_RECORD   DLRecord; */
u8  bAddBaReqInProgress;
u8  bAddBaReqDelayed;
u8  bUsingBa;
@@ -48,7 +48,7 @@ typedef struct _RX_TS_RECORD {
u16 RxLastSeqNum;
u8  RxLastFragNum;
u8  num;
-/* QOS_DL_RECORD   DLRecord; */
+/* QOS_DL_RECORDLRecord; */
 } RX_TS_RECORD, *PRX_TS_RECORD;
 
 
-- 
2.7.4

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

Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

[Thomas Gleixner]

On Mon, 13 Feb 2017, Andy Lutomirski wrote:

> On Sun, Feb 12, 2017 at 11:49 PM, Dexuan Cui  wrote:
> >> From: Thomas Gleixner [mailto:t...@linutronix.de]
> >> Sent: Saturday, February 11, 2017 02:02
> >>  ...
> >> That's important if the stuff happens cross CPU. If the update happens on
> >> the same CPU then this is a different story and as there are VMexits
> >> involved they might provide the required ordering already. But I can't tell
> >> as I have no idea how that host side thing is done.
> >>
> >>   tglx
> >
> > IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock,
> > So I would guess "the structure is only updated just before reentering the 
> > guest
> > after some VM event" (https://rwmj.wordpress.com/2010/10/15/kvm-pvclock/),
> > that is, the update should happen on the same CPU, I guess.
> 
> If the patch is correct, there is one of these shared by all vCPUs, so
> this is not a sufficient explanation.

Right, because that's ony ONE TSC page for the whole guest and then the seq
stuff really lacks barriers.

Thanks,

tglx

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

Re: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

[Andy Lutomirski]

On Sun, Feb 12, 2017 at 11:49 PM, Dexuan Cui  wrote:
>> From: Thomas Gleixner [mailto:t...@linutronix.de]
>> Sent: Saturday, February 11, 2017 02:02
>>  ...
>> That's important if the stuff happens cross CPU. If the update happens on
>> the same CPU then this is a different story and as there are VMexits
>> involved they might provide the required ordering already. But I can't tell
>> as I have no idea how that host side thing is done.
>>
>>   tglx
>
> IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock,
> So I would guess "the structure is only updated just before reentering the 
> guest
> after some VM event" (https://rwmj.wordpress.com/2010/10/15/kvm-pvclock/),
> that is, the update should happen on the same CPU, I guess.

If the patch is correct, there is one of these shared by all vCPUs, so
this is not a sufficient explanation.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [Resend PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove

[Long Li]

> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Saturday, February 11, 2017 9:35 AM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; de...@linuxdriverproject.org; linux-
> p...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [Resend PATCH 1/2 v3] pci-hyperv: properly handle pci bus
> remove
> 
> On Fri, Feb 10, 2017 at 7:18 PM, Long Li  wrote:
> > Hi Bjorn,
> >
> > This patch and the other one in the series ([Resend PATCH 2/2 v3] pci-
> hyperv: lock pci bus on device eject) have been Acked.
> >
> > Is there anything else should be done before it can be merged? Please let
> me know.
> 
> Sorry, I don't know what happened here.  I see your Jan 23 posting in my
> work email (bhelg...@google.com), but I don't see it on the linux-pci or
> linux-kernel lists, and patchwork [1] doesn't have a copy
> either.   I suspect there was something about your email that made
> vger drop it (maybe an HTML or other "fancy" stuff per
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.ke
> rnel.org%2Fmajordomo-
> info.html=02%7C01%7Clongli%40microsoft.com%7Cd3d9fb666bdd4244
> 901b08d452a4692b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> 6224313474452403=UcQu75mTXO3xh5ot%2FZTRDgL5GXayaXjs%2Fugt
> wWe91Ko%3D=0).
> 
> Patchwork works by subscribing to linux-pci and collecting things that look
> like patches.  Then I work from patchwork as a to-do list.
> That's a convenient way to ensure that patches appear on the mailing list
> before I apply them.  It also means that if a patch doesn't appear on 
> linux-pci
> and subsequently in patchwork, I don't know about it.
> 
> Patchwork does have copies of previous versions, but I marked them
> "changes requested".  When I do that, the patch drops off the to-do list
> because I'm expecting a new version, which *will* appear on the list.  I don't
> mark things "changes requested" if I'm only waiting for an ack, so it looks 
> like
> the only change I was looking for was a changelog revision.  Normally I just
> tweak changelogs myself, so I apologize for not doing that in this case.
> 
> Anyway, can you just post the current version, including the acks, and make
> sure it shows up on the mailing list?
> 
> I'm sorry this has languished so long.  Thanks for reminding me about it so we
> can sort this out.

Thank you. I will fix the email and resend the patch.

> 
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fproject%2Flinux-
> pci%2Flist%2F%3Fsubmitter%3D69886%26state%3D*%26q%3D%26archive%3
> Dboth%26delegate=02%7C01%7Clongli%40microsoft.com%7Cd3d9fb66
> 6bdd4244901b08d452a4692b%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> 7C0%7C636224313474452403=ELx04yDnSbe1fxXLy7z2iFoKwazKEMlDLrl
> p4CWhXbk%3D=0=
> 
> >> -Original Message-
> >> From: KY Srinivasan
> >> Sent: Friday, January 27, 2017 10:42 AM
> >> To: Long Li ; Haiyang Zhang
> >> ; Bjorn Helgaas 
> >> Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> >> ker...@vger.kernel.org; Long Li 
> >> Subject: RE: [Resend PATCH 1/2 v3] pci-hyperv: properly handle pci
> >> bus remove
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: Long Li [mailto:lon...@exchange.microsoft.com]
> >> > Sent: Monday, January 23, 2017 9:45 PM
> >> > To: KY Srinivasan ; Haiyang Zhang
> >> > ; Bjorn Helgaas 
> >> > Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> >> > ker...@vger.kernel.org; Long Li 
> >> > Subject: [Resend PATCH 1/2 v3] pci-hyperv: properly handle pci bus
> >> > remove
> >> >
> >> > [This sender failed our fraud detection checks and may not be who
> >> > they appear to be. Learn about spoofing at
> >> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Faka
> >> >
> .ms%2FLearnAboutSpoofing=02%7C01%7Clongli%40microsoft.com%7C
> d3
> >> >
> d9fb666bdd4244901b08d452a4692b%7C72f988bf86f141af91ab2d7cd011db47
> %7
> >> >
> C1%7C0%7C636224313474452403=jlfhIYsJJT4HbcPGSPTk43AApcip%2F
> 9m
> >> > w7snnFn%2FvI74%3D=0]
> >> >
> >> > From: Long Li 
> >> >
> >> > hv_pci_devices_present is called in hv_pci_remove when we remove a
> >> > PCI device from host (e.g. by disabling SRIOV on a device). In
> >> > hv_pci_remove, the bus is already removed before the call, so we
> >> > don't need to rescan the bus in the workqueue scheduled from
> >> > hv_pci_devices_present. By introducing status hv_pcibus_removed, we
> >> can avoid this situation.
> >> >
> >> > Signed-off-by: Long Li 
> >> > Reported-by: Xiaofeng Wang 
> >> Acked-by: K. Y. Srinivasan 
> >> > ---
> >> >  drivers/pci/host/pci-hyperv.c | 20 

[PATCH] pci-hyperv: Use device serial number as PCI domain

[Haiyang Zhang]

This allows PCI domain numbers starts with 1, and also unique
on the same VM. So names, such as VF NIC names, that include
domain number as part of the name, can be shorter than that
based on part of bus UUID previously. The new names will also
stay same for VMs created with copied VHD and same number of
devices.

Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 

---
 drivers/pci/host/pci-hyperv.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 3efcc7b..b92b565 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1315,6 +1315,16 @@ static void put_pcichild(struct hv_pci_dev *hpdev,
get_pcichild(hpdev, hv_pcidev_ref_initial);
get_pcichild(hpdev, hv_pcidev_ref_childlist);
spin_lock_irqsave(>device_list_lock, flags);
+   /* When a device is being added into the bus, we set the PCI domain
+* number to be the device serial number, which is non zero and
+* unique on the same VM. The serial numbers start with 1, and
+* increase by 1 for each device. So device names including this
+* can have shorter names than based on the bus instance UUID.
+* Only the first device serial number is used for domain, so the
+* domain number will not change after the first device is added.
+*/
+   if (list_empty(>children))
+   hbus->sysdata.domain = desc->ser;
list_add_tail(>list_entry, >children);
spin_unlock_irqrestore(>device_list_lock, flags);
return hpdev;
-- 
1.7.1

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

Re: [PATCH v2 3/5] pci: set msi_domain_ops as __ro_after_init

[Keith Busch]

On Fri, Feb 10, 2017 at 05:37:56PM -0800, Jess Frazelle wrote:
> Marked msi_domain_ops structs as __ro_after_init when called only during init.
> This protects the data structure from accidental corruption.
> 
> Suggested-by: Kees Cook 
> Signed-off-by: Jess Frazelle 
>
>  drivers/pci/host/pci-hyperv.c | 2 +-
>  drivers/pci/host/vmd.c| 2 +-

Ok for vmd driver.

Acked-by: Keith Busch 

>  drivers/pci/msi.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: fsl-mc: Add missing header

[Bogdan Purcareata]

Compiling the fsl-mc bus driver will yield a couple of static analysis
errors:
warning: symbol 'fsl_mc_msi_domain_alloc_irqs' was not declared
warning: symbol 'fsl_mc_msi_domain_free_irqs' was not declared.
warning: symbol 'its_fsl_mc_msi_init' was not declared.
warning: symbol 'its_fsl_mc_msi_cleanup' was not declared.

Since these are properly declared, but the header is not included, add
it in the source files. This way the symbol is properly exported.

Signed-off-by: Bogdan Purcareata 
---
Sent against staging-testing.

 drivers/staging/fsl-mc/bus/fsl-mc-msi.c| 1 +
 drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/staging/fsl-mc/bus/fsl-mc-msi.c 
b/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
index 7975c6e..b8b2c86 100644
--- a/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/fsl-mc-msi.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include "../include/mc-bus.h"
+#include "fsl-mc-private.h"
 
 /*
  * Generate a unique ID identifying the interrupt (only used within the MSI
diff --git a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c 
b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
index 0e2c1b5..87e4471 100644
--- a/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
+++ b/drivers/staging/fsl-mc/bus/irq-gic-v3-its-fsl-mc-msi.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include "../include/mc-bus.h"
+#include "fsl-mc-private.h"
 
 static struct irq_chip its_msi_irq_chip = {
.name = "ITS-fMSI",
-- 
1.9.1

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

Re: [PATCH 6/7] staging: r8712u: Fix Sparse warnings in rtl871x_ioctl_linux.c

[Larry Finger]

On 02/13/2017 05:27 AM, David Laight wrote:

From: Larry Finger

Sent: 11 February 2017 03:30
Sparse reports the following:
  CHECK   drivers/staging/rtl8712/rtl871x_ioctl_linux.c
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1422:46: warning: restricted 
__le16 degrades to integer
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1424:46: warning: restricted 
__le16 degrades to integer

Signed-off-by: Larry Finger 
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 0dc18d6..f4167f1 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1419,9 +1419,9 @@ static int r8711_wx_get_rate(struct net_device *dev,
ht_cap = true;
pht_capie = (struct ieee80211_ht_cap *)(p + 2);
memcpy(_rate, pht_capie->supp_mcs_set, 2);
-   bw_40MHz = (pht_capie->cap_info &
+   bw_40MHz = (le16_to_cpu(pht_capie->cap_info) &
IEEE80211_HT_CAP_SUP_WIDTH) ? 1 : 0;
-   short_GI = (pht_capie->cap_info &
+   short_GI = (le16_to_cpu(pht_capie->cap_info) &
(IEEE80211_HT_CAP_SGI_20 |
IEEE80211_HT_CAP_SGI_40)) ? 1 : 0;


You've added a byteswap on le systems - so the title is wrong.
You need to sort out whether the byteswap is needed or not.

Also it is best to byteswap the constant.


Yes, I could byteswap the constant rather than the variable, but I prefer to 
have both be in cpu order. That way there will be no confusion when that 
quantity is used later. In this case, both results are boolean and it would not 
make a difference.


I do not understand the comment about the title being wrong. All multi-byte 
quantities in struct ieee80211_ht_cap are little endian. For the code to work on 
BE hardware, a byteswap is necessary. On LE hardware, le16_to_cpu() is defined 
as ((__force __u16)(__le16)(x)), which does not result in a byteswap.


Larry


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

Re: [PATCH 0/3 staging-next] android: Lowmemmorykiller task tree

[peter enderborg]

On 02/10/2017 11:27 AM, Michal Hocko wrote:
> [I have only now see this cover - it answers some of the questions I've
>  had to specific patches. It would be really great if you could use git
>  send-email to post patch series - it just does the right thing(tm)]
>
> On Thu 09-02-17 14:21:40, peter enderborg wrote:
>> Lowmemorykiller efficiency problem and a solution.
>>
>> Lowmemorykiller in android has a severe efficiency problem. The basic
>> problem is that the registered shrinker gets called very often without
>>  anything actually happening.
> Which is an inherent problem because lkml doesn't belong to shrinkers
> infrastructure.

Not really what this patch address.  I see it as a problem with shrinker
that there no slow-path-free (scan/count) where it should belong.
This patch address a specific problem where lot of cpu are wasted
in low memory conditions.

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

Re: [PATCH 1/3 staging-next] android: Collect statistics from lowmemorykiller

[peter enderborg]

On 02/10/2017 10:15 AM, Michal Hocko wrote:
> On Fri 10-02-17 10:05:34, peter enderborg wrote:
>> On 02/10/2017 08:59 AM, Michal Hocko wrote:
> [...]
>>> The approach was wrong from the day 1. Abusing slab shrinkers
>>> is just a bad place to stick this logic. This all belongs to the
>>> userspace.
>> But now it is there and we have to stick with it.
> It is also adding maintenance cost. Just have a look at the git log and
> check how many patches were just a result of the core changes which
> needed a sync.
>
> I seriously doubt that any of the android devices can run natively on
> the Vanilla kernel so insisting on keeping this code in staging doesn't
> give much sense to me.

I guess that we more than a few that would like to see that.

We have

http://developer.sonymobile.com/open-devices/how-to-build-and-flash-a-linux-kernel/how-to-build-mainline-linux-for-xperia-devices/

It is not the latest on anything and it is not on par with commercial bundled 
software.

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

[PATCHv6 3/3] staging: wlan-ng: realign else if continuation

[Maksymilian Piechota]

realign else if continuation

Signed-off-by: Maksymilian Piechota 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index af83f2a..5277f36 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1308,7 +1308,7 @@ int prism2mgmt_wlansniff(struct wlandevice *wlandev, void 
*msgp)
hw->sniffhdr = 0;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
} else if ((msg->wlanheader.status == 
P80211ENUM_msgitem_status_data_ok) &&
-   (msg->wlanheader.data == P80211ENUM_truth_true)) {
+  (msg->wlanheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 1;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
} else {
-- 
2.1.4

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

[PATCHv6 2/3] staging: wlan-ng: move else if statement to a single line

[Maksymilian Piechota]

move else if statement to a single line

Signed-off-by: Maksymilian Piechota 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index 64a9ebc..af83f2a 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1307,8 +1307,7 @@ int prism2mgmt_wlansniff(struct wlandevice *wlandev, void 
*msgp)
&& (msg->prismheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 0;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
-   } else
-   if ((msg->wlanheader.status == 
P80211ENUM_msgitem_status_data_ok) && 
+   } else if ((msg->wlanheader.status == 
P80211ENUM_msgitem_status_data_ok) &&
(msg->wlanheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 1;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
-- 
2.1.4

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

[PATCHv6 1/3] staging: wlan-ng: move logical continuations at the end of line

[Maksymilian Piechota]

move logical continuations at the end of line

Signed-off-by: Maksymilian Piechota 
---
 drivers/staging/wlan-ng/prism2mgmt.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index 16fb2d3..64a9ebc 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1308,9 +1308,8 @@ int prism2mgmt_wlansniff(struct wlandevice *wlandev, void 
*msgp)
hw->sniffhdr = 0;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
} else
-   if ((msg->wlanheader.status ==
-P80211ENUM_msgitem_status_data_ok)
-   && (msg->wlanheader.data == P80211ENUM_truth_true)) {
+   if ((msg->wlanheader.status == 
P80211ENUM_msgitem_status_data_ok) && 
+   (msg->wlanheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 1;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
} else {
-- 
2.1.4

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

Re: [PATCH 01/01] comedi: fixed multiple line dereference

[Ian Abbott]

On 11/02/17 21:08, Artur Lorincz wrote:

Fixed multiple line dereference for >scan_begin_arg.

Signed-off-by: Artur Lorincz 
---
 drivers/staging/comedi/drivers/adl_pci9118.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c 
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 86450c0..1cc9b7e 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -1279,9 +1279,8 @@ static int pci9118_ai_cmdtest(struct comedi_device *dev,
} else {
arg = cmd->convert_arg * cmd->chanlist_len;
}
-   err |= comedi_check_trigger_arg_min(>
-   scan_begin_arg,
-   arg);
+   err |= comedi_check_trigger_arg_min(
+   >scan_begin_arg, arg);
}
}

--
1.9.1



Looks good, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCHv6 0/3] staging: wlan-ng: align else if statement to coding standard

[Maksymilian Piechota]

PATCHv0:

  - Spaces replaced with tabs

Maksymilian Piechota (1):
  staging: wlan-ng: This patch fixes the checkpatch.pl warning:

else if statement still did not fulfill coding standard requirements.


PATCHv2:

  - else if statement moved to single line

Maksymilian Piechota (1):
  staging: wlan-ng: This patch fixes the checkpatch.pl warning:

Subject was not precise.

PATCHv3:

  - Subject is more precise
  - Changelog text describe every change  

Maksymilian Piechota (1):
  staging: lustre: align else if statement to coding standard

Too much changes for one patch.

PATCHv4:
  
  - Previous patch breaked up to particular patches for every change

Maksymilian Piechota (2):
  staging: lustre: move logical continuations at the end of line
  staging: lustre: move else if statement to a single line

Continuation of the statement should be realigned

PATCHv5:

  - Wrong prefixes in commits and patches titles changed
  - Else if continuation realigned 

Maksymilian Piechota (3):
  staging: wlan-ng: move logical continuations at the end of line
  staging: wlan-ng: move else if statement to a single line
  staging: wlan-ng: realign else if continuation

Lack of patches history. No changelog text for particular patches

PATCHv6:

  - changelog text for patches added
  - patches history added

Maksymilian Piechota (3):
  staging: wlan-ng: move logical continuations at the end of line
  staging: wlan-ng: move else if statement to a single line
  staging: wlan-ng: realign else if continuation
 
drivers/staging/wlan-ng/prism2mgmt.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)


-- 
2.1.4

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

[PATCH] wlan-ng/p80211conv.c: Fix warnings regarding types.

[Anthony Brandon]

Fix several warnings in p80211conv.c emitted when using make C=1 by turning
the type member in wlan_ethhdr and wlan_snap into __be16 and changing
le16_to_cpu into ntohs.

Signed-off-by: Anthony Brandon 
---
 drivers/staging/wlan-ng/p80211conv.c | 2 +-
 drivers/staging/wlan-ng/p80211conv.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 8387e6a..767d0f7 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -387,7 +387,7 @@ int skb_p80211_to_ether(struct wlandevice *wlandev, u32 
ethconv,
   (((memcmp(e_snap->oui, oui_rfc1042,
   WLAN_IEEE_OUI_LEN) == 0) &&
   (ethconv == WLAN_ETHCONV_8021h) &&
-  (p80211_stt_findproto(le16_to_cpu(e_snap->type ||
+  (p80211_stt_findproto(ntohs(e_snap->type ||
   (memcmp(e_snap->oui, oui_rfc1042, WLAN_IEEE_OUI_LEN) !=
0))) {
pr_debug("SNAP+RFC1042 len: %d\n", payload_length);
diff --git a/drivers/staging/wlan-ng/p80211conv.h 
b/drivers/staging/wlan-ng/p80211conv.h
index ed70d98..04bac2e 100644
--- a/drivers/staging/wlan-ng/p80211conv.h
+++ b/drivers/staging/wlan-ng/p80211conv.h
@@ -130,7 +130,7 @@ struct p80211_metawep {
 struct wlan_ethhdr {
u8 daddr[ETH_ALEN];
u8 saddr[ETH_ALEN];
-   u16 type;
+   __be16 type;
 } __packed;
 
 /* local llc header type */
@@ -143,7 +143,7 @@ struct wlan_llc {
 /* local snap header type */
 struct wlan_snap {
u8 oui[WLAN_IEEE_OUI_LEN];
-   u16 type;
+   __be16 type;
 } __packed;
 
 /* Circular include trick */
-- 
2.7.4

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

[PATCH] Staging: wlan-ng: Fixed code style issue:

[Bo YU]

Statements should start on a tabstop

Signed-off-by: YU Bo 
---
 drivers/staging/wlan-ng/prism2mgmt.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
b/drivers/staging/wlan-ng/prism2mgmt.c
index c558ad656c49..b641a59052ac 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -1307,8 +1307,7 @@ int prism2mgmt_wlansniff(struct wlandevice *wlandev, void 
*msgp)
&& (msg->prismheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 0;
wlandev->netdev->type = ARPHRD_IEEE80211_PRISM;
-   } else
-   if ((msg->wlanheader.status ==
+   } else if ((msg->wlanheader.status ==
 P80211ENUM_msgitem_status_data_ok)
&& (msg->wlanheader.data == P80211ENUM_truth_true)) {
hw->sniffhdr = 1;
--
1.7.10.4

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

Re: [patch 01/01] comedi: made comedi_lrange struct constant

[Ian Abbott]

On 11/02/17 20:26, Artur Lorincz wrote:

Added the const type qualifier to the comedi_lrange structure.

Signed-off-by: Artur Lorincz 
---
 drivers/staging/comedi/drivers/addi_apci_3501.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/addi_apci_3501.c 
b/drivers/staging/comedi/drivers/addi_apci_3501.c
index 57f0f46..1fdc0f8 100644
--- a/drivers/staging/comedi/drivers/addi_apci_3501.c
+++ b/drivers/staging/comedi/drivers/addi_apci_3501.c
@@ -94,7 +94,7 @@ struct apci3501_private {
unsigned char timer_mode;
 };

-static struct comedi_lrange apci3501_ao_range = {
+static const struct comedi_lrange apci3501_ao_range = {
2, {
BIP_RANGE(10),
UNI_RANGE(10)
--
1.9.1



That looks good, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] bcm2835-audio: Fix checkpatch errors

[Greg Kroah-Hartman]

On Mon, Feb 13, 2017 at 08:49:06AM +0800, Man Choy wrote:
> A quick question, I just updated my linux-next tree last night,
> checkout tag "next-20170210" and working on the cleanup. How do I
> double check my current working file already been updated by someone
> else to avoid the duplicate work? As of now, the latest linux-next
> tree tag is still "next-20170210"

linux-next is usually a day or so behind my tree, due to the time
differences when it is created and why I usually do work.

You can work off of my staging-next branch in my staging.git tree on
git.kernel.org, that is the most up-to-date branch that ends up in
linux-next.  I also use staging-testing, to test things, but I would not
recommend that for you as it can be rebased and would be a pain to work
against.

It's ok that conflicts happen, that's how kernel development works,
sometimes people send in the same change minutes from each other, so I
have to take the one that was sent first.  It's ok, just move on and
work on something else if you really want to.

> I am on eudyptula challenge and this is my first attempt to send
> kernel patch, sorry about the silly question ;)

It's not silly, it comes up all the time.

good luck!

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

Re: [PATCH v2] Staging: comedi: drivers: comedi_test: Add auto-configuration capability

[Ian Abbott]

On 11/02/17 10:37, Cheah Kok Cheong wrote:

Currently this module needs to be manually configured by COMEDI
userspace tool before the test waveform can be read by a COMEDI
compatible application.

This patch adds auto-configuration capability and makes it the default
loading option. This is achieved by creating a device during init
to stand in for a real hardware device. This allows comedi_auto_config()
to perform auto-configuration. With this patch, the test waveform can
be read by a COMEDI compatible application without needing manual
configuration.

Previous behaviour is still selectable via module loading parameter.
Module loading without passing any parameter will default to
auto-configuration with the same default waveform amplitude and
period values. For auto-configuration, different amplitude and
period values can be set via module loading parameters.

Tested on Xubuntu 16.04 using Xoscope ver: 2.0 which is available
in the Ubuntu repository. Xoscope is a COMEDI compatible digital
oscilloscope application. For manual configuration, only module
loading/unloading is tested.

Here are the truncated dmesg output.
[sudo modprobe comedi_test]

comedi_test: 100 microvolt, 10 microsecond waveform attached
driver 'comedi_test' has successfully auto-configured 'comedi_test'.

[sudo modprobe comedi_test amplitude=250 period=15]

comedi_test: 250 microvolt, 15 microsecond waveform attached
driver 'comedi_test' has successfully auto-configured 'comedi_test'.

[sudo modprobe comedi_test noauto=1]

comedi_test: module is from the staging directory, the quality is unknown,
you have been warned.

For those without an actual hardware, the comedi_test module
is as close as one can get to test the COMEDI system.
Having both auto and manual configuration capability will broaden
the test function of this module.
Hopefully this will make it easier for people to check out the
COMEDI system and contribute to its development.

Signed-off-by: Cheah Kok Cheong 
---

V2:
-Rename module param - Ian
-Rename class - Ian
-Tidy up init error handling - Ian
-Allow module loading to continue when auto-configuration fails - Ian
-Remove redundant "if" statement from module exit
-Edit driver intro to reflect changes

 drivers/staging/comedi/drivers/comedi_test.c | 130 ---
 1 file changed, 118 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/comedi/drivers/comedi_test.c 
b/drivers/staging/comedi/drivers/comedi_test.c
index ec5b9a2..027c972 100644
--- a/drivers/staging/comedi/drivers/comedi_test.c
+++ b/drivers/staging/comedi/drivers/comedi_test.c
@@ -36,7 +36,15 @@
  * generate sample waveforms on systems that don't have data acquisition
  * hardware.
  *
- * Configuration options:
+ * Auto-configuration is the default mode if no parameter is supplied during
+ * module loading. Manual configuration requires COMEDI userspace tool.
+ * To disable auto-configuration mode, pass "noauto=1" parameter for module
+ * loading. Refer modinfo or MODULE_PARM_DESC description below for details.
+ *
+ * Auto-configuration options:
+ *   Refer modinfo or MODULE_PARM_DESC description below for details.
+ *
+ * Manual configuration options:
  *   [0] - Amplitude in microvolts for fake waveforms (default 1 volt)
  *   [1] - Period in microseconds for fake waveforms (default 0.1 sec)
  *
@@ -53,8 +61,27 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #define N_CHANS 8
+#define DEV_NAME "comedi_testd"
+#define CLASS_NAME "comedi_test"
+
+static bool config_mode;
+static unsigned int set_amplitude;
+static unsigned int set_period;
+static struct class *ctcls;
+static struct device *ctdev;
+
+module_param_named(noauto, config_mode, bool, 0444);
+MODULE_PARM_DESC(noauto, "Disable auto-configuration: (1=disable [defaults to 
enable])");
+
+module_param_named(amplitude, set_amplitude, uint, 0444);
+MODULE_PARM_DESC(amplitude, "Set auto mode wave amplitude in microvolts: (defaults 
to 1 volt)");
+
+module_param_named(period, set_period, uint, 0444);
+MODULE_PARM_DESC(period, "Set auto mode wave period in microseconds: (defaults to 
0.1 sec)");

 /* Data unique to this driver */
 struct waveform_private {
@@ -607,13 +634,11 @@ static int waveform_ao_insn_write(struct comedi_device 
*dev,
return insn->n;
 }

-static int waveform_attach(struct comedi_device *dev,
-  struct comedi_devconfig *it)
+static int waveform_common_attach(struct comedi_device *dev,
+ int amplitude, int period)
 {
struct waveform_private *devpriv;
struct comedi_subdevice *s;
-   int amplitude = it->options[0];
-   int period = it->options[1];
int i;
int ret;

@@ -621,12 +646,6 @@ static int waveform_attach(struct comedi_device *dev,
if (!devpriv)
return -ENOMEM;

-   /* set default amplitude and period */
-   if (amplitude <= 0)
-   amplitude = 100;

Re: [PATCH 3/20] staging: rtl8192u: Prefer using the BIT macro

[Greg KH]

On Mon, Feb 13, 2017 at 02:45:04PM +0530, SIMRAN SINGHAL wrote:
> Ok, I will send this patch again with the proper label.

What are you referring to?  Please always properly quote your emails so
we know what you are talking about.  Remember, some of us get over a
thousand emails a day...

http://daringfireball.net/2007/07/on_top

> But do I have to send all the patches again of this patch series?

Why wouldn't you?  The current series is incorrect.

thanks,

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

RE: [PATCH 5/7] staging: r8712u: Fix Sparse endian warning in rtl871x_recv.c

[David Laight]

From: Larry Finger
> Sent: 11 February 2017 03:30
> Sparse reports the following:
>   CHECK   drivers/staging/rtl8712/rtl871x_recv.c
> drivers/staging/rtl8712/rtl871x_recv.c:657:21: warning: incorrect type in 
> assignment (different base
> types)
> drivers/staging/rtl8712/rtl871x_recv.c:657:21:expected unsigned short 
> [unsigned] [assigned]
> [usertype] len
> drivers/staging/rtl8712/rtl871x_recv.c:657:21:got restricted __be16 
> [usertype] 
> 
> Signed-off-by: Larry Finger 
> ---
>  drivers/staging/rtl8712/rtl871x_recv.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8712/rtl871x_recv.c 
> b/drivers/staging/rtl8712/rtl871x_recv.c
> index 147b75b..2ef31a4 100644
> --- a/drivers/staging/rtl8712/rtl871x_recv.c
> +++ b/drivers/staging/rtl8712/rtl871x_recv.c
> @@ -654,8 +654,9 @@ sint r8712_wlanhdr_to_ethhdr(union recv_frame *precvframe)
>   memcpy(ptr, pattrib->dst, ETH_ALEN);
>   memcpy(ptr + ETH_ALEN, pattrib->src, ETH_ALEN);
>   if (!bsnaphdr) {
> - len = htons(len);
> - memcpy(ptr + 12, , 2);
> + __be16 be_tmp = htons(len);
> +
> + memcpy(ptr + 12, _tmp, 2);

Just do:
ptr[12] = len << 8;
ptr[13] = len;

David

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

Re: [PATCH v2 1/1] staging: comedi: s626: usleep_range is preferred over udelay

[Ian Abbott]

On 10/02/17 18:14, Saber Rezvani wrote:

Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/s626.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 0dd5fe2..97939b4 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -1513,7 +1513,7 @@ static int s626_ai_insn_read(struct comedi_device *dev,

for (n = 0; n < insn->n; n++) {
/* Delay 10 microseconds for analog input settling. */
-   udelay(10);
+   usleep_range(10, 20);

/* Start ADC by pulsing GPIO1 low */
gpio_image = readl(dev->mmio + S626_P_GPIO);



That looks fine, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 6/7] staging: r8712u: Fix Sparse warnings in rtl871x_ioctl_linux.c

[David Laight]

From: Larry Finger
> Sent: 11 February 2017 03:30
> Sparse reports the following:
>   CHECK   drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1422:46: warning: restricted 
> __le16 degrades to integer
> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1424:46: warning: restricted 
> __le16 degrades to integer
> 
> Signed-off-by: Larry Finger 
> ---
>  drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> index 0dc18d6..f4167f1 100644
> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> @@ -1419,9 +1419,9 @@ static int r8711_wx_get_rate(struct net_device *dev,
>   ht_cap = true;
>   pht_capie = (struct ieee80211_ht_cap *)(p + 2);
>   memcpy(_rate, pht_capie->supp_mcs_set, 2);
> - bw_40MHz = (pht_capie->cap_info &
> + bw_40MHz = (le16_to_cpu(pht_capie->cap_info) &
>   IEEE80211_HT_CAP_SUP_WIDTH) ? 1 : 0;
> - short_GI = (pht_capie->cap_info &
> + short_GI = (le16_to_cpu(pht_capie->cap_info) &
>   (IEEE80211_HT_CAP_SGI_20 |
>   IEEE80211_HT_CAP_SGI_40)) ? 1 : 0;

You've added a byteswap on le systems - so the title is wrong.
You need to sort out whether the byteswap is needed or not.

Also it is best to byteswap the constant.

David

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

RE: [PATCH 1/7] staging: rtl8712: Fix some Sparse endian messages

[David Laight]

From: Larry Finger
> Sent: 11 February 2017 03:30
> Sparse reports the following:
> 
>   CHECK   drivers/staging/rtl8712/rtl8712_xmit.c
> drivers/staging/rtl8712/rtl8712_xmit.c:564:42: warning: cast from restricted 
> __le32
...

I think you ought to do separate patches for the changes that are only 
annotations
and those that actually change the code.

The latter need a proper patch description.

David.


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

Re: [PATCH 1/1] staging: comedi: ni_pcidio: blank line issues

[Ian Abbott]

On 10/02/17 19:28, Saber Rezvani wrote:

Fix the checkpatch.pl issue:
CHECK: Please use a blank line after function/struct/union/enum
declarations

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/ni_pcidio.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/comedi/drivers/ni_pcidio.c 
b/drivers/staging/comedi/drivers/ni_pcidio.c
index daeb4ad..4fb43f4 100644
--- a/drivers/staging/comedi/drivers/ni_pcidio.c
+++ b/drivers/staging/comedi/drivers/ni_pcidio.c
@@ -230,6 +230,7 @@ enum pci_6534_firmware_registers {  /* 16 bit */
Firmware_Mask_Register = 0x10c,
Firmware_Debug_Register = 0x110,
 };
+
 /* main fpga registers (32 bit)*/
 enum pci_6534_fpga_registers {
FPGA_Control1_Register = 0x200,
@@ -246,6 +247,7 @@ enum pci_6534_fpga_registers {
FPGA_ELC_Read_Register = 0x2b8,
FPGA_ELC_Write_Register = 0x2bc,
 };
+
 enum FPGA_Control_Bits {
FPGA_Enable_Bit = 0x8000,
 };



That's good, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] staging: comedi: ni_pcidio.c: Spaces preferred around operators

[Ian Abbott]

On 10/02/17 19:00, Saber Rezvani wrote:

Fix the checkpatch.pl issue:
CHECK: spaces preferred around that '|' (ctx:VxV)

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/ni_pcidio.c | 40 +++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_pcidio.c 
b/drivers/staging/comedi/drivers/ni_pcidio.c
index daeb4ad..b467ac5 100644
--- a/drivers/staging/comedi/drivers/ni_pcidio.c
+++ b/drivers/staging/comedi/drivers/ni_pcidio.c
@@ -65,7 +65,7 @@
 #define WindowAddressStatus_mask   0x7c

 #define Master_DMA_And_Interrupt_Control 5 /* W */
-#define InterruptLine(x)   ((x)&3)
+#define InterruptLine(x)   ((x) & 3)
 #define OpenIntBIT(2)
 #define Group_Status   5   /* R */
 #define DataLeft   BIT(0)
@@ -100,38 +100,38 @@
 #define Chip_ID_I  25
 #define Chip_ID_O  26
 #define Chip_Version   27
-#define Port_IO(x) (28+(x))
-#define Port_Pin_Directions(x) (32+(x))
-#define Port_Pin_Mask(x)   (36+(x))
-#define Port_Pin_Polarities(x) (40+(x))
+#define Port_IO(x) (28 + (x))
+#define Port_Pin_Directions(x) (32 + (x))
+#define Port_Pin_Mask(x)   (36 + (x))
+#define Port_Pin_Polarities(x) (40 + (x))

 #define Master_Clock_Routing   45
-#define RTSIClocking(x)(((x)&3)<<4)
+#define RTSIClocking(x)(((x) & 3) << 4)

 #define Group_1_Second_Clear   46  /* W */
 #define Group_2_Second_Clear   47  /* W */
 #define ClearExpired   BIT(0)

-#define Port_Pattern(x)(48+(x))
+#define Port_Pattern(x)(48 + (x))

 #define Data_Path  64
 #define FIFOEnableABIT(0)
 #define FIFOEnableBBIT(1)
 #define FIFOEnableCBIT(2)
 #define FIFOEnableDBIT(3)
-#define Funneling(x)   (((x)&3)<<4)
+#define Funneling(x)   (((x) & 3) << 4)
 #define GroupDirection BIT(7)

 #define Protocol_Register_165
 #define OpMode Protocol_Register_1
-#define RunMode(x) ((x)&7)
+#define RunMode(x) ((x) & 7)
 #define Numbered   BIT(3)

 #define Protocol_Register_266
 #define ClockReg   Protocol_Register_2
-#define ClockLine(x)   (((x)&3)<<5)
+#define ClockLine(x)   (((x) & 3) << 5)
 #define InvertStopTrig BIT(7)
-#define DataLatching(x)   (((x)&3)<<5)
+#define DataLatching(x)   (((x) & 3) << 5)

 #define Protocol_Register_367
 #define Sequence   Protocol_Register_3
@@ -141,13 +141,13 @@

 #define Protocol_Register_470
 #define ReqReg Protocol_Register_4
-#define ReqConditioning(x) (((x)&7)<<3)
+#define ReqConditioning(x) (((x) & 7) << 3)

 #define Protocol_Register_571
 #define BlockMode  Protocol_Register_5

 #define FIFO_Control   72
-#define ReadyLevel(x)  ((x)&7)
+#define ReadyLevel(x)  ((x) & 7)

 #define Protocol_Register_673
 #define LinePolarities Protocol_Register_6
@@ -160,7 +160,7 @@

 #define Protocol_Register_774
 #define AckSer Protocol_Register_7
-#define AckLine(x) (((x)&3)<<2)
+#define AckLine(x) (((x) & 3) << 2)
 #define ExchangePins   BIT(7)

 #define Interrupt_Control  75
@@ -180,15 +180,15 @@ static inline unsigned int 
secondary_DMAChannel_bits(unsigned int channel)
 }

 #define Transfer_Size_Control  77
-#define TransferWidth(x)   ((x)&3)
-#define TransferLength(x)  (((x)&3)<<3)
+#define TransferWidth(x)   ((x) & 3)
+#define TransferLength(x)  (((x) & 3) << 3)
 #define RequireRLevel  BIT(5)

 #define Protocol_Register_15   79
 #define DAQOptions Protocol_Register_15
-#define StartSource(x) ((x)&0x3)
+#define StartSource(x) ((x) & 0x3)
 #define InvertStartBIT(2)
-#define StopSource(x)  (((x)&0x3)<<3)
+#define StopSource(x)  (((x) & 0x3) << 3)
 #define ReqStart   BIT(6)
 #define PreStart   BIT(7)

@@ -253,9 +253,9 @@ enum FPGA_Control_Bits {
 #define TIMER_BASE 50  /* nanoseconds */

 #ifdef USE_DMA
-#define IntEn (CountExpired|Waited|PrimaryTC|SecondaryTC)
+#define IntEn (CountExpired | Waited | PrimaryTC | SecondaryTC)
 #else
-#define IntEn (TransferReady|CountExpired|Waited|PrimaryTC|SecondaryTC)
+#define IntEn 

Re: [PATCH] Staging: media: bcm2048: Fixed coding style issue.

[Hans Verkuil]

On 02/12/2017 10:45 PM, Ran Algawi wrote:
> Fixed a coding style issue, where an octal value was needed insted of decimal.
> 
> Signed-off-by: Ran Algawi 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index 37bd439..d605c41 100644
> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> @@ -300,7 +300,7 @@ struct bcm2048_device {
>  };
>  
>  static int radio_nr = -1;/* radio device minor (-1 ==> auto assign) */
> -module_param(radio_nr, int, 0);
> +module_param(radio_nr, int, );

Let's make this 0444, just like most other media drivers with a radio_nr param.

In fact, I propose that you make this patch more useful by looking at the 
output of:

git grep module_param drivers/media/|grep 
'\(video_nr\)\|\(radio_nr\)\|\(vbi_nr\)'

and change all to 0444. I see a mix of , 0444 and 0644 being used, but 0444
is really the only sensible one.

Hans

>  MODULE_PARM_DESC(radio_nr,
>"Minor number for radio device (-1 ==> auto assign)");
>  
> 

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

Re: [PATCH v2 1/1] staging: comedi: dyna_pci10xx: usleep_range is preferred over udelay

[Ian Abbott]

On 10/02/17 18:11, Saber Rezvani wrote:

Fix the checkpatch.pl issue:
CHECK: usleep_range is preferred over udelay

Signed-off-by: Saber Rezvani 
---
 drivers/staging/comedi/drivers/dyna_pci10xx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dyna_pci10xx.c 
b/drivers/staging/comedi/drivers/dyna_pci10xx.c
index c9eb26f..bab7ac9 100644
--- a/drivers/staging/comedi/drivers/dyna_pci10xx.c
+++ b/drivers/staging/comedi/drivers/dyna_pci10xx.c
@@ -89,7 +89,7 @@ static int dyna_pci10xx_insn_read_ai(struct comedi_device 
*dev,
/* trigger conversion */
smp_mb();
outw_p(0x + range + chan, dev->iobase + 2);
-   udelay(10);
+   usleep_range(10, 20);

ret = comedi_timeout(dev, s, insn, dyna_pci10xx_ai_eoc, 0);
if (ret)
@@ -125,7 +125,7 @@ static int dyna_pci10xx_insn_write_ao(struct comedi_device 
*dev,
smp_mb();
/* trigger conversion and write data */
outw_p(data[n], dev->iobase);
-   udelay(10);
+   usleep_range(10, 20);
}
mutex_unlock(>mutex);
return n;
@@ -143,7 +143,7 @@ static int dyna_pci10xx_di_insn_bits(struct comedi_device 
*dev,
mutex_lock(>mutex);
smp_mb();
d = inw_p(devpriv->BADR3);
-   udelay(10);
+   usleep_range(10, 100);

/* on return the data[0] contains output and data[1] contains input */
data[1] = d;
@@ -163,7 +163,7 @@ static int dyna_pci10xx_do_insn_bits(struct comedi_device 
*dev,
if (comedi_dio_update_state(s, data)) {
smp_mb();
outw_p(s->state, devpriv->BADR3);
-   udelay(10);
+   usleep_range(10, 100);
}

data[1] = s->state;



That looks fine, thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: greybus: fix "line over 80 characters" coding style issues

[Johan Hovold]

On Thu, Feb 09, 2017 at 05:30:11PM +0100, Gioh Kim wrote:
> This patch fixes only obvious lines.
> There are still more issues.

Please make this commit message self-contained (e.g. mention what you
are doing here and why).

> Signed-off-by: Gioh Kim 
> ---
>  drivers/staging/greybus/arche-apb-ctrl.c |  5 +++-
>  drivers/staging/greybus/arche-platform.c | 43 
> +---
>  drivers/staging/greybus/audio_codec.c|  5 +++-
>  drivers/staging/greybus/bootrom.c| 13 ++
>  drivers/staging/greybus/es2.c|  3 ++-
>  drivers/staging/greybus/fw-download.c|  6 +++--
>  drivers/staging/greybus/gbphy.c  |  3 ++-
>  drivers/staging/greybus/gpio.c   |  3 ++-
>  drivers/staging/greybus/svc.c| 26 +++
>  drivers/staging/greybus/uart.c   |  8 +++---
>  drivers/staging/greybus/vibrator.c   |  4 ++-
>  11 files changed, 77 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/staging/greybus/arche-apb-ctrl.c 
> b/drivers/staging/greybus/arche-apb-ctrl.c
> index 17fa290..02243b4 100644
> --- a/drivers/staging/greybus/arche-apb-ctrl.c
> +++ b/drivers/staging/greybus/arche-apb-ctrl.c
> @@ -168,7 +168,10 @@ static int standby_boot_seq(struct platform_device *pdev)
>   if (apb->init_disabled)
>   return 0;
>  
> - /* Even if it is in OFF state, then we do not want to change the state 
> */
> + /*
> +  * Even if it is in OFF state,
> +  * then we do not want to change the state
> +  */

Odd comment, but still don't break the line after the comma, break
around 80 cols.

But in this case I think the comment should instead be shortened to:

/* Even if in OFF state we do not want to change the state. */

>   if (apb->state == ARCHE_PLATFORM_STATE_STANDBY ||
>   apb->state == ARCHE_PLATFORM_STATE_OFF)
>   return 0;
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index 338c2d3..aac1145 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -312,9 +312,11 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>   if (arche_pdata->wake_detect_state == WD_STATE_IDLE) {
>   arche_pdata->wake_detect_start = jiffies;
>   /*
> -  * In the begining, when wake/detect goes low (first 
> time), we assume
> -  * it is meant for coldboot and set the flag. If 
> wake/detect line stays low
> -  * beyond 30msec, then it is coldboot else fallback to 
> standby boot.
> +  * In the begining, when wake/detect goes low
> +  * (first time), we assume it is meant for coldboot
> +  * and set the flag. If wake/detect line stays low
> +  * beyond 30msec, then it is coldboot else fallback
> +  * to standby boot.
>*/
>   arche_platform_set_wake_detect_state(arche_pdata,
>
> WD_STATE_BOOT_INIT);
> @@ -330,7 +332,8 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>  /*
>   * Requires arche_pdata->platform_state_mutex to be held
>   */
> -static int arche_platform_coldboot_seq(struct arche_platform_drvdata 
> *arche_pdata)
> +static int
> +arche_platform_coldboot_seq(struct arche_platform_drvdata *arche_pdata)
>  {
>   int ret;
>  
> @@ -364,7 +367,8 @@ static int arche_platform_coldboot_seq(struct 
> arche_platform_drvdata *arche_pdat
>  /*
>   * Requires arche_pdata->platform_state_mutex to be held
>   */
> -static int arche_platform_fw_flashing_seq(struct arche_platform_drvdata 
> *arche_pdata)
> +static int
> +arche_platform_fw_flashing_seq(struct arche_platform_drvdata *arche_pdata)
>  {
>   int ret;
>  
> @@ -398,7 +402,8 @@ static int arche_platform_fw_flashing_seq(struct 
> arche_platform_drvdata *arche_p
>  /*
>   * Requires arche_pdata->platform_state_mutex to be held
>   */
> -static void arche_platform_poweroff_seq(struct arche_platform_drvdata 
> *arche_pdata)
> +static void
> +arche_platform_poweroff_seq(struct arche_platform_drvdata *arche_pdata)
>  {
>   unsigned long flags;
>  
> @@ -561,14 +566,17 @@ static int arche_platform_probe(struct platform_device 
> *pdev)
>   struct device_node *np = dev->of_node;
>   int ret;
>  
> - arche_pdata = devm_kzalloc(>dev, sizeof(*arche_pdata), 
> GFP_KERNEL);
> + arche_pdata = devm_kzalloc(>dev, sizeof(*arche_pdata),
> +GFP_KERNEL);
>   if (!arche_pdata)
>   return -ENOMEM;
>  
>   /* setup svc reset gpio */
>   arche_pdata->is_reset_act_hi = of_property_read_bool(np,
>   "svc,reset-active-high");
> - 

Re: [PATCH 2/2] staging: greybus: fix symbolic permission coding style issues

[Johan Hovold]

On Thu, Feb 09, 2017 at 05:30:12PM +0100, Gioh Kim wrote:
> Fix "Octal permissions are preffered than symbolic ones" issues.
> 
> Signed-off-by: Gioh Kim 

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

RE: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

[Thomas Gleixner]

On Mon, 13 Feb 2017, Dexuan Cui wrote:
> > From: Thomas Gleixner [mailto:t...@linutronix.de]
> > Sent: Saturday, February 11, 2017 02:02
> >  ...
> > That's important if the stuff happens cross CPU. If the update happens on
> > the same CPU then this is a different story and as there are VMexits
> > involved they might provide the required ordering already. But I can't tell
> > as I have no idea how that host side thing is done.
> > 
> 
> IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock,
> So I would guess "the structure is only updated just before reentering the 
> guest
> after some VM event" (https://rwmj.wordpress.com/2010/10/15/kvm-pvclock/),
> that is, the update should happen on the same CPU, I guess.

Guessing does not help much. There are a gazillion ways to implement such a
thing. I'm sure that there exists proper documentation of the mechanism
inside your company.

Thanks,

tglx

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

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

[Philipp Zabel]

Hi Steve,

On Thu, 2017-02-09 at 15:51 -0800, Steve Longerbeam wrote:
> 
> On 02/09/2017 03:49 PM, Steve Longerbeam wrote:
> >
> >
> > On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:
> >> On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:
>  Actually, this exact function already exists as 
>  dw_mipi_dsi_phy_write in
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY
>  register 0x44 might contain a field called HSFREQRANGE_SEL.
> >>> Thanks for pointing out drivers/gpu/drm/rockchip/dw-mipi-dsi.c.
> >>> It's clear from that driver that there probably needs to be a fuller
> >>> treatment of the D-PHY programming here, but I don't know where
> >>> to find the MIPI CSI-2 D-PHY documentation for the i.MX6. The code
> >>> in imxcsi2_reset() was also pulled from FSL, and that's all I really 
> >>> have
> >>> to go on for the D-PHY programming. I assume the D-PHY is also a
> >>> Synopsys core, like the host controller, but the i.MX6 manual doesn't
> >>> cover it.
> >> Why exactly?  What problems are you seeing that would necessitate a
> >> more detailed programming of the D-PHY?  From my testing, I can wind
> >> a 2-lane MIPI bus on iMX6D from 912Mbps per lane down to (eg) 308Mbps
> >> per lane with your existing code without any issues.
> >
> > That's good to hear.
> >
> > Just from my experience with struggles to get the CSI2 receiver
> > up and running with an active clock lane, and my suspicions that
> > some of that could be due to my lack of understanding of the D-PHY
> > programming.
> 
> But I should add that after a re-org of the sequence, it looks more stable
> now. Tested on both the SabreSD and SabreLite with the OV5640.

It seems the OV5640 driver never puts its the CSI-2 lanes into stop
state while not streaming. With the recent s_stream reordering,
streaming from TC358743 does not work anymore, since imx6-mipi-csi2
s_stream is called before tc358743 s_stream, while all lanes are still
in stop state. Then it waits for the clock lane to become active and
fails. I have applied the following patch to revert the reordering
locally to get it to work again.

The initialization order, as Russell pointed out, should be:

1. reset the D-PHY.
2. place MIPI sensor in LP-11 state
3. perform D-PHY initialisation
4. configure CSI2 lanes and de-assert resets and shutdown signals

So csi2_s_stream should wait for stop state on all lanes (the result of
2.) before dphy_init (3.), not wait for active clock afterwards. That
should happen only after sensor_s_stream was called. So unless we are
allowed to reorder steps 1. and 2., we might need the prepare_stream
callback after all.

More specifically, the chapter 40.3.1 "Startup Sequence" in the i.MX6DQ
reference manual states:

1. Deassert presetn signal (global reset)
   - This is probably the APB global reset, so not something we have to
 care about.
2. Configure MIPI Camera Sensor to put all Tx lanes in PL-11 state
3. D-PHY initialization (write 0x14 to address 0x44)
4. CSI2 Controller programming
   - Set N_LANES
   - Deassert PHY_SHUTDOWNZ
   - Deassert PHY_RSTZ
   - Deassert CSI2_RESETN
5. Read the PHY status register (PHY_STATE) to confirm that all data and
   clock lanes of the D-PHY are in Stop State
6. Configure the MIPI Camera Sensor to start transmitting a clock on the
   D-PHY clock lane
7. CSI2 Controller programming - Read the PHY status register
   (PHY_STATE) to confirm that the D-PHY is receiving a clock on the
   D-PHY clock lane

2. can be done in sensor s_power (which tc358743 currently does) only if
the sensor can still be configured in step 6.
Also, 3./4./5. are csi2 code, 6. is sensor code, and 7. is csi2 code
again. For reliable startup we need csi2 receiver code to be called on
both sides of the sensor enabling its clock lane.

--8<--
>From f12758caa3e1d05980cd2ac07587d125449fc860 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Mon, 13 Feb 2017 09:28:27 +0100
Subject: [PATCH] media: imx: revert streamon sequence change

Without this patch, starting streaming from a TC358743 MIPI CSI-2 source
fails with the following error messages:

imx6-mipi-csi2: clock lane timeout, phy_state = 0x06f0
ipu1_csi0: pipeline_set_stream failed with -110

The phy state above has the stopstateclk, rxulpsclknot, and
stopstatedata[3:0] bits set: at this point all lanes are in stop state,
no lane is in ultra low power state or active.
This is no suprise, since tc358743 s_stream(sd, 1) has not been called
due to the recently changed ordering. The imx6-mipi-csi2 s_stream does
wait for the clock lane to become active, so csi2_s_stream must happen
after tc358743_s_stream.

Signed-off-by: Philipp Zabel 
---
 drivers/staging/media/imx/imx-media-utils.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-utils.c 
b/drivers/staging/media/imx/imx-media-utils.c
index 

[PATCH v2 1/1] Staging: vc04_services: Fix the "space prohibited" code style errors

[Mandel Benjamin]

This patch fixes the following code style errors:

ERROR: space prohibited after/before that open/closed parenthesis 

Signed-off-by: Mandel Benjamin 
---
 drivers/staging/vc04_services/interface/vchi/vchi_common.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi_common.h 
b/drivers/staging/vc04_services/interface/vchi/vchi_common.h
index cedb24e..45c2070 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi_common.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi_common.h
@@ -120,9 +120,9 @@
 
 
 //Callback used by all services / bulk transfers
-typedef void (*VCHI_CALLBACK_T)( void *callback_param, //my service local param
+typedef void (*VCHI_CALLBACK_T)(void *callback_param, //my service local param
 VCHI_CALLBACK_REASON_T reason,
-void *handle ); //for transmitting msg's only
+void *handle); //for transmitting msg's only
 
 
 
-- 
1.9.1

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

Re: [PATCH 3/20] staging: rtl8192u: Prefer using the BIT macro

[SIMRAN SINGHAL]

Ok, I will send this patch again with the proper label.

But do I have to send all the patches again of this patch series?

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

[PATCH v2 0/1] Staging: vc04_services: Fix the "wrong indent" code style errors

[Mandel Benjamin]

This patch fixes the following code style errors:

ERROR: code indent should use tabs where possible

Signed-off-by: Mandel Benjamin 
---
 drivers/staging/vc04_services/interface/vchi/vchi_common.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi_common.h 
b/drivers/staging/vc04_services/interface/vchi/vchi_common.h
index 3f7d843..cedb24e 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi_common.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi_common.h
@@ -121,8 +121,8 @@
 
 //Callback used by all services / bulk transfers
 typedef void (*VCHI_CALLBACK_T)( void *callback_param, //my service local param
- VCHI_CALLBACK_REASON_T reason,
- void *handle ); //for transmitting msg's only
+VCHI_CALLBACK_REASON_T reason,
+void *handle ); //for transmitting msg's only
 
 
 
-- 
1.9.1

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

[PATCH] staging: nvec: Fix incorrect type of i2c address

[Franck Demathieu]

From: Franck Demathieu 

The i2c address is unsigned according to the dt-bindings.
Fix sparse issue (-Wtypesign):

  drivers/staging/nvec/nvec.c:781:35: warning: incorrect type in argument 3 
(different signedness)
  drivers/staging/nvec/nvec.c:781:35:expected unsigned int [usertype] 
*out_value
  drivers/staging/nvec/nvec.c:781:35:got int *

Signed-off-by: Franck Demathieu 
---
 drivers/staging/nvec/nvec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/nvec/nvec.h b/drivers/staging/nvec/nvec.h
index c03ca8d..aa7c70e 100644
--- a/drivers/staging/nvec/nvec.h
+++ b/drivers/staging/nvec/nvec.h
@@ -138,7 +138,7 @@ struct nvec_chip {
struct device *dev;
int gpio;
int irq;
-   int i2c_addr;
+   u32 i2c_addr;
void __iomem *base;
struct clk *i2c_clk;
struct reset_control *rst;
-- 
2.8.1

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

Re: [PATCH] staging: greybus: arpc.h: remove duplicate line.

[Johan Hovold]

On Fri, Feb 10, 2017 at 11:16:37PM -0500, Nathan Howard wrote:
> Fix checkpatch.pl issue of the form:
> "CHECK: Please don't use multiple blank lines".

Don't take checkpatch too seriously. Using double blank lines as a
separator is perfectly fine.

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