Re: Clarification for the use of additional fields in the message body
> There's a file in the documentation directory of the kernel > tree describing submitting patches and email client setup. > Read them both, I read this information several times. > do what they say without anything extra. Do you see any special consequences if a bit of "extra" functionality is already provided by the Git software for a while? > Your attempts to "improve" on the system are unnecessary It seems that my approach does not need improvements for the current command "git am". Would a few extensions for the available documentation help to clarify the situation? Do items like "commit mail address" and "commit timestamp" belong together for the data structure "author" by design in this content management system? > and annoying people. I understand that various update suggestions can be surprising. It is also usual that corresponding acceptance might take a bit longer than what some contributors would prefer. 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
Hi Markus, On Wed, Jul 8, 2015 at 5:09 PM, SF Markus Elfring wrote: >> There's a file in the documentation directory of the kernel >> tree describing submitting patches and email client setup. >> Read them both, > > I read this information several times. > > >> do what they say without anything extra. > > Do you see any special consequences if a bit of "extra" functionality > is already provided by the Git software for a while? If it's harmless, then no, but in this case, people are questioning why you're adding it as it adds no value to anyone and makes it look like you don't know what you're doing. >> Your attempts to "improve" on the system are unnecessary > > It seems that my approach does not need improvements for the current > command "git am". > Would a few extensions for the available documentation help to clarify > the situation? The issue is that the headers you're adding, From: and Date: are unnecessary. The From: header you add is unnecessary as your email's From: header has the exact same information. The reason it's there is because sometimes people forward patches on from other people, e.g. if I were to resend one of your patches, I'd add a From: header to the body of the email so it'd be credited to you. The Date: header you add is unnecessary as git-format-patch sets the date header in the email it produces to the author date stored in the commit. (see below) So if you're sending your patches in emails produced by git-format-patch, there's absolutely no reason to include it. > Do items like "commit mail address" and "commit timestamp" > belong together for the data structure "author" by design > in this content management system? The information stored for a commit is: = = = = = = tree 09496defc9eb793c665a7b80aa22f24c7bd5f204 parent 63c07589832bfe5ec49f2523ddb0e94a20af0f31 author Julian Calaby 1435196810 +1000 committer Julian Calaby 1436322540 +1000 = = = = = = Then the subject and commit message. The numbers after the email addresses are the timestamps. They are both almost completely irrelevant for most workflows as people are less interested in when a commit was made and more interested in what release it's in, how it was merged, etc. All of which should be determined without using the timestamp. To be honest, I've only ever used that timestamp for reporting purposes at work, and I'd be surprised if anyone was doing anything other than that with them. In short, nobody cares, and nobody's going to be upset if the actual time you authored a patch is different to the time recorded upstream. >> and annoying people. > > I understand that various update suggestions can be surprising. > It is also usual that corresponding acceptance might take > a bit longer than what some contributors would prefer. How would you feel if someone came in to your place of work and told you to change how you do the job you've been doing for years without a good 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 Wed, 08 Jul 2015, 敬锐 wrote:
>
>
> 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.
Subsequent patches are irrelevant. I Acked this patch, so the Ack
should carry forward.
I'll apply the patch for now, but please bear this in mind for the
future.
Patch applied, 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,
> >> +
Re: [PATCH 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails
On Tue, Jul 07, 2015 at 06:00:27PM +0200, Robert Baldyga wrote: > Decrement is done in ffs_func_unbind() which is not called in this > error path. Oh. Duh. I got functionfs_unbind() and ffs_func_unbind() mixed up. Sorry. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] usb: gadget: atmel_usba_udc: add missing ret value check
Le 07/07/2015 16:02, Robert Baldyga a écrit :
> Add missing return value check. In case of error print debug message
> and return error code.
>
> Signed-off-by: Robert Baldyga
Yes, it's indeed missing:
Acked-by: Nicolas Ferre
Thanks, bye.
> ---
> 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);
>
--
Nicolas Ferre
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 15/20] staging/lustre/libcfs: get rid of debugfs/lnet/console_backoff
On Mon, Jul 06, 2015 at 12:48:53PM -0400, gr...@linuxhacker.ru wrote:
> +static int param_set_uint_minmax(const char *val,
> + const struct kernel_param *kp,
> + unsigned int min, unsigned int max)
> +{
> + unsigned int num;
> + int ret;
> +
> + if (!val)
> + return -EINVAL;
> + ret = kstrtouint(val, 0, &num);
> + if (ret == -EINVAL || num < min || num > max)
^^^
Smatch is smart enough to know that "num" can be uninitialized here on
some paths. It doesn't generate a warning yet because a lot of the
kernel has error paths where we mostly assume things won't fail.
It should probably be:
ret = kstrtouint(val, 0, &num);
if (ret)
return ret;
if (num < min || num > max)
return -EINVAL;
> + return -EINVAL;
> + *((unsigned int *)kp->arg) = num;
> + return 0;
> +}
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 15/20] staging/lustre/libcfs: get rid of debugfs/lnet/console_backoff
Of course, this is not a critical flaw. Don't resend. Fix it later if you want. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: wilc1000: One function call less in mac_ioctl() after error detection
>> The kfree() function was called in two cases by the mac_ioctl() function >> during error handling even if the passed variable did not contain a pointer >> for a valid data item. >> >> * This implementation detail could be improved by the introduction >> of another jump label. >> >> * Drop an unnecessary initialisation for the variable "buff" then. > > That's a different issue, please fix it in a separate patch. I have got an other opinion here. This update suggestion depends on a small source code clean-up from the previous patch, doesn't it? Do you want that I split the second suggestion from this series into more steps? Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 18/20] staging/lustre/libcfs: get rid of debugfs/lnet/debug_mb
On Mon, Jul 06, 2015 at 12:48:56PM -0400, gr...@linuxhacker.ru wrote:
> +static int libcfs_param_debug_mb_set(const char *val,
> + const struct kernel_param *kp)
> +{
> + int rc;
> + unsigned num;
> +
> + rc = kstrtouint(val, 0, &num);
> + if (rc == -EINVAL)
> + return -EINVAL;
Presumably, this is root only so using num uninitialized is not an
information leak.
> +
> + if (!*((unsigned int *)kp->arg)) {
> + *((unsigned int *)kp->arg) = num;
> + return 0;
> + }
> +
> + rc = cfs_trace_set_debug_mb(num);
> +
> + if (!rc)
> + *((unsigned int *)kp->arg) = cfs_trace_get_debug_mb();
> +
> + return rc;
> +}
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 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 Changelog: v2: - Addressed comments from Dan Carpenter and Sergei Shtylyov. v1: https://lkml.org/lkml/2015/7/7/445 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 | 9 - 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, 20 insertions(+), 4 deletions(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 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
---
drivers/usb/gadget/function/f_fs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 6e7be91..6516187 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2897,11 +2897,18 @@ 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)
+ if(!--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 v2 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 --- 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 v2 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()
Since maxpacket_limit was introduced all UDC drivers should use
usb_ep_set_maxpacket_limit() function instead of setting maxpacket value
manually. ep.maxpacket_limit contains actual maximum maxpacket value
supported by hardware which is needed by epautoconf.
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 v2 4/5] staging: emxx_udc: add missing usb_ep_set_maxpacket_limit()
Since maxpacket_limit was introduced all UDC drivers should use usb_ep_set_maxpacket_limit() function instead of setting maxpacket value manually. ep.maxpacket_limit contains actual maximum maxpacket value supported by hardware which is needed by epautoconf. 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..3b7aa36 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 v2 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
Acked-by: Nicolas Ferre
---
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] 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. This is a useless kind of statement because the bug is so jumbled up. I'm assuming you mean that it's fine on 64 bits but not on 32 bits? regards, dan carpenter ___ 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
> If it's harmless, then no, but in this case, people are questioning > why you're adding it as it adds no value Some Git software developers care to keep the information complete for the author commit. > to anyone and makes it look like you don't know what you're doing. I specify message field overrides in my update suggestions intentionally. > The issue is that the headers you're adding, From: and Date: are unnecessary. We have got different opinions about the purpose. > The From: header you add is unnecessary as your email's From: header > has the exact same information. I would like to point out that there is a slight difference in my use case. > The reason it's there is because sometimes people forward patches on > from other people, e.g. if I were to resend one of your patches, > I'd add a From: header to the body of the email so it'd be credited to you. I am also interested in such an use case. > The Date: header you add is unnecessary as git-format-patch sets the > date header in the email it produces to the author date stored in the commit. How do you think about my extra patch preparation for the mentioned mail forwarding? > So if you're sending your patches in emails produced by git-format-patch, > there's absolutely no reason to include it. I disagree here to some degree. The difference in suggested commit timestamps of a few minutes might look negligible for some patches. There are few occasions where the delay between a concrete commit and its publishing by an interface like email can become days. > They are both almost completely irrelevant for most workflows as people > are less interested in when a commit was made and more interested in what > release it's in, how it was merged, etc. All of which should be > determined without using the timestamp. How often will it matter who made and published a change first? > To be honest, I've only ever used that timestamp for reporting > purposes at work, and I'd be surprised if anyone was doing anything > other than that with them. Thanks for your detailed feedback. > How would you feel if someone came in to your place of work > and told you to change how you do the job you've been doing for years > without a good reason? You might feel uncomfortable for a moment if you would interpret such a suggestion as a personal attack. I guess that I point only a few technical details out which can change the popularity of existing functionality from the Git software. Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Alternate rtl8192cu driver.
On 08/07/15 11:14, Dan Carpenter wrote: This is a useless kind of statement because the bug is so jumbled up. I know! Honestly, I did not really understand the question in the first place, seeing as the bug is still open. I'm sure you realize that in the absence of a precise question, I can only tell you that the issues I (and many other people, judging by the popularity of the alternate driver) are experiencing are still present, and not much else. This is on a 64 bit kernel, for what it's worth. I would very much like a way to trace what happens in the driver when NetworkManager attempts to turn the connection on, but I don't know how. If you would be so kind as to indicate to me what would constitute useful information and how to obtain it, I would be happy to help. And Greg KH wrote: That's as "supported" as anything is with Linux :) Kind of dispiriting... but so it goes. I'm happy to try and help make things a bit better for everyone in what small ways I can. Cheers, -- P. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Alternate rtl8192cu driver.
On Wed, Jul 08, 2015 at 12:10:15PM +0200, P. Varet wrote: > On 08/07/15 11:14, Dan Carpenter wrote: > > >This is a useless kind of statement because the bug is so jumbled up. > > I know! Honestly, I did not really understand the question in the > first place, seeing as the bug is still open. I'm sure you realize > that in the absence of a precise question, I can only tell you that > the issues I (and many other people, judging by the popularity of > the alternate driver) are experiencing are still present, and not > much else. This is on a 64 bit kernel, for what it's worth. > > I would very much like a way to trace what happens in the driver > when NetworkManager attempts to turn the connection on, but I don't > know how. The bug report says that it connects fine. Then in 10 minutes the connection dies and reconnects. Is connecting an issue for you? Just start over and describe which symptoms you are seeing. It's like you told us it was exactly the same as the bug report, then when I read the bug report there were too many issues mixed together and now you are saying your issue has totally different symptoms which we are supposed to guess what they are but they are similar-ish because they involve networking... regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Alternate rtl8192cu driver.
Also it would really help if you could test this on a 32 bit system. If we knew this is 32 vs 64 bit bug that would help. regards, dan carpenter ___ 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 7:28 PM, SF Markus Elfring wrote: >> If it's harmless, then no, but in this case, people are questioning >> why you're adding it as it adds no value > > Some Git software developers care to keep the information complete > for the author commit. > > >> to anyone and makes it look like you don't know what you're doing. > > I specify message field overrides in my update suggestions intentionally. > > >> The issue is that the headers you're adding, From: and Date: are unnecessary. > > We have got different opinions about the purpose. Let me rephrase that: they _should_ be unnecessary. >> The From: header you add is unnecessary as your email's From: header >> has the exact same information. > > I would like to point out that there is a slight difference in my use case. Then fix your email client or patch submission process. >> The reason it's there is because sometimes people forward patches on >> from other people, e.g. if I were to resend one of your patches, >> I'd add a From: header to the body of the email so it'd be credited to you. > > I am also interested in such an use case. This happens automatically if you use git-format-patch on a commit you didn't author. Nobody is adding this manually. >> The Date: header you add is unnecessary as git-format-patch sets the >> date header in the email it produces to the author date stored in the commit. > > How do you think about my extra patch preparation for the mentioned > mail forwarding? It sounds like you're using what could only be described as a Rube-Goldberg process to send email. Is there truly no way to simplify that process? (Also, are the servers you send it through re-writing the original headers?) You should be sending the patches directly with SMTP using git-send-email, if you're not, then you're making things overly complicated for yourself. >> So if you're sending your patches in emails produced by git-format-patch, >> there's absolutely no reason to include it. > > I disagree here to some degree. > > The difference in suggested commit timestamps of a few minutes might look > negligible for some patches. There are few occasions where the delay between > a concrete commit and its publishing by an interface like email > can become days. I made a commit a month ago, it got rebased today, in fact, I sent it's metadata in my previous email. When I ran git-format-patch on it, the timestamp in the headers of the email produced was the date from a month ago. If I then sent that email, I believe it'd make it to the list here with that date intact. If it hadn't, I'd be trying to figure out why and either fix it or find a different path to get my patch here. >> They are both almost completely irrelevant for most workflows as people >> are less interested in when a commit was made and more interested in what >> release it's in, how it was merged, etc. All of which should be >> determined without using the timestamp. > > How often will it matter who made and published a change first? If multiple people are submitting identical changes, then the one that is applied is the one the maintainer sees first, which will most likely be determined by which one hit their inbox / list first. Nobody is going to look at timestamps in emails to determine which one will be applied. If you're worried about which one of several versions of a patch will be applied, change the subject to [PATCH v2] . instead of [PATCH] for the second version. >> To be honest, I've only ever used that timestamp for reporting >> purposes at work, and I'd be surprised if anyone was doing anything >> other than that with them. > > Thanks for your detailed feedback. > > >> How would you feel if someone came in to your place of work >> and told you to change how you do the job you've been doing for years >> without a good reason? > > You might feel uncomfortable for a moment if you would interpret > such a suggestion as a personal attack. I'm not interpreting this as a personal attack. > I guess that I point only a few technical details out which can change > the popularity of existing functionality from the Git software. Git was originally written to manage the Linux kernel. This feature was probably added by either Linus himself or one of the original developers who I believe were kernel developers. The patch submission process has been around for a long time, if this feature isn't used, it's for a good reason. Having a feature doesn't mean that it should be used. 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
[PATCH 01/37] usb: gadget: encapsulate endpoint claiming mechanism
So far it was necessary for usb functions to set ep->driver_data in
endpoint obtained from autoconfig to non-null value, to indicate that
endpoint is claimed by function (in autoconfig it was checked if endpoint
has set this field to non-null value, and if it has, it was assumed that
it is claimed). It could cause bugs becouse if some function doesn't
set this field autoconfig could return the same endpoint more than one
time.
To help to avoid such bugs this patch adds claimed flag to struct usb_ep,
and encapsulates endpoint claiming mechanism inside usb_ep_autoconfig_ss()
and usb_ep_autoconfig_reset(), so now usb functions doesn't need to perform
any additional actions to mark endpoint obtained from autoconfig as claimed.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/epautoconf.c | 11 ++-
include/linux/usb/gadget.h | 1 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 919cdfd..8e00ca7 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -53,7 +53,7 @@ ep_matches (
int num_req_streams = 0;
/* endpoint already claimed? */
- if (NULL != ep->driver_data)
+ if (ep->claimed)
return 0;
/* only support ep0 for portable CONTROL traffic */
@@ -240,7 +240,7 @@ find_ep (struct usb_gadget *gadget, const char *name)
* updated with the assigned number of streams if it is
* different from the original value. To prevent the endpoint
* from being returned by a later autoconfig call, claim it by
- * assigning ep->driver_data to some non-null value.
+ * assigning ep->claimed to true.
*
* On failure, this returns a null endpoint descriptor.
*/
@@ -323,6 +323,7 @@ struct usb_ep *usb_ep_autoconfig_ss(
found_ep:
ep->desc = NULL;
ep->comp_desc = NULL;
+ ep->claimed = true;
return ep;
}
EXPORT_SYMBOL_GPL(usb_ep_autoconfig_ss);
@@ -354,7 +355,7 @@ EXPORT_SYMBOL_GPL(usb_ep_autoconfig_ss);
* descriptor bEndpointAddress. For bulk endpoints, the wMaxPacket value
* is initialized as if the endpoint were used at full speed. To prevent
* the endpoint from being returned by a later autoconfig call, claim it
- * by assigning ep->driver_data to some non-null value.
+ * by assigning ep->claimed to true.
*
* On failure, this returns a null endpoint descriptor.
*/
@@ -373,7 +374,7 @@ EXPORT_SYMBOL_GPL(usb_ep_autoconfig);
*
* Use this for devices where one configuration may need to assign
* endpoint resources very differently from the next one. It clears
- * state such as ep->driver_data and the record of assigned endpoints
+ * state such as ep->claimed and the record of assigned endpoints
* used by usb_ep_autoconfig().
*/
void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
@@ -381,7 +382,7 @@ void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
struct usb_ep *ep;
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
- ep->driver_data = NULL;
+ ep->claimed = false;
}
gadget->in_epnum = 0;
gadget->out_epnum = 0;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 4f3dfb7..fcb0a4e 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -173,6 +173,7 @@ struct usb_ep {
const char *name;
const struct usb_ep_ops *ops;
struct list_headep_list;
+ boolclaimed;
unsignedmaxpacket:16;
unsignedmaxpacket_limit:16;
unsignedmax_streams:16;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/37] usb: gadget: rework ep matching and claiming mechanism
Hello, This patch series reworks endpoint matching and claiming mechanism in epautoconf. The patch (1) introduces new safer endpoint claiming method, basing on new 'claimed' flag. It was discussed here [1]. I proposed this solution over year ago and it was accepted, but apparently I forgot to send the final version of patch. Patches (2-3) add the 'capabilities flags' structure and helper macros. This solution is inspired by the 'feature flags' originally proposed by Felipe Balbi in 2013 [2], but unfortunately implementation of this feature has never been completed. Patches (4-36) add' capabilites flags' support to all UDC drivers present in the kernel tree. It's needed to be done before replacing old endpoint matching mechanism, otherwise UDC drivers which doesn't set 'capabilities flags' won't work with new autoconfig. Patch (37) finally replaces old endpoint matching method with the new one basing on capabilities flags. These changes aims to get rid of code, which guesses endpoint capabilities basing on it's name, and introduce new better replacement. In result we have better way to describe types and directions supported by each endpoint. For example the old name-based method didn't allow to have endpoint supporing two types of transfers - there were only ability to support one or all endpoint types. The 'capabilities flags' feature supply precise, flexible and extendible mechanism of description of endpoint hardware limitations, which is desired for proper endpoint matching. Best regards, Robert Baldyga [1] https://lkml.org/lkml/2014/6/16/94 [2] http://www.spinics.net/lists/linux-usb/msg99662.html Robert Baldyga (37): usb: gadget: encapsulate endpoint claiming mechanism usb: gadget: add endpoint capabilities flags usb: gadget: add endpoint capabilities helper macros staging: emxx_udc: add ep capabilities support usb: chipidea: udc: add ep capabilities support usb: dwc2: gadget: add ep capabilities support usb: dwc3: gadget: add ep capabilities support usb: gadget: amd5536udc: add ep capabilities support usb: gadget: at91_udc: add ep capabilities support usb: gadget: bcm63xx_udc: add ep capabilities support usb: gadget: bdc: add ep capabilities support usb: gadget: dummy-hcd: add ep capabilities support usb: gadget: fotg210-udc: add ep capabilities support usb: gadget: fsl_qe_udc: add ep capabilities support usb: gadget: fsl_udc_core: add ep capabilities support usb: gadget: fusb300_udc: add ep capabilities support usb: gadget: goku_udc: add ep capabilities support usb: gadget: gr_udc: add ep capabilities support usb: gadget: lpc32xx_udc: add ep capabilities support usb: gadget: m66592-udc: add ep capabilities support usb: gadget: mv_u3d_core: add ep capabilities support usb: gadget: mv_udc_core: add ep capabilities support usb: gadget: net2272: add ep capabilities support usb: gadget: net2280: add ep capabilities support usb: gadget: omap_udc: add ep capabilities support usb: gadget: pch_ud: add ep capabilities support usb: gadget: pxa25x_udc: add ep capabilities support usb: gadget: pxa27x_udc: add ep capabilities support usb: gadget: r8a66597-udc: add ep capabilities support usb: gadget: s3c-hsudc: add ep capabilities support usb: gadget: s3c2410_udc: add ep capabilities support usb: gadget: udc-xilinx: add ep capabilities support usb: isp1760: udc: add ep capabilities support usb: musb: gadget: add ep capabilities support usb: renesas: gadget: add ep capabilities support usb: gadget: atmel_usba_udc: add ep capabilities support usb: gadget: epautoconf: add endpoint capabilities flags verification drivers/staging/emxx_udc/emxx_udc.c | 60 drivers/usb/chipidea/udc.c | 14 ++ drivers/usb/dwc2/gadget.c | 13 ++ drivers/usb/dwc3/gadget.c | 13 ++ drivers/usb/gadget/epautoconf.c | 83 +++-- drivers/usb/gadget/udc/amd5536udc.c | 57 ++ drivers/usb/gadget/udc/at91_udc.c | 33 + drivers/usb/gadget/udc/atmel_usba_udc.c | 11 + drivers/usb/gadget/udc/bcm63xx_udc.c| 25 -- drivers/usb/gadget/udc/bdc/bdc_ep.c | 9 drivers/usb/gadget/udc/dummy_hcd.c | 65 -- drivers/usb/gadget/udc/fotg210-udc.c| 11 + drivers/usb/gadget/udc/fsl_qe_udc.c | 11 + drivers/usb/gadget/udc/fsl_udc_core.c | 13 ++ drivers/usb/gadget/udc/fusb300_udc.c| 11 + drivers/usb/gadget/udc/goku_udc.c | 8 drivers/usb/gadget/udc/gr_udc.c | 11 + drivers/usb/gadget/udc/lpc32xx_udc.c| 32 + drivers/usb/gadget/udc/m66592-udc.c | 11 + drivers/usb/gadget/udc/mv_u3d_core.c| 9 drivers/usb/gadget/udc/mv_udc_core.c| 9 drivers/usb/gadget/udc/net2272.c| 11 + drivers/usb/gadget/udc/net2280.c| 50 +++- drivers/usb/gadget/udc/omap_
[PATCH 04/37] staging: emxx_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Fixed typo in "epc-nulk" to "epc-bulk".
Signed-off-by: Robert Baldyga
---
drivers/staging/emxx_udc/emxx_udc.c | 60 ++---
1 file changed, 29 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 3b7aa36..0d64bee 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3153,36 +3153,33 @@ static const struct usb_gadget_ops nbu2ss_gadget_ops = {
.ioctl = nbu2ss_gad_ioctl,
};
-static const char g_ep0_name[] = "ep0";
-static const char g_ep1_name[] = "ep1-bulk";
-static const char g_ep2_name[] = "ep2-bulk";
-static const char g_ep3_name[] = "ep3in-int";
-static const char g_ep4_name[] = "ep4-iso";
-static const char g_ep5_name[] = "ep5-iso";
-static const char g_ep6_name[] = "ep6-bulk";
-static const char g_ep7_name[] = "ep7-bulk";
-static const char g_ep8_name[] = "ep8in-int";
-static const char g_ep9_name[] = "ep9-iso";
-static const char g_epa_name[] = "epa-iso";
-static const char g_epb_name[] = "epb-bulk";
-static const char g_epc_name[] = "epc-nulk";
-static const char g_epd_name[] = "epdin-int";
-
-static const char *gp_ep_name[NUM_ENDPOINTS] = {
- g_ep0_name,
- g_ep1_name,
- g_ep2_name,
- g_ep3_name,
- g_ep4_name,
- g_ep5_name,
- g_ep6_name,
- g_ep7_name,
- g_ep8_name,
- g_ep9_name,
- g_epa_name,
- g_epb_name,
- g_epc_name,
- g_epd_name,
+static const struct {
+ const char *name;
+ const struct usb_ep_caps caps;
+} ep_info[NUM_ENDPOINTS] = {
+#define EP_INFO(_name, _type, _dir) \
+ { \
+ .name = _name, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+ USB_EP_CAPS_DIR_ ## _dir), \
+ }
+
+ EP_INFO("ep0", CONTROL, ALL),
+ EP_INFO("ep1-bulk", BULK, ALL),
+ EP_INFO("ep2-bulk", BULK, ALL),
+ EP_INFO("ep3in-int",INT,IN),
+ EP_INFO("ep4-iso", INT,ALL),
+ EP_INFO("ep5-iso", ISO,ALL),
+ EP_INFO("ep6-bulk", ISO,ALL),
+ EP_INFO("ep7-bulk", BULK, ALL),
+ EP_INFO("ep8in-int",INT,IN),
+ EP_INFO("ep9-iso", ISO,ALL),
+ EP_INFO("epa-iso", ISO,ALL),
+ EP_INFO("epb-bulk", BULK, ALL),
+ EP_INFO("epc-bulk", BULK, ALL),
+ EP_INFO("epdin-int",INT,IN),
+
+#undef EP_INFO
};
/*-*/
@@ -3200,7 +3197,8 @@ static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc
*udc)
ep->desc = NULL;
ep->ep.driver_data = NULL;
- ep->ep.name = gp_ep_name[i];
+ ep->ep.name = ep_info[i].name;
+ ep->ep.caps = ep_info[i].caps;
ep->ep.ops = &nbu2ss_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep,
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 06/37] usb: dwc2: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/dwc2/gadget.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4d47b7c..8771b66 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3289,6 +3289,19 @@ static void s3c_hsotg_initep(struct dwc2_hsotg *hsotg,
usb_ep_set_maxpacket_limit(&hs_ep->ep, epnum ? 1024 : EP0_MPS_LIMIT);
hs_ep->ep.ops = &s3c_hsotg_ep_ops;
+ if (epnum == 0) {
+ hs_ep->ep.caps.type_control = true;
+ } else {
+ hs_ep->ep.caps.type_iso = true;
+ hs_ep->ep.caps.type_bulk = true;
+ hs_ep->ep.caps.type_int = true;
+ }
+
+ if (dir_in)
+ hs_ep->ep.caps.dir_in = true;
+ else
+ hs_ep->ep.caps.dir_out = true;
+
/*
* if we're using dma, we need to set the next-endpoint pointer
* to be something valid.
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 05/37] usb: chipidea: udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/chipidea/udc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 764f668..eff7cfb 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1624,6 +1624,20 @@ static int init_eps(struct ci_hdrc *ci)
hwep->ep.name = hwep->name;
hwep->ep.ops = &usb_ep_ops;
+
+ if (i == 0) {
+ hwep->ep.caps.type_control = true;
+ } else {
+ hwep->ep.caps.type_iso = true;
+ hwep->ep.caps.type_bulk = true;
+ hwep->ep.caps.type_int = true;
+ }
+
+ if (j == TX)
+ hwep->ep.caps.dir_in = true;
+ else
+ hwep->ep.caps.dir_out = true;
+
/*
* for ep0: maxP defined in desc, for other
* eps, maxP is set by epautoconfig() called
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 07/37] usb: dwc3: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/dwc3/gadget.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0..8d1f768 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1713,6 +1713,19 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3
*dwc,
return ret;
}
+ if (epnum == 0) {
+ dep->endpoint.caps.type_control = true;
+ } else {
+ dep->endpoint.caps.type_iso = true;
+ dep->endpoint.caps.type_bulk = true;
+ dep->endpoint.caps.type_int = true;
+ }
+
+ if (epnum & 1)
+ dep->endpoint.caps.dir_in = true;
+ else
+ dep->endpoint.caps.dir_out = true;
+
INIT_LIST_HEAD(&dep->request_list);
INIT_LIST_HEAD(&dep->req_queued);
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/37] usb: gadget: add endpoint capabilities helper macros
Add macros useful while initializing array of endpoint capabilities
structures. These macros makes structure initialization more compact
to decrease number of code lines and increase readability of code.
Signed-off-by: Robert Baldyga
---
include/linux/usb/gadget.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 6f3e0fb..e6cbc25 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -158,6 +158,26 @@ struct usb_ep_caps {
unsigned dir_out:1;
};
+#define USB_EP_CAPS_TYPE_CONTROL 0x01
+#define USB_EP_CAPS_TYPE_ISO 0x02
+#define USB_EP_CAPS_TYPE_BULK0x04
+#define USB_EP_CAPS_TYPE_INT 0x08
+#define USB_EP_CAPS_TYPE_ALL \
+ (USB_EP_CAPS_TYPE_ISO | USB_EP_CAPS_TYPE_BULK | USB_EP_CAPS_TYPE_INT)
+#define USB_EP_CAPS_DIR_IN 0x01
+#define USB_EP_CAPS_DIR_OUT 0x02
+#define USB_EP_CAPS_DIR_ALL (USB_EP_CAPS_DIR_IN | USB_EP_CAPS_DIR_OUT)
+
+#define USB_EP_CAPS(_type, _dir) \
+ { \
+ .type_control = !!(_type & USB_EP_CAPS_TYPE_CONTROL), \
+ .type_iso = !!(_type & USB_EP_CAPS_TYPE_ISO), \
+ .type_bulk = !!(_type & USB_EP_CAPS_TYPE_BULK), \
+ .type_int = !!(_type & USB_EP_CAPS_TYPE_INT), \
+ .dir_in = !!(_dir & USB_EP_CAPS_DIR_IN), \
+ .dir_out = !!(_dir & USB_EP_CAPS_DIR_OUT), \
+ }
+
/**
* struct usb_ep - device side representation of USB endpoint
* @name:identifier for the endpoint, such as "ep-a" or "ep9in-bulk"
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/37] usb: gadget: at91_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/at91_udc.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/udc/at91_udc.c
b/drivers/usb/gadget/udc/at91_udc.c
index fc42264..a04b073 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -59,15 +59,29 @@
#defineDRIVER_VERSION "3 May 2006"
static const char driver_name [] = "at91_udc";
-static const char * const ep_names[] = {
- "ep0",
- "ep1",
- "ep2",
- "ep3-int",
- "ep4",
- "ep5",
+
+static const struct {
+ const char *name;
+ const struct usb_ep_caps caps;
+} ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+ { \
+ .name = _name, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+ USB_EP_CAPS_DIR_ ## _dir), \
+ }
+
+ EP_INFO("ep0", CONTROL, ALL),
+ EP_INFO("ep1", ALL,ALL),
+ EP_INFO("ep2", ALL,ALL),
+ EP_INFO("ep3-int", INT,ALL),
+ EP_INFO("ep4", ALL,ALL),
+ EP_INFO("ep5", ALL,ALL),
+
+#undef EP_INFO
};
-#define ep0nameep_names[0]
+
+#define ep0nameep_info[0].name
#define VBUS_POLL_TIMEOUT msecs_to_jiffies(1000)
@@ -1830,7 +1844,8 @@ static int at91udc_probe(struct platform_device *pdev)
for (i = 0; i < NUM_ENDPOINTS; i++) {
ep = &udc->ep[i];
- ep->ep.name = ep_names[i];
+ ep->ep.name = ep_info[i].name;
+ ep->ep.caps = ep_info[i].caps;
ep->ep.ops = &at91_ep_ops;
ep->udc = udc;
ep->int_mask = BIT(i);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 08/37] usb: gadget: amd5536udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/amd5536udc.c | 57 ++---
1 file changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/udc/amd5536udc.c
b/drivers/usb/gadget/udc/amd5536udc.c
index de7e5e2..1a1d91c 100644
--- a/drivers/usb/gadget/udc/amd5536udc.c
+++ b/drivers/usb/gadget/udc/amd5536udc.c
@@ -138,15 +138,51 @@ static DECLARE_TASKLET(disconnect_tasklet,
udc_tasklet_disconnect,
/* endpoint names used for print */
static const char ep0_string[] = "ep0in";
-static const char *const ep_string[] = {
- ep0_string,
- "ep1in-int", "ep2in-bulk", "ep3in-bulk", "ep4in-bulk", "ep5in-bulk",
- "ep6in-bulk", "ep7in-bulk", "ep8in-bulk", "ep9in-bulk", "ep10in-bulk",
- "ep11in-bulk", "ep12in-bulk", "ep13in-bulk", "ep14in-bulk",
- "ep15in-bulk", "ep0out", "ep1out-bulk", "ep2out-bulk", "ep3out-bulk",
- "ep4out-bulk", "ep5out-bulk", "ep6out-bulk", "ep7out-bulk",
- "ep8out-bulk", "ep9out-bulk", "ep10out-bulk", "ep11out-bulk",
- "ep12out-bulk", "ep13out-bulk", "ep14out-bulk", "ep15out-bulk"
+static const struct {
+ const char *name;
+ const struct usb_ep_caps caps;
+} ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+ { \
+ .name = _name, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+ USB_EP_CAPS_DIR_ ## _dir), \
+ }
+
+ EP_INFO(ep0_string, CONTROL, IN),
+ EP_INFO("ep1in-int",BULK, IN),
+ EP_INFO("ep2in-bulk", BULK, IN),
+ EP_INFO("ep3in-bulk", BULK, IN),
+ EP_INFO("ep4in-bulk", BULK, IN),
+ EP_INFO("ep5in-bulk", BULK, IN),
+ EP_INFO("ep6in-bulk", BULK, IN),
+ EP_INFO("ep7in-bulk", BULK, IN),
+ EP_INFO("ep8in-bulk", BULK, IN),
+ EP_INFO("ep9in-bulk", BULK, IN),
+ EP_INFO("ep10in-bulk", BULK, IN),
+ EP_INFO("ep11in-bulk", BULK, IN),
+ EP_INFO("ep12in-bulk", BULK, IN),
+ EP_INFO("ep13in-bulk", BULK, IN),
+ EP_INFO("ep14in-bulk", BULK, IN),
+ EP_INFO("ep15in-bulk", BULK, IN),
+ EP_INFO("ep0out", CONTROL, OUT),
+ EP_INFO("ep1out-bulk", BULK, OUT),
+ EP_INFO("ep2out-bulk", BULK, OUT),
+ EP_INFO("ep3out-bulk", BULK, OUT),
+ EP_INFO("ep4out-bulk", BULK, OUT),
+ EP_INFO("ep5out-bulk", BULK, OUT),
+ EP_INFO("ep6out-bulk", BULK, OUT),
+ EP_INFO("ep7out-bulk", BULK, OUT),
+ EP_INFO("ep8out-bulk", BULK, OUT),
+ EP_INFO("ep9out-bulk", BULK, OUT),
+ EP_INFO("ep10out-bulk", BULK, OUT),
+ EP_INFO("ep11out-bulk", BULK, OUT),
+ EP_INFO("ep12out-bulk", BULK, OUT),
+ EP_INFO("ep13out-bulk", BULK, OUT),
+ EP_INFO("ep14out-bulk", BULK, OUT),
+ EP_INFO("ep15out-bulk", BULK, OUT),
+
+#undef EP_INFO
};
/* DMA usage flag */
@@ -1517,7 +1553,8 @@ static void udc_setup_endpoints(struct udc *dev)
for (tmp = 0; tmp < UDC_EP_NUM; tmp++) {
ep = &dev->ep[tmp];
ep->dev = dev;
- ep->ep.name = ep_string[tmp];
+ ep->ep.name = ep_info[tmp].name;
+ ep->ep.caps = ep_info[tmp].caps;
ep->num = tmp;
/* txfifo size is calculated at enable time */
ep->txfifo = dev->txfifo;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 02/37] usb: gadget: add endpoint capabilities flags
Introduce struct usb_ep_caps which contains information about capabilities
of usb endpoints - supported transfer types and directions. This structure
should be filled by UDC driver for each of its endpoints, and will be
used in epautoconf in new ep matching mechanism which will replace ugly
guessing of endpoint capabilities basing on its name.
Signed-off-by: Robert Baldyga
---
include/linux/usb/gadget.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index fcb0a4e..6f3e0fb 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -141,10 +141,29 @@ struct usb_ep_ops {
};
/**
+ * struct usb_ep_caps - endpoint capabilities description
+ * @type_control:Endpoint supports control type (reserved for ep0).
+ * @type_iso:Endpoint supports isochronous transfers.
+ * @type_bulk:Endpoint supports bulk transfers.
+ * @type_int:Endpoint supports interrupt transfers.
+ * @dir_in:Endpoint supports IN direction.
+ * @dir_out:Endpoint supports OUT direction.
+ */
+struct usb_ep_caps {
+ unsigned type_control:1;
+ unsigned type_iso:1;
+ unsigned type_bulk:1;
+ unsigned type_int:1;
+ unsigned dir_in:1;
+ unsigned dir_out:1;
+};
+
+/**
* struct usb_ep - device side representation of USB endpoint
* @name:identifier for the endpoint, such as "ep-a" or "ep9in-bulk"
* @ops: Function pointers used to access hardware-specific operations.
* @ep_list:the gadget's ep_list holds all of its endpoints
+ * @caps:The structure describing types and directions supported by endoint.
* @maxpacket:The maximum packet size used on this endpoint. The initial
* value can sometimes be reduced (hardware allowing), according to
* the endpoint descriptor used to configure the endpoint.
@@ -167,12 +186,14 @@ struct usb_ep_ops {
* gadget->ep_list. the control endpoint (gadget->ep0) is not in that list,
* and is accessed only in response to a driver setup() callback.
*/
+
struct usb_ep {
void*driver_data;
const char *name;
const struct usb_ep_ops *ops;
struct list_headep_list;
+ struct usb_ep_caps caps;
boolclaimed;
unsignedmaxpacket:16;
unsignedmaxpacket_limit:16;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 11/37] usb: gadget: bdc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/bdc/bdc_ep.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index b04980c..f9a8f57 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_ep.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_ep.c
@@ -1952,12 +1952,18 @@ static int init_ep(struct bdc *bdc, u32 epnum, u32 dir)
ep->bdc = bdc;
ep->dir = dir;
+ if (dir)
+ ep->usb_ep.caps.dir_in = true;
+ else
+ ep->usb_ep.caps.dir_out = true;
+
/* ep->ep_num is the index inside bdc_ep */
if (epnum == 1) {
ep->ep_num = 1;
bdc->bdc_ep_array[ep->ep_num] = ep;
snprintf(ep->name, sizeof(ep->name), "ep%d", epnum - 1);
usb_ep_set_maxpacket_limit(&ep->usb_ep, EP0_MAX_PKT_SIZE);
+ ep->usb_ep.caps.type_control = true;
ep->comp_desc = NULL;
bdc->gadget.ep0 = &ep->usb_ep;
} else {
@@ -1971,6 +1977,9 @@ static int init_ep(struct bdc *bdc, u32 epnum, u32 dir)
dir & 1 ? "in" : "out");
usb_ep_set_maxpacket_limit(&ep->usb_ep, 1024);
+ ep->usb_ep.caps.type_iso = true;
+ ep->usb_ep.caps.type_bulk = true;
+ ep->usb_ep.caps.type_int = true;
ep->usb_ep.max_streams = 0;
list_add_tail(&ep->usb_ep.ep_list, &bdc->gadget.ep_list);
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 10/37] usb: gadget: bcm63xx_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/bcm63xx_udc.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/bcm63xx_udc.c
b/drivers/usb/gadget/udc/bcm63xx_udc.c
index 9db968b..c5e0894 100644
--- a/drivers/usb/gadget/udc/bcm63xx_udc.c
+++ b/drivers/usb/gadget/udc/bcm63xx_udc.c
@@ -44,9 +44,25 @@
#define DRV_MODULE_NAME"bcm63xx_udc"
static const char bcm63xx_ep0name[] = "ep0";
-static const char *const bcm63xx_ep_name[] = {
- bcm63xx_ep0name,
- "ep1in-bulk", "ep2out-bulk", "ep3in-int", "ep4out-int",
+
+static const struct {
+ const char *name;
+ const struct usb_ep_caps caps;
+} bcm63xx_ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+ { \
+ .name = _name, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+ USB_EP_CAPS_DIR_ ## _dir), \
+ }
+
+ EP_INFO(bcm63xx_ep0name, CONTROL, ALL),
+ EP_INFO("ep1in-bulk", BULK, IN),
+ EP_INFO("ep2out-bulk", BULK, OUT),
+ EP_INFO("ep3in-int",INT,IN),
+ EP_INFO("ep4out-int", INT,OUT),
+
+#undef EP_INFO
};
static bool use_fullspeed;
@@ -943,7 +959,8 @@ static int bcm63xx_init_udc_hw(struct bcm63xx_udc *udc)
for (i = 0; i < BCM63XX_NUM_EP; i++) {
struct bcm63xx_ep *bep = &udc->bep[i];
- bep->ep.name = bcm63xx_ep_name[i];
+ bep->ep.name = bcm63xx_ep_info[i].name;
+ bep->ep.caps = bcm63xx_ep_info[i].caps;
bep->ep_num = i;
bep->ep.ops = &bcm63xx_udc_ep_ops;
list_add_tail(&bep->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 13/37] usb: gadget: fotg210-udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/fotg210-udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c
b/drivers/usb/gadget/udc/fotg210-udc.c
index e547ea7..960c70c 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -1153,6 +1153,17 @@ static int fotg210_udc_probe(struct platform_device
*pdev)
ep->ep.name = fotg210_ep_name[i];
ep->ep.ops = &fotg210_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
+
+ if (i == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&fotg210->ep[0]->ep, 0x40);
fotg210->gadget.ep0 = &fotg210->ep[0]->ep;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 12/37] usb: gadget: dummy-hcd: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/dummy_hcd.c | 65 +-
1 file changed, 50 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index 181112c..69fd29a 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -127,23 +127,57 @@ static inline struct dummy_request
*usb_request_to_dummy_request
static const char ep0name[] = "ep0";
-static const char *const ep_name[] = {
- ep0name,/* everyone has ep0 */
+static const struct {
+ const char *name;
+ const struct usb_ep_caps caps;
+} ep_info[] = {
+#define EP_INFO(_name, _type, _dir) \
+ { \
+ .name = _name, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+ USB_EP_CAPS_DIR_ ## _dir), \
+ }
+ /* everyone has ep0 */
+ EP_INFO(ep0name,CONTROL, ALL),
/* act like a pxa250: fifteen fixed function endpoints */
- "ep1in-bulk", "ep2out-bulk", "ep3in-iso", "ep4out-iso", "ep5in-int",
- "ep6in-bulk", "ep7out-bulk", "ep8in-iso", "ep9out-iso", "ep10in-int",
- "ep11in-bulk", "ep12out-bulk", "ep13in-iso", "ep14out-iso",
- "ep15in-int",
-
+ EP_INFO("ep1in-bulk", BULK, IN),
+ EP_INFO("ep2out-bulk", BULK, OUT),
+ EP_INFO("ep3in-iso",ISO,IN),
+ EP_INFO("ep4out-iso", ISO,OUT),
+ EP_INFO("ep5in-int",INT,IN),
+ EP_INFO("ep6in-bulk", BULK, IN),
+ EP_INFO("ep7out-bulk", BULK, OUT),
+ EP_INFO("ep8in-iso",ISO,IN),
+ EP_INFO("ep9out-iso", ISO,OUT),
+ EP_INFO("ep10in-int", INT,IN),
+ EP_INFO("ep11in-bulk", BULK, IN),
+ EP_INFO("ep12out-bulk", BULK, OUT),
+ EP_INFO("ep13in-iso", ISO,IN),
+ EP_INFO("ep14out-iso", ISO,OUT),
+ EP_INFO("ep15in-int", INT,IN),
/* or like sa1100: two fixed function endpoints */
- "ep1out-bulk", "ep2in-bulk",
-
+ EP_INFO("ep1out-bulk", BULK, OUT),
+ EP_INFO("ep2in-bulk", BULK, IN),
/* and now some generic EPs so we have enough in multi config */
- "ep3out", "ep4in", "ep5out", "ep6out", "ep7in", "ep8out", "ep9in",
- "ep10out", "ep11out", "ep12in", "ep13out", "ep14in", "ep15out",
+ EP_INFO("ep3out", ALL,OUT),
+ EP_INFO("ep4in",ALL,IN),
+ EP_INFO("ep5out", ALL,OUT),
+ EP_INFO("ep6out", ALL,OUT),
+ EP_INFO("ep7in",ALL,IN),
+ EP_INFO("ep8out", ALL,OUT),
+ EP_INFO("ep9in",ALL,IN),
+ EP_INFO("ep10out", ALL,OUT),
+ EP_INFO("ep11out", ALL,OUT),
+ EP_INFO("ep12in", ALL,IN),
+ EP_INFO("ep13out", ALL,OUT),
+ EP_INFO("ep14in", ALL,IN),
+ EP_INFO("ep15out", ALL,OUT),
+
+#undef EP_INFO
};
-#define DUMMY_ENDPOINTSARRAY_SIZE(ep_name)
+
+#define DUMMY_ENDPOINTSARRAY_SIZE(ep_info)
/*-*/
@@ -938,9 +972,10 @@ static void init_dummy_udc_hw(struct dummy *dum)
for (i = 0; i < DUMMY_ENDPOINTS; i++) {
struct dummy_ep *ep = &dum->ep[i];
- if (!ep_name[i])
+ if (!ep_info[i].name)
break;
- ep->ep.name = ep_name[i];
+ ep->ep.name = ep_info[i].name;
+ ep->ep.caps = ep_info[i].caps;
ep->ep.ops = &dummy_ep_ops;
list_add_tail(&ep->ep.ep_list, &dum->gadget.ep_list);
ep->halted = ep->wedged = ep->already_seen =
@@ -1684,7 +1719,7 @@ static void dummy_timer(unsigned long _dum_hcd)
}
for (i = 0; i < DUMMY_ENDPOINTS; i++) {
- if (!ep_name[i])
+ if (!ep_info[i].name)
break;
dum->ep[i].already_seen = 0;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 14/37] usb: gadget: fsl_qe_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/fsl_qe_udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c
b/drivers/usb/gadget/udc/fsl_qe_udc.c
index e0822f1..5fb6f8b 100644
--- a/drivers/usb/gadget/udc/fsl_qe_udc.c
+++ b/drivers/usb/gadget/udc/fsl_qe_udc.c
@@ -2417,6 +2417,17 @@ static int qe_ep_config(struct qe_udc *udc, unsigned
char pipe_num)
strcpy(ep->name, ep_name[pipe_num]);
ep->ep.name = ep_name[pipe_num];
+ if (pipe_num == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
+
ep->ep.ops = &qe_ep_ops;
ep->stopped = 1;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 15/37] usb: gadget: fsl_udc_core: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/fsl_udc_core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/drivers/usb/gadget/udc/fsl_udc_core.c
index c60022b..aab5221 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2313,6 +2313,19 @@ static int struct_ep_setup(struct fsl_udc *udc, unsigned
char index,
ep->ep.ops = &fsl_ep_ops;
ep->stopped = 0;
+ if (index == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+
+ if (index & 1)
+ ep->ep.caps.dir_in = true;
+ else
+ ep->ep.caps.dir_out = true;
+
/* for ep0: maxP defined in desc
* for other eps, maxP is set by epautoconfig() called by gadget layer
*/
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 18/37] usb: gadget: gr_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/gr_udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
index c886887..8aa2593 100644
--- a/drivers/usb/gadget/udc/gr_udc.c
+++ b/drivers/usb/gadget/udc/gr_udc.c
@@ -2018,12 +2018,23 @@ static int gr_ep_init(struct gr_udc *dev, int num, int
is_in, u32 maxplimit)
usb_ep_set_maxpacket_limit(&ep->ep, MAX_CTRL_PL_SIZE);
ep->bytes_per_buffer = MAX_CTRL_PL_SIZE;
+
+ ep->ep.caps.type_control = true;
} else {
usb_ep_set_maxpacket_limit(&ep->ep, (u16)maxplimit);
list_add_tail(&ep->ep.ep_list, &dev->gadget.ep_list);
+
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
}
list_add_tail(&ep->ep_list, &dev->ep_list);
+ if (is_in)
+ ep->ep.caps.dir_in = true;
+ else
+ ep->ep.caps.dir_out = true;
+
ep->tailbuf = dma_alloc_coherent(dev->dev, ep->ep.maxpacket_limit,
&ep->tailbuf_paddr, GFP_ATOMIC);
if (!ep->tailbuf)
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 17/37] usb: gadget: goku_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model. Signed-off-by: Robert Baldyga --- drivers/usb/gadget/udc/goku_udc.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/gadget/udc/goku_udc.c b/drivers/usb/gadget/udc/goku_udc.c index 9e8d842..46b8d14 100644 --- a/drivers/usb/gadget/udc/goku_udc.c +++ b/drivers/usb/gadget/udc/goku_udc.c @@ -1257,6 +1257,14 @@ static void udc_reinit (struct goku_udc *dev) INIT_LIST_HEAD (&ep->queue); ep_reset(NULL, ep); + + if (i == 0) + ep->ep.caps.type_control = true; + else + ep->ep.caps.type_bulk = true; + + ep->ep.caps.dir_in = true; + ep->ep.caps.dir_out = true; } dev->ep[0].reg_mode = NULL; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 16/37] usb: gadget: fusb300_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/fusb300_udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/fusb300_udc.c
b/drivers/usb/gadget/udc/fusb300_udc.c
index 3970f45..948845c 100644
--- a/drivers/usb/gadget/udc/fusb300_udc.c
+++ b/drivers/usb/gadget/udc/fusb300_udc.c
@@ -1450,6 +1450,17 @@ static int fusb300_probe(struct platform_device *pdev)
ep->ep.name = fusb300_ep_name[i];
ep->ep.ops = &fusb300_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, HS_BULK_MAX_PACKET_SIZE);
+
+ if (i == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&fusb300->ep[0]->ep, HS_CTL_MAX_PACKET_SIZE);
fusb300->ep[0]->epnum = 0;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 22/37] usb: gadget: mv_udc_core: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/mv_udc_core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/gadget/udc/mv_udc_core.c
b/drivers/usb/gadget/udc/mv_udc_core.c
index d32160d..306a7ff 100644
--- a/drivers/usb/gadget/udc/mv_udc_core.c
+++ b/drivers/usb/gadget/udc/mv_udc_core.c
@@ -1257,6 +1257,9 @@ static int eps_init(struct mv_udc *udc)
ep->wedge = 0;
ep->stopped = 0;
usb_ep_set_maxpacket_limit(&ep->ep, EP0_MAX_PKT_SIZE);
+ ep->ep.caps.type_control = true;
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
ep->ep_num = 0;
ep->ep.desc = &mv_ep0_desc;
INIT_LIST_HEAD(&ep->queue);
@@ -1269,14 +1272,20 @@ static int eps_init(struct mv_udc *udc)
if (i % 2) {
snprintf(name, sizeof(name), "ep%din", i / 2);
ep->direction = EP_DIR_IN;
+ ep->ep.caps.dir_in = true;
} else {
snprintf(name, sizeof(name), "ep%dout", i / 2);
ep->direction = EP_DIR_OUT;
+ ep->ep.caps.dir_out = true;
}
ep->udc = udc;
strncpy(ep->name, name, sizeof(ep->name));
ep->ep.name = ep->name;
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+
ep->ep.ops = &mv_ep_ops;
ep->stopped = 0;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 20/37] usb: gadget: m66592-udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/m66592-udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/m66592-udc.c
b/drivers/usb/gadget/udc/m66592-udc.c
index 309706f..e404553 100644
--- a/drivers/usb/gadget/udc/m66592-udc.c
+++ b/drivers/usb/gadget/udc/m66592-udc.c
@@ -1644,6 +1644,17 @@ static int m66592_probe(struct platform_device *pdev)
ep->ep.name = m66592_ep_name[i];
ep->ep.ops = &m66592_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, 512);
+
+ if (i == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&m66592->ep[0].ep, 64);
m66592->ep[0].pipenum = 0;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 19/37] usb: gadget: lpc32xx_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/lpc32xx_udc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c
b/drivers/usb/gadget/udc/lpc32xx_udc.c
index 3b6a785..00b5006 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -2575,6 +2575,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep0",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 64,
.hwep_num_base = 0,
@@ -2586,6 +2588,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep1-int",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 64,
.hwep_num_base = 2,
@@ -2597,6 +2601,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep2-bulk",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 64,
.hwep_num_base = 4,
@@ -2608,6 +2614,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep3-iso",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 1023,
.hwep_num_base = 6,
@@ -2619,6 +2627,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep4-int",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 64,
.hwep_num_base = 8,
@@ -2630,6 +2640,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep5-bulk",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 64,
.hwep_num_base = 10,
@@ -2641,6 +2653,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep6-iso",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 1023,
.hwep_num_base = 12,
@@ -2652,6 +2666,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep7-int",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 64,
.hwep_num_base = 14,
@@ -2663,6 +2679,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep8-bulk",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 64,
.hwep_num_base = 16,
@@ -2674,6 +2692,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep9-iso",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+ USB_EP_CAPS_DIR_ALL),
},
.maxpacket = 1023,
.hwep_num_base = 18,
@@ -2685,6 +2705,8 @@ static const struct lpc32xx_udc controller_template = {
.ep = {
.name = "ep10-int",
.ops= &lpc32xx_ep_ops,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+ USB_EP_CAPS_DIR_ALL),
},
[PATCH 23/37] usb: gadget: net2272: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/net2272.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index 195baf3..34ec1ec 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -1404,6 +1404,17 @@ net2272_usb_reinit(struct net2272 *dev)
else
ep->fifo_size = 64;
net2272_ep_reset(ep);
+
+ if (i == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&dev->ep[0].ep, 64);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 25/37] usb: gadget: omap_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/omap_udc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/usb/gadget/udc/omap_udc.c
b/drivers/usb/gadget/udc/omap_udc.c
index e2fcdb8..9b7d394 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -2579,6 +2579,28 @@ omap_ep_setup(char *name, u8 addr, u8 type,
ep->double_buf = dbuf;
ep->udc = udc;
+ switch (type) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ ep->ep.caps.type_control = true;
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
+ break;
+ case USB_ENDPOINT_XFER_ISOC:
+ ep->ep.caps.type_iso = true;
+ break;
+ case USB_ENDPOINT_XFER_BULK:
+ ep->ep.caps.type_bulk = true;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ ep->ep.caps.type_int = true;
+ break;
+ };
+
+ if (addr & USB_DIR_IN)
+ ep->ep.caps.dir_in = true;
+ else
+ ep->ep.caps.dir_out = true;
+
ep->ep.name = ep->name;
ep->ep.ops = &omap_ep_ops;
ep->maxpacket = maxp;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 24/37] usb: gadget: net2280: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/net2280.c | 50 ++--
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 2bee912..0295cf7 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -74,19 +74,41 @@ static const char driver_desc[] = DRIVER_DESC;
static const u32 ep_bit[9] = { 0, 17, 2, 19, 4, 1, 18, 3, 20 };
static const char ep0name[] = "ep0";
-static const char *const ep_name[] = {
- ep0name,
- "ep-a", "ep-b", "ep-c", "ep-d",
- "ep-e", "ep-f", "ep-g", "ep-h",
-};
-/* Endpoint names for usb3380 advance mode */
-static const char *const ep_name_adv[] = {
- ep0name,
- "ep1in", "ep2out", "ep3in", "ep4out",
- "ep1out", "ep2in", "ep3out", "ep4in",
+#define EP_INFO(_name, _type, _dir) \
+ { \
+ .name = _name, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## _type, \
+ USB_EP_CAPS_DIR_ ## _dir), \
+ }
+
+static const struct {
+ const char *name;
+ const struct usb_ep_caps caps;
+} ep_info_dft[] = { /* Default endpoint configuration */
+ EP_INFO(ep0name, CONTROL, ALL),
+ EP_INFO("ep-a", ALL,ALL),
+ EP_INFO("ep-b", ALL,ALL),
+ EP_INFO("ep-c", ALL,ALL),
+ EP_INFO("ep-d", ALL,ALL),
+ EP_INFO("ep-e", ALL,ALL),
+ EP_INFO("ep-f", ALL,ALL),
+ EP_INFO("ep-g", ALL,ALL),
+ EP_INFO("ep-h", ALL,ALL),
+}, ep_info_adv[] = { /* Endpoints for usb3380 advance mode */
+ EP_INFO(ep0name, CONTROL, ALL),
+ EP_INFO("ep1in",ALL,IN),
+ EP_INFO("ep2out", ALL,OUT),
+ EP_INFO("ep3in",ALL,IN),
+ EP_INFO("ep4out", ALL,OUT),
+ EP_INFO("ep1out", ALL,OUT),
+ EP_INFO("ep2in",ALL,IN),
+ EP_INFO("ep3out", ALL,OUT),
+ EP_INFO("ep4in",ALL,IN),
};
+#undef EP_INFO
+
/* mode 0 == ep-{a,b,c,d} 1K fifo each
* mode 1 == ep-{a,b} 2K fifo each, ep-{c,d} unavailable
* mode 2 == ep-a 2K fifo, ep-{b,c} 1K each, ep-d unavailable
@@ -2055,7 +2077,8 @@ static void usb_reinit_228x(struct net2280 *dev)
for (tmp = 0; tmp < 7; tmp++) {
struct net2280_ep *ep = &dev->ep[tmp];
- ep->ep.name = ep_name[tmp];
+ ep->ep.name = ep_info_dft[tmp].name;
+ ep->ep.caps = ep_info_dft[tmp].caps;
ep->dev = dev;
ep->num = tmp;
@@ -2095,7 +2118,10 @@ static void usb_reinit_338x(struct net2280 *dev)
for (i = 0; i < dev->n_ep; i++) {
struct net2280_ep *ep = &dev->ep[i];
- ep->ep.name = dev->enhanced_mode ? ep_name_adv[i] : ep_name[i];
+ ep->ep.name = dev->enhanced_mode ? ep_info_adv[i].name :
+ ep_info_dft[i].name;
+ ep->ep.caps = dev->enhanced_mode ? ep_info_adv[i].caps :
+ ep_info_dft[i].caps;
ep->dev = dev;
ep->num = i;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 21/37] usb: gadget: mv_u3d_core: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/mv_u3d_core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/gadget/udc/mv_u3d_core.c
b/drivers/usb/gadget/udc/mv_u3d_core.c
index ea35a24..4c48969 100644
--- a/drivers/usb/gadget/udc/mv_u3d_core.c
+++ b/drivers/usb/gadget/udc/mv_u3d_core.c
@@ -1324,6 +1324,9 @@ static int mv_u3d_eps_init(struct mv_u3d *u3d)
ep->ep.ops = &mv_u3d_ep_ops;
ep->wedge = 0;
usb_ep_set_maxpacket_limit(&ep->ep, MV_U3D_EP0_MAX_PKT_SIZE);
+ ep->ep.caps.type_control = true;
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
ep->ep_num = 0;
ep->ep.desc = &mv_u3d_ep0_desc;
INIT_LIST_HEAD(&ep->queue);
@@ -1339,14 +1342,20 @@ static int mv_u3d_eps_init(struct mv_u3d *u3d)
if (i & 1) {
snprintf(name, sizeof(name), "ep%din", i >> 1);
ep->direction = MV_U3D_EP_DIR_IN;
+ ep->ep.caps.dir_in = true;
} else {
snprintf(name, sizeof(name), "ep%dout", i >> 1);
ep->direction = MV_U3D_EP_DIR_OUT;
+ ep->ep.caps.dir_out = true;
}
ep->u3d = u3d;
strncpy(ep->name, name, sizeof(ep->name));
ep->ep.name = ep->name;
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+
ep->ep.ops = &mv_u3d_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, (unsigned short) ~0);
ep->ep_num = i / 2;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 26/37] usb: gadget: pch_ud: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/pch_udc.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 613547f..cc8fb3c 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -2895,11 +2895,21 @@ static void pch_udc_pcd_reinit(struct pch_udc_dev *dev)
ep->in = ~i & 1;
ep->ep.name = ep_string[i];
ep->ep.ops = &pch_udc_ep_ops;
- if (ep->in)
+ if (ep->in) {
ep->offset_addr = ep->num * UDC_EP_REG_SHIFT;
- else
+ ep->ep.caps.dir_in = true;
+ } else {
ep->offset_addr = (UDC_EPINT_OUT_SHIFT + ep->num) *
UDC_EP_REG_SHIFT;
+ ep->ep.caps.dir_out = true;
+ }
+ if (i == UDC_EP0IN_IDX || i == UDC_EP0OUT_IDX) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
/* need to set ep->ep.maxpacket and set Default Configuration?*/
usb_ep_set_maxpacket_limit(&ep->ep, UDC_BULK_MAX_PKT_SIZE);
list_add_tail(&ep->ep.ep_list, &dev->gadget.ep_list);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 27/37] usb: gadget: pxa25x_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/pxa25x_udc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c
b/drivers/usb/gadget/udc/pxa25x_udc.c
index f6cbe66..1301e29 100644
--- a/drivers/usb/gadget/udc/pxa25x_udc.c
+++ b/drivers/usb/gadget/udc/pxa25x_udc.c
@@ -1821,6 +1821,8 @@ static struct pxa25x_udc memory = {
.name = ep0name,
.ops= &pxa25x_ep_ops,
.maxpacket = EP0_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
+ USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.reg_udccs = &UDCCS0,
@@ -1833,6 +1835,8 @@ static struct pxa25x_udc memory = {
.name = "ep1in-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket = BULK_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size = BULK_FIFO_SIZE,
@@ -1846,6 +1850,8 @@ static struct pxa25x_udc memory = {
.name = "ep2out-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket = BULK_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_OUT),
},
.dev= &memory,
.fifo_size = BULK_FIFO_SIZE,
@@ -1861,6 +1867,8 @@ static struct pxa25x_udc memory = {
.name = "ep3in-iso",
.ops= &pxa25x_ep_ops,
.maxpacket = ISO_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+ USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size = ISO_FIFO_SIZE,
@@ -1874,6 +1882,8 @@ static struct pxa25x_udc memory = {
.name = "ep4out-iso",
.ops= &pxa25x_ep_ops,
.maxpacket = ISO_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+ USB_EP_CAPS_DIR_OUT),
},
.dev= &memory,
.fifo_size = ISO_FIFO_SIZE,
@@ -1888,6 +1898,8 @@ static struct pxa25x_udc memory = {
.name = "ep5in-int",
.ops= &pxa25x_ep_ops,
.maxpacket = INT_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_INT,
+ USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size = INT_FIFO_SIZE,
@@ -1903,6 +1915,8 @@ static struct pxa25x_udc memory = {
.name = "ep6in-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket = BULK_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size = BULK_FIFO_SIZE,
@@ -1916,6 +1930,8 @@ static struct pxa25x_udc memory = {
.name = "ep7out-bulk",
.ops= &pxa25x_ep_ops,
.maxpacket = BULK_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_OUT),
},
.dev= &memory,
.fifo_size = BULK_FIFO_SIZE,
@@ -1930,6 +1946,8 @@ static struct pxa25x_udc memory = {
.name = "ep8in-iso",
.ops= &pxa25x_ep_ops,
.maxpacket = ISO_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ISO,
+ USB_EP_CAPS_DIR_IN),
},
.dev= &memory,
.fifo_size = ISO_FIFO_SIZE,
@@ -1943,6 +1961,8 @@ static struct pxa25x_udc memory = {
.name = "ep9out-iso",
.ops= &pxa25x_ep_ops,
.maxpacket = ISO_FI
[PATCH 28/37] usb: gadget: pxa27x_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/pxa27x_udc.h | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa27x_udc.h
b/drivers/usb/gadget/udc/pxa27x_udc.h
index 11e1423..ded058c 100644
--- a/drivers/usb/gadget/udc/pxa27x_udc.h
+++ b/drivers/usb/gadget/udc/pxa27x_udc.h
@@ -234,25 +234,28 @@
/*
* Endpoint definition helpers
*/
-#define USB_EP_DEF(addr, bname, dir, type, maxpkt) \
-{ .usb_ep = { .name = bname, .ops = &pxa_ep_ops, .maxpacket = maxpkt, }, \
+#define USB_EP_DEF(addr, bname, dir, type, maxpkt, ctype, cdir) \
+{ .usb_ep = { .name = bname, .ops = &pxa_ep_ops, .maxpacket = maxpkt, \
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_ ## ctype, \
+ USB_EP_CAPS_DIR_ ## cdir), }, \
.desc = {.bEndpointAddress = addr | (dir ? USB_DIR_IN : 0), \
- .bmAttributes = type, \
+ .bmAttributes = USB_ENDPOINT_XFER_ ## type, \
.wMaxPacketSize = maxpkt, }, \
.dev = &memory \
}
-#define USB_EP_BULK(addr, bname, dir) \
- USB_EP_DEF(addr, bname, dir, USB_ENDPOINT_XFER_BULK, BULK_FIFO_SIZE)
-#define USB_EP_ISO(addr, bname, dir) \
- USB_EP_DEF(addr, bname, dir, USB_ENDPOINT_XFER_ISOC, ISO_FIFO_SIZE)
-#define USB_EP_INT(addr, bname, dir) \
- USB_EP_DEF(addr, bname, dir, USB_ENDPOINT_XFER_INT, INT_FIFO_SIZE)
-#define USB_EP_IN_BULK(n) USB_EP_BULK(n, "ep" #n "in-bulk", 1)
-#define USB_EP_OUT_BULK(n) USB_EP_BULK(n, "ep" #n "out-bulk", 0)
-#define USB_EP_IN_ISO(n) USB_EP_ISO(n, "ep" #n "in-iso", 1)
-#define USB_EP_OUT_ISO(n) USB_EP_ISO(n, "ep" #n "out-iso", 0)
-#define USB_EP_IN_INT(n) USB_EP_INT(n, "ep" #n "in-int", 1)
-#define USB_EP_CTRLUSB_EP_DEF(0, "ep0", 0, 0, EP0_FIFO_SIZE)
+#define USB_EP_BULK(addr, bname, dir, cdir) \
+ USB_EP_DEF(addr, bname, dir, BULK, BULK_FIFO_SIZE, BULK, cdir)
+#define USB_EP_ISO(addr, bname, dir, cdir) \
+ USB_EP_DEF(addr, bname, dir, ISOC, ISO_FIFO_SIZE, ISO, cdir)
+#define USB_EP_INT(addr, bname, dir, cdir) \
+ USB_EP_DEF(addr, bname, dir, INT, INT_FIFO_SIZE, INT, cdir)
+#define USB_EP_IN_BULK(n) USB_EP_BULK(n, "ep" #n "in-bulk", 1, IN)
+#define USB_EP_OUT_BULK(n) USB_EP_BULK(n, "ep" #n "out-bulk", 0, OUT)
+#define USB_EP_IN_ISO(n) USB_EP_ISO(n, "ep" #n "in-iso", 1, IN)
+#define USB_EP_OUT_ISO(n) USB_EP_ISO(n, "ep" #n "out-iso", 0, OUT)
+#define USB_EP_IN_INT(n) USB_EP_INT(n, "ep" #n "in-int", 1, IN)
+#define USB_EP_CTRLUSB_EP_DEF(0, "ep0", 0, CONTROL, \
+ EP0_FIFO_SIZE, CONTROL, ALL)
#define PXA_EP_DEF(_idx, _addr, dir, _type, maxpkt, _config, iface, altset) \
{ \
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 29/37] usb: gadget: r8a66597-udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/r8a66597-udc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/gadget/udc/r8a66597-udc.c
b/drivers/usb/gadget/udc/r8a66597-udc.c
index 0293f71..baa0609 100644
--- a/drivers/usb/gadget/udc/r8a66597-udc.c
+++ b/drivers/usb/gadget/udc/r8a66597-udc.c
@@ -1935,6 +1935,16 @@ static int r8a66597_probe(struct platform_device *pdev)
ep->ep.name = r8a66597_ep_name[i];
ep->ep.ops = &r8a66597_ep_ops;
usb_ep_set_maxpacket_limit(&ep->ep, 512);
+
+ if (i == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
}
usb_ep_set_maxpacket_limit(&r8a66597->ep[0].ep, 64);
r8a66597->ep[0].pipenum = 0;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 30/37] usb: gadget: s3c-hsudc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/s3c-hsudc.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/gadget/udc/s3c-hsudc.c
b/drivers/usb/gadget/udc/s3c-hsudc.c
index 85a712a..e9def42 100644
--- a/drivers/usb/gadget/udc/s3c-hsudc.c
+++ b/drivers/usb/gadget/udc/s3c-hsudc.c
@@ -1005,6 +1005,21 @@ static void s3c_hsudc_initep(struct s3c_hsudc *hsudc,
hsep->stopped = 0;
hsep->wedge = 0;
+ if (epnum == 0) {
+ hsep->ep.caps.type_control = true;
+ hsep->ep.caps.dir_in = true;
+ hsep->ep.caps.dir_out = true;
+ } else {
+ hsep->ep.caps.type_iso = true;
+ hsep->ep.caps.type_bulk = true;
+ hsep->ep.caps.type_int = true;
+ }
+
+ if (epnum & 1)
+ hsep->ep.caps.dir_in = true;
+ else
+ hsep->ep.caps.dir_out = true;
+
set_index(hsudc, epnum);
writel(hsep->ep.maxpacket, hsudc->regs + S3C_MPR);
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 33/37] usb: isp1760: udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/isp1760/isp1760-udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/isp1760/isp1760-udc.c
b/drivers/usb/isp1760/isp1760-udc.c
index 3699962..1c3d0fd 100644
--- a/drivers/usb/isp1760/isp1760-udc.c
+++ b/drivers/usb/isp1760/isp1760-udc.c
@@ -1383,13 +1383,24 @@ static void isp1760_udc_init_eps(struct isp1760_udc
*udc)
*/
if (ep_num == 0) {
usb_ep_set_maxpacket_limit(&ep->ep, 64);
+ ep->ep.caps.type_control = true;
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
ep->maxpacket = 64;
udc->gadget.ep0 = &ep->ep;
} else {
usb_ep_set_maxpacket_limit(&ep->ep, 512);
+ ep->ep.caps.type_iso = true;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
ep->maxpacket = 0;
list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
}
+
+ if (is_in)
+ ep->ep.caps.dir_in = true;
+ else
+ ep->ep.caps.dir_out = true;
}
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 31/37] usb: gadget: s3c2410_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/s3c2410_udc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c
b/drivers/usb/gadget/udc/s3c2410_udc.c
index 5d9aa81..eb3571e 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -1691,6 +1691,8 @@ static struct s3c2410_udc memory = {
.name = ep0name,
.ops= &s3c2410_ep_ops,
.maxpacket = EP0_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_CONTROL,
+ USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
},
@@ -1702,6 +1704,8 @@ static struct s3c2410_udc memory = {
.name = "ep1-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket = EP_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size = EP_FIFO_SIZE,
@@ -1714,6 +1718,8 @@ static struct s3c2410_udc memory = {
.name = "ep2-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket = EP_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size = EP_FIFO_SIZE,
@@ -1726,6 +1732,8 @@ static struct s3c2410_udc memory = {
.name = "ep3-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket = EP_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size = EP_FIFO_SIZE,
@@ -1738,6 +1746,8 @@ static struct s3c2410_udc memory = {
.name = "ep4-bulk",
.ops= &s3c2410_ep_ops,
.maxpacket = EP_FIFO_SIZE,
+ .caps = USB_EP_CAPS(USB_EP_CAPS_TYPE_BULK,
+ USB_EP_CAPS_DIR_ALL),
},
.dev= &memory,
.fifo_size = EP_FIFO_SIZE,
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 32/37] usb: gadget: udc-xilinx: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/udc-xilinx.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-xilinx.c
b/drivers/usb/gadget/udc/udc-xilinx.c
index 1f24274..1cbb0ac 100644
--- a/drivers/usb/gadget/udc/udc-xilinx.c
+++ b/drivers/usb/gadget/udc/udc-xilinx.c
@@ -1317,12 +1317,21 @@ static void xudc_eps_init(struct xusb_udc *udc)
snprintf(ep->name, EPNAME_SIZE, "ep%d", ep_number);
ep->ep_usb.name = ep->name;
ep->ep_usb.ops = &xusb_ep_ops;
+
+ ep->ep_usb.caps.type_iso = true;
+ ep->ep_usb.caps.type_bulk = true;
+ ep->ep_usb.caps.type_int = true;
} else {
ep->ep_usb.name = ep0name;
usb_ep_set_maxpacket_limit(&ep->ep_usb, EP0_MAX_PACKET);
ep->ep_usb.ops = &xusb_ep0_ops;
+
+ ep->ep_usb.caps.type_control = true;
}
+ ep->ep_usb.caps.dir_in = true;
+ ep->ep_usb.caps.dir_out = true;
+
ep->udc = udc;
ep->epnumber = ep_number;
ep->desc = NULL;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 36/37] usb: gadget: atmel_usba_udc: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 37d414e..267d84f 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -2067,6 +2067,17 @@ static struct usba_ep * usba_udc_pdata(struct
platform_device *pdev,
ep->can_dma = pdata->ep[i].can_dma;
ep->can_isoc = pdata->ep[i].can_isoc;
+ if (i == 0) {
+ ep->ep.caps.type_control = true;
+ } else {
+ ep->ep.caps.type_iso = ep->can_isoc;
+ ep->ep.caps.type_bulk = true;
+ ep->ep.caps.type_int = true;
+ }
+
+ ep->ep.caps.dir_in = true;
+ ep->ep.caps.dir_out = true;
+
if (i)
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 37/37] usb: gadget: epautoconf: add endpoint capabilities flags verification
Introduce endpoint matching mechanism basing on endpoint capabilities
flags. We check if endpoint supports transfer type and direction requested
in ep descriptor. Since we have this new endpoint matching mechanism
there is no need to have old code guessing endpoint capabilities basing
on its name, so we are getting rid of it.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/epautoconf.c | 72 +
1 file changed, 22 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 8e00ca7..38df22a 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -47,7 +47,6 @@ ep_matches (
)
{
u8 type;
- const char *tmp;
u16 max;
int num_req_streams = 0;
@@ -56,58 +55,31 @@ ep_matches (
if (ep->claimed)
return 0;
- /* only support ep0 for portable CONTROL traffic */
type = usb_endpoint_type(desc);
- if (USB_ENDPOINT_XFER_CONTROL == type)
- return 0;
-
- /* some other naming convention */
- if ('e' != ep->name[0])
+ switch (type) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ /* only support ep0 for portable CONTROL traffic */
return 0;
+ case USB_ENDPOINT_XFER_ISOC:
+ if (!ep->caps.type_iso)
+ return 0;
+ break;
+ case USB_ENDPOINT_XFER_BULK:
+ if (!ep->caps.type_bulk)
+ return 0;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ if (!ep->caps.type_int)
+ return 0;
+ break;
+ }
- /* type-restriction: "-iso", "-bulk", or "-int".
-* direction-restriction: "in", "out".
-*/
- if ('-' != ep->name[2]) {
- tmp = strrchr (ep->name, '-');
- if (tmp) {
- switch (type) {
- case USB_ENDPOINT_XFER_INT:
- /* bulk endpoints handle interrupt transfers,
-* except the toggle-quirky iso-synch kind
-*/
- if ('s' == tmp[2]) // == "-iso"
- return 0;
- /* for now, avoid PXA "interrupt-in";
-* it's documented as never using DATA1.
-*/
- if (gadget_is_pxa (gadget)
- && 'i' == tmp [1])
- return 0;
- break;
- case USB_ENDPOINT_XFER_BULK:
- if ('b' != tmp[1]) // != "-bulk"
- return 0;
- break;
- case USB_ENDPOINT_XFER_ISOC:
- if ('s' != tmp[2]) // != "-iso"
- return 0;
- }
- } else {
- tmp = ep->name + strlen (ep->name);
- }
-
- /* direction-restriction: "..in-..", "out-.." */
- tmp--;
- if (!isdigit (*tmp)) {
- if (desc->bEndpointAddress & USB_DIR_IN) {
- if ('n' != *tmp)
- return 0;
- } else {
- if ('t' != *tmp)
- return 0;
- }
- }
+ if (usb_endpoint_dir_in(desc)) {
+ if (!ep->caps.dir_in)
+ return 0;
+ } else {
+ if (!ep->caps.dir_out)
+ return 0;
}
/*
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 35/37] usb: renesas: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/renesas_usbhs/mod_gadget.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
b/drivers/usb/renesas_usbhs/mod_gadget.c
index dc2aa32..ed8d890 100644
--- a/drivers/usb/renesas_usbhs/mod_gadget.c
+++ b/drivers/usb/renesas_usbhs/mod_gadget.c
@@ -1041,12 +1041,18 @@ int usbhs_mod_gadget_probe(struct usbhs_priv *priv)
if (usbhsg_is_dcp(uep)) {
gpriv->gadget.ep0 = &uep->ep;
usb_ep_set_maxpacket_limit(&uep->ep, 64);
+ uep->ep.caps.type_control = true;
}
/* init normal pipe */
else {
usb_ep_set_maxpacket_limit(&uep->ep, 512);
+ uep->ep.caps.type_iso = true;
+ uep->ep.caps.type_bulk = true;
+ uep->ep.caps.type_int = true;
list_add_tail(&uep->ep.ep_list, &gpriv->gadget.ep_list);
}
+ uep->ep.caps.dir_in = true;
+ uep->ep.caps.dir_out = true;
}
ret = usb_add_gadget_udc(dev, &gpriv->gadget);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 34/37] usb: musb: gadget: add ep capabilities support
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga
---
drivers/usb/musb/musb_gadget.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 625d482f..043248a 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1729,6 +1729,7 @@ init_peripheral_ep(struct musb *musb, struct musb_ep *ep,
u8 epnum, int is_in)
INIT_LIST_HEAD(&ep->end_point.ep_list);
if (!epnum) {
usb_ep_set_maxpacket_limit(&ep->end_point, 64);
+ ep->end_point.caps.type_control = true;
ep->end_point.ops = &musb_g_ep0_ops;
musb->g.ep0 = &ep->end_point;
} else {
@@ -1736,9 +1737,20 @@ init_peripheral_ep(struct musb *musb, struct musb_ep
*ep, u8 epnum, int is_in)
usb_ep_set_maxpacket_limit(&ep->end_point,
hw_ep->max_packet_sz_tx);
else
usb_ep_set_maxpacket_limit(&ep->end_point,
hw_ep->max_packet_sz_rx);
+ ep->end_point.caps.type_iso = true;
+ ep->end_point.caps.type_bulk = true;
+ ep->end_point.caps.type_int = true;
ep->end_point.ops = &musb_ep_ops;
list_add_tail(&ep->end_point.ep_list, &musb->g.ep_list);
}
+
+ if (!epnum || hw_ep->is_shared_fifo) {
+ ep->end_point.caps.dir_in = true;
+ ep->end_point.caps.dir_out = true;
+ } else if (is_in)
+ ep->end_point.caps.dir_in = true;
+ else
+ ep->end_point.caps.dir_out = true;
}
/*
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails
Hello.
On 7/8/2015 12:05 PM, Robert Baldyga wrote:
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 | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 6e7be91..6516187 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2897,11 +2897,18 @@ 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)
+ if(!--ffs_opts->refcnt)
+ functionfs_unbind(func->ffs);
Hum, I think you need {} around the outer *if* clause. Either that, or
just fold two *if* statments together.
+
+ return ret;
}
[...]
WBR, Sergei
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: ozwpan: ozusbsvc1.c: Fix missing blank line after declarations
This patch fixes a missing line after declarations issue. Signed-off-by: Johannes Postma --- drivers/staging/ozwpan/ozusbsvc1.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/ozwpan/ozusbsvc1.c b/drivers/staging/ozwpan/ozusbsvc1.c index 301fee8..b6cfecb 100644 --- a/drivers/staging/ozwpan/ozusbsvc1.c +++ b/drivers/staging/ozwpan/ozusbsvc1.c @@ -327,6 +327,7 @@ static void oz_usb_handle_ep_data(struct oz_usb_ctx *usb_ctx, (struct oz_multiple_fixed *)data_hdr; u8 *data = body->data; unsigned int n; + if (!body->unit_size || len < sizeof(struct oz_multiple_fixed) - 1) break; -- 2.4.5 ___ 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 06/07/15 18:24, Dmitry Kalinkin wrote: Some functionality was dropped as it was not good practice >(such as receiving VME interrupts in user space, it's not really doable if >the slave card is Release On Register Access rather than Release on >Acknowledge), Didn't know about RORA. I wonder how different this is compared to the PCI bus case. Little I suspect. What it does mean is that there's no generic mechanism for clearing down an interrupt, so a device specific interrupt routine is required, which needs to be in kernel space. >so the interface became more of a debug mechanism for me. >Others have clearly found it provides enough for them to allow drivers to be >written in user space. > >I was thinking that the opposite might be better, no windows were mapped at >module load, windows could be allocated and mapped using the control device. >This would ensure that unused resources were still available for kernel >based drivers and would mean the driver wouldn't be pre-allocating a bunch >of fairly substantially sized slave window buffers (the buffers could also >be allocated to match the size of the slave window requested). What do you >think? 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. Those who need such API are welcome to develop it:) The aim of the existing APIs is to provide a mechanism for allocating resources. You're right, the resources are limited when scaling to a 32 slot crate. There's a number of ways to share the resources, though they tend to all have trade offs. My experience has been that the majority of VME systems don't tend to stretch up to 32 cards. As for dynamic vme_user device allocation, I don't see the point in this. The only existing kernel VME driver allocates windows in advance, user is just to make sure to leave one free window if she wants to use that. Module parameter for window count will be dynamic enough to handle that. If vme_user grabs all the VME windows, there are no windows available for any kernel level VME drivers to use. If a kernel level driver loads before vme_user and is allocated a window, if vme_user demands 8 windows (and assuming it doesn't deal with some already having been allocated gracefully, which it doesn't at the moment) then it doesn't load. Dynamic allocation would leave "unused" resources available rather than prospectively hogging them. -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 ___ 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/07/15 08:08, Alessio Igor Bogani wrote: I would be glad to try it if the maintainer is willing to receive this type of changes. Such requirements have come up in the past. I'd welcome such support being contributed to the kernel. My view has been that such an API could be built on top of the existing API. Does that seem workable to you? -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: remove dead code
From: Hari Prasath Gujulan Elango
This patch removes commented code.
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/lustre/lustre/osc/osc_cache.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c
b/drivers/staging/lustre/lustre/osc/osc_cache.c
index 5592d32..c72035e 100644
--- a/drivers/staging/lustre/lustre/osc/osc_cache.c
+++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
@@ -1837,12 +1837,6 @@ static int try_to_add_extent_for_io(struct client_obd
*cli,
oap2 = list_first_entry(&tmp->oe_pages, struct osc_async_page,
oap_pending_item);
EASSERT(tmp->oe_owner == current, tmp);
-#if 0
- if (overlapped(tmp, ext)) {
- OSC_EXTENT_DUMP(D_ERROR, tmp, "overlapped %p.\n", ext);
- EASSERT(0, ext);
- }
-#endif
if (oap2cl_page(oap)->cp_type != oap2cl_page(oap2)->cp_type) {
CDEBUG(D_CACHE, "Do not permit different type of IO"
" for a same RPC\n");
--
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/07/15 13: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). I think it's perfectly valid to use a single window to dynamically map to the address space belonging to one of a number of devices supported by a single driver. I think this is almost preferable to mapping a large window over a large portion of the VME address space to drive a number of devices as (depending on there spacing in the VME address space) the latter could cause issues with filling available PCI address space. Admittedly this is more of a problem on 32-bit systems, but... -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 15/20] staging/lustre/libcfs: get rid of debugfs/lnet/console_backoff
On Jul 8, 2015, at 4:28 AM, Dan Carpenter wrote:
> On Mon, Jul 06, 2015 at 12:48:53PM -0400, gr...@linuxhacker.ru wrote:
>> +static int param_set_uint_minmax(const char *val,
>> + const struct kernel_param *kp,
>> + unsigned int min, unsigned int max)
>> +{
>> +unsigned int num;
>> +int ret;
>> +
>> +if (!val)
>> +return -EINVAL;
>> +ret = kstrtouint(val, 0, &num);
>> +if (ret == -EINVAL || num < min || num > max)
> ^^^
> Smatch is smart enough to know that "num" can be uninitialized here on
> some paths. It doesn't generate a warning yet because a lot of the
> kernel has error paths where we mostly assume things won't fail.
>
> It should probably be:
>
> ret = kstrtouint(val, 0, &num);
> if (ret)
> return ret;
> if (num < min || num > max)
> return -EINVAL;
Hm, indeed kstrtouint can return errors other than -EINVAL.
In reality this code comes from net/sunrpc/xprtsock.c
and I failed to see the problem there while copying.
This also suggests that the type is might be enough in demand
to make it generic so that people don't reimplement it themselves?
Thanks!
Bye,
Oleg
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/5] usb: gadget: ffs: call functionfs_unbind() if _ffs_func_bind() fails
On Wed, Jul 08 2015, Robert Baldyga wrote:
> 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
Acked-by: Michal Nazarewicz
> ---
> drivers/usb/gadget/function/f_fs.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index 6e7be91..6516187 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -2897,11 +2897,18 @@ 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)
> + if(!--ffs_opts->refcnt)
> + functionfs_unbind(func->ffs);
> +
> + return ret;
> }
>
>
> --
> 1.9.1
>
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/5] usb: gadget: midi: avoid redundant f_midi_set_alt() call
On Wed, Jul 08 2015, Robert Baldyga wrote: > 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 Acked-by: Michal Nazarewicz > --- > 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 > -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/5] usb: isp1760: udc: add missing usb_ep_set_maxpacket_limit()
On Wed, Jul 08 2015, Robert Baldyga wrote:
> Since maxpacket_limit was introduced all UDC drivers should use
> usb_ep_set_maxpacket_limit() function instead of setting maxpacket value
> manually. ep.maxpacket_limit contains actual maximum maxpacket value
> supported by hardware which is needed by epautoconf.
>
> Signed-off-by: Robert Baldyga
Acked-by: Michal Nazarewicz
> ---
> 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
>
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
___
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
> Is there truly no way to simplify that process? I see some software development possibilities which could improve the communication with high volume mailing lists. > You should be sending the patches directly with SMTP using git-send-email, This tool is also fine for the publishing of a lot of patches. > if you're not, then you're making things overly complicated for yourself. But I prefer a graphical user interface for my mail handling so far. > Having a feature doesn't mean that it should be used. Does any of the "questionable functionality" get occasionally overlooked a bit too often? Regards, Markus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 5/5] usb: gadget: atmel_usba_udc: add missing ret value check
On Wed, Jul 08 2015, Robert Baldyga wrote:
> Add missing return value check. In case of error print debug message
> and return error code.
>
> Signed-off-by: Robert Baldyga
> Acked-by: Nicolas Ferre
Acked-by: Michal Nazarewicz
> ---
> 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
>
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/5] staging: emxx_udc: add missing usb_ep_set_maxpacket_limit()
On Wed, Jul 08 2015, Robert Baldyga wrote: > Since maxpacket_limit was introduced all UDC drivers should use > usb_ep_set_maxpacket_limit() function instead of setting maxpacket value > manually. ep.maxpacket_limit contains actual maximum maxpacket value > supported by hardware which is needed by epautoconf. > > Signed-off-by: Robert Baldyga Acked-by: Michal Nazarewicz > --- > 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..3b7aa36 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); I would break line just after ( like so: + usb_ep_set_maxpacket_limit( + &ep->ep, i ? EP_PACKETSIZE : EP0_PACKETSIZE); > > list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list); > INIT_LIST_HEAD(&ep->queue); > -- > 1.9.1 > -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- ___ 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/07/15 11:52, 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. I'm a little concerned by the latency this might cause, especially if there is one device which is negatively affected by latency. Handling RORA interrupts would be "interesting" if all the windows were dynamically allocated at the time at which an interrupt came in. Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 ___ 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 08 Jul 2015, at 16:41, Martyn Welch wrote: > > On 07/07/15 13: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). > > I think it's perfectly valid to use a single window to dynamically map to the > address space belonging to one of a number of devices supported by a single > driver. I think this is almost preferable to mapping a large window over a > large portion of the VME address space to drive a number of devices as > (depending on there spacing in the VME address space) the latter could cause > issues with filling available PCI address space. Admittedly this is more of a > problem on 32-bit systems, but… Speaking of which. We do have 32 bit SBC’s (Fastwell CPC600) and there we can only map up to 32mb. If we drop an unnecessary alignment requirement, this can be raised up to 63mb. The next comes a hack that is a bit dirty: changing pdev->bus to something like pdev->bus->parent. Then maximal VME window size is only limited by vmalloc memory which on 32bit system can be raised up to ~700 mb by adding vmalloc=768M to kernel argument line. For the reference, here is the iomem mapping of the working system without the hack (also some window mappings are already done): % cat /proc/iomem -0fff : reserved 1000-00097fff : System RAM 00098000-0009 : reserved 000a-000b : PCI Bus :00 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000d-000d0fff : Adapter ROM 000d1000-000d29ff : Adapter ROM 000d3000-000d3fff : Adapter ROM 000d4000-000d4fff : Adapter ROM 000d8000-000dbfff : PCI Bus :00 000dc000-000f : reserved 000f-000f : System ROM 0010-3de8 : System RAM 0100-01822261 : Kernel code 01822262-01ca4e3f : Kernel data 01da1000-01e6dfff : Kernel bss 3de9-3de96fff : ACPI Tables 3de97000-3def : ACPI Non-volatile Storage 3df0-3fff : reserved 4000-febf : PCI Bus :00 d800-d807 : :00:02.0 d808-d80f : :00:02.1 d810-d81f : :00:1d.4 d8100400-d81007ff : :00:1d.7 d8100400-d81007ff : ehci_hcd d820-dfff : PCI Bus :02 d820-d821 : :02:00.0 d820-d821 : e1000 d822-d823 : :02:00.1 d822-d823 : e1000 d824-d825 : :02:01.0 d824-d825 : e1000 d826-d827 : :02:01.1 d826-d827 : e1000 d828-d82f : vme_tsi148.7 d830-d830 : vme_tsi148.0 d831-d930 : vme_tsi148.3 d931-d931 : vme_tsi148.2 dc00-dc000fff : :02:02.0 dc00-dc000fff : vme_tsi148 e800-efff : :00:02.0 f000-f7ff : :00:02.1 fec0-fec003ff : IOAPIC 0 fec1-fec103ff : IOAPIC 1 fee0-feef : pnp 00:01 fee0-fee00fff : Local APIC fee0-fee00fff : pnp 00:02 feff-feff : reserved feff-feff : pnp 00:01 ff80- : INT0800:00 ff80-ffbf : reserved fc00- : reserved ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] vme: lower alignment requirement in pci bridge drivers
Universe II allows PCI address grannularity of 4K or 64K depending on
the window id. tsi148 only supports 64K. Existing driver implementations
are validating window size against this grannularity and then use that
very size as alignment parameter to pci_bus_alloc_resource. This
constraint is excessive, alignment by granularity should be enough.
This changes alignment constraint from size to a fixed constraint of
64K.
Signed-off-by: Dmitry Kalinkin
---
drivers/vme/bridges/vme_ca91cx42.c | 2 +-
drivers/vme/bridges/vme_tsi148.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vme/bridges/vme_ca91cx42.c
b/drivers/vme/bridges/vme_ca91cx42.c
index 834883d..b79a74a 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -553,7 +553,7 @@ static int ca91cx42_alloc_resource(struct
vme_master_resource *image,
image->bus_resource.flags = IORESOURCE_MEM;
retval = pci_bus_alloc_resource(pdev->bus,
- &image->bus_resource, size, size, PCIBIOS_MIN_MEM,
+ &image->bus_resource, size, 0x1, PCIBIOS_MIN_MEM,
0, NULL, NULL);
if (retval) {
dev_err(ca91cx42_bridge->parent, "Failed to allocate mem "
diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index b0132e0..d1e383b 100644
--- a/drivers/vme/bridges/vme_tsi148.c
+++ b/drivers/vme/bridges/vme_tsi148.c
@@ -768,7 +768,7 @@ static int tsi148_alloc_resource(struct vme_master_resource
*image,
image->bus_resource.flags = IORESOURCE_MEM;
retval = pci_bus_alloc_resource(pdev->bus,
- &image->bus_resource, size, size, PCIBIOS_MIN_MEM,
+ &image->bus_resource, size, 0x1, PCIBIOS_MIN_MEM,
0, NULL, NULL);
if (retval) {
dev_err(tsi148_bridge->parent, "Failed to allocate mem "
--
1.8.3.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 08 Jul 2015, at 16:57, Martyn Welch wrote: > > > > On 07/07/15 11:52, 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. > > I'm a little concerned by the latency this might cause, especially if there > is one device which is negatively affected by latency. Handling RORA > interrupts would be "interesting" if all the windows were dynamically > allocated at the time at which an interrupt came in. Latency-critical windows can be statically allocated using current resource based API. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Generic VME UIO driver
> On 08 Jul 2015, at 16:22, Martyn Welch wrote: > > On 06/07/15 18:24, Dmitry Kalinkin wrote: >>> Some functionality was dropped as it was not good practice >>> >(such as receiving VME interrupts in user space, it's not really doable if >>> >the slave card is Release On Register Access rather than Release on >>> >Acknowledge), >> Didn't know about RORA. I wonder how different this is compared to the >> PCI bus case. > > Little I suspect. What it does mean is that there's no generic mechanism for > clearing down an interrupt, so a device specific interrupt routine is > required, which needs to be in kernel space. Yet PCI somehow managed to settle with UIO. Now imagine I am working with a board using vme_user API and I need to implement interrupts. The PCI case teaches me that I need to write a board specific UIO driver. My board is ROAK and allows to configure it's interrupt to any level and any status/id. So I only use a standard vme_irq_request API that generates IACK cycle for me automatically. I also don’t want to limit my end user with a choice of interrupt level and status/id and so I make it configurable. In the end I’ve got a very generic ROAK device driver. What did I do wrong? 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
> Note also that some maintainers have work flow that deliberately smash > the date (i.e., because they are using a system such as guilt), > so if you are depending on the submitted timestamp, it's going to > break on you. Thanks for your hint. I am just trying to offer the possibility for the reuse of a more precise commit timestamp together with an appropriate author mail address for my update suggestions. Do you reject any more such message field overrides? 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
On Wed, Jul 08, 2015 at 09:05:53PM +1000, Julian Calaby wrote: > If multiple people are submitting identical changes, then the one that > is applied is the one the maintainer sees first, which will most > likely be determined by which one hit their inbox / list first. Nobody > is going to look at timestamps in emails to determine which one will > be applied. And some maintainers may choose *not* to act on a patch first, even if they see it first. They might be focused on bug fix patches, and not act on cleanup or feature patches until -rc3 or rc4. Or maybe they will use separate branches for "urgent_for_linus" patches, so two different patchs may end up in completely different git flows. > If you're worried about which one of several versions of a patch will > be applied, change the subject to [PATCH v2] . instead of [PATCH] > for the second version. *Please* do this. In fact, this is the one thing I wish git send-email would do automatically, along with having a place to edit and track the 0/N summary patch. > >> To be honest, I've only ever used that timestamp for reporting > >> purposes at work, and I'd be surprised if anyone was doing anything > >> other than that with them. > > > > Thanks for your detailed feedback. Note also that some maintainers have work flow that deliberately smash the date (i.e., because they are using a system such as guilt), so if you are depending on the submitted timestamp, it's going to break on you. - Ted ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
interested in growing sales?
Hey, We can help you to grow business fast. We provide target email marketing services and can generate you more business and leads. We are looking for long term cooperation which can increase your business sales 2-4 times than now. Please reply back so i can go over options for you. Thanks, Roy Contact: soul2...@tom.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: lustre: make ptlrpc_init static
fix sparse warning in lustre/ptlrpc/ptlrpc_module.c:54:12:
warning: symbol 'ptlrpc_init' was not declared. Should it be static?
The __init macro is moved before the function name to match standard usage.
Signed-off-by: Matt Mooney
---
drivers/staging/lustre/lustre/ptlrpc/ptlrpc_module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_module.c
b/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_module.c
index 5268887..ae99180 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_module.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/ptlrpc_module.c
@@ -51,7 +51,7 @@ extern spinlock_t ptlrpc_rs_debug_lock;
extern struct mutex pinger_mutex;
extern struct mutex ptlrpcd_mutex;
-__init int ptlrpc_init(void)
+static int __init ptlrpc_init(void)
{
int rc, cleanup_phase = 0;
--
2.4.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 28/37] usb: gadget: pxa27x_udc: add ep capabilities support
Robert Baldyga writes: > Convert endpoint configuration to new capabilities model. The commit message is very short to judge the patch's correctness. I'll side up with Felipe's opinion. If it's fine by him, so it is by me. Cheers. -- Robert ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Alternate rtl8192cu driver.
On Wed, Jul 08, 2015 at 12:10:15PM +0200, P. Varet wrote: > And Greg KH wrote: > > >That's as "supported" as anything is with Linux :) > > Kind of dispiriting... but so it goes. Why? That's better than you will get from any other operating system, where you don't have access to the developers who wrote the code, nor even the company. You have a chance here, much more so than anywhere else. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] defines modified to match the 80-char rule
On Mon, 2015-07-06 at 14:16 +0200, Krzysztof Hałasa wrote: > Joe Perches writes: > > >> So, could we have the localized readability when it makes sense, > >> and the default rules when nothing else applies? > > > > Then the question becomes how local. > > The answer seems easy to me: as much as it's needed to get the best > readability. > If that means 4 or 2 custom formatted lines, great. Why not? Changing styles every few lines demands more from a reader's pattern matching capabilities. > It should be the maintainer's call anyway. It's (s)he who has to work > with the code in question most. True. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: rtl8188eu: core: Fixed 80 character length warning
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 net-next,v2] hv_netvsc: Add support to set MTU reservation from guest side
From: Haiyang Zhang Date: Mon, 6 Jul 2015 14:11:37 -0700 > When packet encapsulation is in use, the MTU needs to be reduced for > headroom reservation. > The existing code takes the updated MTU value only from the host side. > But vSwitch extensions, such as Open vSwitch, require the flexibility > to change the MTU to different values from within a guest during the > lifecycle of a vNIC, when the encapsulation protocol is changed. The > patch supports this kind of MTU changes. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan Applied, thanks. ___ 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 11:46 PM, SF Markus Elfring wrote: >> Is there truly no way to simplify that process? > > I see some software development possibilities which could improve > the communication with high volume mailing lists. You shouldn't need any software development, most people's processes are: 1. Make changes 2. git add 3. git commit 4. Repeat 1-3 for all changes they want to make 5. git-format-patch 6. git-send-email through some SMTP server to the list and appropriate other people >From what I've read, you appear to have some semi-automatic tool for steps 1 through 4. I'd strongly recommend changing your patch submission process to use git-format-patch and git-send-email. If Sourceforge's email system doesn't let you send emails with SMTP directly, then you might want to try sending emails through your ISP's mail server. Maintainers use a very similar process, however they collect and review patches in some personal repository in addition to making changes and committing them. Tools like patchwork are simply fancy methods of accumulating patches into git trees. Most people are using git-format-patch and git-send-email, possibly with some scripting around them, to format and send patches. >> You should be sending the patches directly with SMTP using git-send-email, > > This tool is also fine for the publishing of a lot of patches. git-send-email or some other tool? >> if you're not, then you're making things overly complicated for yourself. > > But I prefer a graphical user interface for my mail handling so far. I send my patches using git-send-email through gmail's servers then deal with literally everything else through gmail's web interface or Android app. Using git-send-email doesn't mean you can't use a graphical mail interface. I used to send patches through a carefully configured instance of Thunderbird, however this required too many steps and it loved to mangle patches in ways that annoyed people. >> Having a feature doesn't mean that it should be used. > > Does any of the "questionable functionality" get occasionally overlooked > a bit too often? It's not "questionable functionality", it's functionality we don't see a need for. If I wanted to, I could insert a patch at any point in the history of Linux in my own repository, however any attempt to push that upstream would cause enormous amounts of pain and annoyance, to everyone who attempted to deal with it, so I don't. 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
[PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
From: Ronit Halder Fixed a coding style issue. Signed-off-by: Ronit Halder --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 6f48112..e44f5e6 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client *client, struct ion_buffer *buffer; struct dma_buf *dmabuf; bool valid_handle; + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); mutex_lock(&client->lock); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote: > From: Ronit Halder You do not need a From: here. Please fix your gitconfig file and git send-email will give your name correctly in the email header. regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
On Thu, 2015-07-09 at 11:05 +0530, Sudip Mukherjee wrote: > On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote: > > From: Ronit Halder > > You do not need a From: here. Please fix your gitconfig file and > git send-email will give your name correctly in the email header. > > regards > sudip thanks for pointing it sudip. Sorry for the stupid mistake, version 2 of the patch is coming. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: android: ion: fixed a blank line after declarations coding style issue
On Thu, Jul 09, 2015 at 08:20:57AM +0530, rcodin wrote: > From: Ronit Halder > > Fixed a coding style issue. > > Signed-off-by: Ronit Halder > --- > drivers/staging/android/ion/ion.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/android/ion/ion.c > b/drivers/staging/android/ion/ion.c > index 6f48112..e44f5e6 100644 > --- a/drivers/staging/android/ion/ion.c > +++ b/drivers/staging/android/ion/ion.c > @@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client > *client, > struct ion_buffer *buffer; > struct dma_buf *dmabuf; > bool valid_handle; > + > DEFINE_DMA_BUF_EXPORT_INFO(exp_info); This is a false positive and has been rejected so many times it's really getting old... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: xgifb: prefer using the BIT macro
From: Hari Prasath Gujulan Elango This patch uses the BIT macro for bit shift operation. Signed-off-by: Hari Prasath Gujulan Elango --- drivers/staging/xgifb/XGI_main_26.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/xgifb/XGI_main_26.c b/drivers/staging/xgifb/XGI_main_26.c index 943d463..5bfe151 100644 --- a/drivers/staging/xgifb/XGI_main_26.c +++ b/drivers/staging/xgifb/XGI_main_26.c @@ -18,8 +18,8 @@ #define Index_CR_GPIO_Reg1 0x48 #define Index_CR_GPIO_Reg3 0x4a -#define GPIOG_EN(1<<6) -#define GPIOG_READ (1<<1) +#define GPIOG_ENBIT(6) +#define GPIOG_READ BIT(1) static char *forcecrt2type; static char *mode; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] Staging: android: ion: fixed a blank line after declarations coding style issue
Fixed a coding style issue. Signed-off-by: Ronit Halder --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 6f48112..e44f5e6 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -1106,6 +1106,7 @@ struct dma_buf *ion_share_dma_buf(struct ion_client *client, struct ion_buffer *buffer; struct dma_buf *dmabuf; bool valid_handle; + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); mutex_lock(&client->lock); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: android: ion: fixed a blank line after declarations coding style issue
On Thu, Jul 09, 2015 at 11:39:11AM +0530, Ronit Halder wrote:
> Fixed a coding style issue.
>
> Signed-off-by: Ronit Halder
Greg has commented in your v1 that it is a false positive. See that:
#define DEFINE_DMA_BUF_EXPORT_INFO(a) \
struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
so blank line will not be required here.
regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
