Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

[Alessio Igor Bogani]

Hi Dmitry,

On 6 July 2015 at 19:24, Dmitry Kalinkin  wrote:
[...]
>
> I'm not a VME expert, but it seems that VME windows are a quiet limited 
> resource
> no matter how you allocate your resources. Theoretically we could put up to 32
> different boards in a single crate, so there won't be enough windows for each
> driver to allocate. That said, there is no way around this when putting 
> together
> a really heterogeneous VME system. To overcome such problem, one could
> develop a different kernel API that would not provide windows to the
> drivers, but
> handle reads and writes by reconfiguring windows on the fly, which in turn 
> would
> introduce more latency.

In my humble opinion using user-space drivers (as workaround for
limited windows/images) introduce more latency than let VME driver
dynamically configure windows/images. After all VME systems usually
aren't so much dynamic by its nature (Who likes continuously put in
and out a board which requires an insertion force between 20 and 50
kg?) and are instead heavily used in critical contexts often in
non-stop way.

In fact this is a big obstacle for adoption of this VME stack (at
least for us). We use VME a lot and we care about latency as well so
we use only kernel-space drivers for ours VME boards but unfortunately
the VME stack let us to link a single board with a single window/image
(so max 8 boards on tsi148) only. That said that stack has proven to
be very rock solid.

Until now we have used a modified version of the old vmelinux.org
stack for sharing windows/images between all (ours) VME kernel drivers
and we would be very happy to see something similar in vanilla (at
least coalescence two adjacent addresses with same modifiers).

> Those who need such API are welcome to develop it :)

I would be glad to try it if the maintainer is willing to receive this
type of changes.

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

Re: Clarification for the use of additional fields in the message body

[SF Markus Elfring]

> The date, as far as I know, is ignored. It is the commit date,
> not the authoring date, and once your patch is applied by a maintainer
> (i.e. committed), the date gets reset anyway.

Thanks for your feedback.


> No need to try and preserve it.

I find that it might occasionally help to share and keep the record
on timestamps about the evolution for an original update suggestion.

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

[PATCH 0/5] staging: sm7xxfb: few changes

[Sudip Mukherjee]

Few more changes in sm7xxfb, and hopefully the last changes before I
send the patch to move it to drivers/video/fbdev.

Has been tested with:
1) fbtest available at 
https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/
2) read and write tested on Little-Endian system


regards
sudip

Sudip Mukherjee (5):
  staging: sm7xxfb: remove unused macros
  staging: sm7xxfb: fix error handling
  staging: sm7xxfb: use kernel commandline
  staging: sm7xxfb: define new macros
  staging: sm7xxfb: usr fb_read and fb_write

 drivers/staging/sm7xxfb/sm7xx.h   | 39 +++---
 drivers/staging/sm7xxfb/sm7xxfb.c | 69 ++-
 2 files changed, 37 insertions(+), 71 deletions(-)

-- 
1.8.1.2

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

[PATCH 3/5] staging: sm7xxfb: use kernel commandline

[Sudip Mukherjee]

We were only using the kernel commandline to set the mode if this driver
is builtin, but when it is built as a module we were not having any way
to set the mode. Start using commandline even if it is built as a
module.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xxfb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 8fb62af..4dc9d5f 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -1660,14 +1660,12 @@ static struct pci_driver smtcfb_driver = {
 
 static int __init sm712fb_init(void)
 {
-#ifndef MODULE
char *option = NULL;
 
if (fb_get_options("sm712fb", &option))
return -ENODEV;
if (option && *option)
mode_option = option;
-#endif
sm7xx_vga_setup(mode_option);
 
return pci_register_driver(&smtcfb_driver);
-- 
1.8.1.2

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

[PATCH 4/5] staging: sm7xxfb: define new macros

[Sudip Mukherjee]

Define and use some new macros to work with different situations
based on little-endian and big-endian.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xx.h   | 19 
 drivers/staging/sm7xxfb/sm7xxfb.c | 48 ---
 2 files changed, 29 insertions(+), 38 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
index 31a21bd..6905177 100644
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -95,3 +95,22 @@ struct modeinit {
unsigned char init_cr30_cr4d[SIZE_CR30_CR4D];
unsigned char init_cr90_cra7[SIZE_CR90_CRA7];
 };
+
+#ifdef __BIG_ENDIAN
+#define pal_rgb(r, g, b, val)  (((r & 0xf800) >> 8) | \
+   ((g & 0xe000) >> 13) | \
+   ((g & 0x1c00) << 3) | \
+   ((b & 0xf800) >> 3))
+#define big_addr   0x80
+#define mmio_addr  0x0080
+#define seqw17 smtc_seqw(0x17, 0x30)
+#define big_pixel_depth(p, d)  {if (p == 24) {p = 32; d = 32; } }
+#define big_swap(p)((p & 0xff00ff00 >> 8) | (p & 0x00ff00ff << 8))
+#else
+#define pal_rgb(r, g, b, val)  val
+#define big_addr   0
+#define mmio_addr  0x00c0
+#define seqw17
+#define big_pixel_depth(p, d)
+#define big_swap(p)p
+#endif
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 4dc9d5f..252f110a 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -923,25 +923,14 @@ static int smtc_setcolreg(unsigned regno, unsigned red, 
unsigned green,
val = chan_to_field(red, &sfb->fb->var.red);
val |= chan_to_field(green, &sfb->fb->var.green);
val |= chan_to_field(blue, &sfb->fb->var.blue);
-#ifdef __BIG_ENDIAN
-   pal[regno] = ((red & 0xf800) >> 8) |
-((green & 0xe000) >> 13) |
-((green & 0x1c00) << 3) |
-((blue & 0xf800) >> 3);
-#else
-   pal[regno] = val;
-#endif
+   pal[regno] = pal_rgb(red, green, blue, val);
} else {
u32 *pal = sfb->fb->pseudo_palette;
 
val = chan_to_field(red, &sfb->fb->var.red);
val |= chan_to_field(green, &sfb->fb->var.green);
val |= chan_to_field(blue, &sfb->fb->var.blue);
-#ifdef __BIG_ENDIAN
-   val = (val & 0xff00ff00 >> 8) |
- (val & 0x00ff00ff << 8);
-#endif
-   pal[regno] = val;
+   pal[regno] = big_swap(val);
}
break;
 
@@ -1002,8 +991,7 @@ static ssize_t smtcfb_read(struct fb_info *info, char 
__user *buf,
dst = buffer;
for (i = c >> 2; i--;) {
*dst = fb_readl(src++);
-   *dst = (*dst & 0xff00ff00 >> 8) |
-  (*dst & 0x00ff00ff << 8);
+   *dst = big_swap(*dst);
dst++;
}
if (c & 3) {
@@ -1091,8 +1079,7 @@ static ssize_t smtcfb_write(struct fb_info *info, const 
char __user *buf,
}
 
for (i = c >> 2; i--;) {
-   fb_writel((*src & 0xff00ff00 >> 8) |
- (*src & 0x00ff00ff << 8), dst++);
+   fb_writel(big_swap(*src), dst++);
src++;
}
if (c & 3) {
@@ -1341,10 +1328,8 @@ static int smtc_map_smem(struct smtcfb_info *sfb,
 {
sfb->fb->fix.smem_start = pci_resource_start(pdev, 0);
 
-#ifdef __BIG_ENDIAN
if (sfb->fb->var.bits_per_pixel == 32)
-   sfb->fb->fix.smem_start += 0x80;
-#endif
+   sfb->fb->fix.smem_start += big_addr;
 
sfb->fb->fix.smem_len = smem_len;
 
@@ -1437,10 +1422,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
sfb->fb->var.bits_per_pixel = SCREEN_BPP;
}
 
-#ifdef __BIG_ENDIAN
-   if (sfb->fb->var.bits_per_pixel == 24)
-   sfb->fb->var.bits_per_pixel = (smtc_scr_info.lfb_depth = 32);
-#endif
+   big_pixel_depth(sfb->fb->var.bits_per_pixel, smtc_scr_info.lfb_depth);
/* Map address and memory detection */
mmio_base = pci_resource_start(pdev, 0);
pci_read_config_byte(pdev, PCI_REVISION_ID, &sfb->chip_rev_id);
@@ -1451,11 +1433,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
sfb->fb->fix.mmio_start = mmio_base + 0x0040;
sfb->fb->fix.mmio_len = 0x0040;
smem_size = SM712_VIDEOMEMORYSIZE;
-#ifdef __BIG_ENDIAN
-   sfb->lfb = ioremap(mmio_base, 0x00c0);
-#else
-

[PATCH 5/5] staging: sm7xxfb: usr fb_read and fb_write

[Sudip Mukherjee]

Now since the Big-Endian and Little-Endian based calculations are moved
into a macro we can make fb_read() and fb_write() common for both
Little-Endian and Big-Endian.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xxfb.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 252f110a..b8a1e86 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -946,7 +946,6 @@ static int smtc_setcolreg(unsigned regno, unsigned red, 
unsigned green,
return 0;
 }
 
-#ifdef __BIG_ENDIAN
 static ssize_t smtcfb_read(struct fb_info *info, char __user *buf,
   size_t count, loff_t *ppos)
 {
@@ -1107,7 +1106,6 @@ static ssize_t smtcfb_write(struct fb_info *info, const 
char __user *buf,
 
return (cnt) ? cnt : err;
 }
-#endif /* ! __BIG_ENDIAN */
 
 static void sm7xx_set_timing(struct smtcfb_info *sfb)
 {
@@ -1303,10 +1301,8 @@ static struct fb_ops smtcfb_ops = {
.fb_fillrect  = cfb_fillrect,
.fb_imageblit = cfb_imageblit,
.fb_copyarea  = cfb_copyarea,
-#ifdef __BIG_ENDIAN
.fb_read  = smtcfb_read,
.fb_write = smtcfb_write,
-#endif
 };
 
 /*
-- 
1.8.1.2

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

[PATCH 2/5] staging: sm7xxfb: fix error handling

[Sudip Mukherjee]

We were checking smtc_regbaseaddress and that too at a place where it
can never be NULL. Real check should be on sfb->lfb immediately after
we do ioremap.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xxfb.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 2ff4fe7..8fb62af 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -1456,6 +1456,14 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
 #else
sfb->lfb = ioremap(mmio_base, 0x0080);
 #endif
+   if (!sfb->lfb) {
+   dev_err(&pdev->dev,
+   "%s: unable to map memory mapped IO!\n",
+   sfb->fb->fix.id);
+   err = -ENOMEM;
+   goto failed_fb;
+   }
+
sfb->mmio = (smtc_regbaseaddress =
sfb->lfb + 0x0070);
sfb->dp_regs = sfb->lfb + 0x00408000;
@@ -1466,13 +1474,6 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
dev_info(&pdev->dev, "sfb->lfb=%p\n", sfb->lfb);
}
 #endif
-   if (!smtc_regbaseaddress) {
-   dev_err(&pdev->dev,
-   "%s: unable to map memory mapped IO!\n",
-   sfb->fb->fix.id);
-   err = -ENOMEM;
-   goto failed_fb;
-   }
 
/* set MCLK = 14.31818 * (0x16 / 0x2) */
smtc_seqw(0x6a, 0x16);
-- 
1.8.1.2

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

[PATCH 1/5] staging: sm7xxfb: remove unused macros

[Sudip Mukherjee]

These macros were only defined but not used anywhere.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/sm7xxfb/sm7xx.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
index 4bed094..31a21bd 100644
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -13,8 +13,6 @@
  *  more details.
  */
 
-#define NR_PALETTE256
-
 #define FB_ACCEL_SMI_LYNX 88
 
 #define SCREEN_X_RES  1024
@@ -31,12 +29,8 @@
 
 extern void __iomem *smtc_regbaseaddress;
 #define smtc_mmiowb(dat, reg)  writeb(dat, smtc_regbaseaddress + reg)
-#define smtc_mmioww(dat, reg)  writew(dat, smtc_regbaseaddress + reg)
-#define smtc_mmiowl(dat, reg)  writel(dat, smtc_regbaseaddress + reg)
 
 #define smtc_mmiorb(reg)   readb(smtc_regbaseaddress + reg)
-#define smtc_mmiorw(reg)   readw(smtc_regbaseaddress + reg)
-#define smtc_mmiorl(reg)   readl(smtc_regbaseaddress + reg)
 
 #define SIZE_SR00_SR04  (0x04 - 0x00 + 1)
 #define SIZE_SR10_SR24  (0x24 - 0x10 + 1)
@@ -48,8 +42,6 @@ extern void __iomem *smtc_regbaseaddress;
 #define SIZE_CR00_CR18  (0x18 - 0x00 + 1)
 #define SIZE_CR30_CR4D  (0x4D - 0x30 + 1)
 #define SIZE_CR90_CRA7  (0xA7 - 0x90 + 1)
-#define SIZE_VPR   (0x6C + 1)
-#define SIZE_DPR   (0x44 + 1)
 
 static inline void smtc_crtcw(int reg, int val)
 {
@@ -57,24 +49,12 @@ static inline void smtc_crtcw(int reg, int val)
smtc_mmiowb(val, 0x3d5);
 }
 
-static inline unsigned int smtc_crtcr(int reg)
-{
-   smtc_mmiowb(reg, 0x3d4);
-   return smtc_mmiorb(0x3d5);
-}
-
 static inline void smtc_grphw(int reg, int val)
 {
smtc_mmiowb(reg, 0x3ce);
smtc_mmiowb(val, 0x3cf);
 }
 
-static inline unsigned int smtc_grphr(int reg)
-{
-   smtc_mmiowb(reg, 0x3ce);
-   return smtc_mmiorb(0x3cf);
-}
-
 static inline void smtc_attrw(int reg, int val)
 {
smtc_mmiorb(0x3da);
-- 
1.8.1.2

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

Re: Clarification for the use of additional fields in the message body

[Frans Klaver]

On Tue, Jul 7, 2015 at 9:54 AM, SF Markus Elfring
 wrote:

>> No need to try and preserve it.
>
> I find that it might occasionally help to share and keep the record
> on timestamps about the evolution for an original update suggestion.

I think that as far as these kernel mailing lists are concerned, the
date of the update suggestion is the date on which you submitted the
patch, rather than the date you originally committed it to your local
tree. If you wish to keep track of this evolution for yourself, or
wish to share it, you're better off stashing it somewhere in a
(public) git repo that you control. If you wish, you can always make
mention of that repo below the ---, just above the diffstat. If you
insist on placing the date somewhere, you can also put the date there
if you wish. It'll be ignored by git when applied.

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

Re: [PATCH] Alternate rtl8192cu driver.

[P. Varet]

On 07/06/2015 07:13 PM, Greg KH wrote:


But, have you tried the in-kernel driver for this device?


Hi Greg! Yes, I have. Sorry for not making this clear. The symptoms are as 
described in bug #57171. I haven't tested it again in recent months but I can do 
that for you when I'm back home if you want.


I too would very much prefer to see the in-kernel driver fixed. It doesn't seem 
to be happening, though. I don't have the specific knowledge to help fix it.


I share your misgivings about having redundant drivers. My idea was that maybe 
we could restrict this alternate driver to USB device IDs that are known to work 
well with it but not with the in-kernel driver, at least until the in-kernel 
driver is fixed, since the main issue here is that the in-kernel driver 
currently doesn't support those devices even though it claims to.


This is only a stopgap that isn't meant to stay indefinitely, though. It's a 
generally very unsatisfying solution, but I don't know how else to keep those 
devices supported until the in-kernel driver is fixed.


Mind you, if this discussion unlocks things and the in-kernel driver gets fixed, 
that's definitely the best outcome as far as I'm concerned. :)


Cheers,

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

Re: [PATCH 0/4] staging: wilc1000: cover letter

[Luis de Bethencourt]

On Mon, Jul 06, 2015 at 07:22:09PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jun 26, 2015 at 04:43:44PM +0200, Luis de Bethencourt wrote:
> > Patches to be applied on top of
> > https://patchwork.kernel.org/patch/6655831/
> 
> I don't use patchwork, and when on an airplane with no internet access
> (like right now), a url provides no context at all.  Always use email
> subject lines or something that I can actually reference properly while
> offline...
> 
> thanks,
> 
> greg k-h

OK. Sorry. Didn't knew this but noted for the future.

Thanks for the reviews and merges!
Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8188eu: core: rtw_mlme: remove space before ','

[Sunil Shahu]

Fix coding style error by removing spaces before ',' as suggested by
checkpatch.pl script.

Signed-off-by: Sunil Shahu 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 0558451..e6917ea 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -160,7 +160,7 @@ exit:
return pnetwork;
 }
 
-static void _rtw_free_network(struct   mlme_priv *pmlmepriv , struct 
wlan_network *pnetwork, u8 isfreeall)
+static void _rtw_free_network(struct mlme_priv *pmlmepriv, struct wlan_network 
*pnetwork, u8 isfreeall)
 {
u32 curr_time, delta_time;
u32 lifetime = SCANQUEUE_LIFETIME;
@@ -581,7 +581,7 @@ static int rtw_is_desired_network(struct adapter *adapter, 
struct wlan_network *
 }
 
 /* TODO: Perry: For Power Management */
-void rtw_atimdone_event_callback(struct adapter*adapter , u8 *pbuf)
+void rtw_atimdone_event_callback(struct adapter *adapter, u8 *pbuf)
 {
RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("receive 
atimdone_evet\n"));
return;
@@ -614,7 +614,7 @@ void rtw_survey_event_callback(struct adapter   
*adapter, u8 *pbuf)
spin_lock_bh(&(pmlmepriv->scanned_queue.lock));
ibss_wlan = rtw_find_network(&pmlmepriv->scanned_queue, 
 pnetwork->MacAddress);
if (ibss_wlan) {
-   memcpy(ibss_wlan->network.IEs , pnetwork->IEs, 
8);
+   memcpy(ibss_wlan->network.IEs, pnetwork->IEs, 
8);
spin_unlock_bh(&pmlmepriv->scanned_queue.lock);
goto exit;
}
@@ -1382,7 +1382,7 @@ void _rtw_join_timeout_handler (unsigned long data)
DBG_88E("%s try another roaming\n", __func__);
do_join_r = rtw_do_join(adapter);
if (_SUCCESS != do_join_r) {
-   DBG_88E("%s roaming do_join return 
%d\n", __func__ , do_join_r);
+   DBG_88E("%s roaming do_join return 
%d\n", __func__, do_join_r);
continue;
}
break;
@@ -1997,7 +1997,7 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
p = rtw_get_ie(in_ie+12, _HT_ADD_INFO_IE_, &ielen, in_len-12);
if (p && (ielen == sizeof(struct ieee80211_ht_addt_info))) {
out_len = *pout_len;
-   rtw_set_ie(out_ie+out_len, _HT_ADD_INFO_IE_, ielen, p+2 
, pout_len);
+   rtw_set_ie(out_ie+out_len, _HT_ADD_INFO_IE_, ielen, 
p+2, pout_len);
}
}
return phtpriv->ht_option;
-- 
1.9.1

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

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Paul Bolle]

Just two nits.

On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
> --- /dev/null
> +++ b/net/hv_sock/Kconfig

> +config HYPERV_SOCK
> + tristate "Microsoft Hyper-V Socket (EXPERIMENTAL)"
> + depends on HYPERV
> + default m
> + help
> +   Hyper-V Socket is a socket protocol similar to TCP, allowing
> +   communication between a Linux guest and the host.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called hv_sock. If unsure, say N.

It's a bit odd to advise to say N if one is unsure and set the default
to 'm' at the same time.

> --- /dev/null
> +++ b/net/hv_sock/af_hvsock.c

> +static int hvsock_init(void)
> +{
> + [...]
> +}
> +
> +static void hvsock_exit(void)
> +{
> + [...]
> +}
> +
> +module_init(hvsock_init);
> +module_exit(hvsock_exit);

Any specific reason not to mark these functions __init and __exit?

Thanks,


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

Re: [PATCH] Alternate rtl8192cu driver.

[Dan Carpenter]

On Tue, Jul 07, 2015 at 11:16:04AM +0200, P. Varet wrote:
> On 07/06/2015 07:13 PM, Greg KH wrote:
> 
> >But, have you tried the in-kernel driver for this device?
> 
> Hi Greg! Yes, I have. Sorry for not making this clear. The symptoms
> are as described in bug #57171. I haven't tested it again in recent
> months but I can do that for you when I'm back home if you want.

https://bugzilla.kernel.org/show_bug.cgi?id=57171

This bug is a confusing mix of issues and it seems to be fixed.  Just
use network manager.

Anyway, test again.  If there are still an issues we can start a new
thread with Larry Finger and linux-wireless in the CC list.

regards,
dan carpenter

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

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Dexuan Cui]

> -Original Message-
> From: Paul Bolle
> Sent: Tuesday, July 7, 2015 17:38
> To: Dexuan Cui
> Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
> 
> Just two nits.
> 
> On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
> > --- /dev/null
> > +++ b/net/hv_sock/Kconfig
> 
> > +config HYPERV_SOCK
> > +   tristate "Microsoft Hyper-V Socket (EXPERIMENTAL)"
> > +   depends on HYPERV
> > +   default m
> > +   help
> > + Hyper-V Socket is a socket protocol similar to TCP, allowing
> > + communication between a Linux guest and the host.
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called hv_sock. If unsure, say N.
> 
> It's a bit odd to advise to say N if one is unsure and set the default
> to 'm' at the same time.
Hi Paul,
Thanks for the suggestion!
I'll change the 'default' to n in V2.

> > --- /dev/null
> > +++ b/net/hv_sock/af_hvsock.c
> 
> > +static int hvsock_init(void)
> > +{
> > +   [...]
> > +}
> > +
> > +static void hvsock_exit(void)
> > +{
> > +   [...]
> > +}
> > +
> > +module_init(hvsock_init);
> > +module_exit(hvsock_exit);
> 
> Any specific reason not to mark these functions __init and __exit?
> 
> Paul Bolle
Thanks for pointing this out -- I missed that. 
I'll add __init and __exit in V2.

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

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Olaf Hering]

On Tue, Jul 07, Paul Bolle wrote:

> On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
> > --- /dev/null
> > +++ b/net/hv_sock/Kconfig
> 
> > +config HYPERV_SOCK
> > +   tristate "Microsoft Hyper-V Socket (EXPERIMENTAL)"
> > +   depends on HYPERV
> > +   default m

> It's a bit odd to advise to say N if one is unsure and set the default
> to 'm' at the same time.

The 'default' line has to be removed IMO.

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

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Dexuan Cui]

> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Tuesday, July 7, 2015 18:10
> To: Dexuan Cui; Paul Bolle
> Cc: gre...@linuxfoundation.org; da...@davemloft.net;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; a...@canonical.com; jasow...@redhat.com; KY
> Srinivasan; Haiyang Zhang
> Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
> 
> On Tue, Jul 07, Paul Bolle wrote:
> 
> > On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
> > > --- /dev/null
> > > +++ b/net/hv_sock/Kconfig
> >
> > > +config HYPERV_SOCK
> > > + tristate "Microsoft Hyper-V Socket (EXPERIMENTAL)"
> > > + depends on HYPERV
> > > + default m
> 
> > It's a bit odd to advise to say N if one is unsure and set the default
> > to 'm' at the same time.
> 
> The 'default' line has to be removed IMO.
> 
> Olaf

OK, removing the line seems better than 'default n', though both reproduce
the same "# CONFIG_HYPERV_SOCK is not set".

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

Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

[Dmitry Kalinkin]

Hi Alessio,

[Sorry for double post]

> On 07 Jul 2015, at 10:08, Alessio Igor Bogani  
> wrote:
> 
> Hi Dmitry,
> 
> On 6 July 2015 at 19:24, Dmitry Kalinkin  wrote:
> [...]
> I'm not a VME expert, but it seems that VME windows are a quiet limited 
> resource
> no matter how you allocate your resources. Theoretically we could put up to 32
> different boards in a single crate, so there won't be enough windows for each
> driver to allocate. That said, there is no way around this when putting 
> together
> a really heterogeneous VME system. To overcome such problem, one could
> develop a different kernel API that would not provide windows to the
> drivers, but
> handle reads and writes by reconfiguring windows on the fly, which in turn 
> would
> introduce more latency.
> 
> In my humble opinion using user-space drivers (as workaround for limited 
> windows/images) introduce more latency than let VME driver dynamically 
> configure windows/images. After all VME systems usually aren't so much 
> dynamic by its nature (Who likes continuously put in and out a board which 
> requires an insertion force between 20 and 50 kg?) and are instead heavily 
> used in critical contexts often in non-stop way.
Userspace drivers are not exactly doing this differently. It’s just that you 
can use
that interface to quickly build more flexible site-specific software that knows 
about
whole VME system. So there, having a low level access to windows works well
(there is a 20+ year history of such drivers). But if we want reusable drivers,
especially in the kernel, that will require some more effort in making a driver 
stack.

The API I had in mind would have only vme_master_read and vme_master_write
that would take absolute addresses (not relative to any window). These variants
of access functions would then try to reuse any window that is already able to 
serve
the request or wait for a free window and reconfigure it for the need of the 
request.
After usage the window is to be returned back to the window pool.
Other way to implement these would be to use DMA for everything, since it 
doesn’t
have the limitations that the windows have.
> 
> In fact this is a big obstacle for adoption of this VME stack (at least for 
> us). We use VME a lot and we care about latency as well so we use only 
> kernel-space drivers for ours VME boards but unfortunately the VME stack let 
> us to link a single board with a single window/image (so max 8 boards on 
> tsi148) only. That said that stack has proven to be very rock solid.
Current VME stack links windows not to the boards, but to device drivers. Driver
could potentially minimise window usage within it’s scope (any sort of window
reusing, like mapping whole A16 once to be used with all boards), but this won’t
work across multiple drivers. Even if all of your drivers are window-wise 
economic,
they will still need some amount of windows per each driver. Not that we have 
that
many kernel drivers...
> 
> Until now we have used a modified version of the old vmelinux.org stack for 
> sharing windows/images between all (ours) VME kernel drivers and we would be 
> very happy to see something similar in vanilla (at least coalescence two 
> adjacent addresses with same modifiers).
>  
> Those who need such API are welcome to develop it :)
> 
> I would be glad to try it if the maintainer is willing to receive this type 
> of changes.
> 
> Ciao,
> Alessio
> 

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

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Olaf Hering]

On Tue, Jul 07, Dexuan Cui wrote:

> OK, removing the line seems better than 'default n', though both reproduce
> the same "# CONFIG_HYPERV_SOCK is not set".

Perhaps "default VMBUS" (or whatever syntax is needed) may be the way to
enable it conditionally.

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

Re: [RESEND] mfd: rtsx: add support for rts522A

[Lee Jones]

On Mon, 29 Jun 2015, micky_ch...@realsil.com.cn wrote:

> From: Micky Ching 
> 
> rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
> Add it to file mfd/rts5227.c to support this chip.
> 
> Signed-off-by: Micky Ching 
> ---
>  drivers/mfd/Kconfig  |  7 ++--
>  drivers/mfd/rts5227.c| 77 
> ++--
>  drivers/mfd/rtsx_pcr.c   |  5 +++
>  drivers/mfd/rtsx_pcr.h   |  3 ++
>  include/linux/mfd/rtsx_pci.h |  6 
>  5 files changed, 93 insertions(+), 5 deletions(-)

I Acked this once already.

What's changed since then?

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6538159..614c146 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -686,9 +686,10 @@ config MFD_RTSX_PCI
>   select MFD_CORE
>   help
> This supports for Realtek PCI-Express card reader including rts5209,
> -   rts5229, rtl8411, etc. Realtek card reader supports access to many
> -   types of memory cards, such as Memory Stick, Memory Stick Pro,
> -   Secure Digital and MultiMediaCard.
> +   rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
> +   Realtek card reader supports access to many types of memory cards,
> +   such as Memory Stick, Memory Stick Pro, Secure Digital and
> +   MultiMediaCard.
>  
>  config MFD_RT5033
>   tristate "Richtek RT5033 Power Management IC"
> diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
> index ce012d7..cf13e66 100644
> --- a/drivers/mfd/rts5227.c
> +++ b/drivers/mfd/rts5227.c
> @@ -26,6 +26,14 @@
>  
>  #include "rtsx_pcr.h"
>  
> +static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
> +{
> + u8 val;
> +
> + rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, &val);
> + return val & 0x0F;
> +}
> +
>  static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
>  {
>   u8 driving_3v3[4][3] = {
> @@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr, 
> u8 pm_state)
>   rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
>  
>   if (pm_state == HOST_ENTER_S3)
> - rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
> + rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
>  
>   rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
>  }
> @@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
>   else
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
> - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
> + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
>  
>   return rtsx_pci_send_cmd(pcr, 100);
>  }
> @@ -298,8 +306,73 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
>   pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
>   pcr->rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
>  
> + pcr->ic_version = rts5227_get_ic_version(pcr);
>   pcr->sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
>   pcr->sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
>   pcr->ms_pull_ctl_enable_tbl = rts5227_ms_pull_ctl_enable_tbl;
>   pcr->ms_pull_ctl_disable_tbl = rts5227_ms_pull_ctl_disable_tbl;
> +
> + pcr->reg_pm_ctrl3 = PM_CTRL3;
> +}
> +
> +static int rts522a_optimize_phy(struct rtsx_pcr *pcr)
> +{
> + int err;
> +
> + err = rtsx_pci_write_register(pcr, RTS522A_PM_CTRL3, D3_DELINK_MODE_EN,
> + 0x00);
> + if (err < 0)
> + return err;
> +
> + if (is_version(pcr, 0x522A, IC_VER_A)) {
> + err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
> + PHY_RCR2_INIT_27S);
> + if (err)
> + return err;
> +
> + rtsx_pci_write_phy_register(pcr, PHY_RCR1, PHY_RCR1_INIT_27S);
> + rtsx_pci_write_phy_register(pcr, PHY_FLD0, PHY_FLD0_INIT_27S);
> + rtsx_pci_write_phy_register(pcr, PHY_FLD3, PHY_FLD3_INIT_27S);
> + rtsx_pci_write_phy_register(pcr, PHY_FLD4, PHY_FLD4_INIT_27S);
> + }
> +
> + return 0;
> +}
> +
> +static int rts522a_extra_init_hw(struct rtsx_pcr *pcr)
> +{
> + rts5227_extra_init_hw(pcr);
> +
> + rtsx_pci_write_register(pcr, FUNC_FORCE_CTL, FUNC_FORCE_UPME_XMT_DBG,
> + FUNC_FORCE_UPME_XMT_DBG);
> + rtsx_pci_write_register(pcr, PCLK_CTL, 0x04, 0x04);
> + rtsx_pci_write_register(pcr, PM_EVENT_DEBUG, PME_DEBUG_0, PME_DEBUG_0);
> + rtsx_pci_write_register(pcr, PM_CLK_FORCE_CTL, 0xFF, 0x11);
> +
> + return 0;
> +}
> +
> +/* rts522a operations mainly derived from rts5227, except phy/hw init 
> setting.
> + */
> +static const struct pcr_ops rts522a_pcr_ops = {
> + .fetch_vendor_settings = rts5227_fetch_vendor_settings,
> + .extra_init_hw = rts522a_extra_init_hw,
> + .optimize_phy = rts522a_optimize_phy,
> + .turn_on_led = rts5227_turn_on_led,

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Paul Bolle]

On di, 2015-07-07 at 10:20 +, Dexuan Cui wrote:
> OK, removing the line seems better than 'default n', though both 
> reproduce the same "# CONFIG_HYPERV_SOCK is not set".

Speaking from memory (so chances are I'm forgetting some silly detail)
that is because
# CONFIG_FOO is not set

will be printed if FOO's dependencies are met and FOO either has a
"prompt" or a default of 'n'.

Hope this helps,


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

Re: Clarification for the use of additional fields in the message body

[SF Markus Elfring]

> I think that as far as these kernel mailing lists are concerned,
> the date of the update suggestion is the date on which you submitted the 
> patch,
> rather than the date you originally committed it to your local tree.

I imagine that there are committers who would like to keep
corresponding software development history a bit more accurate.


> If you wish to keep track of this evolution for yourself, or
> wish to share it, you're better off stashing it somewhere in a
> (public) git repo that you control.

Would it be nicer to preserve such data directly also
by the usual mail interface?


> If you insist on placing the date somewhere, you can also put the date
> there if you wish. It'll be ignored by git when applied.

This content management tool provides the capability to store
the discussed information by the parameters "--author=" and "--date=",
doesn't it?
Is the environment variable "GIT_AUTHOR_DATE" also interesting occasionally?

How often do you take extra care for passing appropriate data there?

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

Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

[Alessio Igor Bogani]

Hi Dmitry,

On 7 July 2015 at 12:47, Dmitry Kalinkin  wrote:
[...]
> The API I had in mind would have only vme_master_read and vme_master_write
> that would take absolute addresses (not relative to any window). These
> variants
> of access functions would then try to reuse any window that is already able
> to serve
> the request or wait for a free window and reconfigure it for the need of the
> request.
> After usage the window is to be returned back to the window pool.

Interesting approach.

> Other way to implement these would be to use DMA for everything, since it
> doesn’t
> have the limitations that the windows have.


> On 07 Jul 2015, at 10:08, Alessio Igor Bogani 
> wrote:
[...]
>> In fact this is a big obstacle for adoption of this VME stack (at least for
>> us). We use VME a lot and we care about latency as well so we use only
>> kernel-space drivers for ours VME boards but unfortunately the VME stack let
>> us to link a single board with a single window/image (so max 8 boards on
>> tsi148) only. That said that stack has proven to be very rock solid.
>
> Current VME stack links windows not to the boards, but to device drivers.
> Driver
> could potentially minimise window usage within it’s scope (any sort of
> window
> reusing, like mapping whole A16 once to be used with all boards), but this
> won’t
> work across multiple drivers. Even if all of your drivers are window-wise
> economic,
> they will still need some amount of windows per each driver. Not that we
> have that
> many kernel drivers...

Yes you can share a window/image between all boards of the same type
(in effect we are porting our drivers in this way) *but* it isn't the
expected way to work (see Documentation/vme_api.txt struct
vme_driver's probe() and match() functions and the GE PIO2 VME
driver).

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

Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality

[Dmitry Kalinkin]

> On 07 Jul 2015, at 15:51, Alessio Igor Bogani  
> wrote:
> 

>> Current VME stack links windows not to the boards, but to device drivers.
>> Driver
>> could potentially minimise window usage within it’s scope (any sort of
>> window
>> reusing, like mapping whole A16 once to be used with all boards), but this
>> won’t
>> work across multiple drivers. Even if all of your drivers are window-wise
>> economic,
>> they will still need some amount of windows per each driver. Not that we
>> have that
>> many kernel drivers...
> 
> Yes you can share a window/image between all boards of the same type
> (in effect we are porting our drivers in this way) *but* it isn't the
> expected way to work (see Documentation/vme_api.txt struct
> vme_driver's probe() and match() functions and the GE PIO2 VME
> driver).
And vme_pio2 can’t handle more than 8 boards. This shows that the current
design needs some adjustments. Also would be great if probe() and match()
allowed for void *private data field.

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

Re: Clarification for the use of additional fields in the message body

[Frans Klaver]

On Tue, Jul 7, 2015 at 1:53 PM, SF Markus Elfring
 wrote:
>> I think that as far as these kernel mailing lists are concerned,
>> the date of the update suggestion is the date on which you submitted the 
>> patch,
>> rather than the date you originally committed it to your local tree.
>
> I imagine that there are committers who would like to keep
> corresponding software development history a bit more accurate.

I guess it depends on what your view on accurate is.


>> If you wish to keep track of this evolution for yourself, or
>> wish to share it, you're better off stashing it somewhere in a
>> (public) git repo that you control.
>
> Would it be nicer to preserve such data directly also
> by the usual mail interface?
>
>
>> If you insist on placing the date somewhere, you can also put the date
>> there if you wish. It'll be ignored by git when applied.
>
> This content management tool provides the capability to store
> the discussed information by the parameters "--author=" and "--date=",
> doesn't it?
> Is the environment variable "GIT_AUTHOR_DATE" also interesting occasionally?
>
> How often do you take extra care for passing appropriate data there?

I can't remember ever changing or explicitly preserving the commit
date. I don't think I care enough. I did change the author on botched
patches, but that's an exception. Remembering the author separately
from the committer is something git does by design anyway.

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

[PATCH 0/5] usb: gadget: miscellaneous fixes

[Robert Baldyga]

Hello,

This patch set contains few small bugfixes found in usb gadget functions
and UDC drivers. The most important is the [1] as it fixes bug causing
BUG_ON() in f_fs driver. Remaining patches contain minor fixes.

Best regards,
Robert Baldyga

[1] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails

Robert Baldyga (5):
  usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails
  usb: gadget: midi: avoid redundant f_midi_set_alt() call
  usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()
  staging: emxx_udc: add missing usb_ep_set_maxpacket_limit()
  usb: gadget: atmel_usba_udc: add missing ret value check

 drivers/staging/emxx_udc/emxx_udc.c |  3 ++-
 drivers/usb/gadget/function/f_fs.c  | 10 +-
 drivers/usb/gadget/function/f_midi.c|  4 
 drivers/usb/gadget/udc/atmel_usba_udc.c |  4 
 drivers/usb/isp1760/isp1760-udc.c   |  4 ++--
 5 files changed, 21 insertions(+), 4 deletions(-)

-- 
1.9.1

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

[PATCH 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails

[Robert Baldyga]

Function ffs_do_functionfs_bind() calls functionfs_bind() which allocates
usb request and increments refcounts. These things needs to be cleaned
up by if further steps of initialization fail by calling functionfs_unbind().

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/function/f_fs.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 6e7be91..966b214 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2897,11 +2897,19 @@ static int ffs_func_bind(struct usb_configuration *c,
 struct usb_function *f)
 {
struct f_fs_opts *ffs_opts = ffs_do_functionfs_bind(f, c);
+   struct ffs_function *func = ffs_func_from_usb(f);
+   int ret;
 
if (IS_ERR(ffs_opts))
return PTR_ERR(ffs_opts);
 
-   return _ffs_func_bind(c, f);
+   ret = _ffs_func_bind(c, f);
+   if (ret) {
+   ffs_opts->refcnt--;
+   functionfs_unbind(func->ffs);
+   }
+
+   return ret;
 }
 
 
-- 
1.9.1

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

[PATCH 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()

[Robert Baldyga]

Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/isp1760/isp1760-udc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/isp1760/isp1760-udc.c 
b/drivers/usb/isp1760/isp1760-udc.c
index 18ebf5b1..3699962 100644
--- a/drivers/usb/isp1760/isp1760-udc.c
+++ b/drivers/usb/isp1760/isp1760-udc.c
@@ -1382,11 +1382,11 @@ static void isp1760_udc_init_eps(struct isp1760_udc 
*udc)
 * This fits in the 8kB FIFO without double-buffering.
 */
if (ep_num == 0) {
-   ep->ep.maxpacket = 64;
+   usb_ep_set_maxpacket_limit(&ep->ep, 64);
ep->maxpacket = 64;
udc->gadget.ep0 = &ep->ep;
} else {
-   ep->ep.maxpacket = 512;
+   usb_ep_set_maxpacket_limit(&ep->ep, 512);
ep->maxpacket = 0;
list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
}
-- 
1.9.1

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

[PATCH 2/5] usb: gadget: midi: avoid redundant f_midi_set_alt() call

[Robert Baldyga]

Function midi registers two interfaces with single set_alt() function
which means that f_midi_set_alt() is called twice when configuration
is set. That means that endpoint initialization and ep request allocation
is done two times. To avoid this problem we do such things only once,
for interface number 1 (MIDI Streaming interface).

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/function/f_midi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index 6316aa5..4cef222 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -329,6 +329,10 @@ static int f_midi_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
unsigned i;
int err;
 
+   /* For Control Device interface we do nothing */
+   if (intf == 0)
+   return 0;
+
err = f_midi_start_ep(midi, f, midi->in_ep);
if (err)
return err;
-- 
1.9.1

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

[PATCH 4/5] staging: emxx_udc: add missing usb_ep_set_maxpacket_limit()

[Robert Baldyga]

Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.

Signed-off-by: Robert Baldyga 
---
 drivers/staging/emxx_udc/emxx_udc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 4178d96..f50bf5d 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3203,7 +3203,8 @@ static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc 
*udc)
ep->ep.name = gp_ep_name[i];
ep->ep.ops = &nbu2ss_ep_ops;
 
-   ep->ep.maxpacket = (i == 0 ? EP0_PACKETSIZE : EP_PACKETSIZE);
+   usb_ep_set_maxpacket_limit(&ep->ep,
+   (i == 0 ? EP0_PACKETSIZE : EP_PACKETSIZE));
 
list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
INIT_LIST_HEAD(&ep->queue);
-- 
1.9.1

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

[PATCH 5/5] usb: gadget: atmel_usba_udc: add missing ret value check

[Robert Baldyga]

Add missing return value check. In case of error print debug message
and return error code.

Signed-off-by: Robert Baldyga 
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 4095cce0..37d414e 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1989,6 +1989,10 @@ static struct usba_ep * atmel_udc_of_init(struct 
platform_device *pdev,
ep->can_isoc = of_property_read_bool(pp, "atmel,can-isoc");
 
ret = of_property_read_string(pp, "name", &name);
+   if (ret) {
+   dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
+   goto err;
+   }
ep->ep.name = name;
 
ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
-- 
1.9.1

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

Re: [PATCH 4/5] staging: emxx_udc: add missing usb_ep_set_maxpacket_limit()

[Sergei Shtylyov]

Hello.

On 7/7/2015 5:02 PM, Robert Baldyga wrote:


Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.



Signed-off-by: Robert Baldyga 
---
  drivers/staging/emxx_udc/emxx_udc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)



diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 4178d96..f50bf5d 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3203,7 +3203,8 @@ static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc 
*udc)
ep->ep.name = gp_ep_name[i];
ep->ep.ops = &nbu2ss_ep_ops;

-   ep->ep.maxpacket = (i == 0 ? EP0_PACKETSIZE : EP_PACKETSIZE);
+   usb_ep_set_maxpacket_limit(&ep->ep,
+   (i == 0 ? EP0_PACKETSIZE : EP_PACKETSIZE));


   Inner () not needed.

[...]

WBR, Sergei

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

Re: [PATCH 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails

[Dan Carpenter]

On Tue, Jul 07, 2015 at 04:02:49PM +0200, Robert Baldyga wrote: 
> diff --git a/drivers/usb/gadget/function/f_fs.c 
> b/drivers/usb/gadget/function/f_fs.c
> index 6e7be91..966b214 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -2897,11 +2897,19 @@ static int ffs_func_bind(struct usb_configuration *c,
>struct usb_function *f)
>  {
>   struct f_fs_opts *ffs_opts = ffs_do_functionfs_bind(f, c);
> + struct ffs_function *func = ffs_func_from_usb(f);
> + int ret;
>  
>   if (IS_ERR(ffs_opts))
>   return PTR_ERR(ffs_opts);
>  
> - return _ffs_func_bind(c, f);
> + ret = _ffs_func_bind(c, f);
> + if (ret) {
> + ffs_opts->refcnt--;

Wait, why are we decrementing here?  ffs_func_unbind() already has a
decrement so this looks like a bug to me.  Add a comment if it's really
needed.

> + functionfs_unbind(func->ffs);

regards,
dan carpenter


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

Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant

[Vitaly Kuznetsov]

KY Srinivasan  writes:

>> -Original Message-
>> From: Christoph Hellwig [mailto:h...@infradead.org]
>> Sent: Friday, July 3, 2015 9:19 AM
>> To: Vitaly Kuznetsov
>> Cc: linux-s...@vger.kernel.org; Long Li; KY Srinivasan; Haiyang Zhang; James
>> E.J. Bottomley; de...@linuxdriverproject.org; linux-ker...@vger.kernel.org
>> Subject: Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant
>> 
>> On Wed, Jul 01, 2015 at 11:04:08AM +0200, Vitaly Kuznetsov wrote:
>> > SPC-2/3/4 specs state that "The standard INQUIRY data (see table ...)
>> > shall contain at least 36 bytes". Hyper-V host doesn't always honor this
>> > requirement, e.g. when there is no physical device present at a particular
>> > LUN host sets Peripheral qualifier to 011b and Additional length to 0
>> > (thus making the reply 5-bytes long). Upper level SCSI stack complains
>> > with 'INQUIRY result too short (5), using 36'. Fix the issue by mangling
>> > Additional length field in host's reply at the driver level.
>> 
>> This looks like a big mess, and usage of phys_to_virt is not generally
>> safe to start with.
>> 
>> If HyperV really is that broken the warning seems correct, but if you
>> really have to get rid of it we could add a blist flag to not issue
>> the warning in the core code instead of hacking around it in the driver.
>
> Agreed. We have fixed this issue in win10 and I am trying to get the fix 
> backported.

In case this is fixed in future Hyper-V versions introducing new blist
flags looks like an overkill, let's leave things as they are.

Thanks,

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

Re: [PATCH 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()

[Dan Carpenter]

On Tue, Jul 07, 2015 at 04:02:51PM +0200, Robert Baldyga wrote:
> Should use usb_ep_set_maxpacket_limit instead of setting
> maxpacket value manually.
> 

This is a behavior change, right, since now we're setting
ep->ep.maxpacket and ep->ep.maxpacket_limit where before we only set
the first.  I don't understand.  This patch description is not clear.

regards,
dan carpenter

> Signed-off-by: Robert Baldyga 
> ---
>  drivers/usb/isp1760/isp1760-udc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/isp1760/isp1760-udc.c 
> b/drivers/usb/isp1760/isp1760-udc.c
> index 18ebf5b1..3699962 100644
> --- a/drivers/usb/isp1760/isp1760-udc.c
> +++ b/drivers/usb/isp1760/isp1760-udc.c
> @@ -1382,11 +1382,11 @@ static void isp1760_udc_init_eps(struct isp1760_udc 
> *udc)
>* This fits in the 8kB FIFO without double-buffering.
>*/
>   if (ep_num == 0) {
> - ep->ep.maxpacket = 64;
> + usb_ep_set_maxpacket_limit(&ep->ep, 64);
>   ep->maxpacket = 64;
>   udc->gadget.ep0 = &ep->ep;
>   } else {
> - ep->ep.maxpacket = 512;
> + usb_ep_set_maxpacket_limit(&ep->ep, 512);
>   ep->maxpacket = 0;
>   list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
>   }

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

Re: [PATCH 4/5] staging: emxx_udc: add missing usb_ep_set_maxpacket_limit()

[Dan Carpenter]

On Tue, Jul 07, 2015 at 04:02:52PM +0200, Robert Baldyga wrote:
> Should use usb_ep_set_maxpacket_limit instead of setting
> maxpacket value manually.
> 

Same question.

regards,
dan carpenter

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

[PATCH] staging: comedi: use CAP_SYS_ADMIN instead of CAP_NET_ADMIN

[Ian Abbott]

If the "comedi" module has been loaded with the
"comedi_num_legacy_minors" module parameter set to a non-zero value,
some reserved comedi devices get created.  These can be attached to a
low-level comedi driver using the `COMEDI_DEVCONFIG` ioctl command,
which checks for the `CAP_SYS_ADMIN` capability.  Of course, the comedi
device needs to be opened before the ioctl command can be sent.  If the
comedi device is unattached, `comedi_open()` currently requires the
`CAP_NET_ADMIN` capability.  It makes more sense to just require the
`CAP_SYS_ADMIN` capability here, so change it.

For the curious, commit a8f80e8ff94e ("Networking: use CAP_NET_ADMIN
when deciding to call request_module") changed this capability from
`CAP_SYS_MODULE` to `CAP_NET_ADMIN`, even though it doesn't seem
relevant here.  The original `CAP_SYS_MODULE` capability was due to the
function having some code to request a module using a "char-major-%i-%i"
alias, but that was never compiled in and was removed by commit
f30f2c2d417b ("staging: comedi: remove check for CONFIG_KMOD").

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/comedi_fops.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 985d94b..1679bfb 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2599,8 +2599,8 @@ static int comedi_open(struct inode *inode, struct file 
*file)
cfp->dev = dev;
 
mutex_lock(&dev->mutex);
-   if (!dev->attached && !capable(CAP_NET_ADMIN)) {
-   dev_dbg(dev->class_dev, "not attached and not CAP_NET_ADMIN\n");
+   if (!dev->attached && !capable(CAP_SYS_ADMIN)) {
+   dev_dbg(dev->class_dev, "not attached and not CAP_SYS_ADMIN\n");
rc = -ENODEV;
goto out;
}
-- 
2.1.4

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

Re: Clarification for the use of additional fields in the message body

[SF Markus Elfring]

> I can't remember ever changing or explicitly preserving the commit date.
> I don't think I care enough.

Would any more software developers and maintainers like to share
their experiences around such details?

When do commit timestamps become relevant as a documentation item
for contribution authorship?


> Remembering the author separately from the committer is something
> git does by design anyway.

Do you usually just reuse a procedure from a well-known command
for which a description is provided like the following?
http://git-scm.com/docs/git-am
'…
"From: " and "Subject: " lines starting the body override
the respective commit author name and title values
taken from the headers.
…'

Will further fields be eventually mentioned there?

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

Re: [PATCH 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails

[Robert Baldyga]

On 07/07/2015 04:53 PM, Dan Carpenter wrote:

On Tue, Jul 07, 2015 at 04:02:49PM +0200, Robert Baldyga wrote:

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 6e7be91..966b214 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2897,11 +2897,19 @@ static int ffs_func_bind(struct usb_configuration *c,
 struct usb_function *f)
  {
struct f_fs_opts *ffs_opts = ffs_do_functionfs_bind(f, c);
+   struct ffs_function *func = ffs_func_from_usb(f);
+   int ret;

if (IS_ERR(ffs_opts))
return PTR_ERR(ffs_opts);

-   return _ffs_func_bind(c, f);
+   ret = _ffs_func_bind(c, f);
+   if (ret) {
+   ffs_opts->refcnt--;


Wait, why are we decrementing here?  ffs_func_unbind() already has a
decrement so this looks like a bug to me.  Add a comment if it's really
needed.


Decrement is done in ffs_func_unbind() which is not called in this error 
path. But after all I see another problem here, because we shouldn't 
call functionfs_unbind() if refcnt after decrement is not equal zero. I 
will fix it.





+   functionfs_unbind(func->ffs);


Thanks,
Robert Baldyga

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

Re: [PATCH 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()

[Robert Baldyga]

On 07/07/2015 05:01 PM, Dan Carpenter wrote:

On Tue, Jul 07, 2015 at 04:02:51PM +0200, Robert Baldyga wrote:

Should use usb_ep_set_maxpacket_limit instead of setting
maxpacket value manually.



This is a behavior change, right, since now we're setting
ep->ep.maxpacket and ep->ep.maxpacket_limit where before we only set
the first.  I don't understand.  This patch description is not clear.


Since maxpacket_limit was introduced all UDC drivers should set it, as 
it is used by epautoconf. The ep.maxpacket_limit contains actual maximum 
maxpacket value supported by hardware, ep.maxpacket is set only for 
backward compatibility. Hence setting maxpacket manually instead of 
using usb_ep_set_maxpacket_limit() is actually a bug.


I will add better description to commit message.




Signed-off-by: Robert Baldyga 
---
  drivers/usb/isp1760/isp1760-udc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/isp1760/isp1760-udc.c 
b/drivers/usb/isp1760/isp1760-udc.c
index 18ebf5b1..3699962 100644
--- a/drivers/usb/isp1760/isp1760-udc.c
+++ b/drivers/usb/isp1760/isp1760-udc.c
@@ -1382,11 +1382,11 @@ static void isp1760_udc_init_eps(struct isp1760_udc 
*udc)
 * This fits in the 8kB FIFO without double-buffering.
 */
if (ep_num == 0) {
-   ep->ep.maxpacket = 64;
+   usb_ep_set_maxpacket_limit(&ep->ep, 64);
ep->maxpacket = 64;
udc->gadget.ep0 = &ep->ep;
} else {
-   ep->ep.maxpacket = 512;
+   usb_ep_set_maxpacket_limit(&ep->ep, 512);
ep->maxpacket = 0;
list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
}


Thanks,
Robert Baldyga

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

[PATCH] staging: comedi: cb_pcimdas: add external analog output ranges

[Ian Abbott]

The analog output range is not programmable, but the ranges for each of
the two analog output channels are settable via jumpers.  These jumper
settings are not readable by the driver.  The driver
provides a range table containing all the possible internal ranges
(+/-10V, +/-5V, 0-10V, 0-5V) to provide information to the user
application (although any range selected by the application that differs
from the jumper settings will not produce the expected voltage output).

The range table does not cover all possible ranges of the analog output
channels.  The jumpers also allow an external reference voltage between
0 and 10V to be used as bipolar or unipolar output range.  Add a couple
more ranges to the end of the range table to define these two external
ranges.

Signed-off-by: Ian Abbott 
---
 drivers/staging/comedi/drivers/cb_pcimdas.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/cb_pcimdas.c 
b/drivers/staging/comedi/drivers/cb_pcimdas.c
index 4ebf5aa..47e3839 100644
--- a/drivers/staging/comedi/drivers/cb_pcimdas.c
+++ b/drivers/staging/comedi/drivers/cb_pcimdas.c
@@ -141,11 +141,13 @@ static const struct comedi_lrange cb_pcimdas_ai_uni_range 
= {
  * jumper-settable on the board. The settings are not software-readable.
  */
 static const struct comedi_lrange cb_pcimdas_ao_range = {
-   4, {
+   6, {
BIP_RANGE(10),
BIP_RANGE(5),
UNI_RANGE(10),
-   UNI_RANGE(5)
+   UNI_RANGE(5),
+   RANGE_ext(-1, 1),
+   RANGE_ext(0, 1)
}
 };
 
-- 
2.1.4

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

staging: rtl8192e: function naming cleanup

[Mateusz Kulikowski]

Hi,

One of TODOs for driver I'm working on is cleanup of function names;

I'm working (amongst other things) on that and would like to know 
if and how would you like it submitted:

1 As a one big patch for whole driver 
  (IMO it will be very hard to review unless you have scripts to verify it)
2 Patch per each function (A lot of small patches)
3 all simple static renames in one patch, 'global' and with significantly 
  different names - one patch per function
4 Other ideas?

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

Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Stephen Hemminger]

On Mon,  6 Jul 2015 07:47:29 -0700
Dexuan Cui  wrote:

> Hyper-V VM sockets (hvsock) supplies a byte-stream based communication
> mechanism between the host and a guest. It's kind of TCP over VMBus, but
> the transportation layer (VMBus) is much simpler than IP. With Hyper-V VM
> Sockets, applications between the host and a guest can talk with each
> other directly by the traditional BSD-style socket APIs.
> 
> Hyper-V VM Sockets is only available on Windows 10 host and later. The
> patch implements the necessary support in the guest side by introducing
> a new socket address family AF_HYPERV.
> 
> Signed-off-by: Dexuan Cui 

Is there any chance that AF_VSOCK could be used with different transport
for VMware and Hyper-V. Better to make guest applications host independent.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c

[Valdis . Kletnieks]

On Mon, 06 Jul 2015 21:53:26 -0400, Sreenath Madasu said:
> When the checkpatch.pl script was run, it showed lines with length
> more than 80 characters in rtw_ap.c file. Fixed line number 382 by
> breaking it up into two lines within 80 characters.


> - stainfo_offset = rtw_stainfo_offset(pstapriv, 
> psta);
> + stainfo_offset =
> + rtw_stainfo_offset(pstapriv, psta);
>   if (stainfo_offset_valid(stainfo_offset))
>   chk_alive_list[chk_alive_num++] = 
> stainfo_offset;

Umm... Sreenath?

There's 97 more occurrences of the same problem in that file.

All:  Is it time to kill that checkpatch test, or hide it behind a non-default
flag, to prevent code churn?



pgp_b5RCqkCz8.pgp
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c

[Joe Perches]

On Tue, 2015-07-07 at 15:32 -0400, valdis.kletni...@vt.edu wrote:
> All:  Is it time to kill that checkpatch test, or hide it behind a non-default
> flag, to prevent code churn?

 I'm not an 80 column zealot.

This is for staging isn't it?
Code churn there is expected and somewhat desired.

A lot of time, code churn can be useful when it
reduces the indentation depth.

For instance, this code could use continue more.

The longest line in this file is 158 chars, that's
probably excessive,  awk shows 35 lines > 80 chars.

staging rtl files have a couple hundred lines > 132
and thousands of lines > 80.


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

Re: staging: rtl8192e: function naming cleanup

[Greg KH]

On Tue, Jul 07, 2015 at 07:35:24PM +0200, Mateusz Kulikowski wrote:
> Hi,
> 
> One of TODOs for driver I'm working on is cleanup of function names;
> 
> I'm working (amongst other things) on that and would like to know 
> if and how would you like it submitted:
> 
> 1 As a one big patch for whole driver 
>   (IMO it will be very hard to review unless you have scripts to verify it)
> 2 Patch per each function (A lot of small patches)

This please.  It's easy to verify and review.  I can handle thousands of
patches quite easily, don't ever feel bad about sending lots of
patches.

thanks,

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

Re: [PATCH] Alternate rtl8192cu driver.

[P. Varet]

On 07/07/15 11:54, Dan Carpenter wrote:


https://bugzilla.kernel.org/show_bug.cgi?id=57171

This bug is a confusing mix of issues and it seems to be fixed.  Just
use network manager.


Hi Dan! Thank you for your reply!

I gave it another try, then. The behavior was the same as described 
before, and the device failed to work, as before. That's with kernel 
3.19.0 and NetworkManager 0.9.10 (both from the latest stable Ubuntu 
release).


The last commenter on that bug report appears to have given up on 
helping fix it after finding a version of Realtek's driver patched to 
work on recent kernels... So, what I've been offering. I find myself 
hoping that my work hasn't in fact slowed down the actual bug getting fixed.



If there are still an issues we can start a new
thread with Larry Finger and linux-wireless in the CC list.


That would probably help, yes. Thanks, Dan. :)

In the meanwhile, shouldn't we officially consider the affected devices 
unsupported? I don't very much like the idea of people buying said 
devices in good faith and then realizing that they're in fact not usable 
on Linux by default. (Mind, I have no idea what the proper policy is in 
those matter. Does this suggestion make any sense?)


Cheers,

-- P.

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

Re: [PATCH] Alternate rtl8192cu driver.

[Greg KH]

On Tue, Jul 07, 2015 at 11:37:55PM +0200, P. Varet wrote:
> On 07/07/15 11:54, Dan Carpenter wrote:
> 
> >https://bugzilla.kernel.org/show_bug.cgi?id=57171
> >
> >This bug is a confusing mix of issues and it seems to be fixed.  Just
> >use network manager.
> 
> Hi Dan! Thank you for your reply!
> 
> I gave it another try, then. The behavior was the same as described before,
> and the device failed to work, as before. That's with kernel 3.19.0 and
> NetworkManager 0.9.10 (both from the latest stable Ubuntu release).
> 
> The last commenter on that bug report appears to have given up on helping
> fix it after finding a version of Realtek's driver patched to work on recent
> kernels... So, what I've been offering. I find myself hoping that my work
> hasn't in fact slowed down the actual bug getting fixed.
> 
> >If there are still an issues we can start a new
> >thread with Larry Finger and linux-wireless in the CC list.
> 
> That would probably help, yes. Thanks, Dan. :)
> 
> In the meanwhile, shouldn't we officially consider the affected devices
> unsupported? I don't very much like the idea of people buying said devices
> in good faith and then realizing that they're in fact not usable on Linux by
> default. (Mind, I have no idea what the proper policy is in those matter.
> Does this suggestion make any sense?)

That doesn't make much sense.  If the device doesn't work properly with
the in-kernel driver, contact the author of it, and the mailing list of
the subsystem, and work with them to resolve the issue.

That's as "supported" as anything is with Linux :)

thanks,

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

Re: Clarification for the use of additional fields in the message body

[Julian Calaby]

Hi Markus,

On Wed, Jul 8, 2015 at 2:15 AM, SF Markus Elfring
 wrote:
>> I can't remember ever changing or explicitly preserving the commit date.
>> I don't think I care enough.
>
> Would any more software developers and maintainers like to share
> their experiences around such details?
>
> When do commit timestamps become relevant as a documentation item
> for contribution authorship?

They are never relevant.

"When" a commit happened is never relevant except in relation to other
things, at which point the actual date and time is almost completely
irrelevant.

Just submit your patches using git-format-patch or git-send-email and
friends. There's a file in the documentation directory of the kernel
tree describing submitting patches and email client setup. Read them
both, do what they say without anything extra.

>> Remembering the author separately from the committer is something
>> git does by design anyway.
>
> Do you usually just reuse a procedure from a well-known command
> for which a description is provided like the following?
> http://git-scm.com/docs/git-am
> '…
> "From: " and "Subject: " lines starting the body override
> the respective commit author name and title values
> taken from the headers.
> …'
>
> Will further fields be eventually mentioned there?

Why? Just do what is described in SubmittingPatches. Your attempts to
"improve" on the system are unnecessary and annoying people. The
instructions there are the recommended way to do things for a reason.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RESEND] mfd: rtsx: add support for rts522A

[敬锐]

On 07/07/2015 07:46 PM, Lee Jones wrote:
> On Mon, 29 Jun 2015, micky_ch...@realsil.com.cn wrote:
>
>> From: Micky Ching 
>>
>> rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
>> Add it to file mfd/rts5227.c to support this chip.
>>
>> Signed-off-by: Micky Ching 
>> ---
>>   drivers/mfd/Kconfig  |  7 ++--
>>   drivers/mfd/rts5227.c| 77 
>> ++--
>>   drivers/mfd/rtsx_pcr.c   |  5 +++
>>   drivers/mfd/rtsx_pcr.h   |  3 ++
>>   include/linux/mfd/rtsx_pci.h |  6 
>>   5 files changed, 93 insertions(+), 5 deletions(-)
> I Acked this once already.
>
> What's changed since then?
It's not changed, but I don't have time to fix magic numbers these days,
so, I prefer you apply this patch not waiting next patch.

Thanks.
>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 6538159..614c146 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -686,9 +686,10 @@ config MFD_RTSX_PCI
>>  select MFD_CORE
>>  help
>>This supports for Realtek PCI-Express card reader including rts5209,
>> -  rts5229, rtl8411, etc. Realtek card reader supports access to many
>> -  types of memory cards, such as Memory Stick, Memory Stick Pro,
>> -  Secure Digital and MultiMediaCard.
>> +  rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
>> +  Realtek card reader supports access to many types of memory cards,
>> +  such as Memory Stick, Memory Stick Pro, Secure Digital and
>> +  MultiMediaCard.
>>   
>>   config MFD_RT5033
>>  tristate "Richtek RT5033 Power Management IC"
>> diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
>> index ce012d7..cf13e66 100644
>> --- a/drivers/mfd/rts5227.c
>> +++ b/drivers/mfd/rts5227.c
>> @@ -26,6 +26,14 @@
>>   
>>   #include "rtsx_pcr.h"
>>   
>> +static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
>> +{
>> +u8 val;
>> +
>> +rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, &val);
>> +return val & 0x0F;
>> +}
>> +
>>   static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
>>   {
>>  u8 driving_3v3[4][3] = {
>> @@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr, 
>> u8 pm_state)
>>  rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
>>   
>>  if (pm_state == HOST_ENTER_S3)
>> -rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
>> +rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
>>   
>>  rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
>>   }
>> @@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
>>  rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
>>  else
>>  rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
>> -rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
>>   
>>  return rtsx_pci_send_cmd(pcr, 100);
>>   }
>> @@ -298,8 +306,73 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
>>  pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
>>  pcr->rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
>>   
>> +pcr->ic_version = rts5227_get_ic_version(pcr);
>>  pcr->sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
>>  pcr->sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
>>  pcr->ms_pull_ctl_enable_tbl = rts5227_ms_pull_ctl_enable_tbl;
>>  pcr->ms_pull_ctl_disable_tbl = rts5227_ms_pull_ctl_disable_tbl;
>> +
>> +pcr->reg_pm_ctrl3 = PM_CTRL3;
>> +}
>> +
>> +static int rts522a_optimize_phy(struct rtsx_pcr *pcr)
>> +{
>> +int err;
>> +
>> +err = rtsx_pci_write_register(pcr, RTS522A_PM_CTRL3, D3_DELINK_MODE_EN,
>> +0x00);
>> +if (err < 0)
>> +return err;
>> +
>> +if (is_version(pcr, 0x522A, IC_VER_A)) {
>> +err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
>> +PHY_RCR2_INIT_27S);
>> +if (err)
>> +return err;
>> +
>> +rtsx_pci_write_phy_register(pcr, PHY_RCR1, PHY_RCR1_INIT_27S);
>> +rtsx_pci_write_phy_register(pcr, PHY_FLD0, PHY_FLD0_INIT_27S);
>> +rtsx_pci_write_phy_register(pcr, PHY_FLD3, PHY_FLD3_INIT_27S);
>> +rtsx_pci_write_phy_register(pcr, PHY_FLD4, PHY_FLD4_INIT_27S);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int rts522a_extra_init_hw(struct rtsx_pcr *pcr)
>> +{
>> +rts5227_extra_init_hw(pcr);
>> +
>> +rtsx_pci_write_register(pcr, FUNC_FORCE_CTL, FUNC_FORCE_UPME_XMT_DBG,
>> +FUNC_FORCE_UPME_XMT_DBG);
>> +rtsx_pci_write_register(pcr, PCLK_CTL, 0x04, 0x04);
>> +rtsx_pci_write_register(pcr, PM_EVENT_DEBUG, PME_DEBUG_0, PME_DEBUG_0);
>> +rtsx_pci_write_register(pcr, PM_CLK_FORCE_CTL, 0xFF, 0x11);
>> +
>> +return 0;
>> +}
>> +
>> +/* rts522a operations mainly derived from rts5227, except phy/hw init 

Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c

[Sreenath Madasu]

The kernelnewbies.org guide said "For your first patch, only pick one
warning". That is the reason why I fixed one warning.

Thanks
Sreenath
On Tue, Jul 07, 2015 at 03:32:50PM -0400, valdis.kletni...@vt.edu wrote:
> On Mon, 06 Jul 2015 21:53:26 -0400, Sreenath Madasu said:
> > When the checkpatch.pl script was run, it showed lines with length
> > more than 80 characters in rtw_ap.c file. Fixed line number 382 by
> > breaking it up into two lines within 80 characters.
> 
> 
> > -   stainfo_offset = rtw_stainfo_offset(pstapriv, 
> > psta);
> > +   stainfo_offset =
> > +   rtw_stainfo_offset(pstapriv, psta);
> > if (stainfo_offset_valid(stainfo_offset))
> > chk_alive_list[chk_alive_num++] = 
> > stainfo_offset;
> 
> Umm... Sreenath?
> 
> There's 97 more occurrences of the same problem in that file.
> 
> All:  Is it time to kill that checkpatch test, or hide it behind a non-default
> flag, to prevent code churn?
> 


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

[PATCH] STAGING SUBSYSTEM rtl8188eu driver : Fixed 80 character length warning in rtw_ap.c

[Sreenath Madasu]

When the checkpatch.pl script was run, it showed lines with length
more than 80 characters in rtw_ap.c file. Fixed line number 382 by
breaking it up into two lines within 80 characters.

Signed-off-by: Sreenath Madasu 
---
 drivers/staging/rtl8188eu/core/rtw_ap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c 
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 581af88..293510e 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -379,7 +379,8 @@ voidexpire_timeout_chk(struct adapter *padapter)
if (pmlmeext->active_keep_alive_check) {
int stainfo_offset;
 
-   stainfo_offset = rtw_stainfo_offset(pstapriv, 
psta);
+   stainfo_offset =
+   rtw_stainfo_offset(pstapriv, psta);
if (stainfo_offset_valid(stainfo_offset))
chk_alive_list[chk_alive_num++] = 
stainfo_offset;
continue;
-- 
2.3.6

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

Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c

[Valdis . Kletnieks]

On Tue, 07 Jul 2015 21:08:10 -0400, Sreenath Madasu said:
> The kernelnewbies.org guide said "For your first patch, only pick one
> warning". That is the reason why I fixed one warning.

They mean "don't fix lines over 80 characters *and* missing-blank
warnings in the same patch".


pgpoBhFQVf2aM.pgp
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c

[Valdis . Kletnieks]

On Tue, 07 Jul 2015 13:38:47 -0700, Joe Perches said:

> The longest line in this file is 158 chars, that's
> probably excessive,  awk shows 35 lines > 80 chars.

That doesn't count tabs. Checkpatch throws 98 warnings.


pgpyA7aIF0_ni.pgp
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c

[Joe Perches]

On Tue, 2015-07-07 at 22:08 -0400, valdis.kletni...@vt.edu wrote:
> On Tue, 07 Jul 2015 13:38:47 -0700, Joe Perches said:
> 
> > The longest line in this file is 158 chars, that's
> > probably excessive,  awk shows 35 lines > 80 chars.
> 
> That doesn't count tabs. Checkpatch throws 98 warnings.

Yup, forgot the expand.


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

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Dexuan Cui]

> -Original Message-
> From: Stephen Hemminger
> Sent: Wednesday, July 8, 2015 2:31
> Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
>
> On Mon,  6 Jul 2015 07:47:29 -0700
> Dexuan Cui  wrote:
>
> > Hyper-V VM sockets (hvsock) supplies a byte-stream based communication
> > mechanism between the host and a guest. It's kind of TCP over VMBus, but
> > the transportation layer (VMBus) is much simpler than IP. With Hyper-V VM
> > Sockets, applications between the host and a guest can talk with each
> > other directly by the traditional BSD-style socket APIs.
> >
> > Hyper-V VM Sockets is only available on Windows 10 host and later. The
> > patch implements the necessary support in the guest side by introducing
> > a new socket address family AF_HYPERV.
> >
> > Signed-off-by: Dexuan Cui 
>
> Is there any chance that AF_VSOCK could be used with different transport
> for VMware and Hyper-V. Better to make guest applications host independent.

Hi Stephen,
Thanks for the question. I tried to do that (since AF_HYPERV and AF_VSOCK
are conceptually similar), but I found it would be impractical: I listed the
reasons in my cover letter of the patchset:
https://lkml.org/lkml/2015/7/6/431

IMO the biggest difference is the size of the endpoint (u128 vs. u32):
 in AF_VOSCK
vs.
 in AF_HYPERV.

In the current code of AF_VSOCK and the related transport layer (the wrapper
ops of VMware's VMCI), the size is widely used by "struct sockaddr_vm" (this
struct is also exported to the user space).

So, anyway, the user space application has to explicitly handle the different
endpoint size.

And in the driver side, I'm afraid there is no way to directly reuse the code of
AF_VSOCK with trivial change :-( , because we would have to make the
AF_VSOCK code be able to know the real sockaddr type (sockaddr_vm or
sockaddr_hv? The two structs have different layout and different field names)
at runtime and behave differently. This would make the code a mess, IMO.

That's why I think it would be better to introduce a new address family.

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

RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Dexuan Cui]

> -Original Message-
> From: Olaf Hering
> Sent: Tuesday, July 7, 2015 18:59
> Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
> 
> On Tue, Jul 07, Dexuan Cui wrote:
> 
> > OK, removing the line seems better than 'default n', though both reproduce
> > the same "# CONFIG_HYPERV_SOCK is not set".
> 
> Perhaps "default VMBUS" (or whatever syntax is needed) may be the way to
> enable it conditionally.
> 
> Olaf
Thanks, Olaf!
I think we can use "default m if HYPERV".

Paul, I'll remove the sentence "If unsure, say N."

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

Re: [PATCH] STAGING SUBSYSTEM rtl8188eu driver : Fixed 80 character length warning in rtw_ap.c

[Sudip Mukherjee]

On Tue, Jul 07, 2015 at 09:27:58PM -0400, Sreenath Madasu wrote:
> When the checkpatch.pl script was run, it showed lines with length
> more than 80 characters in rtw_ap.c file. Fixed line number 382 by
> breaking it up into two lines within 80 characters.
Greg told you to fix the subject, its still not ok.
It should have been "staging: rtl8188eu: core: Fixed 80 character length 
warning"

And when you are sending a patch after review, please mark is as [PATCH v2]


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