Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME
On Fri, Dec 19, 2014 at 3:03 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
--- linux-pm.orig/arch/mips/configs/lemote2f_defconfig
+++ linux-pm/arch/mips/configs/lemote2f_defconfig
@@ -37,7 +37,7 @@ CONFIG_MIPS32_N32=y
CONFIG_PM=y
^^^
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=/dev/hda3
-CONFIG_PM_RUNTIME=y
+CONFIG_PM=y
^^^
Now we have two of them
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=m
Other defconfig files may be affected, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] usb: chipidea: add one errata for revision 2.40a
On 12/19/2014 12:19 PM, Peter Chen wrote: On 12/18/2014 06:47 PM, Matthieu CASTET wrote: Le Wed, 17 Dec 2014 20:40:29 +0800, Peter Chen peter.c...@freescale.com a écrit : On Wed, Dec 17, 2014 at 05:31:40PM +0530, Sanchayan Maity wrote: On 12/17/2014 02:05 PM, Peter Chen wrote: Hi all, At the first two patches, I add identification registers APIs, we can get controller's revision by using this APIs. Since I don't have enough spec, if there are any errors, tell me. At the third patch, I implement an errata for revision 2.40a, hope it can fix the problem Sanchayan Maity reported. http://www.spinics.net/lists/linux-usb/msg118544.html @Sanchayan, would you please have a test? Peter Chen (3): usb: chipidea: add identification registers access APIs usb: chipidea: add chipidea revision information usb: chipidea: udc: add errata for revision 2.40a drivers/usb/chipidea/bits.h | 10 + drivers/usb/chipidea/ci.h | 53 + drivers/usb/chipidea/core.c | 23 ++-- drivers/usb/chipidea/udc.c | 18 ++- 4 files changed, 101 insertions(+), 3 deletions(-) Thanks for the patches. I tested the patches with iperf and tried a few times to be sure. The condition is still the same. Oh, bad luck. Be sure the code I added for 2.40a is ran at your board. For information we workarounded this errata with the attached patched. It is based on a old version of the driver. We never had time to clean and submit the patch, but it solve the errata in our case. Matthieu I came in the morning and saw this patch. Immediately modified it and applied. Glad to say that it works. I had iperf running for an hour with no problem and 48.7GBytes of transfer at 116MBits/sec :). Going to run a longer 3 hour iperf test now, but, I guess it should be fine. I will spin a combination patch of what Peter and Matthieu gave me and try sending it by today evening for me, before going on vacation. Please try to see mEp-qh.ptr-cap |= QH_ZLT; in Matthieu's patch is needed or not, since the QH cap is initialized when the ep is enabled, and it should not be changed. Yes, it works without it as well. Peter Thanks a lot Matthieu, Peter and Felipe for the inputs and help. -Cheers, Sanchayan. - Sanchayan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/2] r8152: check the status before submitting rx
Don't submit the rx if the device is unplugged, linking down,
or stopped.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 59b70c5..b39b2e4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1789,6 +1789,11 @@ int r8152_submit_rx(struct r8152 *tp, struct rx_agg
*agg, gfp_t mem_flags)
{
int ret;
+ /* The rx would be stopped, so skip submitting */
+ if (test_bit(RTL8152_UNPLUG, tp-flags) ||
+ !test_bit(WORK_ENABLE, tp-flags) || !(tp-speed LINK_STATUS))
+ return 0;
+
usb_fill_bulk_urb(agg-urb, tp-udev, usb_rcvbulkpipe(tp-udev, 1),
agg-head, agg_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/2] r8152: adjust set_carrier
Update the tp-speed at the beginning of the function. Then,
the other fucntion could use it for checking linking status.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2d1c77e..59b70c5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2848,26 +2848,25 @@ static void rtl8153_down(struct r8152 *tp)
static void set_carrier(struct r8152 *tp)
{
struct net_device *netdev = tp-netdev;
- u8 speed;
+ u8 old_speed = tp-speed;
clear_bit(RTL8152_LINK_CHG, tp-flags);
- speed = rtl8152_get_speed(tp);
+ tp-speed = rtl8152_get_speed(tp);
- if (speed LINK_STATUS) {
- if (!(tp-speed LINK_STATUS)) {
+ if (tp-speed LINK_STATUS) {
+ if (!(old_speed LINK_STATUS)) {
tp-rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, tp-flags);
netif_carrier_on(netdev);
}
} else {
- if (tp-speed LINK_STATUS) {
+ if (old_speed LINK_STATUS) {
netif_carrier_off(netdev);
tasklet_disable(tp-tl);
tp-rtl_ops.disable(tp);
tasklet_enable(tp-tl);
}
}
- tp-speed = speed;
}
static void rtl_work_func_t(struct work_struct *work)
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/2] r8152: adjust r8152_submit_rx
Avoid r8152_submit_rx() from submitting rx during unexpected moment. This could reduce the time of stopping rx. For patch #1, the tp-speed should be updated early. Then, the patch #2 could use it to check the current linking status. Hayes Wang (2): r8152: adjust set_carrier r8152: check the status before submitting rx drivers/net/usb/r8152.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usb: chipidea: Add chipidea revision information
Define ci_get_revision API to know the controller revision
information according to chipidea 1.1a, 2.0a, 2.4 and 2.5a
spec. Besides, add one entry in struct ci_hdrc to indicate
revision information. This can be used for adding different
code for revisions, implementing erratas.
Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
---
drivers/usb/chipidea/bits.h | 10 ++
drivers/usb/chipidea/core.c | 23 +--
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index ca57e3d..e935ccc 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -15,6 +15,16 @@
#include linux/usb/ehci_def.h
+/*
+ * ID
+ * For 1.x revision, bit24 - bit31 are reserved
+ * For 2.x revision, bit25 - bit28 are 0x2
+ */
+#define TAG(0x1F 16)
+#define REVISION (0xF 21)
+#define VERSION(0xF 25)
+#define CIVERSION (0x7 29)
+
/* HCCPARAMS */
#define HCCPARAMS_LEN BIT(17)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 9bdc6bd..33a8c4a 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -136,6 +136,22 @@ static int hw_alloc_regmap(struct ci_hdrc *ci, bool is_lpm)
return 0;
}
+static enum CI_REVISION ci_get_revision(struct ci_hdrc *ci)
+{
+ int ver = hw_read_id_reg(ci, ID_ID, VERSION) __ffs(VERSION);
+ enum CI_REVISION rev = CI_REVISION_UNKNOWN;
+
+ if (ver == 0x2) {
+ int rev_reg = hw_read_id_reg
+ (ci, ID_ID, REVISION) __ffs(REVISION);
+ rev = rev_reg + CI_REVISION_20;
+ } else if (ver == 0x0) {
+ rev = CI_REVISION_1X;
+ }
+
+ return rev;
+}
+
/**
* hw_read_intr_enable: returns interrupt enable register
*
@@ -245,8 +261,11 @@ static int hw_device_init(struct ci_hdrc *ci, void __iomem
*base)
/* Clear all interrupts status bits*/
hw_write(ci, OP_USBSTS, 0x, 0x);
- dev_dbg(ci-dev, ChipIdea HDRC found, lpm: %d; cap: %p op: %p\n,
- ci-hw_bank.lpm, ci-hw_bank.cap, ci-hw_bank.op);
+ ci-rev = ci_get_revision(ci);
+
+ dev_dbg(ci-dev,
+ ChipIdea HDRC found, revision: %d, lpm: %d; cap: %p op: %p\n,
+ ci-rev, ci-hw_bank.lpm, ci-hw_bank.cap, ci-hw_bank.op);
/* setup lock mode ? */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: chipidea: Add errata for revision 2.40a
At chipidea revision 2.40a, there is a below errata:
9000531823 B2-Medium Adding a dTD to a Primed Endpoint May Not Get Recognized
Title: Adding a dTD to a Primed Endpoint May Not Get Recognized
Impacted Configuration: All device mode configurations.
Description:
There is an issue with the add dTD tripwire semaphore (ATDTW bit in USBCMD
register)
that can cause the controller to ignore a dTD that is added to a primed
endpoint.
When this happens, the software can read the tripwire bit and the status bit at
'1'
even though the endpoint is unprimed.
After executing a dTD, the device controller endpoint state machine executes a
final
read of the dTD terminate bit to check if the application added a dTD to the
linked
list at the last moment. This read is done in the finpkt_read_latest_next_td
(44) state.
After the read is performed, if the terminate bit is still set, the state
machine moves
to unprime the endpoint. The decision to unprime the endpoint is done in the
checkqh_decision (59) state, based on the value of the terminate bit.
Before reaching the checkqh_decision state, the state machine traverses the
writeqhtd_status (57), writeqh_status (56), and release_prime_mask (42) states.
As shown in the waveform, the ep_addtd_tripwire_clr signal is not set to clear
the tripwire bit in these states.
Workaround:
The software must implement a periodic poll cycle, and check for each dTD
pending on execution (Active = 1), if the enpoint is primed. It can do this by
reading
the corresponding bits in the ENDPTPRIME and ENDPTSTAT registers. If these bits
are
read at 0, the software needs to re-prime the endpoint by writing 1 to the
corresponding
bit in the ENDPTPRIME register. This can be done for every microframe, every
frame or
with a larger interval, depending on the urgency of transfer execution for the
application.
Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
---
drivers/usb/chipidea/udc.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 0444d3f..551ab37 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -522,6 +522,20 @@ static void free_pending_td(struct ci_hw_ep *hwep)
kfree(pending);
}
+static int reprime_dtd(struct ci_hdrc *ci, struct ci_hw_ep *hwep,
+ struct td_node *node)
+{
+ hwep-qh.ptr-td.next = node-dma;
+ hwep-qh.ptr-td.token =
+ cpu_to_le32(~(TD_STATUS_HALTED | TD_STATUS_ACTIVE));
+
+ /* Synchronize before ep prime */
+ wmb();
+
+ return hw_ep_prime(ci, hwep-num, hwep-dir,
+ hwep-type == USB_ENDPOINT_XFER_CONTROL);
+}
+
/**
* _hardware_dequeue: handles a request at hardware level
* @gadget: gadget
@@ -535,6 +549,7 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct
ci_hw_req *hwreq)
struct td_node *node, *tmpnode;
unsigned remaining_length;
unsigned actual = hwreq-req.length;
+ struct ci_hdrc *ci = hwep-ci;
if (hwreq-req.status != -EALREADY)
return -EINVAL;
@@ -544,6 +559,11 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct
ci_hw_req *hwreq)
list_for_each_entry_safe(node, tmpnode, hwreq-tds, td) {
tmptoken = le32_to_cpu(node-ptr-token);
if ((TD_STATUS_ACTIVE tmptoken) != 0) {
+ int n = hw_ep_bit(hwep-num, hwep-dir);
+
+ if (ci-rev == CI_REVISION_24)
+ if (!hw_read(ci, OP_ENDPTSTAT, BIT(n)))
+ reprime_dtd(ci, hwep, node);
hwreq-req.status = -EALREADY;
return -EBUSY;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] usb: chipidea: Add identification registers access APIs
Using hw_write_id_reg and hw_read_id_reg to write and read
identification registers contents. This can be used to get
controller information, change some system configurations
and so on.
Signed-off-by: Sanchayan Maity maitysancha...@gmail.com
---
drivers/usb/chipidea/ci.h | 53 +
1 file changed, 53 insertions(+)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index ea40626..94db636 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -29,6 +29,15 @@
/**
* REGISTERS
*/
+/* Identification Registers */
+#define ID_ID 0x0
+#define ID_HWGENERAL 0x4
+#define ID_HWHOST 0x8
+#define ID_HWDEVICE0xc
+#define ID_HWTXBUF 0x10
+#define ID_HWRXBUF 0x14
+#define ID_SBUSCFG 0x90
+
/* register indices */
enum ci_hw_regs {
CAP_CAPLENGTH,
@@ -97,6 +106,18 @@ enum ci_role {
CI_ROLE_END,
};
+enum CI_REVISION {
+ CI_REVISION_1X = 10,/* Revision 1.x */
+ CI_REVISION_20 = 20, /* Revision 2.0 */
+ CI_REVISION_21, /* Revision 2.1 */
+ CI_REVISION_22, /* Revision 2.2 */
+ CI_REVISION_23, /* Revision 2.3 */
+ CI_REVISION_24, /* Revision 2.4 */
+ CI_REVISION_25, /* Revision 2.5 */
+ CI_REVISION_25_PLUS, /* Revision above than 2.5 */
+ CI_REVISION_UNKNOWN = 99, /* Unknown Revision */
+};
+
/**
* struct ci_role_driver - host/gadget role driver
* @start: start this role
@@ -168,6 +189,7 @@ struct hw_bank {
* @b_sess_valid_event: indicates there is a vbus event, and handled
* at ci_otg_work
* @imx28_write_fix: Freescale imx28 needs swp instruction for writing
+ * @rev: The revision number for controller
*/
struct ci_hdrc {
struct device *dev;
@@ -207,6 +229,7 @@ struct ci_hdrc {
boolid_event;
boolb_sess_valid_event;
boolimx28_write_fix;
+ enum CI_REVISIONrev;
};
static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
@@ -244,6 +267,36 @@ static inline void ci_role_stop(struct ci_hdrc *ci)
}
/**
+ * hw_read_id_reg: reads from a identification register
+ * @ci: the controller
+ * @offset: offset from the beginning of identification registers region
+ * @mask: bitfield mask
+ *
+ * This function returns register contents
+ */
+static inline u32 hw_read_id_reg(struct ci_hdrc *ci, u32 offset, u32 mask)
+{
+ return ioread32(ci-hw_bank.abs + offset) mask;
+}
+
+/**
+ * hw_write_id_reg: writes to a identification register
+ * @ci: the controller
+ * @offset: offset from the beginning of identification registers region
+ * @mask: bitfield mask
+ * @data: new value
+ */
+static inline void hw_write_id_reg(struct ci_hdrc *ci, u32 offset,
+ u32 mask, u32 data)
+{
+ if (~mask)
+ data = (ioread32(ci-hw_bank.abs + offset) ~mask)
+ | (data mask);
+
+ iowrite32(data, ci-hw_bank.abs + offset);
+}
+
+/**
* hw_read: reads from a hw register
* @ci: the controller
* @reg: register index
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] usb: chipidea: add one errata for revision 2.40a
The first two patches add identification register API's. These can be used to get controller's revision. The third patch implements an errata for revision 2.40a. Not sure which other SOCs implement this version of the Chipidea core but this fixes the usb client issue observed on Vybrids. The patch was tested on a Toradex Colibri VF61 module with the 3.18 kernel. iperf tests ran for three hours plus, with these patches applied have found the USB client connection to be now reliable. This patchset is based off on Shawn Guo's for-next branch https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/tree/?h=for-next The credit for the patches and fix goes to Matthieu Castet and Peter Chen. First two patches are by Peter Chen and the third patch which fixed the bug we observed was reported by Matthieu Castet. The discussion of the problem and the relevant testing details can be found at this link: http://www.spinics.net/lists/linux-usb/msg118544.html The first version of this patchset originally send by Peter Chen can be found at this link: http://www.spinics.net/lists/linux-usb/msg118753.html Comments for review are welcome :). Note: I am going on a vacation so will not be able to reply or do any further tests till Monday. Will attend and take care of any comments/requests for further changes/testing from Tuesday. Apologize for the delay in advance. Sanchayan Maity (3): usb: chipidea: Add identification registers access APIs usb: chipidea: Add chipidea revision information usb: chipidea: Add errata for revision 2.40a drivers/usb/chipidea/bits.h | 10 drivers/usb/chipidea/ci.h | 53 +++ drivers/usb/chipidea/core.c | 23 +-- drivers/usb/chipidea/udc.c | 20 4 files changed, 104 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
Hi Everybody, After several test with IGEPv2 board (OMAP3) and linux kernel 3.17 and 3.18, the OTG works but, (from my point of view) with an weird behaviour. The OTG like a Host only is activated after load a gadget driver, I mean that, If I plug a USB memory dongle in the OTG port before load a Gadget driver like g_ether the dongle is not recognized. After load g_ether driver, the usb dongle is recognized without problems. I miss something in the configuration? It this the normal behaviour? Best Regards Eduard 2014-12-17 11:18 GMT+01:00 Agustí Fontquerni a...@iseebcn.com: Hi everybody, We are working on IGEPv2 board about OTG issue. 2014-11-19 18:53 GMT+01:00 Tony Lindgren t...@atomide.com: * Enric Balletbo Serra eballe...@gmail.com [141119 03:14]: 2014-11-18 16:42 GMT+01:00 Tony Lindgren t...@atomide.com: Checked again, and no luck. It's very weird because from the OTG point of view, OTG is exactly the same between Beagleboard-XM and IGEPv2. Can you confirm that you're using kernel 3.18-rc5 without other patches applied ? At this moment, I don't have a Beagleboard-XM to test, I'll try to get one because at this moment I'm a bit stuck with this problem. Yes it was with v3.18-rc5 and the defconfig patch I posted except I had to disable all the other MUSB platforms. Also tested it with built in modules. Maybe you need to check the .dts pinctrl entries for hsusb0_* lines? Command root@arm:/sys/kernel/debug/pinctrl# cat pinctrl-maps | grep -5 usb reports: device 480025a0.pinmux state default type MUX_GROUP (2) controlling device 480025a0.pinmux group pinmux_hsusbb1_pins function pinmux_hsusbb1_pins So, I think that is needed configure usb0 in lastest omap3-igep0020.dts Moreover, in old 2.6.37 kernel, we saw omap_mux pin configuration in /sys/kernel/debug/omap_mux/hsusb0_xxx. Now in newer 3.1x kernels, Where could it read omap_mux pin configuration ? Regards, Tony Best Regards, Agusti Fontquerni -- Eduard Gavin Carulla e: ega...@iseebcn.com t: +34 935 763 931 t: +34 935 763 932 www.isee.biz C/ Marcos Redondo, 5 Valldoreix CP. 08197 (Barcelona) - Spain Important notice: This message and any files transmitted with it are confidential and intended solely for the individual to whom it is addressed. Unauthorized publication, use, dissemination, forwarding, printing or copying of this email and its associated attachments is strictly prohibited. If you have received this email in error, please notify the sender and delete the original immediately. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/29] usb: dwc2: gadget: don't embedded ep0 buffers
Hello. On 12/18/2014 9:53 PM, Mian Yousaf Kaukab wrote: s/embedded/embed/ in the subject. When using DMA, data of the previous setup packet can be read back from cache because ep0 and ctrl buffers are embedded in struct s3c_hsotg. Allocate buffers instead of embeddeding them. s/embeddeding/embedding/. Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com [...] WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/29] usb: dwc2: gadget: write correct value in ahbcfg register
On 12/18/2014 9:53 PM, Mian Yousaf Kaukab wrote: From: Gregory Herrero gregory.herr...@intel.com Felipe requires some change log in every patch. Signed-off-by: Gregory Herrero gregory.herr...@intel.com [...] WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/29] usb: dwc2: gadget: add device tree property to enable dma
On 12/18/2014 9:53 PM, Mian Yousaf Kaukab wrote:
From: Gregory Herrero gregory.herr...@intel.com
* Add an of specific function to parse device node properties.
* Enable dma usage only if device tree property 'g_use_dma' is present.
Hyphen is preferred to underscore in the device tree prop names.
Signed-off-by: Gregory Herrero gregory.herr...@intel.com
[...]
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 58699c3..eb58305 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
[...]
@@ -3402,6 +3402,24 @@ static void s3c_hsotg_delete_debug(struct dwc2_hsotg
*hsotg)
debugfs_remove(hsotg-debug_root);
}
+#ifdef CONFIG_OF
+static int s3c_hsotg_of_probe(struct dwc2_hsotg *hsotg)
+{
+ struct device_node *np = hsotg-dev-of_node;
+
+ /* Enable dma if requested in device tree */
+ if (of_find_property(np, g_use_dma, NULL))
Use of_propery_read_bool() please.
+ hsotg-g_using_dma = true;
+
+ return 0;
The function always returns 0, why not make it *void* for now?
[...]
@@ -3421,6 +3439,10 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
/* Set default UTMI width */
hsotg-phyif = GUSBCFG_PHYIF16;
+ ret = s3c_hsotg_of_probe(hsotg);
+ if (ret)
+ return ret;
Dead code as s3c_hsotg_of_probe() always returns 0.
[...]
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/29] usb: dwc2: gadget: don't embedded ep0 buffers
Hi, Thank you for reviewing these patches. -Original Message- From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] Sent: Friday, December 19, 2014 1:34 PM To: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; pa...@synopsys.com Subject: Re: [PATCH 04/29] usb: dwc2: gadget: don't embedded ep0 buffers Hello. On 12/18/2014 9:53 PM, Mian Yousaf Kaukab wrote: s/embedded/embed/ in the subject. When using DMA, data of the previous setup packet can be read back from cache because ep0 and ctrl buffers are embedded in struct s3c_hsotg. Allocate buffers instead of embeddeding them. s/embeddeding/embedding/. Ok. Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com [...] WBR, Sergei BR, Yousaf -- Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, Sweden Registration Number: 556189-6027 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/29] usb: dwc2: gadget: write correct value in ahbcfg register
Hi, -Original Message- From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] Sent: Friday, December 19, 2014 1:36 PM To: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; pa...@synopsys.com Subject: Re: [PATCH 05/29] usb: dwc2: gadget: write correct value in ahbcfg register On 12/18/2014 9:53 PM, Mian Yousaf Kaukab wrote: From: Gregory Herrero gregory.herr...@intel.com Felipe requires some change log in every patch. We thought the patch is simple enough to be described by the subject. If this is required, I will add some description to it. Signed-off-by: Gregory Herrero gregory.herr...@intel.com [...] WBR, Sergei BR, Yousaf -- Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm, Sweden Registration Number: 556189-6027 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] renesas_usbhs: fix platform init error message
Hello. On 12/19/2014 4:33 AM, yoshihiro shimoda wrote: [...] There is a typo (prove instead of probe) in the error message printed when the platform initialization fails. Replace that word with more fitting init. Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com this actually goes through me, I'll take it in a bit. Er, OK. Could you update MAINTAINERS? there is no entry for renesas driver in MAINTAINERS. Shimoda-san, care to send a patch adding yourself or Morimoto-san as maintainers for Renesas driver and pointing to my tree in kernel.org ? I would like to move the renesas_usbhs driver to drivers/usb/gadget/udc somehow. Because the driver is almost used for a gadget driver. The driver has a host driver support now. But, it is not used recently. After that, this MAINTAINERS issue becomes clear, I think. Felipe-san and Sergei-san, what do you think? I'm against such move. Thank you for the reply. But, I would like to know why you are against such move. Because we still need the host mode; RZ/A1H (R7S72100) SoC should need it soon), and bi-modal USBHS hardware is better placed in its own directory. Best regards, Yoshihiro Shimoda WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] usb: gadget: at91_udc: move prepare clk into process context
Hi Felipe, On Thu, Nov 20, 2014 at 01:50:49PM -0600, Felipe Balbi wrote: On Wed, Nov 19, 2014 at 04:37:27PM +0100, Nicolas Ferre wrote: From: Ronald Wahl ronald.w...@raritan.com Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc: prepare clk before calling enable) added clock preparation in interrupt context. This is not allowed as it might sleep. Also setting the clock rate is unsafe to call from there for the same reason. Move clock preparation and setting clock rate into process context (at91udc_probe). Signed-off-by: Ronald Wahl ronald.w...@raritan.com Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com Acked-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Cc: Felipe Balbi ba...@ti.com Cc: sta...@vger.kernel.org # v3.17+ --- Hi Felipe, I forgot to answer you on this patch. So I resend it now with the proper stable tag. You can also queue it during this -rc phase if you feel it is still possible. I think it's late for v3.18, so it'll go on v3.19 and get backported to 3.17 and 3.18. Sorry :-s Although this commit (b2ba27a5c56f usb: gadget: at91_udc: move prepare clk into process context) is tagged for stable v3.17+, it seems like it could be applied to earlier kernels. 3.16, 3.13 and 3.12 seem to be affected by the same issue (and they all include commit 7628083227b6 usb: gadget: at91_udc: prepare clk before calling enable). Is there any reason for not applying it in these trees? Cheers, -- Luís cheers -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] usb: gadget: at91_udc: move prepare clk into process context
On 19.12.2014 14:51, Luis Henriques wrote: Hi Felipe, On Thu, Nov 20, 2014 at 01:50:49PM -0600, Felipe Balbi wrote: On Wed, Nov 19, 2014 at 04:37:27PM +0100, Nicolas Ferre wrote: From: Ronald Wahl ronald.w...@raritan.com Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc: prepare clk before calling enable) added clock preparation in interrupt context. This is not allowed as it might sleep. Also setting the clock rate is unsafe to call from there for the same reason. Move clock preparation and setting clock rate into process context (at91udc_probe). Signed-off-by: Ronald Wahl ronald.w...@raritan.com Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com Acked-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Cc: Felipe Balbi ba...@ti.com Cc: sta...@vger.kernel.org # v3.17+ --- Hi Felipe, I forgot to answer you on this patch. So I resend it now with the proper stable tag. You can also queue it during this -rc phase if you feel it is still possible. I think it's late for v3.18, so it'll go on v3.19 and get backported to 3.17 and 3.18. Sorry :-s Although this commit (b2ba27a5c56f usb: gadget: at91_udc: move prepare clk into process context) is tagged for stable v3.17+, it seems like it could be applied to earlier kernels. 3.16, 3.13 and 3.12 seem to be affected by the same issue (and they all include commit 7628083227b6 usb: gadget: at91_udc: prepare clk before calling enable). Is there any reason for not applying it in these trees? Not to forget 3.14 (LTS) which was the branch where I primarily found the issue... - ron -- Ronald Wahl - ronald.w...@raritan.com - Phone +49 375271349-0 Fax -99 Raritan Deutschland GmbH, Kornmarkt 7, 08056 Zwickau, Germany USt-IdNr. DE813094160, Steuer-Nr. 227/117/01749 Amtsgericht Chemnitz HRB 23605 Geschäftsführung: Stuart Hopper, Ralf Ploenes -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] usb: gadget: at91_udc: move prepare clk into process context
Le 19/12/2014 15:02, Ronald Wahl a écrit : On 19.12.2014 14:51, Luis Henriques wrote: Hi Felipe, On Thu, Nov 20, 2014 at 01:50:49PM -0600, Felipe Balbi wrote: On Wed, Nov 19, 2014 at 04:37:27PM +0100, Nicolas Ferre wrote: From: Ronald Wahl ronald.w...@raritan.com Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc: prepare clk before calling enable) added clock preparation in interrupt context. This is not allowed as it might sleep. Also setting the clock rate is unsafe to call from there for the same reason. Move clock preparation and setting clock rate into process context (at91udc_probe). Signed-off-by: Ronald Wahl ronald.w...@raritan.com Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com Acked-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Cc: Felipe Balbi ba...@ti.com Cc: sta...@vger.kernel.org # v3.17+ --- Hi Felipe, I forgot to answer you on this patch. So I resend it now with the proper stable tag. You can also queue it during this -rc phase if you feel it is still possible. I think it's late for v3.18, so it'll go on v3.19 and get backported to 3.17 and 3.18. Sorry :-s Although this commit (b2ba27a5c56f usb: gadget: at91_udc: move prepare clk into process context) is tagged for stable v3.17+, it seems like it could be applied to earlier kernels. 3.16, 3.13 and 3.12 seem to be affected by the same issue (and they all include commit 7628083227b6 usb: gadget: at91_udc: prepare clk before calling enable). Is there any reason for not applying it in these trees? Not to forget 3.14 (LTS) which was the branch where I primarily found the issue... Well it's maybe an issue with the re-naming of the directory to drivers/usb/gadget/udc/ introduced by patch: 90fccb529d24 (usb: gadget: Gadget directory cleanup - group UDC drivers) The patch doesn't apply out of the box but it surely can be applied in those earlier kernels. Thanks, bye. -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] usb: gadget: at91_udc: move prepare clk into process context
On Fri, Dec 19, 2014 at 03:08:15PM +0100, Nicolas Ferre wrote: Le 19/12/2014 15:02, Ronald Wahl a écrit : On 19.12.2014 14:51, Luis Henriques wrote: Hi Felipe, On Thu, Nov 20, 2014 at 01:50:49PM -0600, Felipe Balbi wrote: On Wed, Nov 19, 2014 at 04:37:27PM +0100, Nicolas Ferre wrote: From: Ronald Wahl ronald.w...@raritan.com Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc: prepare clk before calling enable) added clock preparation in interrupt context. This is not allowed as it might sleep. Also setting the clock rate is unsafe to call from there for the same reason. Move clock preparation and setting clock rate into process context (at91udc_probe). Signed-off-by: Ronald Wahl ronald.w...@raritan.com Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com Acked-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Cc: Felipe Balbi ba...@ti.com Cc: sta...@vger.kernel.org # v3.17+ --- Hi Felipe, I forgot to answer you on this patch. So I resend it now with the proper stable tag. You can also queue it during this -rc phase if you feel it is still possible. I think it's late for v3.18, so it'll go on v3.19 and get backported to 3.17 and 3.18. Sorry :-s Although this commit (b2ba27a5c56f usb: gadget: at91_udc: move prepare clk into process context) is tagged for stable v3.17+, it seems like it could be applied to earlier kernels. 3.16, 3.13 and 3.12 seem to be affected by the same issue (and they all include commit 7628083227b6 usb: gadget: at91_udc: prepare clk before calling enable). Is there any reason for not applying it in these trees? Not to forget 3.14 (LTS) which was the branch where I primarily found the issue... Yes, of course! Sorry. Well it's maybe an issue with the re-naming of the directory to drivers/usb/gadget/udc/ introduced by patch: 90fccb529d24 (usb: gadget: Gadget directory cleanup - group UDC drivers) The patch doesn't apply out of the box but it surely can be applied in those earlier kernels. Right, the file was renamed but the backport seems to be trivial. Thanks for confirming. Cheers, -- Luís Thanks, bye. -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/29] usb: dwc2: gadget: write correct value in ahbcfg register
On 12/19/2014 3:45 PM, Kaukab, Yousaf wrote: [...] On 12/18/2014 9:53 PM, Mian Yousaf Kaukab wrote: From: Gregory Herrero gregory.herr...@intel.com Felipe requires some change log in every patch. We thought the patch is simple enough to be described by the subject. If this is required, I will add some description to it. In this case change log indeed wouldn't hurt. Signed-off-by: Gregory Herrero gregory.herr...@intel.com [...] BR, Yousaf WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proper delay function in host driver
On Fri, 19 Dec 2014, vichy wrote: hi all: For HW bug, we have to mdelay(100) in getting root hub port status. That's quite a bug! 100 ms is a very long delay. With a bug that big, it's questionable whether the hardware will work correctly at all. But it suffer system performance. (The place we need to add is like below) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 388cfd8..9a6b841 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -760,6 +760,7 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, retval = -ENODEV; break; } + mdelay(100); status = xhci_get_port_status(hcd, bus_state, port_array, wIndex, temp, flags); if (status == 0x) Then I try to use msleep(100) but I found hub_port_status will first mutex_lock(hub-status_mutex); then calling get_port_status. That mean the deadlock may happen. No it doesn't. Is there any better way to do so? Consider other chips that don't have this hardware bug. Is there any reason to make those systems wait 100 ms when they don't need to? That's what your patch would do. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [DISCUSSION] USB device remote wakeup is not working for S3 case
On Fri, 19 Dec 2014, Du, Changbin wrote: There's a simple solution: Call device_set_wakeup_enable() for the device! You can do this from the command line by: echo auto /sys/bus/usb/devices/.../power/control where the ... is the pathname for your device. Yes, this can enable auto-suspend for usb device like a mouse. And remote wakeup does work for RPM because rpm suspend refers to the needs_remote_wakeup flag. But this doesn't impact system level suspend. The correct thing is: echo enabled /sys/bus/usb/devices/.../power/wakeup Yes, I'm sorry, you're right. It's easy to mix up autosuspend and wakeup. This will call device_set_wakeup_enable() for the device and should work. But unfortunately it seems didn't work even the wakeup file shows enabled which means the device is wakeup enabled(Tried on 3.16 3.18 kernel). This is a different issue, I will check. You have to make sure that wakeup is also enabled for the host controller the device is attached to. For some host controllers, it may also be necessary to enable wakeup for the root hub. Could we also enable wakeup for usb mouse? Or is there any concern to enable it? Per my opinion, most people may expect clicking mouse can awake system. It doesn't matter to me, but you should ask the people on the linux-input mailing list. Also, what about wakeup for a non-USB mouse? Shouldn't that be enabled as well? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB Creative Soundcard non-functioning on 3.13 kernel and above
Hello, I was told to email this to this list... I filed a kernel bug here: https://bugzilla.kernel.org/show_bug.cgi?id=90101 With the following content: I have done extensive testing on this issue, and basically on any kernel version higher than or equal to 3.13, I am unable to use my USB Create Soundblaster card. The issue seems related to the USB subsystem as it works just fine in the USB3 ports. I did a kernel bisect between 3.12.0 and 3.13.0, and the offending commit is d0ce5c6b9208c79fc725c578eebdeb5724faf17d USB: EHCI: use a bandwidth-allocation table https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d0ce5c6b9208c79fc725c578eebdeb5724faf17d What happens is video playback stutters very heavily and there is no sound stream making it out the SPDIF port on the USB soundcard. I also tried with the speaker-test application and get a Broken pipe error. $ speaker-test -D iec958:CARD=Pro,DEV=0 -c 2 -t wav speaker-test 1.0.28 Playback device is iec958:CARD=Pro,DEV=0 Stream parameters are 48000Hz, S16_LE, 2 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Using max buffer size 262144 Periods = 4 Unable to set hw params for playback: Broken pipe Setting of hwparams failed: Broken pipe If I move to the USB3 port it works as expected, so the issue is most definitely on the USB2 side. The USB hardware is: 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) Subsystem: Lenovo Device 3086 Kernel driver in use: ehci-pci The Soundblaster hardware is: Bus 001 Device 004: ID 041e:30df Creative Technology, Ltd Thank you for your time. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] r8152: drop the tx packet with invalid length
On Fri, 2014-12-19 at 06:42 +, Hayes Wang wrote:
Excuse me. I try to implement ndo_gso_check() with kernel 3.18.
However, I still get packets with gso and their skb lengths are more
than the acceptable one. Do I miss something?
+static bool rtl8152_gso_check(struct sk_buff *skb, struct net_device *dev)
+{
+ if ((skb-len + sizeof(struct tx_desc)) agg_buf_sz)
+ return false;
+
+ return true;
+}
@@ -5861,6 +5876,9 @@ static const struct net_device_ops rtl8152_netdev_ops =
{
.ndo_set_mac_address= rtl8152_set_mac_address,
.ndo_change_mtu = rtl8152_change_mtu,
.ndo_validate_addr = eth_validate_addr,
+ .ndo_gso_check = rtl8152_gso_check,
};
You are right, it seems ndo_gso_check() is buggy at this moment.
Presumably this method should alter %features so that we really segment
the packets in software.
features = ~NETIF_F_GSO_MASK;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Creative Soundcard non-functioning on 3.13 kernel and above
On Fri, 19 Dec 2014 robton...@gmail.com wrote: Hello, I was told to email this to this list... I filed a kernel bug here: https://bugzilla.kernel.org/show_bug.cgi?id=90101 With the following content: I have done extensive testing on this issue, and basically on any kernel version higher than or equal to 3.13, I am unable to use my USB Create Soundblaster card. The issue seems related to the USB subsystem as it works just fine in the USB3 ports. I did a kernel bisect between 3.12.0 and 3.13.0, and the offending commit is d0ce5c6b9208c79fc725c578eebdeb5724faf17d USB: EHCI: use a bandwidth-allocation table https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d0ce5c6b9208c79fc725c578eebdeb5724faf17d What happens is video playback stutters very heavily and there is no sound stream making it out the SPDIF port on the USB soundcard. I also tried with the speaker-test application and get a Broken pipe error. $ speaker-test -D iec958:CARD=Pro,DEV=0 -c 2 -t wav speaker-test 1.0.28 Playback device is iec958:CARD=Pro,DEV=0 Stream parameters are 48000Hz, S16_LE, 2 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 262144 Period size range from 48 to 131072 Using max buffer size 262144 Periods = 4 Unable to set hw params for playback: Broken pipe Setting of hwparams failed: Broken pipe If I move to the USB3 port it works as expected, so the issue is most definitely on the USB2 side. The USB hardware is: 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) Subsystem: Lenovo Device 3086 Kernel driver in use: ehci-pci The Soundblaster hardware is: Bus 001 Device 004: ID 041e:30df Creative Technology, Ltd You'll have to collect a bunch of additional information. I'd like to see the entry in /sys/kernel/debug/usb/devices that describes the sound card, and the contents of the files under /sys/kernel/debug/usb/ehci/:00:1a.0/. I'd also like to see the dmesg log for when you try the test program, and a usbmon trace as well. This will require CONFIG_DEBUG_FS, CONFIG_USB_DEBUG, and CONFIG_USB_MON to be enabled in the kernel configuration. Can you do all this under a 3.18 or 3.17 kernel? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] r8152: drop the tx packet with invalid length
On Fri, 2014-12-19 at 09:36 -0800, Eric Dumazet wrote:
On Fri, 2014-12-19 at 06:42 +, Hayes Wang wrote:
Excuse me. I try to implement ndo_gso_check() with kernel 3.18.
However, I still get packets with gso and their skb lengths are more
than the acceptable one. Do I miss something?
+static bool rtl8152_gso_check(struct sk_buff *skb, struct net_device *dev)
+{
+ if ((skb-len + sizeof(struct tx_desc)) agg_buf_sz)
+ return false;
+
+ return true;
+}
@@ -5861,6 +5876,9 @@ static const struct net_device_ops rtl8152_netdev_ops
= {
.ndo_set_mac_address= rtl8152_set_mac_address,
.ndo_change_mtu = rtl8152_change_mtu,
.ndo_validate_addr = eth_validate_addr,
+ .ndo_gso_check = rtl8152_gso_check,
};
You are right, it seems ndo_gso_check() is buggy at this moment.
Presumably this method should alter %features so that we really segment
the packets in software.
features = ~NETIF_F_GSO_MASK;
Could you try following patch ?
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 7df221788cd4..0346bcfe72a5 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -314,7 +314,7 @@ static rx_handler_result_t macvtap_handle_frame(struct
sk_buff **pskb)
*/
if (q-flags IFF_VNET_HDR)
features |= vlan-tap_features;
- if (netif_needs_gso(dev, skb, features)) {
+ if (netif_needs_gso(dev, skb, features)) {
struct sk_buff *segs = __skb_gso_segment(skb, features, false);
if (IS_ERR(segs))
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 22bcb4e12e2a..9cacabaea175 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -578,6 +578,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
unsigned long flags;
struct netfront_queue *queue = NULL;
unsigned int num_queues = dev-real_num_tx_queues;
+ netdev_features_t features;
u16 queue_index;
/* Drop the packet if no queues are set up */
@@ -611,9 +612,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct
net_device *dev)
spin_lock_irqsave(queue-tx_lock, flags);
+ features = netif_skb_features(skb);
if (unlikely(!netif_carrier_ok(dev) ||
(slots 1 !xennet_can_sg(dev)) ||
-netif_needs_gso(dev, skb, netif_skb_features(skb {
+netif_needs_gso(dev, skb, features))) {
spin_unlock_irqrestore(queue-tx_lock, flags);
goto drop;
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c31f74d76ebd..fb1f8c900df9 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3608,13 +3608,19 @@ static inline bool skb_gso_ok(struct sk_buff *skb,
netdev_features_t features)
}
static inline bool netif_needs_gso(struct net_device *dev, struct sk_buff *skb,
- netdev_features_t features)
+ netdev_features_t *features)
{
- return skb_is_gso(skb) (!skb_gso_ok(skb, features) ||
- (dev-netdev_ops-ndo_gso_check
-!dev-netdev_ops-ndo_gso_check(skb, dev)) ||
- unlikely((skb-ip_summed != CHECKSUM_PARTIAL)
-(skb-ip_summed != CHECKSUM_UNNECESSARY)));
+ if (!skb_is_gso(skb))
+ return false;
+ if (!skb_gso_ok(skb, *features))
+ return true;
+ if (dev-netdev_ops-ndo_gso_check
+ !dev-netdev_ops-ndo_gso_check(skb, dev)) {
+ *features = ~NETIF_F_GSO_MASK;
+ return true;
+ }
+ return skb-ip_summed != CHECKSUM_PARTIAL
+ skb-ip_summed != CHECKSUM_UNNECESSARY;
}
static inline void netif_set_gso_max_size(struct net_device *dev,
diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28d0a66..b61c26b45bb7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2668,7 +2668,7 @@ static struct sk_buff *validate_xmit_skb(struct sk_buff
*skb, struct net_device
if (skb-encapsulation)
features = dev-hw_enc_features;
- if (netif_needs_gso(dev, skb, features)) {
+ if (netif_needs_gso(dev, skb, features)) {
struct sk_buff *segs;
segs = skb_gso_segment(skb, features);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
usb: musb: Scheduling of interrupt endpoints
Hi all, Long time ago, TI shipped a kernel named linux-2.6.32.17-psp03.01.01.39 with an additional kernel option for scheduling of interrupt endpoints. AFAIK, this seems to be the only possibility to attach more that 4 in endpoints to MUSB (at least on a DM368). This feature reserves one hardware endpoint unit to time schedule interrupt in endpoints based on its bInterval value triggered by the SOF interrupt. I didn't find any discussion about adding such a feature to the mainline kernel. IMHO, this feature is absolutely necessary. But there may be reasons, not to add it (e.g. CPU load). Please let me know your thoughts and ideas. Best regards -Carsten -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/2] r8152: check the status before submitting rx
From: Hayes Wang hayesw...@realtek.com
Date: Fri, 19 Dec 2014 16:56:00 +0800
Don't submit the rx if the device is unplugged, linking down,
or stopped.
...
@@ -1789,6 +1789,11 @@ int r8152_submit_rx(struct r8152 *tp, struct rx_agg
*agg, gfp_t mem_flags)
{
int ret;
+ /* The rx would be stopped, so skip submitting */
+ if (test_bit(RTL8152_UNPLUG, tp-flags) ||
+ !test_bit(WORK_ENABLE, tp-flags) || !(tp-speed LINK_STATUS))
+ return 0;
+
I think netif_carrier_off() should always be true in all three of those
situations, and would be a much simpler test than what you've coded
here.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME
On Friday, December 19, 2014 09:13:29 AM Geert Uytterhoeven wrote: On Fri, Dec 19, 2014 at 3:03 AM, Rafael J. Wysocki r...@rjwysocki.net wrote: --- linux-pm.orig/arch/mips/configs/lemote2f_defconfig +++ linux-pm/arch/mips/configs/lemote2f_defconfig @@ -37,7 +37,7 @@ CONFIG_MIPS32_N32=y CONFIG_PM=y ^^^ CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION=/dev/hda3 -CONFIG_PM_RUNTIME=y +CONFIG_PM=y ^^^ Now we have two of them CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m Other defconfig files may be affected, too. Good catch, I felt I might have forgotten about something ... Fixed up patch is appended, thanks! --- From: Rafael J. Wysocki rafael.j.wyso...@intel.com Subject: PM: Eliminate CONFIG_PM_RUNTIME Having switched over all of the users of CONFIG_PM_RUNTIME to use CONFIG_PM directly, turn the latter into a user-selectable option and drop the former entirely from the tree. Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Reviewed-by: Ulf Hansson ulf.hans...@linaro.org --- arch/arm/configs/ape6evm_defconfig |2 +- arch/arm/configs/armadillo800eva_defconfig |2 +- arch/arm/configs/bcm_defconfig |2 +- arch/arm/configs/bockw_defconfig |2 +- arch/arm/configs/davinci_all_defconfig |2 +- arch/arm/configs/exynos_defconfig |2 +- arch/arm/configs/ezx_defconfig |1 - arch/arm/configs/hisi_defconfig|2 +- arch/arm/configs/imote2_defconfig |1 - arch/arm/configs/imx_v6_v7_defconfig |2 +- arch/arm/configs/keystone_defconfig|2 +- arch/arm/configs/kzm9g_defconfig |2 +- arch/arm/configs/lager_defconfig |2 +- arch/arm/configs/mackerel_defconfig|1 - arch/arm/configs/marzen_defconfig |2 +- arch/arm/configs/omap1_defconfig |1 - arch/arm/configs/prima2_defconfig |2 +- arch/arm/configs/sama5_defconfig |2 +- arch/arm/configs/shmobile_defconfig|2 +- arch/arm/configs/sunxi_defconfig |2 +- arch/arm/configs/tegra_defconfig |2 +- arch/arm/configs/u8500_defconfig |2 +- arch/arm/configs/vt8500_v6_v7_defconfig|2 +- arch/arm/mach-omap2/Kconfig|6 +++--- arch/mips/configs/db1xxx_defconfig |2 +- arch/mips/configs/lemote2f_defconfig |1 - arch/mips/configs/loongson3_defconfig |2 +- arch/mips/configs/nlm_xlp_defconfig|2 +- arch/mips/configs/nlm_xlr_defconfig|2 +- arch/powerpc/configs/ps3_defconfig |2 +- arch/sh/Kconfig|2 +- arch/sh/configs/apsh4ad0a_defconfig|2 +- arch/sh/configs/sdk7786_defconfig |2 +- drivers/usb/host/isp1760-hcd.c |2 +- drivers/usb/host/oxu210hp-hcd.c|2 +- include/linux/devfreq.h|2 +- kernel/power/Kconfig | 16 ++-- 37 files changed, 39 insertions(+), 48 deletions(-) Index: linux-pm/arch/arm/configs/ape6evm_defconfig === --- linux-pm.orig/arch/arm/configs/ape6evm_defconfig +++ linux-pm/arch/arm/configs/ape6evm_defconfig @@ -33,7 +33,7 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_VFP=y CONFIG_NEON=y CONFIG_BINFMT_MISC=y -CONFIG_PM_RUNTIME=y +CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y Index: linux-pm/arch/arm/configs/armadillo800eva_defconfig === --- linux-pm.orig/arch/arm/configs/armadillo800eva_defconfig +++ linux-pm/arch/arm/configs/armadillo800eva_defconfig @@ -43,7 +43,7 @@ CONFIG_KEXEC=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set -CONFIG_PM_RUNTIME=y +CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y Index: linux-pm/arch/arm/configs/bcm_defconfig === --- linux-pm.orig/arch/arm/configs/bcm_defconfig +++ linux-pm/arch/arm/configs/bcm_defconfig @@ -39,7 +39,7 @@ CONFIG_CPU_IDLE=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set -CONFIG_PM_RUNTIME=y +CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_DIAG=y Index: linux-pm/arch/arm/configs/bockw_defconfig === --- linux-pm.orig/arch/arm/configs/bockw_defconfig +++ linux-pm/arch/arm/configs/bockw_defconfig @@ -29,7 +29,7 @@ CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_VFP=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set -CONFIG_PM_RUNTIME=y +CONFIG_PM=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y Index: linux-pm/arch/arm/configs/davinci_all_defconfig === --- linux-pm.orig/arch/arm/configs/davinci_all_defconfig +++
Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME
Rafael J. Wysocki r...@rjwysocki.net writes: [...] Fixed up patch is appended, thanks! --- From: Rafael J. Wysocki rafael.j.wyso...@intel.com Subject: PM: Eliminate CONFIG_PM_RUNTIME Having switched over all of the users of CONFIG_PM_RUNTIME to use CONFIG_PM directly, turn the latter into a user-selectable option and drop the former entirely from the tree. Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Reviewed-by: Ulf Hansson ulf.hans...@linaro.org Acked-by: Kevin Hilman khil...@linaro.org I assume you're planning to get this in early in the v3.19-rc cycle, correct? That way we can hopefully avoid conflicts with the various defconfig changes we're taking through the arm-soc tree. Also, thanks for taking care of all the tree-wide changes. This is a great change. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] PM: Eliminate CONFIG_PM_RUNTIME
On Friday, December 19, 2014 01:49:34 PM Kevin Hilman wrote: Rafael J. Wysocki r...@rjwysocki.net writes: [...] Fixed up patch is appended, thanks! --- From: Rafael J. Wysocki rafael.j.wyso...@intel.com Subject: PM: Eliminate CONFIG_PM_RUNTIME Having switched over all of the users of CONFIG_PM_RUNTIME to use CONFIG_PM directly, turn the latter into a user-selectable option and drop the former entirely from the tree. Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Reviewed-by: Ulf Hansson ulf.hans...@linaro.org Acked-by: Kevin Hilman khil...@linaro.org I assume you're planning to get this in early in the v3.19-rc cycle, correct? That way we can hopefully avoid conflicts with the various defconfig changes we're taking through the arm-soc tree. I'm going to send a pull request with these changes tomorrow. Also, thanks for taking care of all the tree-wide changes. This is a great change. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Creative Soundcard non-functioning on 3.13 kernel and above
You'll have to collect a bunch of additional information. I'd like to see the entry in /sys/kernel/debug/usb/devices that describes the sound card, and the contents of the files under /sys/kernel/debug/usb/ehci/:00:1a.0/. /sys/kernel/debug/usb/devices: - http://paste.ubuntu.com/9573759/ /sys/kernel/debug/usb/ehci/:00:1a.0/* - http://paste.ubuntu.com/9573789/ I'd also like to see the dmesg log for when you try the test program, http://paste.ubuntu.com/9573956/ and a usbmon trace as well. This will require CONFIG_DEBUG_FS, http://paste.ubuntu.com/9573950/ ran a few different things. Can you do all this under a 3.18 or 3.17 kernel? did it with 3.18.1-gentoo Please excuse the ubuntu pastebins as it is my favorite one. ;) Thanks! -phunyguy -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
