[RFC] ASoC: Add compatible for mt6359-sound device

2020-11-30 Thread Shane Chien
From: "Shane.Chien" In the change "[v2,1/2] Add mediatek codec mt6359 driver", The compatible of mt6359-sound device is removed due to it is regarded as a part of parent device, which is only reflecting Linux model instead of hardware. However, if the device is not given a comaptible, of_node of

[PATCH] ASoC: Remove mt6359_platform_driver_remove

2020-11-10 Thread Shane Chien
From: "Shane.Chien" remove mt6359_platform_driver_remove due to it is useless. Signed-off-by: Shane.Chien --- sound/soc/codecs/mt6359.c | 12 1 file changed, 12 deletions(-) diff --git a/sound/soc/codecs/mt6359.c b/sound/soc/codecs/mt6359.c index ecdfd57..d37dbd2 100644 ---

[PATCH v3 0/2] Fix vaud18 power leakage of mt6359

2020-11-09 Thread Shane Chien
From: "Shane.Chien" This series of patches is to fix vaud18 power leakage problem. vaud18 will be enable only when mt6359 audio path is turned on. Change since v2: - fix dt-binnding syntex error Change since v1: - use dapm regulator supply widget for vaud18 control. - add vaud18 regulator

[PATCH v3 1/2] ASoC: Fix vaud18 power leakage of mt6359

2020-11-09 Thread Shane Chien
From: "Shane.Chien" vaud18 is power of mt6359 audio path. It should only enable when audio is used, instead of in boot up stage. Once mt6359 audio path is enabled or disabled, vaud18 is controlled by regulator supply widget "LDO_VAUD18". Due to vaud18 is controlled by regulator dapm macro

[PATCH v3 2/2] dt-bindings: mediatek: mt6359: Add new property for mt6359

2020-11-09 Thread Shane Chien
From: "Shane.Chien" This patch add "LDO_VAUD18-supply" property to control vaud18 regulator. It is labeled as required due to mt6359 audio path always need to enable vaud18. Signed-off-by: Shane.Chien --- .../devicetree/bindings/sound/mt6359.yaml |9 + 1 file changed, 9

[PATCH v2 0/2] Fix vaud18 power leakage of mt6359

2020-11-09 Thread Shane Chien
From: "Shane.Chien" This series of patches is to fix vaud18 power leakage problem. vaud18 will be enable only when mt6359 audio path is turned on. Change since v1: - use dapm regulator supply widget for vaud18 control. - add vaud18 regulator property in mt6359 dt-binding. Shane.Chien (2):

[PATCH v2 2/2] dt-bindings: mediatek: mt6359: Add new property for mt6359

2020-11-09 Thread Shane Chien
From: "Shane.Chien" This patch add "LDO_VAUD18-supply" property to control vaud18 regulator. It is labeled as required due to mt6359 audio path always need to enable vaud18. Signed-off-by: Shane.Chien --- .../devicetree/bindings/sound/mt6359.yaml |9 + 1 file changed, 9

[PATCH v2 1/2] ASoC: Fix vaud18 power leakage of mt6359

2020-11-09 Thread Shane Chien
From: "Shane.Chien" vaud18 is power of mt6359 audio path. It should only enable when audio is used, instead of in boot up stage. Once mt6359 audio path is enabled or disabled, vaud18 is controlled by regulator supply widget "LDO_VAUD18". Due to vaud18 is controlled by regulator dapm macro

[PATCH] ASoC: Fix vaud18 power leakage of mt6359

2020-11-05 Thread Shane Chien
From: "Shane.Chien" vaud18 is power of mt6359 audio path. It should only enable when audio is used, instead of in boot up stage. Once mt6359 audio path is enabled or disabled, vaud18 is controlled by using regulator in supply widget "LDO_VAUD18". Due to vaud18 is controlled by regulator instead

[PATCH] ASoC: Use memset_io to access I/O memory

2020-09-18 Thread Shane Chien
From: "Shane.Chien" Use memset_io to access I/O memory, instead of memset. Signed-off-by: Shane.Chien --- sound/core/pcm_native.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 9e0b2d7..a4efa84 100644 ---

[PATCH 0/1] Use memset_io to access I/O memory

2020-09-18 Thread Shane Chien
From: "Shane.Chien" Use memset_io to access I/O memory, instead of memset. Shane.Chien (1): ASoC: Use memset_io to access I/O memory sound/core/pcm_native.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.9.5

Darowizna

2020-05-29 Thread SHANE MISSLER
Nazywam się SHANE MISSLER, wygrałem loterię o wartości 451 milionów dolarów i postanowiłem przekazać tobie kwotę 5500 000,00 €. Przekazuję wam tę darowiznę za miłość, którą mam dla ludzkości i za pomoc osobom dotkniętym pandemią w waszym kraju.Skontaktuj się ze mną, aby odebrać tę

Spende von 5 Millionen Euro

2019-09-20 Thread Shane Missler
Dies ist eine persönliche Mail, die ich an Sie adressiere. Ich bin SHANE MISSLER aus Florida, USA. Wie Sie bereits wissen, habe ich einen Lotto-Jackpot in Höhe von 451 Mio. USD (330 Mio. GBP) gewonnen und das Geld hat mein Leben und mein Familienleben verändert, aber es wird mein Herz nicht

Spende von 5 Millionen Euro

2019-09-18 Thread Shane Missler
Dies ist eine persönliche Mail, die ich an Sie adressiere. Ich bin SHANE MISSLER aus Florida, USA. Wie Sie bereits wissen, habe ich einen Lotto-Jackpot in Höhe von 451 Mio. USD (330 Mio. GBP) gewonnen und das Geld hat mein Leben und mein Familienleben verändert, aber es wird mein Herz nicht

YOU HAVE BEEN CHOSEN

2018-07-27 Thread Shane Missler
organizations within your locality.   Should you wish to verify,below are link to that effect:     http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU   Kindly Forward your Message of Acceptance to: shaness...@yahoo.com   Best Regards.     Shane

YOU HAVE BEEN CHOSEN

2018-07-27 Thread Shane Missler
organizations within your locality.   Should you wish to verify,below are link to that effect:     http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU   Kindly Forward your Message of Acceptance to: shaness...@yahoo.com   Best Regards.     Shane

YOU HAVE BEEN CHOSEN

2018-07-27 Thread Shane Missler
organizations within your locality.   Should you wish to verify,below are link to that effect:     http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU   Kindly Forward your Message of Acceptance to: shaness...@yahoo.com   Best Regards.     Shane

YOU HAVE BEEN CHOSEN

2018-07-27 Thread Shane Missler
organizations within your locality.   Should you wish to verify,below are link to that effect:     http://www.bbc.com/news/world-us-canada-42671157 https://www.youtube.com/watch?v=G6IAFzRF4oU   Kindly Forward your Message of Acceptance to: shaness...@yahoo.com   Best Regards.     Shane

RE: [PATCH] qlogicpti: Return correct error code

2016-02-29 Thread Seymour, Shane M
Reviewed-by: Shane Seymour <shane.seym...@hpe.com>

RE: [PATCH] qlogicpti: Return correct error code

2016-02-29 Thread Seymour, Shane M
Reviewed-by: Shane Seymour

RE: [PATCH] snic: correctly check for array overrun on overly long version number

2016-02-29 Thread Seymour, Shane M
Reviewed-by: Shane Seymour <shane.seym...@hpe.com>

RE: [PATCH] snic: correctly check for array overrun on overly long version number

2016-02-29 Thread Seymour, Shane M
Reviewed-by: Shane Seymour

RE: [PATCH] ipr: fix out-of-bounds null overwrite

2016-01-05 Thread Seymour, Shane M
> len = snprintf(fname, 99, "%s", buf); > - fname[len-1] = '\0'; Since it appears that's the only time len is actually used in that function can you please remove the variable len completely as part of the patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

RE: [PATCH] ipr: fix out-of-bounds null overwrite

2016-01-05 Thread Seymour, Shane M
> len = snprintf(fname, 99, "%s", buf); > - fname[len-1] = '\0'; Since it appears that's the only time len is actually used in that function can you please remove the variable len completely as part of the patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

RE: [PATCH 2/2] pci: Update VPD size with correct length

2015-12-17 Thread Seymour, Shane M
[V5] Vendor specific: 02.03 [YA] Asset tag: NA [RV] Reserved: checksum good, 0 byte(s) reserved End ... --- Tested-by: Shane Seymour -- To unsubscribe from this list: send the line "unsubscribe linux-k

RE: [PATCH 1/2] pci: Update VPD definitions

2015-12-17 Thread Seymour, Shane M
gt; Cc: Bjorn Helgaas > Signed-off-by: Hannes Reinecke Tested-by: Shane Seymour -- 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 r

RE: [PATCH 1/2] pci: Update VPD definitions

2015-12-17 Thread Seymour, Shane M
uyck <alexander.du...@gmail.com> > Cc: Bjorn Helgaas <bhelg...@google.com> > Signed-off-by: Hannes Reinecke <h...@suse.com> Tested-by: Shane Seymour <shane.seym...@hpe.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

RE: [PATCH 2/2] pci: Update VPD size with correct length

2015-12-17 Thread Seymour, Shane M
[V5] Vendor specific: 02.03 [YA] Asset tag: NA [RV] Reserved: checksum good, 0 byte(s) reserved End ... --- Tested-by: Shane Seymour <shane.seym...@hpe.com> -- To unsubscribe from this list: send the line "

RE: [PATCHv2] pci: Update VPD size with correct length

2015-12-16 Thread Seymour, Shane M
> The only 'error' cases I've encountered so far is a read of all zeroes (and a > halting the machine once you've read beyond a certain point) or a read of > 0xff throughout the entire area. So that approach would work for both of them. I should add that I'd tested the previous patch and this

RE: [PATCHv2] pci: Update VPD size with correct length

2015-12-16 Thread Seymour, Shane M
> The only 'error' cases I've encountered so far is a read of all zeroes (and a > halting the machine once you've read beyond a certain point) or a read of > 0xff throughout the entire area. So that approach would work for both of them. I should add that I'd tested the previous patch and this

RE: [PATCH v5 1/2] block: invalidate the page cache when issuing BLKZEROOUT.

2015-12-14 Thread Seymour, Shane M
Thank you for taking the issues I raised about converting unsigned to signed into account. Reviewed-by: Shane Seymour

RE: [PATCH v5 1/2] block: invalidate the page cache when issuing BLKZEROOUT.

2015-12-14 Thread Seymour, Shane M
Thank you for taking the issues I raised about converting unsigned to signed into account. Reviewed-by: Shane Seymour <shane.seym...@hpe.com>

RE: [PATCH v4] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-16 Thread Seymour, Shane M
> v4: Check the start/len arguments for overflows prior to feeding the page > cache bogus numbers (that it'll ignore anyway). > Signed-off-by: Darrick J. Wong Reviewed-by: Shane Seymour -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in th

RE: [PATCH v4] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-16 Thread Seymour, Shane M
> v4: Check the start/len arguments for overflows prior to feeding the page > cache bogus numbers (that it'll ignore anyway). > Signed-off-by: Darrick J. Wong <darrick.w...@oracle.com> Reviewed-by: Shane Seymour <shane.seym...@hpe.com> -- To unsubscribe from thi

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-12 Thread Seymour, Shane M
alue like that but it seems like an unusual value for your code to be willing to pass into truncate_inode_pages_range(). Shane -- 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.k

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-12 Thread Seymour, Shane M
alue like that but it seems like an unusual value for your code to be willing to pass into truncate_inode_pages_range(). Shane -- 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.k

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-11 Thread Seymour, Shane M
> which would make the other checks I suggested to ensure that neither start > or end were more than (uint64_t)LLONG_MAX unnecessary. My apologies I was wrong about what I said above - after thinking about it for longer you still need to make sure that at least len is not greater than

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-11 Thread Seymour, Shane M
> I don't have a device large enough to test for signedness errors, since > passing > huge values for start and len never make it past the i_size_read check. > However, I do see that I forgot to check the padding values, so I'll update > that. Then do you want to at least consider converting

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-11 Thread Seymour, Shane M
> I don't have a device large enough to test for signedness errors, since > passing > huge values for start and len never make it past the i_size_read check. > However, I do see that I forgot to check the padding values, so I'll update > that. Then do you want to at least consider converting

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-11 Thread Seymour, Shane M
> which would make the other checks I suggested to ensure that neither start > or end were more than (uint64_t)LLONG_MAX unnecessary. My apologies I was wrong about what I said above - after thinking about it for longer you still need to make sure that at least len is not greater than

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-10 Thread Seymour, Shane M
unsigned values being implicitly converted to signed are unfounded (I would have hoped for compiler warnings about any implicit conversions though). Thanks Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

RE: [PATCH] block: create ioctl to discard-or-zeroout a range of blocks

2015-11-10 Thread Seymour, Shane M
unsigned values being implicitly converted to signed are unfounded (I would have hoped for compiler warnings about any implicit conversions though). Thanks Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

RE: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1

2015-02-15 Thread Seymour, Shane M
I found the manual pages really confusing so I had a go at rewriting them - there were places in the manual page that didn't match the functionality provided by your code as well as I could tell). My apologies for a few formatting issues though. I still don't like parts of epoll_pwait1 but it's

RE: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1

2015-02-15 Thread Seymour, Shane M
I found the manual pages really confusing so I had a go at rewriting them - there were places in the manual page that didn't match the functionality provided by your code as well as I could tell). My apologies for a few formatting issues though. I still don't like parts of epoll_pwait1 but it's

3.10.0-rcX vmstat regression

2013-06-10 Thread Shane Shrybman
# CONFIG_HIGH_RES_TIMERS is not set Sorry if this report is a duplicate, Shane -- 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 FA

3.10.0-rcX vmstat regression

2013-06-10 Thread Shane Shrybman
# CONFIG_HIGH_RES_TIMERS is not set Sorry if this report is a duplicate, Shane -- 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

[RFC] Implementing tape statistics

2013-03-20 Thread Seymour, Shane M
Before you start reading this I want to apologize in advance for the length of this email. The length is important though to make sure all of the arguments and counter-arguments are represented in asking for feedback about how tape statistics would be best implemented. There is some demand for

[RFC] Implementing tape statistics

2013-03-20 Thread Seymour, Shane M
Before you start reading this I want to apologize in advance for the length of this email. The length is important though to make sure all of the arguments and counter-arguments are represented in asking for feedback about how tape statistics would be best implemented. There is some demand for

RE: [3.8-{rc1,rc2}] ata1.00: failed to get Identify Device Data, Emask 0x1

2013-01-04 Thread Huang, Shane
uble to you guys. Thanks, Shane

RE: [3.8-{rc1,rc2}] ata1.00: failed to get Identify Device Data, Emask 0x1

2013-01-04 Thread Huang, Shane
, Shane

[PATCH v2] MIPS: MSP71xx: Move include files

2012-12-24 Thread Shane McDonald
Now that Yosemite's gone we can move the MSP71xx include files one level up. Signed-off-by: Shane McDonald --- Patch history: V1: Original patch V2: Use format-patch's -M option to indicate file renames .../cpu-feature-overrides.h|0 .../msp71xx => mach-pmcs-msp7

[PATCH v2] MIPS: MSP71xx: Move include files

2012-12-24 Thread Shane McDonald
Now that Yosemite's gone we can move the MSP71xx include files one level up. Signed-off-by: Shane McDonald mcdonald.sh...@gmail.com --- Patch history: V1: Original patch V2: Use format-patch's -M option to indicate file renames .../cpu-feature-overrides.h|0

MIPS: MSP71xx: Indicate new location of source files in Platform file

2012-12-23 Thread Shane McDonald
The source files for the MSP71xx support code have been moved in commit 13a347ef60c68e490809dad8fcf79c25eabc4d58, "MIPS: MSP71xx: Move code." Update the Platform file to indicate the new location. Signed-off-by: Shane McDonald --- arch/mips/pmcs-msp71xx/Platform |4 ++-- 1 files

MIPS: MSP71xx: Indicate new location of source files in Platform file

2012-12-23 Thread Shane McDonald
The source files for the MSP71xx support code have been moved in commit 13a347ef60c68e490809dad8fcf79c25eabc4d58, MIPS: MSP71xx: Move code. Update the Platform file to indicate the new location. Signed-off-by: Shane McDonald mcdonald.sh...@gmail.com --- arch/mips/pmcs-msp71xx/Platform |4

Re: RM9000 / E9000, MSP71xx class processors, SOCs and eval boards

2012-12-06 Thread Shane McDonald
ons of the MSP7120 (no hardware to test with). I had hoped that someone from PMC-Sierra would respond, but maybe they don't care anymore... Shane McDonald -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.o

Re: RM9000 / E9000, MSP71xx class processors, SOCs and eval boards

2012-12-06 Thread Shane McDonald
to test with). I had hoped that someone from PMC-Sierra would respond, but maybe they don't care anymore... Shane McDonald -- 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

RE: ata4.00: failed to get Identify Device Data, Emask 0x1

2012-11-16 Thread Huang, Shane
my patch first without testing so as to meet kernel 3.7 bug fix window? Thanks, Shane -- 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 Ple

RE: ata4.00: failed to get Identify Device Data, Emask 0x1

2012-11-16 Thread Huang, Shane
testing so as to meet kernel 3.7 bug fix window? Thanks, Shane -- 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

RE: ata4.00: failed to get Identify Device Data, Emask 0x1

2012-10-18 Thread Huang, Shane
> Agree. If NCQ does not imply support of this log page, we should > definitely refine the check condition used here. > > I suppose Shane will take care of this, but if he doesn't, I'll do that > at a later time. I tried word 78 bit 5(Hardware Feature Control) which does not work

RE: ata4.00: failed to get Identify Device Data, Emask 0x1

2012-10-18 Thread Huang, Shane
Agree. If NCQ does not imply support of this log page, we should definitely refine the check condition used here. I suppose Shane will take care of this, but if he doesn't, I'll do that at a later time. I tried word 78 bit 5(Hardware Feature Control) which does not work, it is 0 on my HDD

RE: [patch] PCI: disable the MSI of AMD RS690

2008-01-25 Thread Shane Huang
f RS690+SB700 on the market. Thanks Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

RE: [patch] PCI: disable the MSI of AMD RS690

2008-01-25 Thread Shane Huang
one SB600+RS690 board, and can help to verify this RS690 MSI disablement patch with a new kernel version such as 2.6.24-rc7, that's great. BTW: RS690 MSI disablement should NOT affect SB700 MSI, because as I know, there will not be the combination of RS690+SB700 on the market. Thanks Shane

RE: [PATCH] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
Hi Tejun: > Okay, here's reformatted in-line version. Shane, please invest some > time into setting up email environment. Sending patches via email is > an important part of the linux kernel development process and if > you're gonna submit patches, you're just gonna have to do

[PATCH] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
because 0x4395 is SB800 device ID. Signed-off-by: Shane Huang <[EMAIL PROTECTED]> diff -ruN linux-2.6.24-rc7_org/drivers/pci/quirks.c linux-2.6.24-rc7_new/drivers/pci/quirks.c --- linux-2.6.24-rc7_org/drivers/pci/quirks.c 2008-01-23 14:44:53.0 +0800 +++ linux-2.6.24-rc7_new/drive

RE: [patch] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
another update patch later. Thanks Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

RE: [patch] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
I did some modification to this patch and send it again, Please check it. The quirk to 0x4395 has been removed because 0x4395 only belongs to SB800. Thanks Shane > -Original Message- > From: Shane Huang > > SB700 SATA MSI bug will be fixed in SB700 revision A21 at >

[patch] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
SB700 SATA MSI bug will be fixed in SB700 revision A21 at hardware level, but the SB700 revision older than A21 will also be found in the market. This patch modify the original quirk commit bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it. Signed-off-by: Shane Huang <[EM

[patch] PCI: disable the MSI of AMD RS690

2008-01-24 Thread Shane Huang
is the workaround. Signed-off-by: Shane Huang <[EMAIL PROTECTED]> Since there is some word wrapping problem with my mail client MS outlook if I copy the patch into the text, so I'll also attach the patch as an attachment. Please check it. diff -ruN old/drivers/pci/quirks.c new/drive

[patch] PCI: disable the MSI of AMD RS690

2008-01-24 Thread Shane Huang
is the workaround. Signed-off-by: Shane Huang [EMAIL PROTECTED] Since there is some word wrapping problem with my mail client MS outlook if I copy the patch into the text, so I'll also attach the patch as an attachment. Please check it. diff -ruN old/drivers/pci/quirks.c new/drivers/pci/quirks.c

[patch] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
SB700 SATA MSI bug will be fixed in SB700 revision A21 at hardware level, but the SB700 revision older than A21 will also be found in the market. This patch modify the original quirk commit bc38b411fe696fad32b261f492cb4afbf1835256 instead of withdrawing it. Signed-off-by: Shane Huang [EMAIL

RE: [patch] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
I did some modification to this patch and send it again, Please check it. The quirk to 0x4395 has been removed because 0x4395 only belongs to SB800. Thanks Shane -Original Message- From: Shane Huang SB700 SATA MSI bug will be fixed in SB700 revision A21 at hardware level

RE: [patch] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
later. Thanks Shane -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[PATCH] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
because 0x4395 is SB800 device ID. Signed-off-by: Shane Huang [EMAIL PROTECTED] diff -ruN linux-2.6.24-rc7_org/drivers/pci/quirks.c linux-2.6.24-rc7_new/drivers/pci/quirks.c --- linux-2.6.24-rc7_org/drivers/pci/quirks.c 2008-01-23 14:44:53.0 +0800 +++ linux-2.6.24-rc7_new/drivers/pci

RE: [PATCH] PCI: modify SB700 SATA MSI quirk

2008-01-24 Thread Shane Huang
Hi Tejun: Okay, here's reformatted in-line version. Shane, please invest some time into setting up email environment. Sending patches via email is an important part of the linux kernel development process and if you're gonna submit patches, you're just gonna have to do it. Right

Re: [2.6 patch] videobuf-core.c locking fixes

2007-12-12 Thread Shane
15 userptr buffers so whatever is happening may be happening once per buffer sometimes. dunno Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.htm

Re: [2.6 patch] videobuf-core.c locking fixes

2007-12-12 Thread Shane
On Dec 12, 2007 2:44 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Wed, Dec 12, 2007 at 01:57:27PM -0500, Shane wrote: > > On Dec 12, 2007 11:37 AM, Shane <[EMAIL PROTECTED]> wrote: > > > On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]>

Re: 2.6.24-rc5 "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined!

2007-12-12 Thread Shane
On Dec 12, 2007 11:37 AM, Shane <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > ... > > The proper solution is provided by this changeset: > > http://git.kernel.org/?p=linux/kernel/git/mche

Re: 2.6.24-rc5 "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined!

2007-12-12 Thread Shane
with a bttv card. Mauro and Adrian, Thanks for your prompt attention to this and for promptly pushing the fix to Linus. Regards, Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: 2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

2007-12-12 Thread Shane
. Mauro and Adrian, Thanks for your prompt attention to this and for promptly pushing the fix to Linus. Regards, Shane -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo

Re: 2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

2007-12-12 Thread Shane
On Dec 12, 2007 11:37 AM, Shane [EMAIL PROTECTED] wrote: On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: ... The proper solution is provided by this changeset: http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commitdiff;h

Re: [2.6 patch] videobuf-core.c locking fixes

2007-12-12 Thread Shane
On Dec 12, 2007 2:44 PM, Adrian Bunk [EMAIL PROTECTED] wrote: On Wed, Dec 12, 2007 at 01:57:27PM -0500, Shane wrote: On Dec 12, 2007 11:37 AM, Shane [EMAIL PROTECTED] wrote: On Dec 12, 2007 9:21 AM, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: ... The proper solution is provided

Re: [2.6 patch] videobuf-core.c locking fixes

2007-12-12 Thread Shane
userptr buffers so whatever is happening may be happening once per buffer sometimes. dunno Shane -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

2.6.24-rc5 "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined!

2007-12-11 Thread Shane
-core.o Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#1) MODPOST 202 modules ERROR: "videobuf_read_start" [drivers/media/video/videobuf-dvb.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Shane diff --git a/drivers/media/video/videobuf

2.6.24-rc5 videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined!

2007-12-11 Thread Shane
-core.o Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#1) MODPOST 202 modules ERROR: videobuf_read_start [drivers/media/video/videobuf-dvb.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Shane diff --git a/drivers/media/video/videobuf-core.c b

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-10 Thread Shane
t to both client and server, > but no luck. I'm using NFSv3, but I applied two patches. The one you mention from Eric and the patch Trond posted in this thread. > > Still see empty folders. That was the symptom I had without Trond's patch. Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-10 Thread Shane
applied it to both client and server, but no luck. I'm using NFSv3, but I applied two patches. The one you mention from Eric and the patch Trond posted in this thread. Still see empty folders. That was the symptom I had without Trond's patch. Shane -- To unsubscribe from this list: send the line

Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

2007-12-08 Thread Shane
tatic struct dentry_operations proc_dentry_operations = > { > .d_delete = proc_delete_dentry, > - .d_revalidate = proc_revalidate_dentry, > }; > > /* > -- > 1.5.3.rc6.17.g1911 Confirmed. This patch fixes the problem for me. Shane -- To unsubscribe from this list:

Re: [PATCH 2.6.24-rc4] proc: Remove/Fix proc generic d_revalidate

2007-12-08 Thread Shane
the problem for me. Shane -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
07, Andrew Morton wrote: > > > > On Fri, 07 Dec 2007 17:51:58 -0500 > > > > Trond Myklebust <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > On Fri, 2007-12-07 at 14:39 -0500, Shane wrote: > > > > > > O

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
On Dec 7, 2007 2:16 PM, Shane <[EMAIL PROTECTED]> wrote: ... > Confirmed working in rc4-git5. I'll deploy this kernel in a few more > spots and check for other regressions. Hmm, I installed a new kernel built from the same sources on the NFS server. And now I don't see any

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
On Dec 7, 2007 1:55 PM, Shane <[EMAIL PROTECTED]> wrote: > On Dec 7, 2007 1:46 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote: > ... > > This problem has already been reported. The fix (which I'm planning on > > sending to Linus soon) is appended. > > Thanks Tron

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
On Dec 7, 2007 1:46 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote: ... > This problem has already been reported. The fix (which I'm planning on > sending to Linus soon) is appended. Thanks Trond. Sorry for the duplicate report, I did actually do some searching... I will confirm the

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
ile handle Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
rA/dirB/dirC --> Stale NFS file handle ls /dirA/dirB/dirD --> Stale NFS file handle I will do a few more builds/boots and check -rc3-git2 and -rc3-git3. Will report back shortly, Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
will do a few more builds/boots and check -rc3-git2 and -rc3-git3. Will report back shortly, Shane -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
handle Shane -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
On Dec 7, 2007 1:46 PM, Trond Myklebust [EMAIL PROTECTED] wrote: ... This problem has already been reported. The fix (which I'm planning on sending to Linus soon) is appended. Thanks Trond. Sorry for the duplicate report, I did actually do some searching... I will confirm the fix. Shane

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
On Dec 7, 2007 1:55 PM, Shane [EMAIL PROTECTED] wrote: On Dec 7, 2007 1:46 PM, Trond Myklebust [EMAIL PROTECTED] wrote: ... This problem has already been reported. The fix (which I'm planning on sending to Linus soon) is appended. Thanks Trond. Sorry for the duplicate report, I did

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
On Dec 7, 2007 2:16 PM, Shane [EMAIL PROTECTED] wrote: ... Confirmed working in rc4-git5. I'll deploy this kernel in a few more spots and check for other regressions. Hmm, I installed a new kernel built from the same sources on the NFS server. And now I don't see anything at all

Re: 2.6.24-rc3-git4 NFS crossmnt regression

2007-12-07 Thread Shane
:58 -0500 Trond Myklebust [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 14:39 -0500, Shane wrote: On Dec 7, 2007 2:16 PM, Shane [EMAIL PROTECTED] wrote: ... Confirmed working in rc4-git5. I'll deploy this kernel in a few more spots and check

  1   2   3   >