ehci-dbg prints random memory (# CONFIG_DYNAMIC_DEBUG is not set)
Hi, I'm trying to debug some EHCI issue so I enabled debugging by adding ccflags-y := -DDEBUG to the drivers/usb/host/Makefile Some of debugging lines contain random memory, e.g.: ehci-platform ehci-platform.0: .|��`|���5P5@�3�.��*�.|��o It's caused by dbg_status, dbg_cmd and dbg_port calling ehci_dbg even with: # CONFIG_DYNAMIC_DEBUG The lack of above config implies using dummy dbg_status_buf, dbg_command_buf and dbg_port_buf. They don't print anything to the buffer and it stays uninitialized. Can you give me a hint how to solve this (apart from enabling CONFIG_DYNAMIC_DEBUG for my debugging which I did)? Should dbg_*_buf functions return some error instead of 0? We could check for that in dbg_* functions then. Unfortunately I'm not sure how it's going to affect other places, e.g. fill_registers_buffer. -- Rafał -- 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
[PATCHv4 1/3] usb: storage: scsiglue: further describe our 240 sector limit
Just so we have some sort of documentation as to why
we limit our Mass Storage transfers to 240 sectors,
let's update the comment to make clearer that
devices were found that would choke with larger
transfers.
While at that, also make sure to clarify that other
operating systems have similar, albeit different,
limits on mass storage transfers.
Signed-off-by: Felipe Balbi
---
drivers/usb/storage/scsiglue.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 90901861bfc0..9da1fb3d0ff4 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -565,7 +565,24 @@ static const struct scsi_host_template
usb_stor_host_template = {
/* lots of sg segments can be handled */
.sg_tablesize = SCSI_MAX_SG_CHAIN_SEGMENTS,
- /* limit the total size of a transfer to 120 KB */
+
+ /*
+* Limit the total size of a transfer to 120 KB.
+*
+* Some devices are known to choke with anything larger. It seems like
+* the problem stems from the fact that original IDE controllers had
+* only an 8-bit register to hold the number of sectors in one transfer
+* and even those couldn't handle a full 256 sectors.
+*
+* Because we want to make sure we interoperate with as many devices as
+* possible, we will maintain a 240 sector transfer size limit for USB
+* Mass Storage devices.
+*
+* Tests show that other operating have similar limits with Microsoft
+* Windows 7 limiting transfers to 128 sectors for both USB2 and USB3
+* and Apple Mac OS X 10.11 limiting transfers to 256 sectors for USB2
+* and 2048 for USB3 devices.
+*/
.max_sectors = 240,
/* merge commands... this seems to help performance, but
--
2.8.0.rc2
--
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
[PATCHv4 0/3] usb: storage: increase limit to 2048 sectors
here's v4 of the scsiglue limit patch. Changes since v3: - Respect USB_FL_MAX_SECTORS* if they are set for USB3 devices Changes since v2: - Add a patch fixing multi-line comment style - s/limitting/limiting - Remove US_FL_USB3 flag Felipe Balbi (3): usb: storage: scsiglue: further describe our 240 sector limit usb: storage: scsiglue: limit USB3 devices to 2048 sectors usb: storage: fix multi-line comment style drivers/usb/storage/alauda.c | 22 ++- drivers/usb/storage/cypress_atacb.c| 34 ++-- drivers/usb/storage/datafab.c | 22 ++- drivers/usb/storage/debug.c| 3 +- drivers/usb/storage/debug.h| 3 +- drivers/usb/storage/ene_ub6250.c | 25 +-- drivers/usb/storage/freecom.c | 75 +--- drivers/usb/storage/initializers.c | 15 +- drivers/usb/storage/initializers.h | 15 +- drivers/usb/storage/isd200.c | 51 ++--- drivers/usb/storage/jumpshot.c | 22 ++- drivers/usb/storage/karma.c| 3 +- drivers/usb/storage/option_ms.c| 6 +- drivers/usb/storage/protocol.c | 12 +- drivers/usb/storage/protocol.h | 3 +- drivers/usb/storage/realtek_cr.c | 12 +- drivers/usb/storage/scsiglue.c | 169 - drivers/usb/storage/scsiglue.h | 3 +- drivers/usb/storage/sddr09.c | 82 +--- drivers/usb/storage/sddr55.c | 45 +++-- drivers/usb/storage/shuttle_usbat.c| 16 +- drivers/usb/storage/sierra_ms.c| 3 +- drivers/usb/storage/transport.c| 165 ++-- drivers/usb/storage/transport.h| 3 +- drivers/usb/storage/uas.c | 3 +- drivers/usb/storage/unusual_alauda.h | 3 +- drivers/usb/storage/unusual_cypress.h | 3 +- drivers/usb/storage/unusual_datafab.h | 6 +- drivers/usb/storage/unusual_devs.h | 334 ++--- drivers/usb/storage/unusual_freecom.h | 3 +- drivers/usb/storage/unusual_isd200.h | 3 +- drivers/usb/storage/unusual_jumpshot.h | 3 +- drivers/usb/storage/unusual_karma.h| 3 +- drivers/usb/storage/unusual_onetouch.h | 6 +- drivers/usb/storage/unusual_realtek.h | 3 +- drivers/usb/storage/unusual_sddr09.h | 3 +- drivers/usb/storage/unusual_sddr55.h | 3 +- drivers/usb/storage/unusual_uas.h | 3 +- drivers/usb/storage/unusual_usbat.h| 3 +- drivers/usb/storage/usb.c | 98 ++ drivers/usb/storage/usb.h | 14 +- drivers/usb/storage/usual-tables.c | 3 +- 42 files changed, 851 insertions(+), 455 deletions(-) -- 2.8.0.rc2 -- 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
[PATCHv4 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors
USB3 devices, because they are much newer, have much
less chance of having issues with larger transfers.
We still keep a limit because anything above 2048
sectors really rendered negligible speed
improvements, so we will simply ignore
that. Transferring 1MiB should already give us
pretty good performance.
Signed-off-by: Felipe Balbi
---
drivers/usb/storage/scsiglue.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 9da1fb3d0ff4..2bb6a88858ea 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -127,6 +127,11 @@ static int slave_configure(struct scsi_device *sdev)
if (queue_max_hw_sectors(sdev->request_queue) > max_sectors)
blk_queue_max_hw_sectors(sdev->request_queue,
max_sectors);
+ } else if (us->pusb_dev->speed >= USB_SPEED_SUPER) {
+ /* USB3 devices will be limited to 2048 sectors. This gives us
+* better throughput on most devices.
+*/
+ blk_queue_max_hw_sectors(sdev->request_queue, 2048);
} else if (sdev->type == TYPE_TAPE) {
/* Tapes need much higher max_sector limits, so just
* raise it to the maximum possible (4 GB / 512) and
--
2.8.0.rc2
--
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
[PATCHv4 3/3] usb: storage: fix multi-line comment style
No functional changes here, just making sure our
storage driver uses a consistent multi-line comment
style.
Signed-off-by: Felipe Balbi
---
drivers/usb/storage/alauda.c | 22 ++-
drivers/usb/storage/cypress_atacb.c| 34 ++--
drivers/usb/storage/datafab.c | 22 ++-
drivers/usb/storage/debug.c| 3 +-
drivers/usb/storage/debug.h| 3 +-
drivers/usb/storage/ene_ub6250.c | 25 +--
drivers/usb/storage/freecom.c | 75 +---
drivers/usb/storage/initializers.c | 15 +-
drivers/usb/storage/initializers.h | 15 +-
drivers/usb/storage/isd200.c | 51 ++---
drivers/usb/storage/jumpshot.c | 22 ++-
drivers/usb/storage/karma.c| 3 +-
drivers/usb/storage/option_ms.c| 6 +-
drivers/usb/storage/protocol.c | 12 +-
drivers/usb/storage/protocol.h | 3 +-
drivers/usb/storage/realtek_cr.c | 12 +-
drivers/usb/storage/scsiglue.c | 147 ++-
drivers/usb/storage/scsiglue.h | 3 +-
drivers/usb/storage/sddr09.c | 82 +---
drivers/usb/storage/sddr55.c | 45 +++--
drivers/usb/storage/shuttle_usbat.c| 16 +-
drivers/usb/storage/sierra_ms.c| 3 +-
drivers/usb/storage/transport.c| 165 ++--
drivers/usb/storage/transport.h| 3 +-
drivers/usb/storage/uas.c | 3 +-
drivers/usb/storage/unusual_alauda.h | 3 +-
drivers/usb/storage/unusual_cypress.h | 3 +-
drivers/usb/storage/unusual_datafab.h | 6 +-
drivers/usb/storage/unusual_devs.h | 334 ++---
drivers/usb/storage/unusual_freecom.h | 3 +-
drivers/usb/storage/unusual_isd200.h | 3 +-
drivers/usb/storage/unusual_jumpshot.h | 3 +-
drivers/usb/storage/unusual_karma.h| 3 +-
drivers/usb/storage/unusual_onetouch.h | 6 +-
drivers/usb/storage/unusual_realtek.h | 3 +-
drivers/usb/storage/unusual_sddr09.h | 3 +-
drivers/usb/storage/unusual_sddr55.h | 3 +-
drivers/usb/storage/unusual_uas.h | 3 +-
drivers/usb/storage/unusual_usbat.h| 3 +-
drivers/usb/storage/usb.c | 98 ++
drivers/usb/storage/usb.h | 14 +-
drivers/usb/storage/usual-tables.c | 3 +-
42 files changed, 829 insertions(+), 455 deletions(-)
diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c
index 171fa7d793bc..1d8b03c81030 100644
--- a/drivers/usb/storage/alauda.c
+++ b/drivers/usb/storage/alauda.c
@@ -829,8 +829,10 @@ static int alauda_write_lba(struct us_data *us, u16 lba,
pba = MEDIA_INFO(us).lba_to_pba[zone][lba_offset];
if (pba == 1) {
- /* Maybe it is impossible to write to PBA 1.
- Fake success, but don't do anything. */
+ /*
+* Maybe it is impossible to write to PBA 1.
+* Fake success, but don't do anything.
+*/
printk(KERN_WARNING
"alauda_write_lba: avoid writing to pba 1\n");
return USB_STOR_TRANSPORT_GOOD;
@@ -977,10 +979,12 @@ static int alauda_read_data(struct us_data *us, unsigned
long address,
usb_stor_dbg(us, "Read %d zero pages (LBA %d) page
%d\n",
pages, lba, page);
- /* This is not really an error. It just means
- that the block has never been written.
- Instead of returning USB_STOR_TRANSPORT_ERROR
- it is better to return all zero data. */
+ /*
+* This is not really an error. It just means
+* that the block has never been written.
+* Instead of returning USB_STOR_TRANSPORT_ERROR
+* it is better to return all zero data.
+*/
memset(buffer, 0, len);
} else {
@@ -1222,8 +1226,10 @@ static int alauda_transport(struct scsi_cmnd *srb,
struct us_data *us)
}
if (srb->cmnd[0] == ALLOW_MEDIUM_REMOVAL) {
- /* sure. whatever. not like we can stop the user from popping
- the media out of the device (no locking doors, etc) */
+ /*
+* sure. whatever. not like we can stop the user from popping
+* the media out of the device (no locking doors, etc)
+*/
return USB_STOR_TRANSPORT_GOOD;
}
diff --git a/drivers/usb/storage/cypress_atacb.c
b/drivers/usb/storage/cypress_atacb.c
index c80d3dec9a34..5e4af44d7d9f 100644
--- a/drivers/usb/storage/cypress_atacb.c
+++ b/drivers/usb/storage/cypress_atacb.c
@@ -110,13 +110,17 @@ static void cypress_atacb_passthrough(struct scsi_cmnd
*srb, struct us_data *us)
/* first build the ATACB command */
srb->cmd_len = 16;
- s
Re: [PATCHv3 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors
Hi, Alan Stern writes: > On Tue, 12 Apr 2016, Felipe Balbi wrote: > >> > I should have noticed this before. If something goes wrong with the >> > 2048-sector limit, this doesn't permit the user to override. Shouldn't >> > the test for USB_SPEED_SUPER go after the other FL_MAX_SECTORS tests? >> >> you mean that a USB3 device with US_FL_MAX_SECTORS* should still respect >> the 64 limit ? yeah I can do that. I'll send a new version tomorrow (so >> I can wait for confirmation from you) > > Yes, that's exactly what I meant. Otherwise we will be unable to > handle such devices, if (or when!) they show up. alright, cool. v4 coming right up ;-) -- balbi signature.asc Description: PGP signature
Re: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed
On 4/12/2016 12:18 AM, Bjørn Mork wrote:
> John Youn writes:
>
>> Hi,
>>
>> I would like to port the following commit from 4.6 to older kernels.
>>
>> 1a85329171094951956a37acc8abb7e51c1e742e ("usb: gadget: composite:
>> Return bcdUSB 0x0310")
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a85329171094951956a37acc8abb7e51c1e742e
>
> You are of course free to do that. Why do you need it to be in
> everybody else's stable kernels?
>
> Ref the current discussion on "security fixes only" stable kernels. It
> seems some people think that the current stable rules already allow too
> much potentionally harmful stuff. Allowing new features like this isn't
> going to help there...
>
>> There is a some concern that revving the bcdUSB to 0x0310 will cause
>> problems for SuperSpeed devices based on older kernels that don't
>> otherwise have any USB 3.1 specific code.
>>
>> On the device side I don't think there will be any problems because
>> there aren't really any checks against bcdUSB. We just set it to
>> 0x0300 (0x0310 for kernel 4.6+) based on if the gadget tells us it
>> supports SuperSpeed or higher.
>>
>> And I don't think there should be any problems for a host connecting
>> to these devices since any SuperSpeed capable host should know about
>> bcdUSB = 0x03XX. And I don't think the USB spec defines any different
>> functionality based solely on 0x0300 vs 0x0310.
>
> Luckily I'm not the one to decide this, but I believe
> Documentation/stable_kernel_rules.txt require a lot more than that.
> Could you relate this to "fixing a bug" somehow?
It only relates to fixing a failure in the CV.
>
>> The reason for this backport is that the USB CV tool now checks this
>> and ostensibly USB IF certification will require this for "new"
>> devices. So if you are basing a new device on a kernel older than 4.6,
>> it will not pass CV.
>
> That sounds like a feature to me ;)
Ok thanks, good points.
Not everyone will want this in their existing, previously-certified
products. This could bring other problems for those devices, like
having to recertify.
I think there is a valid argument for having it there as well since
everyone certifying a device needs it. It could be considered a
failure in that it's been a requirement since USB 3.1. And I feel like
it could be backported to a few most recent kernel versions without
issue. Say, 4.4, which is too recent to have any Enhanced SuperSpeed
devices certified on it which doesn't also have to conform to USB 3.1.
But yeah, I don't think it should be backported to much older kernels
and I'm ok if it's only in 4.6 onwards.
Regards,
John
--
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: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed
On 4/11/2016 11:25 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> Hi,
>>
>> I would like to port the following commit from 4.6 to older kernels.
>>
>> 1a85329171094951956a37acc8abb7e51c1e742e ("usb: gadget: composite:
>> Return bcdUSB 0x0310")
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a85329171094951956a37acc8abb7e51c1e742e
>>
>> There is a some concern that revving the bcdUSB to 0x0310 will cause
>> problems for SuperSpeed devices based on older kernels that don't
>> otherwise have any USB 3.1 specific code.
>>
>> On the device side I don't think there will be any problems because
>> there aren't really any checks against bcdUSB. We just set it to
>> 0x0300 (0x0310 for kernel 4.6+) based on if the gadget tells us it
>> supports SuperSpeed or higher.
>>
>> And I don't think there should be any problems for a host connecting
>> to these devices since any SuperSpeed capable host should know about
>> bcdUSB = 0x03XX. And I don't think the USB spec defines any different
>> functionality based solely on 0x0300 vs 0x0310.
>
> well, there is the actual SuperSpeedPlus speed. And, sure, that won't be
SuperSpeedPlus support is determined by the SSP Dev Cap
Descriptor. You can have bcdUSB 0x0310 and not have SuperSpeedPlus.
> supported by XHCI driver on those older kernels which begs the question:
> What's the benefit of backporting that change ?
To fix CV test failure for devices based on those kernels.
>
>> The reason for this backport is that the USB CV tool now checks this
>> and ostensibly USB IF certification will require this for "new"
>> devices. So if you are basing a new device on a kernel older than 4.6,
>> it will not pass CV.
>
> Wait, even SuperSpeed GEN1-only devices *must* set bcdUSB to 0x0310 ? Do
> you have a reference to that ? I find that pretty odd because this means
> that if I take any of my USB3 devices that I already have today, and run
> them against latest USBCV, they'll all fail and that's not very nice.
Yup, that is exactly what happens. See 9.6.1 in the USB 3.1
specification. Also the CV tool and compliance test specification from
USB IF say this as well. If you test with any existing SuperSpeed
device it will fail.
>
> Are you, perhaps, miss-reading the recommendation ? For example, when we
> got the LPM ECN, all device were required to set bcdUSB to 0x0210 iff
> they supported LPM. This means that you would only fail USBCV if you had
> bcdUSB set to 0x0210 and didn't support LPM. You can still certify USB
> 2.0 without LPM, right ?
Yes that's correct for 2.0.
John
--
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
ジェームズHartopから
ジェームズHartopから、 私はあなたとあなたの家族がやっているか、私の手紙が今日健康とあなたの最高の気分でお会いすることを期待しますか？親切にあなたのプライバシーに侵入するための私を許してください。あなたは私達の両方の相互利益になります金融ビジネス関係で信頼することはできますか？私はあなたが私はあなたを伝えることを約午前何に興味を持つであろうことを期待して、あなたの国の国際ビジネス情報から自分の名前と連絡先を得ました。 私はここイギリスでHarlesdenからジェームズ・ウィリアムHartop、北西ロンドン、と思います。私は、UBS銀行、ロンドンのために働きます。私は私達の両方に莫大な利益をもたらすであろうビジネスの提案についてあなたを書いています。私の部署では、UBS AGのカバレッジおよびアドバイザリーのマネージングディレクター/ヘッドなので、私は次のいずれかに属するアカウントで22.3百万英ポンドスターリング（二十二百三十万英ポンドスターリング）の放棄合計を発見しました私たちの外国人の故人の顧客、彼の死と彼の家族に生じたヘリコプターのクラッシュ2010年1月10日の犠牲者だった億万長者のビジネスモーグル後期氏モイゼスサバマスリ、メキシコからのユダヤ人。サバは47歳でした。また、衝突時のチョッパーに彼の妻、息子アブラハム（アルバート）と彼の義理の娘でした。パイロットはまた、死んでいました。 ご連絡の選択は、特にによるトランザクションの感度および本明細書の機密保持のために、あなたが住んでいる場所の地理的な性質から、興奮しています。現在、私たちの銀行は来アップするために請求のために親戚のいずれかを待っている誰もがそれをやっていません。私は個人的に、今、私は22.3百万ポンドの価値がこのアカウントの収益があなたに支払うことができるようにあなたの同意が故人の親族/ウィル受益次のようにあなたを提供しようと5年間の親戚を見つけるに失敗しました。 これは支払わまたは共有これらの割合で、私には60％と、あなたに40％になります。私たちが作っているこの主張をバックアップするために使用することができ、必要なすべての法的文書を確保しています。私が必要とするすべての文書にあなたの名前に充填し、正当な受益者としてあなたを証明するためにここに法廷でそれを合法化することです。私が今必要とするすべては、私たちはこのトランザクションを介して、参照可能にするためにあなたの正直な協力、機密性と信頼です。私は、これは法律の違反からあなたを保護する正当な配置の下で実行されることを保証します。 我々はそれを介して、実行するために7日を持っているように、私に次のようにしてください。これはPLEASE非常に急務です。 1.氏名： 2.あなたの直接携帯電話番号： 3.あなたの連絡先住所： 4.あなたの職業： 5.あなたの国籍： 6.あなたの性別/年齢： 系統的検索を経てきたが、私はあなたがこの提案が興味深い見つけることを期待してあなたに連絡することを決めました。より多くの情報をご提出します。このメッセージの確認に喜ばとご関心を示しています。私はあなたの決定を知らせるのではなく待っている私を保つに努めます。 よろしく、 ジェームズW.Hartop UBS AG、投資銀行 1フィンズベリー・アベニュー、ロンドン EC2M 2PP、イギリス。 www.ubs.com
ジェームズHartopから、
ジェームズHartopから、 私はあなたとあなたの家族がやっているか、私の手紙が今日健康とあなたの最高の気分でお会いすることを期待しますか？親切にあなたのプライバシーに侵入するための私を許してください。あなたは私達の両方の相互利益になります金融ビジネス関係で信頼することはできますか？私はあなたが私はあなたを伝えることを約午前何に興味を持つであろうことを期待して、あなたの国の国際ビジネス情報から自分の名前と連絡先を得ました。 私はここイギリスでHarlesdenからジェームズ・ウィリアムHartop、北西ロンドン、と思います。私は、UBS銀行、ロンドンのために働きます。私は私達の両方に莫大な利益をもたらすであろうビジネスの提案についてあなたを書いています。私の部署では、UBS AGのカバレッジおよびアドバイザリーのマネージングディレクター/ヘッドなので、私は次のいずれかに属するアカウントで22.3百万英ポンドスターリング（二十二百三十万英ポンドスターリング）の放棄合計を発見しました私たちの外国人の故人の顧客、彼の死と彼の家族に生じたヘリコプターのクラッシュ2010年1月10日の犠牲者だった億万長者のビジネスモーグル後期氏モイゼスサバマスリ、メキシコからのユダヤ人。サバは47歳でした。また、衝突時のチョッパーに彼の妻、息子アブラハム（アルバート）と彼の義理の娘でした。パイロットはまた、死んでいました。 ご連絡の選択は、特にによるトランザクションの感度および本明細書の機密保持のために、あなたが住んでいる場所の地理的な性質から、興奮しています。現在、私たちの銀行は来アップするために請求のために親戚のいずれかを待っている誰もがそれをやっていません。私は個人的に、今、私は22.3百万ポンドの価値がこのアカウントの収益があなたに支払うことができるようにあなたの同意が故人の親族/ウィル受益次のようにあなたを提供しようと5年間の親戚を見つけるに失敗しました。 これは支払わまたは共有これらの割合で、私には60％と、あなたに40％になります。私たちが作っているこの主張をバックアップするために使用することができ、必要なすべての法的文書を確保しています。私が必要とするすべての文書にあなたの名前に充填し、正当な受益者としてあなたを証明するためにここに法廷でそれを合法化することです。私が今必要とするすべては、私たちはこのトランザクションを介して、参照可能にするためにあなたの正直な協力、機密性と信頼です。私は、これは法律の違反からあなたを保護する正当な配置の下で実行されることを保証します。 我々はそれを介して、実行するために7日を持っているように、私に次のようにしてください。これはPLEASE非常に急務です。 1.氏名： 2.あなたの直接携帯電話番号： 3.あなたの連絡先住所： 4.あなたの職業： 5.あなたの国籍： 6.あなたの性別/年齢： 系統的検索を経てきたが、私はあなたがこの提案が興味深い見つけることを期待してあなたに連絡することを決めました。より多くの情報をご提出します。このメッセージの確認に喜ばとご関心を示しています。私はあなたの決定を知らせるのではなく待っている私を保つに努めます。 よろしく、 ジェームズW.Hartop UBS AG、投資銀行 1フィンズベリー・アベニュー、ロンドン EC2M 2PP、イギリス。 www.ubs.com
[PATCH] doc: usb: Fix typo in gadget_multi documentation
It tries to "match" drivers for each interface (not "much"). Signed-off-by: Diego Herranz --- Documentation/usb/gadget_multi.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/usb/gadget_multi.txt b/Documentation/usb/gadget_multi.txt index 7d66a86..5faf514 100644 --- a/Documentation/usb/gadget_multi.txt +++ b/Documentation/usb/gadget_multi.txt @@ -43,7 +43,7 @@ For the gadget two work under Windows two conditions have to be met: First of all, Windows need to detect the gadget as an USB composite gadget which on its own have some conditions[4]. If they are met, Windows lets USB Generic Parent Driver[5] handle the device which then -tries to much drivers for each individual interface (sort of, don't +tries to match drivers for each individual interface (sort of, don't get into too many details). The good news is: you do not have to worry about most of the -- 1.9.1 -- 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] usb: host: xhci-plat: add firmware for the R-Car M3-W xHCI controllers
On Tue, Apr 12, 2016 at 04:28:44PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a firmware for the USB 3.0 host controllers of Renesas
> R-Car M3-W SoC.
>
> - This firmware is possible to be used on R-Car H2 and M2. However,
>this version causes performance degradation on such SoCs.
> - This firmware is impossible to be used on R-Car H3 because data
>transfer might not work correctly.
>
> So, we would like to keep the v1 and v2 firmware.
>
> Signed-off-by: Yoshihiro Shimoda
OK, applied. Thanks!
regards, --Kyle
> ---
> WHENCE| 3 ++-
> r8a779x_usb3_v3.dlmem | Bin 0 -> 9472 bytes
> 2 files changed, 2 insertions(+), 1 deletion(-)
> create mode 100644 r8a779x_usb3_v3.dlmem
>
> diff --git a/WHENCE b/WHENCE
> index c2d83f4..02b46c7 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -2922,10 +2922,11 @@ Licence:
>
> --
>
> -Driver: xhci-rcar -- Renesas R-Car H2/M2/H3 USB 3.0 host controller driver
> +Driver: xhci-rcar -- Renesas R-Car Gen2/3 USB 3.0 host controller driver
>
> File: r8a779x_usb3_v1.dlmem
> File: r8a779x_usb3_v2.dlmem
> +File: r8a779x_usb3_v3.dlmem
>
> Licence: Redistributable. See LICENCE.r8a779x_usb3 for details.
>
> diff --git a/r8a779x_usb3_v3.dlmem b/r8a779x_usb3_v3.dlmem
> new file mode 100644
> index
> ..eac36a96bee1a8614eef9caa88e5a9de136af30c
> GIT binary patch
> literal 9472
> zcmai44O~=J+J9z-JD0DE%!QeY2nRwwB{K
> zD4Ci1rfYs>HkeYmO5m31jV34~)&K>O6o(P~7+pbD-BR(s|8ob#ecSi9{C@v?&b{~C
> z=R9BMInQ~9;u*j3Mp7NIzY7#;Wi4;XjLuOsWLNsr{b*C7mr~CYucqgTozEhh{^R~y
> z;vS+T2HOp?$LiOfB6?v)tUmHIQGg^i{2qOuk!V3ieSzE5L0Y{>@tLiXt@SPOBxf;E
> zcrN-@$=L9oxZiARx2;Ij7m}7V@vjlZ%gTD4C)LZbUMqSBIZC^3^pDz$QG`+K+il|K
> zoUE)CDx}B;>vpN(*eD`dshO-vOVTf;lBi+&&3%Xx^|@h0OUc1_f4i^UdWA?Am#Du6
> zN-vUarO`e}U&H23NYn>vw6vJa9UQ0O#=ag%y4R9SWH%TEW028$gSvva0iw=m`=i-@
> z|0oUh7jq>;W} zL$KbkNSYBk&LKV}a>k{QXrMIFP-14!wKIal-C~6yJ8`HKY|@al zdIY^I_*2JZ43+#duTbaq;Qg%3;F-(B{etJ>dci7j(9}uJ-_~}8Ol5ox(>FZatD9fi
> zHHEJcG-8TWD>&P0g)CnS=N58&wL+&*X0$643HCADmA#SI1-oL>RN|VTE#vIUe4Sl6
> z5LwA-U^}hkOso~U#&n*J(UYOLSUZM2Z8Tl4XB@COWn~lWTcwV^g1dx%va;gtlT+}<
> z(E)a4XTX5?FO@@gWM$#qcjeHR(BKd+8fE2ZGHla8MoYSKb+SQYWRfyJvu@Wk99u~k
> z`FTUG)Db8vv3I|>li#0iYyDm)D`9uvJ-;UP#
> zebKXWzJ^Kmicyo6l2If0rE7^}d{Et6;vR6sc&$}!P$0f9ShrKdF^PF=aEe{=QvLI?
> z5WqTP01yCir>9m)ZtKZwustPX^?o?;pR1)71GTUI$yVc}{Yk
> z+JjgbP5o`{`yGk;X7I^Y412d{gs0Xwf@x%#__NI^{Ugw0IB3)OZ18h!a|P8K&2cNh
> z*RDobScrv}KYU(;H53z|r6sU>6<4wHvxXvJypMUAHf@=R`O|zCPqZ;_`8lxS?a&5K
> zZ4+jnZLuqEU6NjjQ@u-F;|oEBt#MiT9i(eE_V|GdewHO3G&-eOtsX ziTcg>0=#eU({OA6Q3_wH`g4JJk*j#1q`|JNr}_!D_Rk?@g*wuc>c-stql(62J+(p?
> z0*fNe5w`ZPFy?|fhWU2UQ1-r1jUZEFSY&!b?N3qrtJHpjRaSmdW!A(WR-U}WzE}o|
> zer}uKUw*DC-U|gMgVgojD{DIE_YPUfhOCQBOjb1pwfBWwFX62&?zL`Da@-xe+9WHb
> zCKg?6?PexF-Y|VxC4YQrfgKqa%bk>S(_XRz+ zwsynvMEzxTj7$0_vpl|@gcVk*b>co-blCjQtIV>JKOxv7E8~XQ+FL*)M$h=LwO>X5
> zA+;|nuf}^?I-%|42`om-%C#Y|_B}Gr#JFA=^Ki#(50CaCHgOd^`QW1_wsvP4lhVT}
> z*f0y4ik5n%-_$+pCk2UmS9hOjucVu@tUP(o=x@{!J#lz|2+El}B6kSlH~L+i5pnbe
> zUF3{BYa2MD-slk52?G$vxdyfi`u}Y08q5*N`z2=k!(~KxE%t}O-OmQ%{cyGK_uzqa
> zSgF2cG1c(a8=v*DN7~aBW!ZGc^yQHjQ$Moahzi^n5s z^dsb$ZkfAQvpmx>H zniI5e+jHCJyf z%bX;Aq8f1_w z*vq+wt>Sk^#G*h|dt#6Fh{lUgiyOQABldGC{67$R18wk1cvYsY*SasObFpzr>7<)%
> zaD$gY(YWt&h%Mdgd|lTDq4$g3>KDwyy(>xX=1f**4)Ub3$kRMXR-zv0{i^xyS9X3N
> z)>7Dmp41YIJ09Dk6 ze4Bl4QzCgUx<{Ng4IuBxP^uWFmrCCmG;-fNjp9}@OT22X<8l!3-NqvG7&VgSW0oa|
> zv;MgHs(M$fR}{CPsVfp5J|9Gh`nBp)wx5op@xIgPiIkFYz*k?Hgj@g?^y!SVjrY#K
> z>Tp)wP0rRn1{SPVrNByD%wmzgBX_1QqH*@t*^T16;z4LtV~4imCL8K(tY0N=7PV8|
> zX%(rl8F-UN_9>|jbBMk}sl{$~DFgfLyb-OBV=vH-_L@Qw0iGzRFnE9aU7wWrME&Ss
> zrm=2K(Ia|_DK56&aMAn=P94h`9LO2g2_-^3BKqd!dSnU1sR-AX={od(F1eD^B04vP
> zITMShYfK&2Zw$LX5ayKj5Tes*7EhQIuJ$5g^wt}5RH{XwXL^)fD;{N(!cr z=29s+1Y{h)VHrmNp5}%1aOiCRkX+|KBy+e{|97S3iDZf(6ZNHjG=O5rMuX{B^bifB
> z;WUa8Xe=esqx2X}gwJ$7S~M2)Q?8FdcA8Q-!mezh4Y(eswxM< zuH4ZU;ku8zjx6aoR|(Hge|7_|u?yRfKLzMn7S&&00FU35&$QE-&!pM@Jd-AGQ6 zb_>qL51|)TniM8YAf9d#TzGnW%z7r{4EEGAG8`P*k#{IqpC8h*;z#CW3Z_uHkHRP%
> zSCJxdH6a^)B}L|AC&>Ip-~bRaQRb6@?Gw3pnV%{w?WXX(O2G^o;h z^Uc7N$7KH1Nisifvdpgs9JpWdxE@r3yQygP=at$C$ z4Nd=sM&Ruz8bc35-xDbj7>`*BAD8*ODKa1V1ZDx6fOnph`RM z(P=V2c$&;FoG$Z?fHqy`M*=&5Mqv0%nRm_N!P(-_9{Ju> zuK+UV$h;ef&6N3+r=WR0zWeJe?7j|Tj(C-;6LLi_2b=Ljp0e|>0zZ6S5Jm=K zv2&Cm&}woz^cO09?u%^4CNI@ln_c{JWH7E#pYpOI=eI48l{!-+r(UPvvB&K
> zdh&AH&hw~hdK}*fzd!lyqf0G8g+{d&vVw=uW>#%uRngp|C
> zM2whz>9n|A{91Hh9UyA3?-dz)Mw&B1s49H`jZgDQ zhdrDqPz66dOozDlA@OmW;=fPWlJHFea^XPh$dAclN+MkcsB$)G+j8r;>0!Z1A(J@x
> z@^NmW8g~Y&UX+EswbPg@uCsL-^TcIludo5DApsdc->yn=gP1J3O*%@EBBcVXhIkEI
> z2bOs(KJ3!4bwF8_TrfQTV6Z< zy4jPFkA%cmKE)zka;kTRd!#}k;opn4^JeE3=q*v-8OEY;N=A6#Dhhr^&})=~92Z|U
> zp>m-RUSWul-gUT5JY|WUV{=5`h~V%7(VeHGDnxnBZ122s%6+=8 zH?R}#UCCb7-IbF`dBw1~tK!+Acj=bEe~N{QtRd24zT{bToL<#+rO`4nf(|G4!Fo15
> zS1 zPL6%MT&EG85k-jneI;v#Sz_nM7{) z5PPZh>HWUC?9JJsCPm2-KZQ)|jn9gm!gFGs@Vr<8tF$W)L2LRu-hR!^!hX2r31 z#9XH%IJ{E)-jJ1D!ewV46#P3-fqhNdNu2g`cnx+4YsT}Jax$>vWxRMv*P)vMYu?Ar
> z;5lJhRl1H=rQ7MPX<
Re: [PATCH v2 2/2] USB: uas: Add a new NO_REPORT_LUNS quirk
On Tue, 12 Apr 2016, Hans de Goede wrote: > Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with > an usb-id of: 0bc2:331a, as these will fail to respond to a > REPORT_LUNS command. > > Cc: sta...@vger.kernel.org > Reported-and-tested-by: David Webb > Signed-off-by: Hans de Goede > --- > Changes in v2: > -Document new j quirk in Documentation/kernel-parameters.txt Acked-by: 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
[PATCH net,stable] cdc_mbim: apply "NDP to end" quirk to all Huawei devices
We now have a positive report of another Huawei device needing
this quirk: The ME906s-158 (12d1:15c1). This is an m.2 form
factor modem with no obvious relationship to the E3372 (12d1:157d)
we already have a quirk entry for. This is reason enough to
believe the quirk might be necessary for any number of current
and future Huawei devices.
Applying the quirk to all Huawei devices, since it is crucial
to any device affected by the firmware bug, while the impact
on non-affected devices is negligible.
The quirk can if necessary be disabled per-device by writing
N to /sys/class/net//cdc_ncm/ndp_to_end
Reported-by: Andreas Fett
Signed-off-by: Bjørn Mork
---
I'm requesting this for stable, but it depends on commit
f8c0cfa5eca9 ("net: cdc_mbim: add "NDP to end" quirk for Huawei E3372")
so it is only applicable to v4.3 (where the dependency is
backported), v4.4 and v4.5
Bjørn
drivers/net/usb/cdc_mbim.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index bdd83d95ec0a..96a5028621c8 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -617,8 +617,13 @@ static const struct usb_device_id mbim_devs[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(0x0bdb, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&cdc_mbim_info,
},
- /* Huawei E3372 fails unless NDP comes after the IP packets */
- { USB_DEVICE_AND_INTERFACE_INFO(0x12d1, 0x157d, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
+
+ /* Some Huawei devices, ME906s-158 (12d1:15c1) and E3372
+* (12d1:157d), are known to fail unless the NDP is placed
+* after the IP packets. Applying the quirk to all Huawei
+* devices is broader than necessary, but harmless.
+*/
+ { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MBIM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&cdc_mbim_info_ndp_to_end,
},
/* default entry */
--
2.1.4
--
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: XHCI is slow during boot (bios/efi) and leaves many dmesg messages
Hey,
On 11-04-16 10:22, Felipe Balbi wrote:
Hi,
Olliver Schinagl writes:
Hey all,
On 11-04-16 07:12, Felipe Balbi wrote:
Hi,
Janna Martl writes:
On 2016-04-04 9:06:28, Olliver Schinagl wrote:
Hi list,
I have a Apple Inc. MacBookPro11,1 (with the most recent 'bios': BIOS
MBP111.88Z.0138.B16.1509081438 09/08/2015).
At the beginning, USB worked normally. After a while (and after newer kernel
versions released by debian?) things started to act strangely. For one, the
you need to try with latest kernel from Linus. Please download v4.6-rc3
from kernel.org, compile and try with that.
I've tried with kernels from 3.16 to v4.6-rc2 updating every few weeks.
Anything special I should watch out for in rc3 that changed since rc2?
nothing special. Just to confirm, can you check that disabling LPM
solves the problem ?
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index f0640b7a1c42..9c3ead114ad5 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -127,8 +127,8 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
- xhci->quirks |= XHCI_LPM_SUPPORT;
- xhci->quirks |= XHCI_INTEL_HOST;
+ /* xhci->quirks |= XHCI_LPM_SUPPORT; */
+ /* xhci->quirks |= XHCI_INTEL_HOST; */
xhci->quirks |= XHCI_AVOID_BEI;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
No change what so ever. I also booted a few times to OSX (to install
some updates in hopes there where some bios/efi' updates) and while the
restart 'speed' was good on one reboot, the other 10 or so failed to
reboot quickly. It 'feels' like the xhci controller is in a wrong state
at shutdown and takes a while before it can even boot (reading the EFI
disks etc before bringing up the apple bootloader. Whatever causes it to
boot correctly, I don't know).
I'm happy to try any other patch on top of 4.6-rc3
bios/efi boot takes a very long time (probably due to the same reason I describe
later) just to get to the bootloader/grub. Likley resetting and probing for USB
ports/mass storage. When grub finally pops up, I can use the (internal USB based
keyboard) normally to select a grub entry etc.
Booting the kernel then works reasonably fine, until it loads the xhci module.
It spews some messages in dmesg (taking some 15 seconds) and only then, the
keyboard starts to work again.
which messages ? We need these dmesg messages
As mentioned by Janna, they are at the bugzilla issue number 115741 [0]
(unless you prefer them zipped otherwise they sometimes don't fit).
no, it's okay.
--
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: [PATCHv3 2/3] usb: storage: scsiglue: limit USB3 devices to 2048 sectors
On Tue, 12 Apr 2016, Felipe Balbi wrote: > > I should have noticed this before. If something goes wrong with the > > 2048-sector limit, this doesn't permit the user to override. Shouldn't > > the test for USB_SPEED_SUPER go after the other FL_MAX_SECTORS tests? > > you mean that a USB3 device with US_FL_MAX_SECTORS* should still respect > the 64 limit ? yeah I can do that. I'll send a new version tomorrow (so > I can wait for confirmation from you) Yes, that's exactly what I meant. Otherwise we will be unable to handle such devices, if (or when!) they show up. 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] usb: Add driver for UCSI
On Tue, Apr 12, 2016 at 06:12:04AM -0700, Greg KH wrote:
> On Tue, Apr 12, 2016 at 02:43:36PM +0300, Heikki Krogerus wrote:
> > + ucsi.usb_data_role=
>
> Ick, this isn't the 1990's anymore, please don't use module parameters
> for anything that is required for a driver. Make it automatic if at all
> possible, and if not, then make it at the least, a per-device attribute.
OK, makes sense.
> > +struct ucsi {
> > + struct device *dev;
> > + struct ucsi_data __iomem *data;
> > +
> > + int status;
> > + struct completion complete;
> > + struct ucsi_capability cap;
> > + struct ucsi_connector *connector;
> > +
> > + struct mutex ppm_lock;
>
> What does this lock? Document it please.
Will do.
> > + atomic_t event_pending;
>
> Your atomic_t is a poor-man's lock, I don't see why it's even needed.
> If you feel you need to keep it around, you better document the heck out
> of it proving that you used it correctly everywhere (hint, I saw a few
> places it was not used correctly...)
You are correct, there is no use for it. I'll get rid of it.
> > +static void ucsi_acpi_notify(acpi_handle handle, u32 event, void *data)
> > +{
> > + struct ucsi *ucsi = data;
> > + u32 cci = ucsi->data->cci;
> > +
> > + dev_dbg(ucsi->dev, "%s: cci 0x%x\n", __func__, cci);
>
> Delete all of your debugging code please, that's what ftrace is for.
OK.
> > + if (!atomic_read(&ucsi->event_pending)) {
> > + atomic_inc(&ucsi->event_pending);
>
> Oh look, a bug :(
>
> Again, document it if you think you need it, but really, I think you can
> get rid of it entirely.
Yes, I'll get rid of it.
Thanks,
--
heikki
--
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] usb: Add driver for UCSI
On Tue, Apr 12, 2016 at 03:10:01PM +0200, Oliver Neukum wrote:
> On Tue, 2016-04-12 at 14:43 +0300, Heikki Krogerus wrote:
>
> > +static int ucsi_init(struct ucsi *ucsi)
> > +{
> > + struct ucsi_connector *con;
> > + struct ucsi_control ctrl;
> > + int ret;
> > + int i;
> > +
> > + atomic_set(&ucsi->event_pending, 0);
> > + init_completion(&ucsi->complete);
> > + mutex_init(&ucsi->ppm_lock);
> > +
> > + mutex_lock(&ucsi->ppm_lock);
> > +
> > + /* Reset */
> > + ret = ucsi_acpi_cmd(ucsi, UCSI_PPM_RESET);
> > + if (ret)
> > + return ret;
>
> With a lock held?
Good catch. Thanks.
> > +static int ucsi_acpi_remove(struct platform_device *pdev)
> > +{
> > + struct ucsi *ucsi = platform_get_drvdata(pdev);
> > +
> > + acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev),
> > + ACPI_ALL_NOTIFY, ucsi_acpi_notify);
> > +
> > + /* Disable all notifications */
> > + ucsi_acpi_cmd(ucsi, UCSI_SET_NOTIFICATION_ENABLE);
>
> You remove the handler before you disable notifications?
I'll change the order.
Thanks,
--
heikki
--
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] usb: Add driver for UCSI
On Tue, 2016-04-12 at 14:43 +0300, Heikki Krogerus wrote:
> +static int ucsi_init(struct ucsi *ucsi)
> +{
> + struct ucsi_connector *con;
> + struct ucsi_control ctrl;
> + int ret;
> + int i;
> +
> + atomic_set(&ucsi->event_pending, 0);
> + init_completion(&ucsi->complete);
> + mutex_init(&ucsi->ppm_lock);
> +
> + mutex_lock(&ucsi->ppm_lock);
> +
> + /* Reset */
> + ret = ucsi_acpi_cmd(ucsi, UCSI_PPM_RESET);
> + if (ret)
> + return ret;
With a lock held?
> +static int ucsi_acpi_remove(struct platform_device *pdev)
> +{
> + struct ucsi *ucsi = platform_get_drvdata(pdev);
> +
> + acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev),
> +ACPI_ALL_NOTIFY, ucsi_acpi_notify);
> +
> + /* Disable all notifications */
> + ucsi_acpi_cmd(ucsi, UCSI_SET_NOTIFICATION_ENABLE);
You remove the handler before you disable notifications?
Regards
Oliver
--
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] usb: Add driver for UCSI
On Tue, Apr 12, 2016 at 02:43:36PM +0300, Heikki Krogerus wrote:
> + ucsi.usb_data_role=
Ick, this isn't the 1990's anymore, please don't use module parameters
for anything that is required for a driver. Make it automatic if at all
possible, and if not, then make it at the least, a per-device attribute.
> +struct ucsi {
> + struct device *dev;
> + struct ucsi_data __iomem *data;
> +
> + int status;
> + struct completion complete;
> + struct ucsi_capability cap;
> + struct ucsi_connector *connector;
> +
> + struct mutex ppm_lock;
What does this lock? Document it please.
> + atomic_t event_pending;
Your atomic_t is a poor-man's lock, I don't see why it's even needed.
If you feel you need to keep it around, you better document the heck out
of it proving that you used it correctly everywhere (hint, I saw a few
places it was not used correctly...)
> +};
> +
> +static char data_role[7];
> +module_param_string(usb_data_role, data_role, sizeof(data_role), 0644);
> +MODULE_PARM_DESC(usb_data_role, " USB Data Role - host or device");
Again, don't use module parameters.
> +static void ucsi_acpi_notify(acpi_handle handle, u32 event, void *data)
> +{
> + struct ucsi *ucsi = data;
> + u32 cci = ucsi->data->cci;
> +
> + dev_dbg(ucsi->dev, "%s: cci 0x%x\n", __func__, cci);
Delete all of your debugging code please, that's what ftrace is for.
> + if (!atomic_read(&ucsi->event_pending)) {
> + atomic_inc(&ucsi->event_pending);
Oh look, a bug :(
Again, document it if you think you need it, but really, I think you can
get rid of it entirely.
thanks,
greg k-h
--
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 v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space
Hello.
On 4/12/2016 2:10 PM, changbin...@intel.com wrote:
From: "Du, Changbin"
For DWC3 USB controller, the Global Debug Queue/FIFO Space Available
Register(GDBGFIFOSPACE) can be used to dump FIFO/Queue available space.
Space needed before (.
This can be used to check some special issues, like whether data is
successfully copied from memory to fifo when a trb is blocked.
Signed-off-by: Du, Changbin
---
v4:
Do not fail silently, but print error.
[...]
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 615d4dc..83e5bc1 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
[...]
@@ -642,10 +681,15 @@ void dwc3_debugfs_init(struct dwc3 *dwc)
dwc->regset->nregs = ARRAY_SIZE(dwc3_regs);
dwc->regset->base = dwc->regs;
+
Why?
file = debugfs_create_regset32("regdump", S_IRUGO, root, dwc->regset);
if (!file)
dev_err(dwc->dev, "Can't create debugfs regdump\n");
+ file = debugfs_create_file("fifo", S_IRUGO, root, dwc, &dwc3_fifo_fops);
+ if (!file)
+ dev_err(dwc->dev, "Can't create debugfs fifo\n");
+
if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
dwc, &dwc3_mode_fops);
MBR, 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
[PATCH] usb: Add driver for UCSI
USB Type-C Connector System Software Interface (UCSI) is specification that defines the registers and data structures that can be used to control USB Type-C ports on a system. UCSI is used on several Intel Broxton SoC based platforms. Things that UCSI can be used to control include at least USB Data Role swapping, Power Role swapping and controlling of Alternate Modes on top of providing general details about the port and the partners that are attached to it. The initial purpose of the UCSI driver is to allow the user to define a preferred USB Data Role - Host or Device - which will be used on the port in cases where both the USB Type-C port on the running system and the partner are Dual Role capable. In those cases with USB Type-C ports the role will get selected randomly. Most mobile systems will want to use USB in peripheral (device) mode by default, and in many cases Desktop systems, Linux distributions etc., want to use USB in Host mode. The preferred data role is delivered to the driver with a simple module parameter "usb_data_role". The goal is to integrate the driver later to an USB Type-C framework for Linux kernel, and at the same time add support for more extensive USB Type-C port control that UCSI offers, for example Power Role swapping, Alternate Mode control etc. The UCSI specification is public can be obtained from here: http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html Signed-off-by: Heikki Krogerus --- Documentation/kernel-parameters.txt | 13 ++ drivers/usb/misc/Kconfig| 24 ++ drivers/usb/misc/Makefile | 1 + drivers/usb/misc/ucsi.c | 430 drivers/usb/misc/ucsi.h | 198 + 5 files changed, 666 insertions(+) create mode 100644 drivers/usb/misc/ucsi.c create mode 100644 drivers/usb/misc/ucsi.h Hi guys, I'm not going to be able to give any users for the USB Type-C Class yet so I'm proposing this separated UCSI driver for now. It will provide control over the USB data role and nothing else at this point. We would need the driver to support the Broxton SoC based products that are coming soon to the market. With the mobile products, being able to control the data role is important. The default mode should really be device mode with those. That is what the user will expect. The user will definitely not like it if he/she has to unplug/replug the cable in order to attempt to get the USB into device mode so he/she can charge his/her phone or tablet. Thanks, diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f4109de..53c4bee 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -4039,6 +4039,19 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ,,, See also Documentation/input/joystick-parport.txt + ucsi.usb_data_role= + [USB] On dual role capable systems, select the preferred + USB Data Role for the USB Type-C ports - host or device. + + After connection to an other dual role capable system, + if the partner gets the preferred role, UCSI driver + executes data role swap as defined in USB Type-C + specification. + + On desktop systems host role is often preferred, and on + mobile systems device role is usually preferred as the + default data role. + udbg-immortal [PPC] When debugging early kernel crashes that happen after console_init() and before a proper console driver takes over, this boot options might diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig index f7a7fc2..7cd5cbc 100644 --- a/drivers/usb/misc/Kconfig +++ b/drivers/usb/misc/Kconfig @@ -268,3 +268,27 @@ config USB_CHAOSKEY To compile this driver as a module, choose M here: the module will be called chaoskey. + +config UCSI + tristate "USB Type-C Connector System Software Interface driver" + depends on ACPI + help + USB Type-C Connector System Software Interface (UCSI) is a + specification for an interface that allows the Operating System to + control the USB Type-C ports on a system. Things the need controlling + include the USB Data Role (host or device), and when USB Power + Delivery is supported, the Power Role (source or sink). With USB + Type-C Connectors, when two Dual Role capable devices are attached + together, the Data Role is selected randomly. Therefore it is + important to give the OS a way to select the role. Otherwise the user + would have to unplug and replug in order in order to attempt to swap + the Data and Power R
[PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space
From: "Du, Changbin"
For DWC3 USB controller, the Global Debug Queue/FIFO Space Available
Register(GDBGFIFOSPACE) can be used to dump FIFO/Queue available space.
This can be used to check some special issues, like whether data is
successfully copied from memory to fifo when a trb is blocked.
Signed-off-by: Du, Changbin
---
v4:
Do not fail silently, but print error.
---
drivers/usb/dwc3/core.h| 5 +
drivers/usb/dwc3/debugfs.c | 44
2 files changed, 49 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 6254b2f..899cf76 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -348,6 +348,11 @@
#define DWC3_DSTS_LOWSPEED (2 << 0)
#define DWC3_DSTS_FULLSPEED1 (3 << 0)
+/* Global Debug Queue/FIFO Space Available Register */
+#define DWC3_GDBGFIFOSPACE_NUM(x) (((x) << 0) & 0x1F)
+#define DWC3_GDBGFIFOSPACE_TYPE(x) (((x) << 5) & 0xE0)
+#define DWC3_GDBGFIFOSPACE_GET_SPACE(x)(((x) >> 16) & 0x)
+
/* Device Generic Command Register */
#define DWC3_DGCMD_SET_LMP 0x01
#define DWC3_DGCMD_SET_PERIODIC_PAR0x02
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 615d4dc..83e5bc1 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -426,6 +426,45 @@ static const struct file_operations dwc3_mode_fops = {
.release= single_release,
};
+static int dwc3_fifo_show(struct seq_file *s, void *unused)
+{
+ struct dwc3 *dwc = s->private;
+ unsigned long flags;
+ unsigned inttype, index;
+ const char *name;
+ u32 reg;
+
+ static const char * const fifo_names[] = {
+ "TxFIFO", "RxFIFO", "TxReqQ", "RxReqQ", "RxInfoQ",
+ "DescFetchQ", "EventQ", "ProtocolStatusQ"};
+ spin_lock_irqsave(&dwc->lock, flags);
+ for (type = 0; type < 8; type++) {
+ name = fifo_names[type];
+ for (index = 0; index < 32; index++) {
+ dwc3_writel(dwc->regs, DWC3_GDBGFIFOSPACE,
+ DWC3_GDBGFIFOSPACE_NUM(index) |
+ DWC3_GDBGFIFOSPACE_TYPE(type));
+ reg = dwc3_readl(dwc->regs, DWC3_GDBGFIFOSPACE);
+ seq_printf(s, "%s%02d = %d\n", name, index,
+ DWC3_GDBGFIFOSPACE_GET_SPACE(reg));
+ }
+ }
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ return 0;
+}
+
+static int dwc3_fifo_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, dwc3_fifo_show, inode->i_private);
+}
+
+static const struct file_operations dwc3_fifo_fops = {
+ .open = dwc3_fifo_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
static int dwc3_testmode_show(struct seq_file *s, void *unused)
{
struct dwc3 *dwc = s->private;
@@ -642,10 +681,15 @@ void dwc3_debugfs_init(struct dwc3 *dwc)
dwc->regset->nregs = ARRAY_SIZE(dwc3_regs);
dwc->regset->base = dwc->regs;
+
file = debugfs_create_regset32("regdump", S_IRUGO, root, dwc->regset);
if (!file)
dev_err(dwc->dev, "Can't create debugfs regdump\n");
+ file = debugfs_create_file("fifo", S_IRUGO, root, dwc, &dwc3_fifo_fops);
+ if (!file)
+ dev_err(dwc->dev, "Can't create debugfs fifo\n");
+
if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
dwc, &dwc3_mode_fops);
--
2.5.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 v4 0/2] Add a new debugfs entry to dump FIFO/Queue available space
From: "Du, Changbin" FIFO/Queue available space info can be used to debug dwc3 issues. First we remove unnecessary checking for debugfs api call, then add the new entry. Du, Changbin (2): usb: dwc3: make dwc3_debugfs_init return value be void usb: dwc3: add debugfs node to dump FIFO/Queue available space drivers/usb/dwc3/core.c| 10 + drivers/usb/dwc3/core.h| 5 +++ drivers/usb/dwc3/debug.h | 6 +-- drivers/usb/dwc3/debugfs.c | 98 +- 4 files changed, 72 insertions(+), 47 deletions(-) -- 2.5.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 v4 1/2] usb: dwc3: make dwc3_debugfs_init return value be void
From: "Du, Changbin"
Debugfs init failure is not so important. We can continue our job on
this failure. Also no break need for debugfs_create_file call failure.
Signed-off-by: Du, Changbin
---
v4:
Do not fail silently, but print error.
---
drivers/usb/dwc3/core.c| 10 +
drivers/usb/dwc3/debug.h | 6 ++---
drivers/usb/dwc3/debugfs.c | 56 +-
3 files changed, 24 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 17fd814..30f825c 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1062,19 +1062,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret)
goto err5;
- ret = dwc3_debugfs_init(dwc);
- if (ret) {
- dev_err(dev, "failed to initialize debugfs\n");
- goto err6;
- }
-
+ dwc3_debugfs_init(dwc);
pm_runtime_allow(dev);
return 0;
-err6:
- dwc3_core_exit_mode(dwc);
-
err5:
dwc3_event_buffers_cleanup(dwc);
diff --git a/drivers/usb/dwc3/debug.h b/drivers/usb/dwc3/debug.h
index 07fbc2d..71e3180 100644
--- a/drivers/usb/dwc3/debug.h
+++ b/drivers/usb/dwc3/debug.h
@@ -217,11 +217,11 @@ static inline const char
*dwc3_gadget_event_type_string(u8 event)
void dwc3_trace(void (*trace)(struct va_format *), const char *fmt, ...);
#ifdef CONFIG_DEBUG_FS
-extern int dwc3_debugfs_init(struct dwc3 *);
+extern void dwc3_debugfs_init(struct dwc3 *);
extern void dwc3_debugfs_exit(struct dwc3 *);
#else
-static inline int dwc3_debugfs_init(struct dwc3 *d)
-{ return 0; }
+static inline void dwc3_debugfs_init(struct dwc3 *d)
+{ }
static inline void dwc3_debugfs_exit(struct dwc3 *d)
{ }
#endif
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..615d4dc 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -618,24 +618,24 @@ static const struct file_operations dwc3_link_state_fops
= {
.release= single_release,
};
-int dwc3_debugfs_init(struct dwc3 *dwc)
+void dwc3_debugfs_init(struct dwc3 *dwc)
{
struct dentry *root;
- struct dentry *file;
- int ret;
+ struct dentry *file;
root = debugfs_create_dir(dev_name(dwc->dev), NULL);
- if (!root) {
- ret = -ENOMEM;
- goto err0;
+ if (IS_ERR_OR_NULL(root)) {
+ if (!root)
+ dev_err(dwc->dev, "Can't create debugfs root\n");
+ return;
}
-
dwc->root = root;
dwc->regset = kzalloc(sizeof(*dwc->regset), GFP_KERNEL);
if (!dwc->regset) {
- ret = -ENOMEM;
- goto err1;
+ dev_err(dwc->dev, "Failed to alloc regset\n");
+ debugfs_remove_recursive(root);
+ return;
}
dwc->regset->regs = dwc3_regs;
@@ -643,44 +643,28 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
dwc->regset->base = dwc->regs;
file = debugfs_create_regset32("regdump", S_IRUGO, root, dwc->regset);
- if (!file) {
- ret = -ENOMEM;
- goto err1;
- }
+ if (!file)
+ dev_err(dwc->dev, "Can't create debugfs regdump\n");
if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
file = debugfs_create_file("mode", S_IRUGO | S_IWUSR, root,
dwc, &dwc3_mode_fops);
- if (!file) {
- ret = -ENOMEM;
- goto err1;
- }
+ if (!file)
+ dev_err(dwc->dev, "Can't create debugfs mode\n");
}
if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE) ||
IS_ENABLED(CONFIG_USB_DWC3_GADGET)) {
file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root,
dwc, &dwc3_testmode_fops);
- if (!file) {
- ret = -ENOMEM;
- goto err1;
- }
-
- file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
root,
- dwc, &dwc3_link_state_fops);
- if (!file) {
- ret = -ENOMEM;
- goto err1;
- }
- }
+ if (!file)
+ dev_err(dwc->dev, "Can't create debugfs testmode\n");
- return 0;
-
-err1:
- debugfs_remove_recursive(root);
-
-err0:
- return ret;
+ file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
+ root, dwc, &dwc3_link_state_fops);
+ if (!file)
+ dev_err(dwc->dev, "Can't create debugfs link_state\n");
+ }
}
void dwc3_debugfs_exit(struct dwc3 *dwc)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubs
[PATCH v2 2/2] USB: uas: Add a new NO_REPORT_LUNS quirk
Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
an usb-id of: 0bc2:331a, as these will fail to respond to a
REPORT_LUNS command.
Cc: sta...@vger.kernel.org
Reported-and-tested-by: David Webb
Signed-off-by: Hans de Goede
---
Changes in v2:
-Document new j quirk in Documentation/kernel-parameters.txt
---
Documentation/kernel-parameters.txt | 2 ++
drivers/usb/storage/uas.c | 14 +-
drivers/usb/storage/unusual_uas.h | 7 +++
drivers/usb/storage/usb.c | 5 -
include/linux/usb_usual.h | 2 ++
5 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index ecc74fa..0b3de80 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -4077,6 +4077,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
sector if the number is odd);
i = IGNORE_DEVICE (don't bind to this
device);
+ j = NO_REPORT_LUNS (don't use report luns
+ command, uas only);
l = NOT_LOCKABLE (don't try to lock and
unlock ejectable media);
m = MAX_SECTORS_64 (don't transfer more
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index b1ec749..16bc679 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -2,7 +2,7 @@
* USB Attached SCSI
* Note that this is not the same as the USB Mass Storage driver
*
- * Copyright Hans de Goede for Red Hat, Inc. 2013 - 2014
+ * Copyright Hans de Goede for Red Hat, Inc. 2013 - 2016
* Copyright Matthew Wilcox for Intel Corp, 2010
* Copyright Sarah Sharp for Intel Corp, 2010
*
@@ -781,6 +781,17 @@ static int uas_eh_bus_reset_handler(struct scsi_cmnd *cmnd)
return SUCCESS;
}
+static int uas_target_alloc(struct scsi_target *starget)
+{
+ struct uas_dev_info *devinfo = (struct uas_dev_info *)
+ dev_to_shost(starget->dev.parent)->hostdata;
+
+ if (devinfo->flags & US_FL_NO_REPORT_LUNS)
+ starget->no_report_luns = 1;
+
+ return 0;
+}
+
static int uas_slave_alloc(struct scsi_device *sdev)
{
struct uas_dev_info *devinfo =
@@ -831,6 +842,7 @@ static struct scsi_host_template uas_host_template = {
.module = THIS_MODULE,
.name = "uas",
.queuecommand = uas_queuecommand,
+ .target_alloc = uas_target_alloc,
.slave_alloc = uas_slave_alloc,
.slave_configure = uas_slave_configure,
.eh_abort_handler = uas_eh_abort_handler,
diff --git a/drivers/usb/storage/unusual_uas.h
b/drivers/usb/storage/unusual_uas.h
index ccc113e..53341a7 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -64,6 +64,13 @@ UNUSUAL_DEV(0x0bc2, 0x3312, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_ATA_1X),
+/* Reported-by: David Webb */
+UNUSUAL_DEV(0x0bc2, 0x331a, 0x, 0x,
+ "Seagate",
+ "Expansion Desk",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_REPORT_LUNS),
+
/* Reported-by: Hans de Goede */
UNUSUAL_DEV(0x0bc2, 0x3320, 0x, 0x,
"Seagate",
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index 43576ed..9de988a 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -482,7 +482,7 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
US_FL_NO_READ_DISC_INFO | US_FL_NO_READ_CAPACITY_16 |
US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES |
- US_FL_MAX_SECTORS_240);
+ US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS);
p = quirks;
while (*p) {
@@ -532,6 +532,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
case 'i':
f |= US_FL_IGNORE_DEVICE;
break;
+ case 'j':
+ f |= US_FL_NO_REPORT_LUNS;
+ break;
case 'l':
f |= US_FL_NOT_LOCKABLE;
break;
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 7f5f78b..245f57d 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -79,6 +79,8 @@
/* Cannot handle MI_REPORT_SUPPORTED_OPERATION_CODES */ \
US_FLAG(MAX_SECTORS_240,0x0800) \
/* Sets max_sectors to 240 */ \
+ US_FLAG(NO_REPORT_LUNS, 0x1000) \
+
[PATCH v2 1/2] USB: uas: Limit qdepth at the scsi-host level
Commit 64d513ac31bd ("scsi: use host wide tags by default") causes
the SCSI core to queue more commands then we can handle on devices with
multiple LUNs, limit the queue depth at the scsi-host level instead of
per slave to fix this.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1315013
Cc: sta...@vger.kernel.org # 4.4.x and 4.5.x
Signed-off-by: Hans de Goede
---
Changes in v2:
-Fix some spelling issues in the commit message and in a comment
---
drivers/usb/storage/uas.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 13e4cc3..b1ec749 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -824,7 +824,6 @@ static int uas_slave_configure(struct scsi_device *sdev)
if (devinfo->flags & US_FL_BROKEN_FUA)
sdev->broken_fua = 1;
- scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
return 0;
}
@@ -956,6 +955,12 @@ static int uas_probe(struct usb_interface *intf, const
struct usb_device_id *id)
if (result)
goto set_alt0;
+ /*
+* 1 tag is reserved for untagged commands +
+* 1 tag to avoid off by one errors in some bridge firmwares
+*/
+ shost->can_queue = devinfo->qdepth - 2;
+
usb_set_intfdata(intf, shost);
result = scsi_add_host(shost, &intf->dev);
if (result)
--
2.7.3
--
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 1/2] dt/bindings/usb: Add bindings for PIC32 MUSB driver.
On 04/11/2016 08:40 PM, Rob Herring wrote:
> On Thu, Apr 07, 2016 at 06:02:59PM +0530, Purna Chandra Mandal wrote:
>> Document devicetree binding for the USB controller
>> and USB Phy found on Microchip PIC32 class devices.
>>
>> Signed-off-by: Purna Chandra Mandal
>>
>> ---
>>
>> Changes in v2: None
>>
>> .../bindings/usb/microchip,pic32-musb.txt | 67
>> ++
>> 1 file changed, 67 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/usb/microchip,pic32-musb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/microchip,pic32-musb.txt
>> b/Documentation/devicetree/bindings/usb/microchip,pic32-musb.txt
>> new file mode 100644
>> index 000..e1cec9d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/microchip,pic32-musb.txt
>> @@ -0,0 +1,67 @@
>> +Microchip PIC32 MUSB DRC/OTG controller
>> +---
>> +
>> +Required properties:
>> + - compatible : should be "microchip,pic32mzda-usb".
>> + - reg : offset and length of "MUSB Core Registers" and
>> + "USB Clock & Reset Registers".
>> + - reg-names: should be "mc", and "usbcr" in order
>> + - clocks : clock specifier for the musb controller clock
>> + - clock-names : should be "usb_clk"
>> + - interrupts : interrupt number for MUSB Core General interrupt
>> + and DMA interrupt
>> + - interrupt-names : must be "mc" and "dma" in order.
>> + - phys : phy specifier for the otg phy.
>> + - dr_mode : should be one of "host", "peripheral" or "otg".
>> + - mentor,multipoint: Should be "1" indicating the musb controller supports
>> + multipoint. This is MUSB configuration-specific
>> setting.
>> + - mentor,num-eps : Specifies the number of endpoints. This is also a
>> + MUSB configuration-specific setting. Should be set to
>> "8".
>> + - mentor,ram-bits : Specifies the ram address size. Should be set to "11".
>> + - mentor,power : Should be "500". This signifies the controller can
>> supply
>> + up to 500mA when operating in host mode.
>> + - phys : phandle of the USB phy.
>> + - usb_overcurrent : phandle to MUSB over-current note. It should have
>> + interrupt number for over-current detection logic.
> This node is only an interrupt? Then you should use interrupts-extended
> and make this interrupt the 3rd one. interrupts-extended will let you
> have different interrupt parents for each irq.
Will use 'interrupts-extended' instead.
>> +
>> +Optional properties:
>> + - microchip,fifo-mode: Specifies layout of internal SRAM for end-point
>> fifos.
>> +Should be 0 (default) or 1.
> Make this a boolean.
ack.
>> +
>> +Example:
>> +aliases {
>> +usb1 = &usb1;
>> +phy1 = &usb1_phy;
>> +};
>> +
>> +usb1: hsusb1_core@1f8e3000 {
>> +compatible = "microchip,pic32mzda-usb";
>> +reg = <0x1f8e3000 0x1000>,
>> + <0x1f884000 0x1000>;
>> +reg-names = "mc", "usbcr";
>> +interrupts = <132 IRQ_TYPE_EDGE_RISING>,
>> + <133 IRQ_TYPE_LEVEL_HIGH>;
>> +interrupt-names = "mc", "dma";
>> +dr_mode = "host";
>> +mentor,multipoint = <1>;
>> +mentor,num-eps = <8>;
>> +mentor,ram-bits = <11>;
>> +mentor,power = <500>;
>> +phys = <&usb1_phy>;
>> +clocks = <&rootclk PB5CLK>;
>> +clock-names = "usb_clk";
>> +usb_overcurrent = <&usb1_overcurrent>;
>> +};
>> +
>> +usb1_phy: hsusb1_phy@1f8e4000 {
>> +compatible = "usb-nop-xceiv";
>> +reg = <0x1f8e4000 0x1000>;
>> +clocks = <&rootclk UPLLCLK>;
>> +clock-names = "main_clk";
>> +clock-frequency = <2400>;
>> +};
>> +
>> +usb1_overcurrent: hsusb1_oc@0 {
>> +interrupt-parent = <&gpio1>;
>> +interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
>> +};
>> --
>> 1.8.3.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v3] usb: dwc3: fix memory leak of dwc->regset
Hi,
changbin...@intel.com writes:
> From: "Du, Changbin"
>
> dwc->regset is allocated on dwc3_debugfs_init, and should
> be released on init failure or dwc3_debugfs_exit. Btw,
> The line "dwc->root = NULL" is unnecessary, so remove it.
>
> Signed-off-by: Du, Changbin
> ---
I've modifed the patch a little bit just to make sure the error labels
are easy to follow:
commit c7232c5fdcc5e1b6fc39b498b58573553ebb43da
Author: Du, Changbin
Date: Tue Apr 12 16:24:34 2016 +0800
usb: dwc3: fix memory leak of dwc->regset
dwc->regset is allocated on dwc3_debugfs_init, and should
be released on init failure or dwc3_debugfs_exit. Btw,
The line "dwc->root = NULL" is unnecessary, so remove it.
Signed-off-by: Du, Changbin
[ felipe.ba...@linux.intel.com : add another err label for the new
error condition ]
Signed-off-by: Felipe Balbi
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe1b6a7..cebf9e38b60a 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -645,7 +645,7 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
file = debugfs_create_regset32("regdump", S_IRUGO, root, dwc->regset);
if (!file) {
ret = -ENOMEM;
- goto err1;
+ goto err2;
}
if (IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)) {
@@ -653,7 +653,7 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
dwc, &dwc3_mode_fops);
if (!file) {
ret = -ENOMEM;
- goto err1;
+ goto err2;
}
}
@@ -663,19 +663,22 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
dwc, &dwc3_testmode_fops);
if (!file) {
ret = -ENOMEM;
- goto err1;
+ goto err2;
}
file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
root,
dwc, &dwc3_link_state_fops);
if (!file) {
ret = -ENOMEM;
- goto err1;
+ goto err2;
}
}
return 0;
+err2:
+ kfree(dwc->regset);
+
err1:
debugfs_remove_recursive(root);
@@ -686,5 +689,5 @@ err0:
void dwc3_debugfs_exit(struct dwc3 *dwc)
{
debugfs_remove_recursive(dwc->root);
- dwc->root = NULL;
+ kfree(dwc->regset);
}
patch is longer but functionally equivalent.
--
balbi
signature.asc
Description: PGP signature
[PATCH v3] usb: dwc3: fix memory leak of dwc->regset
From: "Du, Changbin"
dwc->regset is allocated on dwc3_debugfs_init, and should
be released on init failure or dwc3_debugfs_exit. Btw,
The line "dwc->root = NULL" is unnecessary, so remove it.
Signed-off-by: Du, Changbin
---
v3:
remove unnecessary if(!NULL) for free
v2:
Title changed;
free dwc->regset on failure path.
---
drivers/usb/dwc3/debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..07d99eb 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -678,7 +678,7 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
err1:
debugfs_remove_recursive(root);
-
+ kfree(dwc->regset);
err0:
return ret;
}
@@ -686,5 +686,5 @@ err0:
void dwc3_debugfs_exit(struct dwc3 *dwc)
{
debugfs_remove_recursive(dwc->root);
- dwc->root = NULL;
+ kfree(dwc->regset);
}
--
2.5.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 3/3] usb: dwc3: gadget: Fix suspend/resume during device mode
Gadget controller might not be always active during system
suspend/resume as gadget driver might not have yet been loaded or
might have been unloaded prior to system suspend.
Check if we're active and only then perform
necessary actions during suspend/resume.
Signed-off-by: Roger Quadros
---
drivers/usb/dwc3/gadget.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 3ac170f..efbb801 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2931,6 +2931,9 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
int dwc3_gadget_suspend(struct dwc3 *dwc)
{
+ if (!dwc->gadget_driver)
+ return 0;
+
if (dwc->pullups_connected) {
dwc3_gadget_disable_irq(dwc);
dwc3_gadget_run_stop(dwc, true, true);
@@ -2949,6 +2952,9 @@ int dwc3_gadget_resume(struct dwc3 *dwc)
struct dwc3_ep *dep;
int ret;
+ if (!dwc->gadget_driver)
+ return 0;
+
/* Start with SuperSpeed Default */
dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512);
--
2.5.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
Re: [PATCH v2] usb: dwc3: fix memory leak of dwc->regset
Hi, changbin...@intel.com writes: > From: "Du, Changbin" > > dwc->regset is allocated on dwc3_debugfs_init, and should > be released on init failure or dwc3_debugfs_exit. Btw, > The line "dwc->root = NULL" is unnecessary, so remove it. > > Signed-off-by: Du, Changbin > --- > v2: > Title changed; > free dwc->regset on failure path. > > --- > drivers/usb/dwc3/debugfs.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c > index 9ac37fe..abd8889 100644 > --- a/drivers/usb/dwc3/debugfs.c > +++ b/drivers/usb/dwc3/debugfs.c > @@ -678,7 +678,8 @@ int dwc3_debugfs_init(struct dwc3 *dwc) > > err1: > debugfs_remove_recursive(root); > - > + if (!dwc->regset) > + kfree(dwc->regset); IOW: if regset is NULL, free NULL. This check is wrong and unnecessary ;-) kfree(NULL) is safe. -- balbi signature.asc Description: PGP signature
Re: [PATCH v6 07/10] usb: dwc3: gadget: Fix suspend/resume during dual-role mode
On 12/04/16 11:00, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> On 11/04/16 16:26, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Roger Quadros writes: On 11/04/16 15:23, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> Gadget controller might not be always active during suspend/ >> resume when we are operating in dual-role/otg mode. >> Check if we're active and only if we are then perform >> necessary actions during suspend/resume. > > I don't get this. If we're operating in OTG, we should have a gadget > driver loaded, no ? > At boot gadget driver is not automatically loaded. We're still in OTG mode but OTG state machine hasn't started. System suspend/resume can still happen. User might also load/unload the gadget driver prior to system suspend. >>> >>> good point, this should go in the -rc too. >>> >> But there is no dual-role mode currently so it won't fix any bug yet :). > > this should be a problem even for device-only, right ? > > i) boot-up > ii) modprobe dwc3 > iii) echo mem > /sys/power/state > Indeed. It is applicable for device-only mode as well. I'll send this patch for rc then. cheers, -roger -- 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 v2] usb: dwc3: fix memory leak of dwc->regset
From: "Du, Changbin"
dwc->regset is allocated on dwc3_debugfs_init, and should
be released on init failure or dwc3_debugfs_exit. Btw,
The line "dwc->root = NULL" is unnecessary, so remove it.
Signed-off-by: Du, Changbin
---
v2:
Title changed;
free dwc->regset on failure path.
---
drivers/usb/dwc3/debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..abd8889 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -678,7 +678,8 @@ int dwc3_debugfs_init(struct dwc3 *dwc)
err1:
debugfs_remove_recursive(root);
-
+ if (!dwc->regset)
+ kfree(dwc->regset);
err0:
return ret;
}
@@ -686,5 +687,5 @@ err0:
void dwc3_debugfs_exit(struct dwc3 *dwc)
{
debugfs_remove_recursive(dwc->root);
- dwc->root = NULL;
+ kfree(dwc->regset);
}
--
2.5.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
Re: [PATCH v5 1/2] USB: serial: cp210x: Adding GPIO support for CP2105
On 12/04/16 09:08, Johan Hovold wrote: On Tue, Apr 12, 2016 at 09:01:52AM +0100, Martyn Welch wrote: Johan, Thanks for reviewing the other patch in this series. I haven't seen any feedback regarding this patch, is it still in your queue? It is, and I will get to it. I've managed to gather some review backlog this past month that I need to get through first. No problem, thanks for letting me know. Martyn -- 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] usb: dwc3: free dwc->regset on dwc3_debugfs_exit
Hi, "Du, Changbin" writes: > Hi, Balbi, > >> > Hmm, I agree from this point. I will combine this patch with other two >> patches >> > (due to their dependency). And I'd like remove the 'dwc->root=NULL' as >> well, >> >> you are creating a dependency that doesn't exist. Please stop that. You >> should have two separate branches based on v4.6-rc3 (or, if you prefer, >> one based on my testing/fixes and another based on my testing/next). On >> one branch you have *only* $subject and you fix *all* the memory >> leaks. On the other branch you have the other two patches. >> >> Ignore the fact that we might have a conflict, that's for git (and >> maintainers) to handle when they happen. >> >> Again, don't create dependencies between fixes for the -rc cycle and >> changes for the next merge window. >> > Thanks for dedicated explanation. I was concern about the conflict. yeah, no problem ;-) > Now it is very clear for me to handle such situation. good :-) glad we could sort it out. -- balbi signature.asc Description: PGP signature
Re: [PATCH v5 1/2] USB: serial: cp210x: Adding GPIO support for CP2105
On Tue, Apr 12, 2016 at 09:01:52AM +0100, Martyn Welch wrote: > Johan, > > Thanks for reviewing the other patch in this series. I haven't seen any > feedback regarding this patch, is it still in your queue? It is, and I will get to it. I've managed to gather some review backlog this past month that I need to get through first. Thanks, Johan -- 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 v6 07/10] usb: dwc3: gadget: Fix suspend/resume during dual-role mode
Hi, Roger Quadros writes: > On 11/04/16 16:26, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros writes: >>> On 11/04/16 15:23, Felipe Balbi wrote: Hi, Roger Quadros writes: > Gadget controller might not be always active during suspend/ > resume when we are operating in dual-role/otg mode. > Check if we're active and only if we are then perform > necessary actions during suspend/resume. I don't get this. If we're operating in OTG, we should have a gadget driver loaded, no ? >>> At boot gadget driver is not automatically loaded. We're still in OTG mode >>> but OTG state machine hasn't started. >>> System suspend/resume can still happen. >>> >>> User might also load/unload the gadget driver prior to system suspend. >> >> good point, this should go in the -rc too. >> > But there is no dual-role mode currently so it won't fix any bug yet :). this should be a problem even for device-only, right ? i) boot-up ii) modprobe dwc3 iii) echo mem > /sys/power/state -- balbi signature.asc Description: PGP signature
Re: [PATCH v5 1/2] USB: serial: cp210x: Adding GPIO support for CP2105
Johan,
Thanks for reviewing the other patch in this series. I haven't seen any
feedback regarding this patch, is it still in your queue?
Martyn
On 29/03/16 17:47, Martyn Welch wrote:
This patch adds support for the GPIO found on the CP2105. Unlike the GPIO
provided by some of the other devices supported by the cp210x driver, the
GPIO on the CP2015 is muxed on pins otherwise used for serial control
lines. The GPIO have been configured in 2 separate banks as the choice to
configure the pins for GPIO is made separately for pins shared with each
of the 2 serial ports this device provides, though the choice is made for
all pins associated with that port in one go. The choice of whether to use
the pins for GPIO or serial is made by adding configuration to a one-time
programable PROM in the chip and can not be changed at runtime. The device
defaults to GPIO.
This device supports either push-pull or open-drain modes, it doesn't
provide an explicit input mode, though the state of the GPIO can be read
when used in open-drain mode. Like with pin use, the mode is configured in
the one-time programable PROM and can't be changed at runtime.
Signed-off-by: Martyn Welch
---
V2: - Doesn't break build when gpiolib isn't selected.
V3: - Tracking GPIO state so pins no longer get their state changed should
the pin be in open-drain mode and be pulled down externally whilst
another pin is set.
- Reworked buffers and moved to byte accesses to remove the
questionable buffer size logic and byte swapping.
- Added error reporting.
- Removed incorrect/pointless comments.
- Renamed tmp variable to make use clearer.
V4: - Fixed memory leak in cp210x_gpio_get error path.
V5: - Determining shared GPIO based on device type.
- Reordered vendor specific values by value.
- Use interface device for gpio messages.
- Remove unnecessary empty lines.
- Using kzalloc rather than kcalloc.
- Added locking to port_priv->output_state.
- Added dummy cp2105_shared_gpio_init for !CONFIG_GPIOLIB.
- Removed unnecessary masking on u8.
- Added support for use of GPIO pin as RS485 traffic indication or activity
LEDs.
- Use correct dev for GPIO device.
- Set can_sleep.
- Roll in initial configuration state support.
- Print error message & continue if GPIO fails.
- Simplified ifdef'ing.
drivers/usb/serial/cp210x.c | 353 +++-
1 file changed, 349 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index c740592..b1eb8da 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -23,6 +23,9 @@
#include
#include
#include
+#include
+#include
+#include
#define DRIVER_DESC "Silicon Labs CP210x RS232 serial adaptor driver"
@@ -44,10 +47,14 @@ static int cp210x_tiocmset(struct tty_struct *, unsigned
int, unsigned int);
static int cp210x_tiocmset_port(struct usb_serial_port *port,
unsigned int, unsigned int);
static void cp210x_break_ctl(struct tty_struct *, int);
+static int cp210x_attach(struct usb_serial *);
+static void cp210x_release(struct usb_serial *);
static int cp210x_port_probe(struct usb_serial_port *);
static int cp210x_port_remove(struct usb_serial_port *);
static void cp210x_dtr_rts(struct usb_serial_port *p, int on);
+#define CP210X_FEATURE_HAS_SHARED_GPIO BIT(0)
+
static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x045B, 0x0053) }, /* Renesas RX610 RX-Stick */
{ USB_DEVICE(0x0471, 0x066A) }, /* AKTAKOM ACE-1001 cable */
@@ -133,7 +140,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
- { USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
+ { USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA71) }, /* Infinity GPS-MIC-1 Radio Monophone */
{ USB_DEVICE(0x10C4, 0xF001) }, /* Elan Digital Systems USBscope50 */
{ USB_DEVICE(0x10C4, 0xF002) }, /* Elan Digital Systems USBwave12 */
@@ -199,9 +206,20 @@ static const struct usb_device_id id_table[] = {
MODULE_DEVICE_TABLE(usb, id_table);
+struct cp210x_dev_private {
+ u8 partnum;
+};
+
struct cp210x_port_private {
__u8bInterfaceNumber;
boolhas_swapped_line_ctl;
+#ifdef CONFIG_GPIOLIB
+ struct usb_serial *serial;
+ struct gpio_chipgc;
+ struct mutexoutput_lock;
+ unsigned intoutput_state;
+ unsigned int*gpio_map;
+#endif
};
static struct usb_serial_driver cp210x_device = {
@@ -220,6 +238,8 @@ static struct usb_serial_driver c
[PATCH] usb: host: xhci-plat: add firmware for the R-Car M3-W xHCI controllers
This patch adds a firmware for the USB 3.0 host controllers of Renesas
R-Car M3-W SoC.
- This firmware is possible to be used on R-Car H2 and M2. However,
this version causes performance degradation on such SoCs.
- This firmware is impossible to be used on R-Car H3 because data
transfer might not work correctly.
So, we would like to keep the v1 and v2 firmware.
Signed-off-by: Yoshihiro Shimoda
---
WHENCE| 3 ++-
r8a779x_usb3_v3.dlmem | Bin 0 -> 9472 bytes
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 r8a779x_usb3_v3.dlmem
diff --git a/WHENCE b/WHENCE
index c2d83f4..02b46c7 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2922,10 +2922,11 @@ Licence:
--
-Driver: xhci-rcar -- Renesas R-Car H2/M2/H3 USB 3.0 host controller driver
+Driver: xhci-rcar -- Renesas R-Car Gen2/3 USB 3.0 host controller driver
File: r8a779x_usb3_v1.dlmem
File: r8a779x_usb3_v2.dlmem
+File: r8a779x_usb3_v3.dlmem
Licence: Redistributable. See LICENCE.r8a779x_usb3 for details.
diff --git a/r8a779x_usb3_v3.dlmem b/r8a779x_usb3_v3.dlmem
new file mode 100644
index
..eac36a96bee1a8614eef9caa88e5a9de136af30c
GIT binary patch
literal 9472
zcmai44O~=J+J9z-JD0DE%!QeY2nRwwB{K
zD4Ci1rfYs>HkeYmO5m31jV34~)&K>O6o(P~7+pbD-BR(s|8ob#ecSi9{C@v?&b{~C
z=R9BMInQ~9;u*j3Mp7NIzY7#;Wi4;XjLuOsWLNsr{b*C7mr~CYucqgTozEhh{^R~y
z;vS+T2HOp?$LiOfB6?v)tUmHIQGg^i{2qOuk!V3ieSzE5L0Y{>@tLiXt@SPOBxf;E
zcrN-@$=L9oxZiARx2;Ij7m}7V@vjlZ%gTD4C)LZbUMqSBIZC^3^pDz$QG`+K+il|K
zoUE)CDx}B;>vpN(*eD`dshO-vOVTf;lBi+&&3%Xx^|@h0OUc1_f4i^UdWA?Am#Du6
zN-vUarO`e}U&H23NYn>vw6vJa9UQ0O#=ag%y4R9SWH%TEW028$gSvva0iw=m`=i-@
z|0oUh7jq>;W}k{QXrMIFP-14!wKIal-C~6yJ8`HKY|@aldci7j(9}uJ-_~}8Ol5ox(>FZatD9fi
zHHEJcG-8TWD>&P0g)CnS=N58&wL+&*X0$643HCADmA#SI1-oL>RN|VTE#vIUe4Sl6
z5LwA-U^}hkOso~U#&n*J(UYOLSUZM2Z8Tl4XB@COWn~lWTcwV^g1dx%va;gtlT+}<
z(E)a4XTX5?FO@@gWM$#qcjeHR(BKd+8fE2ZGHla8MoYSKb+SQYWRfyJvu@Wk99u~k
z`FTUG)Db8vv3I|>li#0iYyDm)D`9uvJ-;UP#
zebKXWzJ^Kmicyo6l2If0rE7^}d{Et6;vR6sc&$}!P$0f9ShrKdF^PF=aEe{=QvLI?
z5WqTP01yCir>9m)ZtKZwustPX^?o?;pR1)71GTUI$yVc}{Yk
z+JjgbP5o`{`yGk;X7I^Y412d{gs0Xwf@x%#__NI^{Ugw0IB3)OZ18h!a|P8K&2cNh
z*RDobScrv}KYU(;H53z|r6sU>6<4wHvxXvJypMUAHf@=R`O|zCPqZ;_`8lxS?a&5K
zZ4+jnZLuqEU6NjjQ@u-F;|oEBt#MiT9i(eE_V|GdewHO3G&-eOtsX0=#eU({OA6Q3_wH`g4JJk*j#1q`|JNr}_!D_Rk?@g*wuc>c-stql(62J+(p?
z0*fNe5w`ZPFy?|fhWU2UQ1-r1jUZEFSY&!b?N3qrtJHpjRaSmdW!A(WR-U}WzE}o|
zer}uKUw*DC-U|gMgVgojD{DIE_YPUfhOCQBOjb1pwfBWwFX62&?zL`Da@-xe+9WHb
zCKg?6?PexF-Y|VxC4YQrfgKqa%bk>S(_XRz+co-blCjQtIV>JKOxv7E8~XQ+FL*)M$h=LwO>X5
zA+;|nuf}^?I-%|42`om-%C#Y|_B}Gr#JFA=^Ki#(50CaCHgOd^`QW1_wsvP4lhVT}
z*f0y4ik5n%-_$+pCk2UmS9hOjucVu@tUP(o=x@{!J#lz|2+El}B6kSlH~L+i5pnbe
zUF3{BYa2MD-slk52?G$vxdyfi`u}Y08q5*N`z2=k!(~KxE%t}O-OmQ%{cyGK_uzqa
zSgF2cG1c(a8=v*DN7~aBW!ZGc^yQHjQ$Moahzi^n5sHSk^#G*h|dt#6Fh{lUgiyOQABldGC{67$R18wk1cvYsY*SasObFpzr>7<)%
zaD$gY(YWt&h%Mdgd|lTDq4$g3>KDwyy(>xX=1f**4)Ub3$kRMXR-zv0{i^xyS9X3N
z)>7Dmp41YIJ09Dk6Tp)wP0rRn1{SPVrNByD%wmzgBX_1QqH*@t*^T16;z4LtV~4imCL8K(tY0N=7PV8|
zX%(rl8F-UN_9>|jbBMk}sl{$~DFgfLyb-OBV=vH-_L@Qw0iGzRFnE9aU7wWrME&Ss
zrm=2K(Ia|_DK56&aMAn=P94h`9LO2g2_-^3BKqd!dSnU1sR-AX={od(F1eD^B04vP
zITMShYfK&2Zw$LX5ayKj5Tes*7EhQIuJ$5g^wt}5RH{XwXL^)fD;{N(!crqL51|)TniM8YAf9d#TzGnW%z7r{4EEGAG8`P*k#{IqpC8h*;z#CW3Z_uHkHRP%
zSCJxdH6a^)B}L|AC&>Ip-~bRaQRb6@?Gw3pnV%{w?WXX(O2G^o;h`*BAD8*ODKa1V1ZDx6fOnph`RM0zZ6S5Jm=K!-+r(UPvvB&K
zdh&AH&hw~hdK}*fzd!lyqf0G8g+{d&vVw=uW>#%uRngp|C
zM2whz>9n|A{91Hh9UyA3?-dz)Mw&B1s49H`jZgDQ0!Z1A(J@x
z@^NmW8g~Y&UX+EswbPg@uCsL-^TcIludo5DApsdc->yn=gP1J3O*%@EBBcVXhIkEI
z2bOs(KJ3!4bwF8_TrfQTV6Z6>Fyi~U9;#Y2fP`6V<{VFZH|_0dp~%3p(#~?vrn$LbaN*+|
z@ak{J^`Uysnz-Lrov<}Q7l-^dfKxR;3HcF=o&Roam(G>>>UoF+^Fy$9DnkDmlfule|w#?548nZ(|!N>b4WZ^_uB4mqht{xF2DHkzkfq?f__q_LV+1(Ll
z(gK;+=gIt{yfBQ}#oPIoaCYLa^i^DZjeo=O8vhos4%h&^3v2`4cj!GUiEqRn`J7oQ
zaNIY#Uz|V6RAGf>=9l5RCLjJ34tk6E#w`?Bvzda9=sjDhA851a<-TZ+qXf%D3%oL3
z-!JaI(a}kLCt-ie?-$3SmjB*Qbrsvu7P0u%cT#i`n~lvA^FkZ0=`XO^GGD-K$W3~=
z@8PijV#eXvD^3TS!%xqLm=L{~(d(g=znIZFx|q?T7yX=P5z|BkxOH*vi-RSO_?d5#
zcB(e6CT&w%@Hh>vq_y!`vv&^7ne8^`&MqF&gh-nO&E|*>VS%_48A>3$A-dqYjkUK6
z%G9=b#dR~gcdaZl`@bmR7Kluu`GrN0bYbCj;a{IWQ^>emQ^>e0E$pcRu^i@J4!>;=
zKwM>Xs@0LNzwufIr{+c&
zP(AzWY2EnZ4fIU$)q=^$uvzx6mjd7m%w{aAWhLyN;U1ckP&?LZ%uQ%|B1>%Hyh0AH
z4xw!Vsxz)iT=QKUaDB3<4H;nYuClTBjw%}=E9D<-z%|CzHWd1HmEpRvs9@;5qY7-Y
zlKVj$^1sFp%5ZhM3UEy-syE&{itT^a56W=e`#}M&ajtp}`#@0fv{zO@bpr?P(Q3>iy8-(#*MhSFKz4ErK
zZ1e9>$ru@h(_u7fi%JJu+iG^xL5Mf8dJVF*9Q3{y-xMbslF~)&Pd-5_PLxn{`8R*8nr*#d
z73?~T=@c!C(29ntz~QfPAyyex9gmVEkRxWEIrSkrL*|i
zq;cVSclQ2A|MMg~cWazdOOVGUr+&>UmzVGUb+^UP4sQ39t|`&OcYn^H%Boa+Zfp
zHf+X;b08`OsC{m{zo8B_yxw;^pVF}!P5Ch6RO4hr$qYZmHK5qT;TlvJe#xH?`Odam
zZha`-yl&n2hg)@jA*y&gw_Kg!J;EBP#jbi2zaMB4C|NsMRxS_IVwZ0TvPxOy4)HtG
zBwB*XP-&;~*<)vp2v0t&9O|-~ZU?fg)?zA0z1?CW3um-RpDeSEJQT$8Ti$qB*?x19
zTDkUH#$)huxyY;*U=P^lH)z`
z0#)DOU%{Ich0-23WMijG+
Re: [RFC] Change bcdUSB in older kernels to return 0x0310 for SuperSpeed
John Youn writes:
> Hi,
>
> I would like to port the following commit from 4.6 to older kernels.
>
> 1a85329171094951956a37acc8abb7e51c1e742e ("usb: gadget: composite:
> Return bcdUSB 0x0310")
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a85329171094951956a37acc8abb7e51c1e742e
You are of course free to do that. Why do you need it to be in
everybody else's stable kernels?
Ref the current discussion on "security fixes only" stable kernels. It
seems some people think that the current stable rules already allow too
much potentionally harmful stuff. Allowing new features like this isn't
going to help there...
> There is a some concern that revving the bcdUSB to 0x0310 will cause
> problems for SuperSpeed devices based on older kernels that don't
> otherwise have any USB 3.1 specific code.
>
> On the device side I don't think there will be any problems because
> there aren't really any checks against bcdUSB. We just set it to
> 0x0300 (0x0310 for kernel 4.6+) based on if the gadget tells us it
> supports SuperSpeed or higher.
>
> And I don't think there should be any problems for a host connecting
> to these devices since any SuperSpeed capable host should know about
> bcdUSB = 0x03XX. And I don't think the USB spec defines any different
> functionality based solely on 0x0300 vs 0x0310.
Luckily I'm not the one to decide this, but I believe
Documentation/stable_kernel_rules.txt require a lot more than that.
Could you relate this to "fixing a bug" somehow?
> The reason for this backport is that the USB CV tool now checks this
> and ostensibly USB IF certification will require this for "new"
> devices. So if you are basing a new device on a kernel older than 4.6,
> it will not pass CV.
That sounds like a feature to me ;)
Bjørn
--
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 v5 1/4] leds: core: add generic support for RGB Color LED's
On 04/09/2016 06:01 PM, Pavel Machek wrote: Hi! What's tricky about patterns is that you need to control 3 (or more) leds at a time. Problem you are trying to solve here is ... control of 3 leds, at the same time. So let's solve them together. OK, now I've got your point. So we'd need to have a means for defining patterns. The interface could be located at /sys/class/leds/patterns. We'd need to have a flexible way for defining LED class devices involved in a pattern. Since we cannot guarantee no space in a LED class device name, then a single attribute containing space separated list is not an option. We'd have to create a predefined set of attributes that would contain LED class device name. Predefined implies that it would be a fixed number, i.e. either some attributes would always remain unused or, which is even worse, we could run out of free attributes for some use cases. There's a better solution: make pattern behave as a trigger for leds it controls. So we'd have /sys/class/leds/patterns/lp5523 then we'd have /sys/class/leds/lp5523::red/trigger = "lp5523:1" /sys/class/leds/lp5523::green/trigger = "lp5523:2" /sys/class/leds/lp5523::blue/trigger = "lp5523:3" (or something similar, I'd have to boot the n900 to see the exact names). How about implementing patterns as a specific typer of triggers? Let's say we have ledtrig-rgb-pattern: Well, we'd need ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, ... , as we can have more than one rgb led. But yes. Triggers can have many listeners, i.e. led_trigger_event() sets brightness on all LED class devices registered on given trigger. We could have led_trigger_rgb_event() that would set brightness on all groups-of-three LEDs registered on given rgb-trigger. I agree that ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, etc. would be also needed to add a capability of setting different colors on different LED devices. After setting a trigger following sysfs attribute would appear in a LED class device sysfs interface: $cat /sys/class/lp5523::red/rgb_color red green blue [none] $echo "red" > /sys/class/leds/lp5523::red/rgb_color and similarly $echo "green" > /sys/class/leds/lp5523::green/rgb_color $echo "blue" > /sys/class/leds/lp5523::blue/rgb_color Yes, that would work -- selecting channels from the pattern. Similar approach could be applied for blink patterns: There could be additional attributes provided for defining the position in a blink sequence, or/and blink period. For patterns, I'd suggest array of (r g b time) values. Pattern engines can do stuff like "slowly turn LED from off to red, then switch color to white, then slowly turn it to yellow, then turn it off at once" with defined speeds for "slowly" and option of either linear on non-linear brightness ramping. The last option might be a bit too much, but I believe we should support the rest. Yes, that's an interesting idea. It also turns out that trigger based patterns could be also used for defining generic patterns for a group of monochrome LEDs. -- Best regards, Jacek Anaszewski -- 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] usb: host: xhci-plat: add firmware for the R-Car M3 xHCI controllers
Hi Geert-san,
> -Original Message-
> From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com] On
> Behalf Of Geert Uytterhoeven
> Sent: Tuesday, April 12, 2016 3:55 PM
> To: Yoshihiro Shimoda
> Cc: linux-firmw...@kernel.org; USB list ;
> linux-renesas-...@vger.kernel.org
> Subject: Re: [PATCH] usb: host: xhci-plat: add firmware for the R-Car M3 xHCI
> controllers
>
> Hi Shimoda-san,
>
> On Tue, Apr 12, 2016 at 8:42 AM, Yoshihiro Shimoda
> wrote:
> > This patch adds a firmware for the USB 3.0 host controllers of Renesas
> > R-Car M3 SoC.
>
> I guess you mean "R-Car M3-W"?
Thank you for the point. Yes, I mean "R-Car M3-W".
So, I'll fix it.
Best regards,
Yoshihiro Shimoda
> 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
Re: [PATCH 0/7] usb: host: add support for threaded IRQs
Hi, Greg Kroah-Hartman writes: > On Mon, Apr 11, 2016 at 03:44:09PM +0300, Felipe Balbi wrote: >> Hi guys, >> >> this patchset introduces support for threaded IRQs >> for host controllers drivers to use. Right now, only >> XHCI has been converted, but more drivers could >> easily be converted as well. >> >> With this series we can, eventually, spend much less >> time with IRQs disabled. Note that, because we're >> masking XHCI's IRQs, we could run our thread >> handlers with IRQs enabled, but I haven't tested >> that yet. > > Does it really benifit anything? Do you have any measurements? Why the I have measurements showing that it doesn't have a negative impact. > added work for no real need, and increased latency? the latency is negligible. XHCI's irqs are used for completions and aborts, not to start transfers. Also, it's a generally a good idea to spend less time in hardirq context. Not to mention that this is a good stepping stone for further optimization; we could (and probably should) have a per-device-slot irq thread and also per-device-slot locks and demote the controller's lock to only the parts which actually need to access controller-wide resources (for the most part we have slot-specific registers, anyway). Now, the benefit of the work yet to come is that we could be processing N slots concurrently given we have N cpu cores. Note, also, that we're not forcing anybody to use this but given that XHCI has these separate units referred to as 'device slots', we might as well exploit that, right ? -- balbi signature.asc Description: PGP signature
