On Mon, 2021-04-05 at 09:04 +0200, Greg Kroah-Hartman wrote:
> On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> > cc Yaqii Wu
> >
> > I'll test it , thanks
>
> Did you test this series and find any problems? If not, I'll go queue
> these up...
Yes, found an issue on the start-spl
On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> cc Yaqii Wu
>
> I'll test it , thanks
Did you test this series and find any problems? If not, I'll go queue
these up...
thanks,
greg k-h
On Tue, 2021-03-30 at 16:06 +0800, Ikjoon Jang wrote:
> Software bandwidth checking logics used by xhci-mtk puts
> a quite heavy constraints to TT periodic endpoint allocations.
>
> This patch provides a relaxed bandwidth calculation by
> - Allowing multiple periodic transac
cc Yaqii Wu
I'll test it , thanks
On Tue, 2021-03-30 at 16:06 +0800, Ikjoon Jang wrote:
> Remove unnecessary variables in check_sch_bw().
> No functional changes, just for better readability.
>
> Signed-off-by: Ikjoon Jang
> ---
>
> drivers/usb/host/xhci-mtk-sch.c | 52 +-
Remove unnecessary variables in check_sch_bw().
No functional changes, just for better readability.
Signed-off-by: Ikjoon Jang
---
drivers/usb/host/xhci-mtk-sch.c | 52 +
1 file changed, 21 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sc
Software bandwidth checking logics used by xhci-mtk puts
a quite heavy constraints to TT periodic endpoint allocations.
This patch provides a relaxed bandwidth calculation by
- Allowing multiple periodic transactions in a same microframe
for a device with multiple interrupt endpoints.
- Using
on Jang (2):
usb: xhci-mtk: remove unnecessary assignments in periodic TT scheduler
usb: xhci-mtk: relax periodic TT bandwidth checking
drivers/usb/host/xhci-mtk-sch.c | 120 +++-
drivers/usb/host/xhci-mtk.h | 2 -
2 files changed, 41 insertions(+), 81
When the USB headset is plug into an external hub, sometimes
can't set config due to not enough bandwidth, so need improve
LS/FS INT/ISOC bandwidth scheduling with TT.
Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked
endpoints")
Cc: stable
Signed-o
It's clearer to use @sch_tt to check whether need do TT schedule,
no function is changed.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/usb/host/xhci-mtk-sch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb
It's clearer to use @sch_tt to check whether need do TT schedule,
no function is changed.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-
When the USB headset is plug into an external hub, sometimes
can't set config due to not enough bandwidth, so need improve
LS/FS INT/ISOC bandwidth scheduling with TT.
Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked
endpoints")
Cc: stable
Signed-o
On Mon, Feb 8, 2021 at 11:27 AM Chunfeng Yun wrote:
>
> When the USB headset is plug into an external hub, sometimes
> can't set config due to not enough bandwidth, so need improve
> LS/FS INT/ISOC bandwidth scheduling with TT.
>
> Fixes: 08e469de87a2 ("usb:
When the USB headset is plug into an external hub, sometimes
can't set config due to not enough bandwidth, so need improve
LS/FS INT/ISOC bandwidth scheduling with TT.
Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with
multi-TT")
Signed-off-by: Yaqii Wu
thermal_notify_framework just updates for a single trip point where as
thermal_zone_device_update does other bookkeeping like updating the
temperature of the thermal zone and setting the next trip point etc.
Replace thermal_notify_framework with thermal_zone_device_update as the
later is more thoro
thermal_notify_framework with thermal_zone_device_update as the
later is more thorough.
Signed-off-by: Thara Gopinath
The title could be just "iwlwifi: mvm: tt: Replace
thermal_notify_framework".
But via which tree is this going? I assume it's not
wireless-drivers-next so:
Thanks for the
thermal_notify_framework just updates for a single trip point where as
thermal_zone_device_update does other bookkeeping like updating the
temperature of the thermal zone and setting the next trip point etc.
Replace thermal_notify_framework with thermal_zone_device_update as the
later is more thoro
amework with thermal_zone_device_update as the
> later is more thorough.
>
> Signed-off-by: Thara Gopinath
The title could be just "iwlwifi: mvm: tt: Replace
thermal_notify_framework".
But via which tree is this going? I assume it's not
wireless-drivers-next so:
Acked-by: Kalle Valo
--
cturer: Apple, Inc.
> > usb 1-1.1: SerialNumber: DWH915501TFJKLTAM
> > xhci-mtk 1120.xhci: Not enough bandwidth!
> > usb 1-1.1: can't set config #2, error -28
> >
> > improve low-speed/full-speed INT/ISOC bandwidth scheduling with USB
> > muli-TT.
> >
-...@vger.kernel.org; open list ; Tianping
Fang (方天平) ; moderated list:ARM/Mediatek SoC
support
主题: Re: [RFC PATCH v3 1/5] usb: xhci-mtk: improve bandwidth scheduling with
multi-TT
On Tue, Dec 22, 2020 at 5:35 PM Chunfeng Yun wrote:
>
> From: Zhanyong Wang
>
> After inserted th
th!
> usb 1-1.1: can't set config #2, error -28
>
> improve low-speed/full-speed INT/ISOC bandwidth scheduling with USB
> muli-TT.
>
> Signed-off-by: Yaqii Wu
> Signed-off-by: Chunfeng Yun
> ---
> v2~v3: no changes
> ---
> drivers/usb/host/xhci-mtk-sch.c | 91
h USB
muli-TT.
Signed-off-by: Yaqii Wu
Signed-off-by: Chunfeng Yun
---
v2~v3: no changes
---
drivers/usb/host/xhci-mtk-sch.c | 91 -
drivers/usb/host/xhci-mtk.h | 8 ++-
2 files changed, 84 insertions(+), 15 deletions(-)
mode change 100644 => 100755 dri
On Thu, Dec 10, 2020 at 06:47:46PM +0800, Ikjoon Jang wrote:
> xhci-mtk creates internal data structures for representing the
> relationship between endpoint and TT.
>
> This patch simply delays its association between endpoint and TT
> when it's really loaded onto inte
xhci-mtk creates internal data structures for representing the
relationship between endpoint and TT.
This patch simply delays its association between endpoint and TT
when it's really loaded onto internal bandwidth table.
This is a preparation step for fixing unreleased periodic
TT bandwidth
From: Linus Lüssing
[ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ]
The unicast packet rerouting code makes several assumptions. For
instance it assumes that there is always exactly one destination in the
TT. This breaks for multicast frames in a unicast packets in several ways
From: Linus Lüssing
[ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ]
The unicast packet rerouting code makes several assumptions. For
instance it assumes that there is always exactly one destination in the
TT. This breaks for multicast frames in a unicast packets in several ways
From: Linus Lüssing
[ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ]
The unicast packet rerouting code makes several assumptions. For
instance it assumes that there is always exactly one destination in the
TT. This breaks for multicast frames in a unicast packets in several ways
From: Linus Lüssing
[ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ]
The unicast packet rerouting code makes several assumptions. For
instance it assumes that there is always exactly one destination in the
TT. This breaks for multicast frames in a unicast packets in several ways
From: Linus Lüssing
[ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ]
The unicast packet rerouting code makes several assumptions. For
instance it assumes that there is always exactly one destination in the
TT. This breaks for multicast frames in a unicast packets in several ways
From: Linus Lüssing
[ Upstream commit 7dda5b3384121181c4e79f6eaeac2b94c0622c8d ]
The unicast packet rerouting code makes several assumptions. For
instance it assumes that there is always exactly one destination in the
TT. This breaks for multicast frames in a unicast packets in several ways
h USB
muli-TT.
Signed-off-by: Yaqii Wu
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/usb/host/xhci-mtk-sch.c | 91 ++---
drivers/usb/host/xhci-mtk.h | 8 +++-
2 files changed, 84 insertions(+), 15 deletions(-)
mode change 100644 => 100755
h USB
muli-TT.
Signed-off-by: Yaqii Wu
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 91 ++---
drivers/usb/host/xhci-mtk.h | 8 +++-
2 files changed, 84 insertions(+), 15 deletions(-)
mode change 100644 => 100755 drivers/usb/host/
h USB
muli-TT.
Signed-off-by: Yaqii Wu
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 91 ++---
drivers/usb/host/xhci-mtk.h | 8 +++-
2 files changed, 84 insertions(+), 15 deletions(-)
mode change 100644 => 100755 drivers/usb/host/
_err("Failed allocating page table\n");
return -ENOMEM;
}
@@ -288,7 +286,6 @@ int ttm_sg_tt_init(struct ttm_dma_tt *tt
else
ret = ttm_dma_tt_alloc_page_directory(ttm_dma);
if (ret) {
- ttm_tt_destroy(ttm);
pr_err("Failed allocating page table\n");
return -ENOMEM;
}
_err("Failed allocating page table\n");
return -ENOMEM;
}
@@ -287,7 +285,6 @@ int ttm_sg_tt_init(struct ttm_dma_tt *tt
else
ret = ttm_dma_tt_alloc_page_directory(ttm_dma);
if (ret) {
- ttm_tt_destroy(ttm);
pr_err("Failed allocating page table\n");
return -ENOMEM;
}
_err("Failed allocating page table\n");
return -ENOMEM;
}
@@ -287,7 +285,6 @@ int ttm_sg_tt_init(struct ttm_dma_tt *tt
else
ret = ttm_dma_tt_alloc_page_directory(ttm_dma);
if (ret) {
- ttm_tt_destroy(ttm);
pr_err("Failed allocating page table\n");
return -ENOMEM;
}
_err("Failed allocating page table\n");
return -ENOMEM;
}
@@ -288,7 +286,6 @@ int ttm_sg_tt_init(struct ttm_dma_tt *tt
else
ret = ttm_dma_tt_alloc_page_directory(ttm_dma);
if (ret) {
- ttm_tt_destroy(ttm);
pr_err("Failed allocating page table\n");
return -ENOMEM;
}
. Its internal endpoint state will always
be halted on any stall, even if the device side of the endpiont is not
halted. So we do need to issue the reset endpoint command to clear the
xHC host intenal endpoint halt state, but should not request the HS hub
to clear the TT buffer unless device side of
. Its internal endpoint state will always
be halted on any stall, even if the device side of the endpiont is not
halted. So we do need to issue the reset endpoint command to clear the
xHC host intenal endpoint halt state, but should not request the HS hub
to clear the TT buffer unless device side of
tt
From: Linus Lüssing
commit a3c7cd0cdf1107f891aff847ad481e34df727055 upstream.
Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard/not
From: Linus Lüssing
commit a3c7cd0cdf1107f891aff847ad481e34df727055 upstream.
Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard/not
From: Linus Lüssing
commit a3c7cd0cdf1107f891aff847ad481e34df727055 upstream.
Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard/not
From: Linus Lüssing
commit a3c7cd0cdf1107f891aff847ad481e34df727055 upstream.
Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard/not
From: Linus Lüssing
[ Upstream commit a3c7cd0cdf1107f891aff847ad481e34df727055 ]
Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard
From: Linus Lüssing
[ Upstream commit a3c7cd0cdf1107f891aff847ad481e34df727055 ]
Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard
From: Linus Lüssing
[ Upstream commit a3c7cd0cdf1107f891aff847ad481e34df727055 ]
Syzbot has reported some issues with the locking assumptions made for
the multicast tt/tvlv worker: It was able to trigger the WARN_ON() in
batadv_mcast_mla_tt_retract() and batadv_mcast_mla_tt_add().
While hard
3.16.62-rc1 review patch. If anyone has any objections, please let me know.
--
From: Sven Eckelmann
commit e7136e48ffdfb9f37b0820f619380485eb407361 upstream.
The function batadv_tt_global_orig_entry_add is responsible for adding new
tt_orig_list_entry to the orig_list. It firs
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
--
From: Linus Lüssing
commit a44ebeff6bbd6ef50db41b4195fca87b21aefd20 upstream.
When a (broken) node wrongly sends multicast TT entries with a ROAM
flag then this causes any receiving node to drop
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
--
From: Linus Lüssing
commit 4a519b83da16927fb98fd32b0f598e639d1f1859 upstream.
Since commit 54e22f265e87 ("batman-adv: fix TT sync flag inconsistencies")
TT sync flags and TT non-sync&#
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
--
From: Simon Wunderlich
commit ad7e2c466d8b0a7056cd248e1df6bb7296e014f7 upstream.
This should slightly improve readability
Signed-off-by: Simon Wunderlich
Signed-off-by: Marek Lindner
Signed-off-b
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Sven Eckelmann
[ Upstream commit e7136e48ffdfb9f37b0820f619380485eb407361 ]
The function batadv_tt_global_orig_entry_add is responsible for adding new
tt_orig_list_entry to the orig_list. It fi
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Sven Eckelmann
[ Upstream commit e7136e48ffdfb9f37b0820f619380485eb407361 ]
The function batadv_tt_global_orig_entry_add is responsible for adding new
tt_orig_list_entry to the orig_list. It f
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Sven Eckelmann
[ Upstream commit e7136e48ffdfb9f37b0820f619380485eb407361 ]
The function batadv_tt_global_orig_entry_add is responsible for adding new
tt_orig_list_entry to the orig_list. It f
3.16.60-rc1 review patch. If anyone has any objections, please let me know.
--
From: Linus Lüssing
commit 7072337e52b3e9d5460500d8dc9cbc1ba2db084c upstream.
The previous TT sync fix so far only fixed TT responses issued by the
target node directly. So far, TT responses issued
itself (addition and/or deletion of entries).
The per-VLAN headers are used by OGM recipients for consistency
checks. Said consistency check might determine that a full
translation table request is needed to restore consistency. If
the TT sender adds per-VLAN headers of empty VLANs into the OGM
buffer
which can be used to store the TVLV container for TT and add the VLAN
information to it.
This will be done in three phases:
1. count the number of VLANs and their entries
2. allocate the buffer using the counters from the previous step and limits
from the caller (parameter tt_len)
3
From: Sven Eckelmann
[ Upstream commit e7136e48ffdfb9f37b0820f619380485eb407361 ]
The function batadv_tt_global_orig_entry_add is responsible for adding new
tt_orig_list_entry to the orig_list. It first checks whether the entry
already is in the list or not. If it is, then the creation of a new
From: Sven Eckelmann
[ Upstream commit e7136e48ffdfb9f37b0820f619380485eb407361 ]
The function batadv_tt_global_orig_entry_add is responsible for adding new
tt_orig_list_entry to the orig_list. It first checks whether the entry
already is in the list or not. If it is, then the creation of a new
From: Sven Eckelmann
[ Upstream commit e7136e48ffdfb9f37b0820f619380485eb407361 ]
The function batadv_tt_global_orig_entry_add is responsible for adding new
tt_orig_list_entry to the orig_list. It first checks whether the entry
already is in the list or not. If it is, then the creation of a new
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
[ Upstream commit d9954405758a0cbbe258d9b4d4dc12a06fa48a28 ]
The ucode_loaded check should be under the mutex, since it can
otherwise change state after we looked at it and befor
From: Johannes Berg
[ Upstream commit d9954405758a0cbbe258d9b4d4dc12a06fa48a28 ]
The ucode_loaded check should be under the mutex, since it can
otherwise change state after we looked at it and before we got
the mutex. Fix that.
Fixes: 5c89e7bc557e ("iwlwifi: mvm: add registration to cooling dev
Hi Ben,
On Tue, Nov 07, 2017 at 01:42:35PM +, Ben Hutchings wrote:
> That function didn't exist in 3.16 (at least not under that name).
Ah, you're right, back then the netlink interface did not
exist in batman-adv yet, only the debugfs one.
batadv_tt_global_print_entry would be the equivalent
On Tue, 2017-11-07 at 02:16 +0100, Linus Lüssing wrote:
> Hi Ben!
>
> On Mon, Nov 06, 2017 at 11:03:02PM +, Ben Hutchings wrote:
> > 3.16.50-rc1 review patch. If anyone has any objections, please let
> > me know.
> >
> > --
> >
> > From: Linus Lüssing
> >
> > commit 54e22f
Hi Ben!
On Mon, Nov 06, 2017 at 11:03:02PM +, Ben Hutchings wrote:
> 3.16.50-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Linus Lüssing
>
> commit 54e22f265e872ae140755b3318521d400a094605 upstream.
[...]
> [bwh: Backported to 3.16:
>
3.16.50-rc1 review patch. If anyone has any objections, please let me know.
--
From: Linus Lüssing
commit 54e22f265e872ae140755b3318521d400a094605 upstream.
This patch fixes an issue in the translation table code potentially
leading to a TT Request + Response storm. The issue
this problem with the returned
length of 0. Not checking this value results in an invalid memory access
when either tt_data or tt_change is accessed.
Reported-by: Dan Carpenter
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Sven Eckelmann
Sig
this problem with the returned
length of 0. Not checking this value results in an invalid memory access
when either tt_data or tt_change is accessed.
Reported-by: Dan Carpenter
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Sven Eckelmann
Sig
this problem with the returned
length of 0. Not checking this value results in an invalid memory access
when either tt_data or tt_change is accessed.
Reported-by: Dan Carpenter
Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
Signed-off-by: Sven Eckelmann
Sig
lated vlan */
vlan = batadv_softif_vlan_get(bat_priv, vid);
if (WARN(!vlan, "adding TT local entry %pM to non-existent VLAN %d",
-addr, BATADV_PRINT_VID(vid)))
+addr, BATADV_PRINT_VID(vid))) {
+ kfree(tt_local);
+
eak which can occur once an
originator times out. On timeout the according global translation table
entry might not get purged correctly. Furthermore, the non purged TT
entry will cause its orig-node to leak, too. Which additionally can lead
to the new multicast optimization feature not kicking in beca
errors like this
in the console:
usb usb1: clear tt 1 (9043) error -22
The specific test case I used looks like this:
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 17, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 2: Dev 19, If 0, ..., Driver=usbhid
I find that when I plug a full speed (NOT high speed) hub into a dwc2
port and then I plug a bunch of devices into that full speed hub that
dwc2 goes bat guano crazy. Specifically, it just spews errors like this
in the console:
usb usb1: clear tt 1 (9043) error -22
The specific test case I
& FS periodic endpoints which its device don't attach
- * to TT are also ignored, root-hub will schedule them directly
+* for LS & FS periodic endpoints which its device is not behind
+* a TT are also ignored, root-hub will schedule them directly,
+* but need s
3.16.7-ckt18 -stable review patch. If anyone has any objections, please let me
know.
--
From: =?UTF-8?q?Linus=20L=C3=BCssing?=
commit ac4eebd48461ec993e7cb614d5afe7df8c72e6b7 upstream.
Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One
OGM handler might undo
index acb981a..c4736c8 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tt.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tt.c
@@ -612,15 +612,10 @@ void iwl_tt_initialize(struct iwl_priv *priv)
memset(tt, 0, sizeof(struct iwl_tt_mgmt));
tt->state = IWL_TI_0;
-
Cached memory accesses between the CPU and the GPU are not coherent on
ARM. Use the DMA TTM allocator on this architecture to obtain coherent
memory.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/n
3.13.11.4 -stable review patch. If anyone has any objections, please let me
know.
--
From: Antonio Quartulli
[ Upstream commit cc2f33860cea0e48ebec096130bd0f7c4bf6e0bc ]
Change introduced by 88e48d7b3340ef07b108eb8a8b3813dd093cc7f7
("batman-adv: make DAT drop ARP requests tar
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Antonio Quartulli
[ Upstream commit cc2f33860cea0e48ebec096130bd0f7c4bf6e0bc ]
Change introduced by 88e48d7b3340ef07b108eb8a8b3813dd093cc7f7
("batman-adv: make DAT drop ARP requests targeting
3.13-stable review patch. If anyone has any objections, please let me know.
--
From: Antonio Quartulli
[ Upstream commit e889241f45f9cecbc84a6ffed577083ab52e62ee ]
When accessing a TT-TVLV container in the OGM RX path
the variable pointing to the list of changes to apply is
different endianess.
Fix this by converting the VID to Network Order before
processing it. This guarantees that every node uses the same
byte order.
Introduced by 7ea7b4a142758deaf46c1af0ca9ceca6dd55138b
("batman-adv: make the TT CRC logic VLAN specific")
Reported-by: Russel Senior
Sig
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: William Gulland
[ Upstream commit 2c7b871b9102c497ba8f972aa5d38532f05b654d ]
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control
3.8.13.7 -stable review patch. If anyone has any objections, please let me
know.
--
From: William Gulland
commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: William Gulland
commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it&#
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: William Gulland
commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it&#
3.0-stable review patch. If anyone has any objections, please let me know.
--
From: William Gulland
commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it&#
3.2.50-rc1 review patch. If anyone has any objections, please let me know.
--
From: William Gulland
commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it&#
3.5.7.18 -stable review patch. If anyone has any objections, please let me
know.
--
From: William Gulland
commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer
On Thu, 27 Jun 2013, William Gulland wrote:
> Control transfers have both IN and OUT (or SETUP) packets, so when
> clearing TT buffers for a control transfer it's necessary to send
> two HUB_CLEAR_TT_BUFFER requests to the hub.
>
> Signed-off-by: William Gulland
On Thu, 27 Jun 2013, William Gulland wrote:
> Control transfers have both IN and OUT (or SETUP) packets, so when
> clearing TT buffers for a control transfer it's necessary to send
> two HUB_CLEAR_TT_BUFFER requests to the hub.
What makes you think this is necessary?
Hello.
On 28-06-2013 3:10, William Gulland wrote:
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: William Gulland
---
dr
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: William Gulland
---
drivers/usb/core/hub.c | 9 +
1 file changed, 9 inser
3.6.11.2 stable review patch.
If anyone has any objections, please let me know.
--
From: Marek Lindner
[ Upstream commit b47506d91259c29b9c75c404737eb6525556f9b4 ]
batadv_iv_ogm_process() accesses the packet using the tt_num_changes
attribute regardless of the real packet len (
3.8-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Lindner
[ Upstream commit b47506d91259c29b9c75c404737eb6525556f9b4 ]
batadv_iv_ogm_process() accesses the packet using the tt_num_changes
attribute regardless of the real packet len (ass
On Mon, Mar 4, 2013 at 2:08 PM, Kent Yoder wrote:
>>> >
>>> > +
>>> > +#ifdef CONFIG_OF
>>> > +static const struct of_device_id tpm_tis_i2c_of_match[] = {
>>> > + { .compatible = "infineon,tpm_i2c_infineon", .data = (void *)0 },
>>> > + { .compatible = "infineon,slb9635tt", .data = (void *)0 }
>> >
>> > +
>> > +#ifdef CONFIG_OF
>> > +static const struct of_device_id tpm_tis_i2c_of_match[] = {
>> > + { .compatible = "infineon,tpm_i2c_infineon", .data = (void *)0 },
>> > + { .compatible = "infineon,slb9635tt", .data = (void *)0 },
>> > + { .compatible = "infineon,slb9645tt", .data =
Hi Kent,
short reply from my private account - so only talking on behalf of myself.
Am Montag, 4. März 2013, 18:41:04 schrieb Kent Yoder:
> Hi Peter,
>
> Sorry for the long delay in getting this reviewed...
No problem.
>
> > - for (count = 0; count < MAX_COUNT; count++) {
> > - u
On Mon, Mar 04, 2013 at 11:41:04AM -0600, Kent Yoder wrote:
> > .id_table = tpm_tis_i2c_table,
> > .probe = tpm_tis_i2c_probe,
> > .remove = tpm_tis_i2c_remove,
> > @@ -703,11 +759,12 @@ static struct i2c_driver tpm_tis_i2c_driver = {
> >.name = "tpm_i2c_infineon",
> >
This driver adds support for Infineon's new SLB 9645 TT 1.2 I2C TPMs,
which supports clockstretching, combined reads and a bus speed of
up to 400khz. The device also has a new device id.
The driver works now also fine with device trees, so you can
instantiate your device by adding:
+
This driver adds support for Infineon's new SLB 9645 TT 1.2 I2C TPMs,
which supports clockstretching, combined reads and a bus speed of
up to 400khz. The device also has a new device id.
The driver works now also fine with device trees, so you can
instantiate your device by adding:
+
3.5.7u1 -stable review patch. If anyone has any objections, please let me know.
--
From: Octavian Purdila
commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c upstream.
There is a race condition in the USB hub code with regard to handling
TT clear requests that can get the HCD
1 - 100 of 123 matches
Mail list logo
