Re: Clarification for the use of additional fields in the message body
From: Markus Elfring elfr...@users.sourceforge.net Date: Sat, 27 Jun 2015 15:56:57 +0200 Why is this in the body of the email? Does the canonical patch format support to preserve specific details about a shown commit by specification of fields like Date and From in the message body? Regards, Markus ___ 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
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
[PATCH] staging: comedi: cb_pcimdas: add external analog output ranges
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 abbo...@mev.co.uk --- 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
Re: [PATCH 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()
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 r.bald...@samsung.com --- 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
Re: [PATCH 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails
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
[PATCH] staging: comedi: use CAP_SYS_ADMIN instead of CAP_NET_ADMIN
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 abbo...@mev.co.uk --- 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
On Tue, Jul 7, 2015 at 9:54 AM, SF Markus Elfring elfr...@users.sourceforge.net 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 0/4] staging: wilc1000: cover letter
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
Re: [PATCH] Alternate rtl8192cu driver.
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: Clarification for the use of additional fields in the message body
On Tue, Jul 7, 2015 at 8:21 AM, SF Markus Elfring elfr...@users.sourceforge.net wrote: From: Markus Elfring elfr...@users.sourceforge.net Date: Sat, 27 Jun 2015 15:56:57 +0200 Why is this in the body of the email? Does the canonical patch format support to preserve specific details about a shown commit by specification of fields like Date and From in the message body? Using From: in the body can be used to provide your properly spelled name, or the name/e-mail of the actual author, if that happens not to be the sender. git-send-email will do that automagically for you. If From: is not specified in the message body, the e-mails sender will be used as author. 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. No need to try and preserve it. Frans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
Hi Dmitry, On 6 July 2015 at 19:24, Dmitry Kalinkin dmitry.kalin...@gmail.com 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
[PATCH 3/5] staging: sm7xxfb: use kernel commandline
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 su...@vectorindia.org --- 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
Define and use some new macros to work with different situations based on little-endian and big-endian. Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- 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 - sfb-lfb = ioremap(mmio_base, 0x0080); -#endif +
[PATCH 5/5] staging: sm7xxfb: usr fb_read and fb_write
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 su...@vectorindia.org --- 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
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 su...@vectorindia.org --- 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
These macros were only defined but not used anywhere. Signed-off-by: Sudip Mukherjee su...@vectorindia.org --- 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
[PATCH 0/5] staging: sm7xxfb: few changes
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
Re: Clarification for the use of additional fields in the message body
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
Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
On Mon, 6 Jul 2015 07:47:29 -0700 Dexuan Cui de...@microsoft.com 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 de...@microsoft.com 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
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
staging: rtl8192e: function naming cleanup
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: staging: rtl8192e: function naming cleanup
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.
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] Warnings : Fixed 80 character length warning in rtw_ap.c
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? shrug 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: [PATCH] Alternate rtl8192cu driver.
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
Hi Markus, On Wed, Jul 8, 2015 at 2:15 AM, SF Markus Elfring elfr...@users.sourceforge.net 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: Clarification for the use of additional fields in the message body
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
Hi Dmitry, On 7 July 2015 at 12:47, Dmitry Kalinkin dmitry.kalin...@gmail.com 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 alessioigorbog...@gmail.com 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: [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. --- /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 6/7] hvsock: introduce Hyper-V VM Sockets feature
-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: [RESEND] mfd: rtsx: add support for rts522A
On Mon, 29 Jun 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn 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 micky_ch...@realsil.com.cn --- 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, + .turn_off_led = rts5227_turn_off_led, + .enable_auto_blink =
Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
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: [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 ___ 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
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: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
Hi Alessio, [Sorry for double post] On 07 Jul 2015, at 10:08, Alessio Igor Bogani alessioigorbog...@gmail.com wrote: Hi Dmitry, On 6 July 2015 at 19:24, Dmitry Kalinkin dmitry.kalin...@gmail.com 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
[PATCH] staging: rtl8188eu: core: rtw_mlme: remove space before ','
Fix coding style error by removing spaces before ',' as suggested by checkpatch.pl script. Signed-off-by: Sunil Shahu shsh...@gmail.com --- 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] Alternate rtl8192cu driver.
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
-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: [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 micky_ch...@realsil.com.cn 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 micky_ch...@realsil.com.cn --- 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 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 =
Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c
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
Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c
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
[PATCH] STAGING SUBSYSTEM rtl8188eu driver : Fixed 80 character length warning in rtw_ap.c
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 sreenath.mad...@gmail.com --- 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
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
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
[PATCH 0/5] usb: gadget: miscellaneous fixes
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
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 r.bald...@samsung.com --- 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 5/5] usb: gadget: atmel_usba_udc: add missing ret value check
Add missing return value check. In case of error print debug message and return error code. Signed-off-by: Robert Baldyga r.bald...@samsung.com --- 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()
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 r.bald...@samsung.com --- 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: Clarification for the use of additional fields in the message body
On Tue, Jul 7, 2015 at 1:53 PM, SF Markus Elfring elfr...@users.sourceforge.net 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 2/5] usb: gadget: midi: avoid redundant f_midi_set_alt() call
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 r.bald...@samsung.com --- 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()
Should use usb_ep_set_maxpacket_limit instead of setting maxpacket value manually. Signed-off-by: Robert Baldyga r.bald...@samsung.com --- 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 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()
Should use usb_ep_set_maxpacket_limit instead of setting maxpacket value manually. Signed-off-by: Robert Baldyga r.bald...@samsung.com --- 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
Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
On 07 Jul 2015, at 15:51, Alessio Igor Bogani alessioigorbog...@gmail.com wrote: snip 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: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
-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 de...@microsoft.com 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 de...@microsoft.com 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): u32 ContextID, u32 Port in AF_VOSCK vs. u128 GUID_VM_ID, u128 GUID_ServiceID 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
-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 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()
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 r.bald...@samsung.com --- 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] scsi: storvsc: make INQUIRY response SPC-compliant
KY Srinivasan k...@microsoft.com 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 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails
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 4/5] staging: emxx_udc: add missing usb_ep_set_maxpacket_limit()
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