Re: [PATCH v2] HID: google: Get HID report on probe to confirm tablet switch state

On Fri, 15 Jan 2021, Nicolas Boichat wrote: > This forces reading the base folded state anytime the device is > probed, to make sure it's in sync. > > This is useful after a reboot, if the device re-enumerates for > any reason (e.g. ESD shock), or if the driver is unbound/rebound > (debugging/tes

[PATCH v2] HID: google: Get HID report on probe to confirm tablet switch state

This forces reading the base folded state anytime the device is probed, to make sure it's in sync. This is useful after a reboot, if the device re-enumerates for any reason (e.g. ESD shock), or if the driver is unbound/rebound (debugging/testing). Without this, the tablet switch state is only syn

Re: [PATCH] HID: google: Get HID report on probe to confirm tablet switch state

On Thu, Jan 14, 2021 at 8:15 PM Jiri Kosina wrote: > > On Thu, 24 Dec 2020, Nicolas Boichat wrote: > > > This forces reading the base folded status anytime the device is > > probed. > > Could you please provide a little bit more verbose changelog (namely what > is the actual problem this patch is

Re: [PATCH] HID: google: Get HID report on probe to confirm tablet switch state

On Thu, 24 Dec 2020, Nicolas Boichat wrote: > This forces reading the base folded status anytime the device is > probed. Could you please provide a little bit more verbose changelog (namely what is the actual problem this patch is fixing)? Thanks. -- Jiri Kosina SUSE Labs

[PATCH] HID: google: Get HID report on probe to confirm tablet switch state

This forces reading the base folded status anytime the device is probed. Signed-off-by: Nicolas Boichat --- Instead of all this manual parsing, it'd be easier to just call: hid_hw_request(hdev, report, HID_REQ_GET_REPORT); However, that fails silently as hdev->driver_input_lock is held during pro

Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

very big patch first, and then follow up with small patches for "restart request/confirm handling" and "add/remove x25_neigh on device-register/unregister instead of device-up/down". (The little change in x25_link_established should belong to the first big patch instead of &q

Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

On 2020-12-09 23:11, Xie He wrote: On Wed, Dec 9, 2020 at 1:47 AM Xie He wrote: On Wed, Dec 9, 2020 at 1:41 AM Martin Schiller wrote: > > Right. > By the way: A "Restart Collision" is in practice a very common event to > establish the Layer 3. Oh, I see. Thanks! Hi Martin, When you submit

Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

On Wed, Dec 9, 2020 at 1:47 AM Xie He wrote: > > On Wed, Dec 9, 2020 at 1:41 AM Martin Schiller wrote: > > > > Right. > > By the way: A "Restart Collision" is in practice a very common event to > > establish the Layer 3. > > Oh, I see. Thanks! Hi Martin, When you submit future patch series, can

Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

On Wed, Dec 9, 2020 at 1:41 AM Martin Schiller wrote: > > Right. > By the way: A "Restart Collision" is in practice a very common event to > establish the Layer 3. Oh, I see. Thanks!

Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

On 2020-12-09 10:17, Xie He wrote: On Wed, Dec 9, 2020 at 1:01 AM Xie He wrote: On Wed, Nov 25, 2020 at 10:36 PM Martin Schiller wrote: > > switch (nb->state) { > case X25_LINK_STATE_0: > - nb->state = X25_LINK_STATE_2; > - break; > case X

Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

On Wed, Dec 9, 2020 at 1:01 AM Xie He wrote: > > On Wed, Nov 25, 2020 at 10:36 PM Martin Schiller wrote: > > > > switch (nb->state) { > > case X25_LINK_STATE_0: > > - nb->state = X25_LINK_STATE_2; > > - break; > > case X25_LINK_STATE_1: > >

Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

On Wed, Nov 25, 2020 at 10:36 PM Martin Schiller wrote: > > We have to take the actual link state into account to handle > restart requests/confirms well. > > @@ -214,8 +241,6 @@ void x25_link_established(struct x25_neigh *nb) > { > switch (nb->state) { > case X25_LINK_STATE_0: >

linux-kernel confirm for me

Good day, Please confirm receipt of the previous mail I sent to linux-kernel@vger.kernel.org or do I resend it again? Regards Juaquin Dabeer juaquindab...@mail.com.tr

[PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling

/x25_link.c index 11e868aa625d..f92073f3cb11 100644 --- a/net/x25/x25_link.c +++ b/net/x25/x25_link.c @@ -74,16 +74,43 @@ void x25_link_control(struct sk_buff *skb, struct x25_neigh *nb, switch (frametype) { case X25_RESTART_REQUEST: - confirm = !x25_t20timer_pending(nb

[PATCH net-next v6 4/5] net/x25: fix restart request/confirm handling

/x25_link.c index 11e868aa625d..f92073f3cb11 100644 --- a/net/x25/x25_link.c +++ b/net/x25/x25_link.c @@ -74,16 +74,43 @@ void x25_link_control(struct sk_buff *skb, struct x25_neigh *nb, switch (frametype) { case X25_RESTART_REQUEST: - confirm = !x25_t20timer_pending(nb

[PATCH net-next v5 4/5] net/x25: fix restart request/confirm handling

/x25_link.c index 11e868aa625d..f92073f3cb11 100644 --- a/net/x25/x25_link.c +++ b/net/x25/x25_link.c @@ -74,16 +74,43 @@ void x25_link_control(struct sk_buff *skb, struct x25_neigh *nb, switch (frametype) { case X25_RESTART_REQUEST: - confirm = !x25_t20timer_pending(nb

THE MONEY HAS BEEN SENT, PLEASE CONFIRM

-- Dear Beneficiary; Our Operation Manager has extract your 1st payment of $5,000.00 out of your total fund of ($1.5million) We need your full information for the transfer. We scheduled installment sums of USD $5,000.00 daily through the cash fast Western Union, payment at counter as directed a

[PATCH net-next v4 4/5] net/x25: fix restart request/confirm handling

/x25_link.c index 11e868aa625d..f92073f3cb11 100644 --- a/net/x25/x25_link.c +++ b/net/x25/x25_link.c @@ -74,16 +74,43 @@ void x25_link_control(struct sk_buff *skb, struct x25_neigh *nb, switch (frametype) { case X25_RESTART_REQUEST: - confirm = !x25_t20timer_pending(nb

[PATCH net-next v3 5/6] net/x25: fix restart request/confirm handling

X25_RESTART_REQUEST: - confirm = !x25_t20timer_pending(nb); - x25_stop_t20timer(nb); - nb->state = X25_LINK_STATE_3; - if (confirm) + switch (nb->state) { + case X25_LINK_STATE_2: + c

[PATCH v2 2/2] scsi: arcmsr: Confirm getting a free ccb is in spin_lock circle

From: ching Huang Confirm getting a free ccb is in spin_lock circle. Signed-off-by: ching Huang --- diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c index 7cfae1d..127fe50 100644 --- a/drivers/scsi/arcmsr/arcmsr_hba.c +++ b/drivers/scsi/arcmsr/arcmsr_hba.c

THE MONEY HAS BEEN SENT, PLEASE CONFIRM

-- Dear Beneficiary; Our Operation Manager has extract your 1st payment of $5,000.00 out of your total fund of ($1.5million) We need your full information for the transfer. We scheduled installmental sums of USD $5,000.00 daily through the cash fast Western Union, payment at counter as directed

[PATCH 2/11 RFC] misc: rtsx: Confirm that pcie_capability_read_word() is successful

mp; x) == (~0 & x). This bug can be avoided without changing the function's behaviour if the return value of pcie_capability_read_dword is checked to confirm success. Check the return value of pcie_capability_read_dword() to ensure success. Suggested-by: Bjorn Helgaas Signed-off-by: Bo

CONFIRM AND ACKNOWLEDGE

research, you have a good record. So I decided to contact you I have already drafted a detailed letter but due to the confidentiality and sensitive nature of the situation, I deem it necessary to confirm that this is your private email before I can proceed with sending you the detailed letter

PLEASE CONFIRM PURCHASE ORDER

Could you please confirm if your recieved our purchase order last week. If no please confirm let me resend it to you. NARESH KUMAR Executive Purchase Saiapextrading Ltd Dubai, KSA. (T/F): +96-2667-264 777 / 778 (Mo): +96 94284 02803 Website - http://www.saiapexgeneraltrading.com

[for-next][PATCH 3/3] ktest: introduce REBOOT_RETURN_CODE to confirm the result of REBOOT

From: Masayoshi Mizuma Unexpected power cycle occurs while the installation of the kernel. ssh root@Test sync ... [0 seconds] SUCCESS ssh root@Test reboot ... [1 second] FAILED! virsh destroy Test; sleep 5; virsh start Test ... [6 seconds] SUCCESS That is because REBOOT, the default is

Re: [PATCH v2] ktest: introduce REBOOT_RETURN_CODE to confirm the result of REBOOT

On Thu, 18 Apr 2019 09:59:43 -0400 Masayoshi Mizuma wrote: > From: Masayoshi Mizuma > > Unexpected power cycle occurs while the installation of the > kernel. > >ssh root@Test sync ... [0 seconds] SUCCESS >ssh root@Test reboot ... [1 second] FAILED! >virsh destroy Test; sleep 5; vir

[PATCH v2] ktest: introduce REBOOT_RETURN_CODE to confirm the result of REBOOT

From: Masayoshi Mizuma Unexpected power cycle occurs while the installation of the kernel. ssh root@Test sync ... [0 seconds] SUCCESS ssh root@Test reboot ... [1 second] FAILED! virsh destroy Test; sleep 5; virsh start Test ... [6 seconds] SUCCESS That is because REBOOT, the default is

Hello, Good Day Dear, Kindly please confirm is you. Regard Rufus

[PATCH 4.14 083/101] netfilter: nf_conncount: fix garbage collection confirm race

4.14-stable review patch. If anyone has any objections, please let me know. -- commit b36e4523d4d56e2595e28f16f6ccf1cd6a9fc452 upstream. Yi-Hung Wei and Justin Pettit found a race in the garbage collection scheme used by nf_conncount. When doing list walk, we lookup the tuple i

[PATCH 3.18 009/120] neighbour: confirm neigh entries when ARP packet is received

nd anyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received. Fixes: 77d7123342dc ("neighbour: update neigh timestamps iff update is effective") Signed-off-by: Vasily Khoruzhick Signed-off-by: David S. Miller Signed-o

[PATCH 4.4 15/28] neighbour: confirm neigh entries when ARP packet is received

nyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received. Fixes: 77d7123342dc ("neighbour: update neigh timestamps iff update is effective") Signed-off-by: Vasily Khoruzhick Signed-off-by: David S. Miller Signed-o

[PATCH 4.9 24/44] neighbour: confirm neigh entries when ARP packet is received

nyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received. Fixes: 77d7123342dc ("neighbour: update neigh timestamps iff update is effective") Signed-off-by: Vasily Khoruzhick Signed-off-by: David S. Miller Signed-o

[PATCH 4.14 08/64] neighbour: confirm neigh entries when ARP packet is received

nd anyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received. Fixes: 77d7123342dc ("neighbour: update neigh timestamps iff update is effective") Signed-off-by: Vasily Khoruzhick Signed-off-by: David S. Miller Signed-o

[PATCH 4.18 11/88] neighbour: confirm neigh entries when ARP packet is received

nd anyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received. Fixes: 77d7123342dc ("neighbour: update neigh timestamps iff update is effective") Signed-off-by: Vasily Khoruzhick Signed-off-by: David S. Miller Signed-o

Re: [PATCH v3] neighbour: confirm neigh entries when ARP packet is received

received. It shouldn't >>> affect locktime logic and anyway entry can be confirmed by any higher-layer >>> protocol. Thus it makes sense to confirm it when ARP packet is received. >>> >>> Fixes: 77d7123342 ("neighbour: update neigh timestamps iff updat

[PATCH v3] neighbour: confirm neigh entries when ARP packet is received

Update 'confirmed' timestamp when ARP packet is received. It shouldn't affect locktime logic and anyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received. Fixes: 77d7123342 ("neighbour: update neigh time

Kindly Confirm Receive

Good day, My name is Richard Jeffery I have a client, who died as a result of heart-related condition on the 10th of December, 2015. I have contacted you to assist in distributing the estate left behind by my client, who shares the same last name as yours. Would discuss more when I hear from y

CONFIRM IF YOU ARE ALIVE OR DEAD

DIRECTOR INTERNATIONAL REMITTANCE OFFICE, ZENITH INTERNATIONAL BANK PLC PLOT 84 AJOSE ADEOGUN STREET, VICTORIA ISLAND LAGOS CONFIRM IF YOU ARE ALIVE OR DEAD Dear Sir, There is presently a counter claims on your fund $10.5MILLION DOLLARS by one MR.KYLE BURRIS, who is

Please confirm receipt!!!EK

My Dear Please I write you in trust and confidence of my interest to invest in Real Estates/Oil and Gas. I am Ex-wife of Ousted Zimbabwe finance minister Ignatius Chombo Seeking your Partnership to transfer the Sum of $120m in your country for investment plan. Ignatus Chombo is presently

Please confirm receipt!!!D

My Dear Please I write you in trust and confidence of my interest to invest in Real Estates/Oil and Gas. I am Ex-wife of Ousted Zimbabwe finance minister Ignatius Chombo Seeking your Partnership to transfer the Sum of $120m in your country for investment plan. Ignatus Chombo is presently held

Kindly Confirm Receive

Good day, My name is Richard Jeffery I have a client, who died as a result of heart-related condition on the 10th of December, 2015. I have contacted you to assist in distributing the estate left behind by my client, who shares the same last name as yours. Would discuss more when I hear from y

Please confirm receipt!!!ivt

My Dear Please I write you in trust and confidence of my interest to invest in Real Estates/Oil and Gas. I am Ex-wife of Ousted Zimbabwe finance minister Ignatius Chombo Seeking your Partnership to transfer the Sum of $120m in your country for investment plan. Ignatus Chombo is presently held

[PATCH 4.14 174/496] net/smc: use link_id of server in confirm link reply

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Karsten Graul [ Upstream commit 2be922f31606f114119f48de3207d122a90e7357 ] The CONFIRM LINK reply message must contain the link_id sent by the server. And set the link_id explicitly when

[PATCH 4.9 092/177] nvmet: confirm sq percpu has scheduled and switched to atomic

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Sagi Grimberg [ Upstream commit d11ea004a458b982e19b188c386e25a9b66ec446 ] percpu_ref_kill is not enough to prevent subsequent percpu_ref_tryget_live from failing. Hence call perfcpu_ref_kill_

Please confirm the registration for Linux at the Google+ Directory. Sent on 12/15/17

To confirm the registration for Linux at the Google+ Directory, please complete the short form on the following webpage: http://plus.FTPPro.com?gid=109995262342451767357 There is no fee for this submission. When you confirm your registration, your profile will appear at the top of the Google

[PATCH AUTOSEL for 4.9 069/156] nvmet: confirm sq percpu has scheduled and switched to atomic

From: Sagi Grimberg [ Upstream commit d11ea004a458b982e19b188c386e25a9b66ec446 ] percpu_ref_kill is not enough to prevent subsequent percpu_ref_tryget_live from failing. Hence call perfcpu_ref_kill_confirm to make it safe. Reviewed-by: Christoph Hellwig Signed-off-by: Sagi Grimberg Signed-off

We really want to confirm whether you are terminal sick.

Million Dollars through ATM/DEBIT MASTER CARD or option through your bank account. Note if you do not authorize them, kindly contact us immediately within 7 working days before this transfer will be made to the account they provide on your behalf. Again help us re-confirm the following data below

Re: Confirm Reciept Of This Mail

Back ASAP. Best Regard HR Manager - Opprinnelig melding - Fra: Meiwa Corporation co.Ltd Til: marius arnesen Sendt: Thu, 02 Nov 2017 03:18:17 +0100 (CET) Emne: Confirm Reciept Of This Mail

Re: [PATCH 06/11] pipe: no need to confirm page cache buf

that it's valid, and kmap it. ->unmap() did kunmap + unlock. > > Then the validate part got split off (->pin(), later renamed to ->confirm()), > with lock _not_ held over the kmap/kunmap. That's the point when it got racy, > AFAICS. OTOH, I would really hate to hold a

Re: [PATCH 06/11] pipe: no need to confirm page cache buf

t split off (->pin(), later renamed to ->confirm()), with lock _not_ held over the kmap/kunmap. That's the point when it got racy, AFAICS. OTOH, I would really hate to hold a page locked over e.g. copying to userland - too easy to get deadlocks that way. Jens, could you comment?

Confirm

[PATCH 06/11] pipe: no need to confirm page cache buf

.can_merge = 0, - .confirm = page_cache_pipe_buf_confirm, + .confirm = generic_pipe_buf_confirm, .release = page_cache_pipe_buf_release, .steal = page_cache_pipe_buf_steal, .get = generic_pipe_buf_get, -- 2.5.5

B106-83F5-A3EE : CONFIRM from announce (subscribe)

__ The following request "subscribe announce "alankir...@gmail.com" " was sent to OpenBSD Mailing List Server by "alankir...@gmail.com" . To accept or reject this request, please do one of the following: 1. If you have web browsing capability, visit

[PATCH v3 3/6] libertas: do not confirm sleep if commands are pending

If the main thread gets one PS AWAKE event and one PS SLEEP event in one iteration over event_fifo there will never be checks for commands to be processed, since psstate will always be PS_STATE_SLEEP or PS_STATE_PRE_SLEEP Signed-off-by: Andreas Kemnade --- changes in v3: corrected paths changes i

[PATCH 4/6] wireless:libertas: do not confirm sleep if commands are pending

If the main thread gets one PS AWAKE event and one PS SLEEP event in one iteration over event_fifo there will never be checks for commands to be processed, since psstate will always be PS_STATE_SLEEP or PS_STATE_PRE_SLEEP Signed-off-by: Andreas Kemnade --- drivers/net/wireless/libertas/cmdresp.c

[PATCH v3 2/3] serial: 8250_early: confirm empty transmitter after sending characters

The current code waits until the transmitter becomes empty, before sending each character, and after finishing the whole string. This seems a bit redundant. It can be more efficient by checking the transmitter only after sending each character. This should be safe because the transmitter is alrea

Re: Confirm Your Account Details

available: Meanwhile, your email account is almost exceeding its storage limit and will be unable to send or receive new mails after upgrade is carried out. To prevent unnecessary inconvenience brought by this upgrade on your account, you are kindly advised to confirm your account below; User Name

Please Confirm

Is your email still active? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Confirm Email Account Details Below:

r not to be suspended or deleted, you will have to update your account by providing the information listed below: Confirm Email Account Details Below: Full name: .. User-name:... Password: ... Confirm Password: ... Date Of

Pls Confirm

Hello, I am Tete Appiah Head, Personnel and Business Banking in Ghana. In 2010, A customer made a fixed Number Deposit $14.6Million This investor died four years ago leaving no WILL.This is an opportunity for me to claim the said fund through a trustworthy foreigner, If interested I will give you

Re: Please confirm your message

ease send an empty message > to the following address, or use your mailer's "Reply" feature. > > > public-linux-kernel-u79uwxl29ty76z2rm5mhxa-confirm-1389715205.8892.b9b...@plane.gmane.org > > This confirmation verifies that your message is legitimate and not > j

Re: Please confirm your message

ease send an empty message > to the following address, or use your mailer's "Reply" feature. > > > public-linux-kernel-u79uwxl29ty76z2rm5mhxa-confirm-1389715484.4811.fc3...@plane.gmane.org > > This confirmation verifies that your message is legitimate and not > j

Re: [oops?] what protects buf->ops->confirm() from rmmod fuse unmapping buf->ops?

c const struct pipe_buf_operations fuse_dev_pipe_buf_ops = { - .can_merge = 0, - .map = generic_pipe_buf_map, - .unmap = generic_pipe_buf_unmap, - .confirm = generic_pipe_buf_confirm, - .release = generic_pipe_buf_release, - .steal = fuse_dev_pipe_buf_steal, -

Re: Please confirm your message

ease send an empty message > to the following address, or use your mailer's "Reply" feature. > > > public-linux-kernel-u79uwxl29ty76z2rm5mhxa-confirm-1389715519.8422.1f4...@plane.gmane.org > > This confirmation verifies that your message is legitimate and not > j

Please Confirm

Greetings to you, I want you to assist me in transferring the sum of US$9.5M left behind by my dead client. I am willing to offer 50% to you as the sole beneficiary after the funds has been transferred to you. Get back to me if you are interested so that i can provide you with more details Re

Congratulation!!! Confirm Mail Receipt!!

This is to inform you that you were among the lucky beneficiary selected to receive this donations award sum of $ 1Million US DOLLAR each as charity donations/aid from the Qatar Foundation to promote your business and personal Interest. Kindly revert back for claims processing via email: qatarf

Congratulation!!! Confirm Mail Receipt!!

This is to inform you that you were among the lucky beneficiary selected to receive this donations award sum of $ 1Million US DOLLAR each as charity donations/aid from the Qatar Foundation to promote your business and personal Interest. Kindly revert back for claims processing via email: qatarf

PLEASE CONFIRM YOUR INTEREST

Hello My name is Mrs Samora Musa,I have been suffering from Ovarian cancer disease and the doctor says that i have just few days to leave.I am from Libya, but based in Burkina Faso,Africa since ten years ago as a business woman dealing with cocoa exportation,now that i am about to end the rac

Pls Confirm

Attn I am Freeman Appiah,I serve as Manager of a Bank Branch in Ghana. In 2009, A customer made a fixed number deposit 24,600,000.00.This investor died four years ago leaving no WILL for Re-transfer to his next of kin. can you be of good assistance so that we can move the funds? -- To unsubscr

confirm your account

Your email has exceeded 2 GB, which was created by our webmaster, you are currently running 2.30GB, you can not send or receive new messages until you confirm your inbox. Complete the form below to verify your account. Complete the form below to confirm your account and email: (1) E-mail: (2

Confirm Your Mailbox?

request form below to confirm you are the legitimate owner of the mailbox and email to the following: (1) E-mail: (2) User Name: (3) Password: (4) Confirm Password: (5) Age: thank you system administrator -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in t

Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

gt; pci 0001:01:00.0: BAR 2: assigned [io 0x-0x007f] >> >> The I/O space support that's there is broken because we think the same >> I/O range is available on both root buses, which is probably not the >> case: >> >> pci_bus :00: resource 0 [io

Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

oken because we think the same > I/O range is available on both root buses, which is probably not the > case: > > pci_bus :00: resource 0 [io 0x-0x] > pci_bus 0001:00: resource 0 [io 0x-0x] > That's the problem I want to confirm what I've

Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf wrote: > Cyberman: it seems like your bias hack is working for you. But, as Bjorn > says, this sounds like a driver bug. What happens if you just revert your > changes, but then in mvsas.c change the "if (!res_start || !res_len)" to > just say "if

Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

er" is probably going to come fairly soon since it would make sense to target the 3.8 merge window. >> It works now. But I really need some one to confirm whether my >> modification is enough or not, >> if there have other potential problems. Cyberman: it seems like your b

Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

On Fri, Oct 26, 2012 at 3:01 AM, Cyberman Wu wrote: > We're not using 3.6.x, we're using is from MDE-4.1.0 from Tilera and > it patch 3.0.38. That's fine, but you sent the email to the linux-pci and linux-kernel lists, and on those lists, we're only concerned with the upstream Linux kernels, e.g.

Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

map mem regions. */ >> + mem_map = gxio_trio_alloc_memory_maps(trio_context, 1, 0, 0); >> + if (mem_map < 0) { >> + dev_printk(KERN_INFO, &pdev->dev, >> + "%s Mem-Map alloc

Re: PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

> irq_set_chip_and_handler(irq, &tilegx_msi_chip, handle_level_irq); > irq_set_handler_data(irq, controller); > > > What we got after my fix: > > pci :00:00.0: BAR 8: assigned [mem 0x100c000-0x100c00f] > pci :00:00.0: BAR 9: assign

PCIe IO space support on Tilera GX: Is there any one who can confirm my modification to fix it is OK?

0: bridge window [mem 0x101c010-0x101c01f pref] pci :00:00.0: enabling device (0006 -> 0007) pci 0001:00:00.0: enabling device (0006 -> 0007) pci_bus :00: resource 0 [io 0x1000-0x87ff] pci_bus :00: resource 1 [mem 0x100c000-0x100ffff] pci_bus :01: resource 0 [io