Re: [GIT PULL] x86 fixes
I used a very old userspace, and embedded systems are much more likely to use uclibc than glibc. However, if they try to use SSE without checking they will break on a hell of a lot more hardware. On August 17, 2015 5:19:10 PM PDT, Andy Lutomirski wrote: >On Mon, Aug 17, 2015 at 5:06 PM, H. Peter Anvin wrote: >> User space does not need to treat for FPU instructions, except for >performance reasons, because the kernel emulates the full x87 FPU. So >it is localized to the kernel. > >But user space needs to avoid SSE2 and such, I suspect. In general, >I'd be surprised if things work well if we emulate the FPU (and set >CR0.em? I haven't checked out Linux's FPU emulation works) if user >code sees fancy instruction sets exposed and possibly even OSXSAVE. > >None of this matters except for testing, since it's very unlikely that >any CPU exists that supports XSAVE, XMM, SSE2, etc but uses emulated >x87. But if we emulate such a beast, things could break, and I bet >that's what Ingo's seeing. (Also, lots of distros target "i686" these >days, and that might cause its own set of problems.) > >--Andy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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/
Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator
Hi Mark Brown, On Friday 14 August 2015 11:30 PM, Mark Brown wrote: > On Mon, Jul 27, 2015 at 04:54:09PM +0530, Kishon Vijay Abraham I wrote: > >> vsel_reg and enable_reg of the pbias regulator descriptor should actually >> have the offset from syscon. However after the pbias device tree node > > I'm having a hard time understanding this statement, sorry. What makes > you say that they "shouild actually have the offset from syscon"? What > is the problem that this is supposed to fix? The register to program pbias regulator is 0x4A002E00. The syscon base address is 0x4a002000. So the vsel_reg and enable_reg should have the offset from syscon base address. regulator_enable_regmap gets the base address from 'regmap' and offset from 'enable_reg' in order to program the pbias regulator. But without this patch vsel_reg and enable_reg have the absolute address instead of just the offset. > >> is moved as a child node of syscon, vsel_reg and enable_reg has the >> absolute address because of the address translation that happens while >> creating device from device tree node. >> So avoid using platform_get_resource and use of_get_address in order to >> get only the offset (untranslated address) and populate these in >> vsel_reg and enable_reg. > > This sounds like we're going in the wrong direction, we're moving from a > more generic API to a firmware specific one. Why is this a good fix? platform_get_resource can be used if we need the absolute address but here we need only the offset. Thanks Kishon -- 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/
Re: [PATCH v2] asus-laptop: Add key found on Asus F3M
On Wed, Aug 12, 2015 at 09:06:08AM +0200, Corentin Chary wrote: > On Wed, Aug 5, 2015 at 10:29 PM, Darren Hart wrote: > > On Wed, Jul 29, 2015 at 09:31:23PM +0200, Łukasz Stelmach wrote: > >> Asus F3M has two keys labeled with an icon of a touchpad. The first, > >> reported as 0x6B is next to the power key and the second, reported as > >> 0x6A, is F9 combined with Fn button. When I was pressing the latter, I was > >> getting "Unknown key 6a pressed" message before applying this patch. > >> > >> Asus F3M does not support WMI so the commit does not update key mappings > >> in the asus-nb-wmi.c file. > >> > >> I have not tested this mapping on any other Asus laptop. > >> > >> Signed-off-by: Łukasz Stelmach > > > > Thanks Łukasz. > > > > Corentin, any concerns? > > Acked-by: Corentin Chary > > Sorry for the delay, I won't really have a stable internet connection > until October. It's already in next, but thank you for following up. -- Darren Hart Intel Open Source Technology Center -- 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/
Re: [PATCH] leds: leds-fsg: Use devm_led_classdev_register
On Mon, Aug 17, 2015 at 2:02 PM, Vaishali Thakkar
wrote:
>
> On 17 Aug 2015 13:57, "Jacek Anaszewski" wrote:
>>
>> Hi Vaishali,
>>
>> Thanks for the patch. Unfortunately it causes build break.
>> Please fix the issues and resubmit.
>
> Oops! I am really very sorry. By mistake I sent a basic version of patch
> instead of final one. Thanks for the review.
>
> I'll send v2 with the fix of that build error.
Hi Jacek,
Can you please tell me what are those build errors?
After looking at my patch, I can expect that as I forgot to
remove '.remove = fsg_led_remove' from structure,
it can cause an error. Also, there is one typing mistake in
function name. So, both of these can be a reason for
breaking a build.
Also to be on safe side, I tried to cross compile it for arm
architecture. But to my surprise, it is not compiling properly.
So, it would be good if you can point me to the script you
used for compilation so that I can check it before sending a new
version.
Thank You.
>>
>> On 08/15/2015 12:21 PM, Vaishali Thakkar wrote:
>>>
>>> Use resource-managed function devm_led_classdev_register instead
>>> of led_classdev_register to make the error-path simpler.
>>>
>>> To be compatible with the change, various gotos are replced with
>>> direct returns and unneeded labels are dropped. Also, remove
>>> fsg_led_remove as it is now redundant.
>>>
>>> Signed-off-by: Vaishali Thakkar
>>> ---
>>> drivers/leds/leds-fsg.c | 51
>>> -
>>> 1 file changed, 12 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/drivers/leds/leds-fsg.c b/drivers/leds/leds-fsg.c
>>> index 2b4dc73..df0e5da 100644
>>> --- a/drivers/leds/leds-fsg.c
>>> +++ b/drivers/leds/leds-fsg.c
>>> @@ -156,60 +156,33 @@ static int fsg_led_probe(struct platform_device
>>> *pdev)
>>> latch_value = 0x;
>>> *latch_address = latch_value;
>>>
>>> - ret = led_classdev_register(>dev, _wlan_led);
>>> + ret = devm_led_classdev_register(>dev, _wlan_led);
>>> if (ret < 0)
>>> - goto failwlan;
>>> + return ret;
>>>
>>> - ret = led_classdev_register(>dev, _wan_led);
>>> + ret = devm_led_classdev_register(>dev, _wan_led);
>>> if (ret < 0)
>>> - goto failwan;
>>> + return ret;
>>>
>>> - ret = led_classdev_register(>dev, _sata_led);
>>> + ret = devm_led_classdev_register(>dev, _sata_led);
>>> if (ret < 0)
>>> - goto failsata;
>>> + return ret;
>>>
>>> - ret = led_classdev_register(>dev, _usb_led);
>>> + ret = devm_led_classdev_register(>dev, _usb_led);
>>> if (ret < 0)
>>> - goto failusb;
>>> + return ret;
>>>
>>> - ret = led_classdev_register(>dev, _sync_led);
>>> + ret = devm_classdev_register(>dev, _sync_led);
>>> if (ret < 0)
>>> - goto failsync;
>>> + return ret;
>>>
>>> - ret = led_classdev_register(>dev, _ring_led);
>>> + ret = devm_led_classdev_register(>dev, _ring_led);
>>> if (ret < 0)
>>> - goto failring;
>>> -
>>> - return ret;
>>> -
>>> - failring:
>>> - led_classdev_unregister(_sync_led);
>>> - failsync:
>>> - led_classdev_unregister(_usb_led);
>>> - failusb:
>>> - led_classdev_unregister(_sata_led);
>>> - failsata:
>>> - led_classdev_unregister(_wan_led);
>>> - failwan:
>>> - led_classdev_unregister(_wlan_led);
>>> - failwlan:
>>> + return ret;
>>>
>>> return ret;
>>> }
>>>
>>> -static int fsg_led_remove(struct platform_device *pdev)
>>> -{
>>> - led_classdev_unregister(_wlan_led);
>>> - led_classdev_unregister(_wan_led);
>>> - led_classdev_unregister(_sata_led);
>>> - led_classdev_unregister(_usb_led);
>>> - led_classdev_unregister(_sync_led);
>>> - led_classdev_unregister(_ring_led);
>>> -
>>> - return 0;
>>> -}
>>> -
>>> -
>>> static struct platform_driver fsg_led_driver = {
>>> .probe = fsg_led_probe,
>>> .remove = fsg_led_remove,
>>>
>>
>>
>> --
>> Best Regards,
>> Jacek Anaszewski
--
Vaishali
--
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/
Re: provide more common DMA API functions V2
On Tue, 18 Aug 2015 07:38:25 +0200 Christoph Hellwig wrote: > On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote: > > 110254 bytes saved, shrinking the kernel by a whopping 0.17%. > > Thoughts? > > Sounds fine to me. OK, I'll clean it up a bit, check that each uninlining actually makes sense and then I'll see how it goes. > > > > I'll merge these 5 patches for 4.3. That means I'll release them into > > linux-next after 4.2 is released. > > So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the > wrong way around? Linus will be releasing 4.2 in 1-2 weeks and until then, linux-next is supposed to contain only 4.2 material. Once 4.2 is released, linux-next is open for 4.3 material. -- 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/
Re: [PATCH 02/20] staging: rtl8192u: r8192U_core: fix consistent spacing code style error
On Tue, Aug 18, 2015 at 01:38:21AM -0400, Raphaël Beamonte wrote: > 2015-08-18 1:02 GMT-04:00 Sudip Mukherjee : > > since you are modifying these lines for consistent spacing, it will be > > better to have: > > (priv->ShortRetryLimit << TCR_SRL_OFFSET) | // Short retry limit > > > This should be: > > priv->eeprom_CustomerID = eprom_read(dev, (EEPROM_Customer_ID>>1)) >> 8; > > Are you talking about spacing around the << and >> ? > If so, shouldn't that last line be: > priv->eeprom_CustomerID = eprom_read(dev, (EEPROM_Customer_ID >> 1)) >> 8; yeah.. I missed that >>1 , i only noticed >>8 as you have changed that. > > And should I thus apply that to the whole file? I think that will be better, since you are sending the patch for consistent spacing. And some of your patches are not having any commit message. Greg will not accept such patches. So while you are sending take care of that also. regards sudip -- 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/
Re: [PATCH v2] rtc: s3c: fix disabled clocks for alarm
On 12.08.2015 19:21, Joonyoung Shim wrote:
> The clock enable/disable codes for alarm have been removed from
> commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
> control") and the clocks are disabled even if alarm is set, so alarm
> interrupt can't happen.
>
> The s3c_rtc_setaie function can be called several times with 'enabled'
> argument having same value, so it needs to check whether clocks are
> enabled or not.
>
> Signed-off-by: Joonyoung Shim
> Cc: # v4.1
> ---
> This is v2 of prior patch "[PATCH 4/4] rtc: s3c: enable/disable clocks
> for alarm".
>
> Changelog for v2:
> - commit messages is modified by Krzysztof suggestion
> - make to backportable patch
> - add Cc-stable
>
> drivers/rtc/rtc-s3c.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
Looks good now:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
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/
Re: [PATCH 12/20] staging: rtl8192u: r8192U_core: fix externs in .c file code style issue
2015-08-18 1:30 GMT-04:00 Sudip Mukherjee : > These are not externs. These are forward declarations. I copied the message from checkpatch. Will edit that to make it more accurate! Thanks, Raphaël -- 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/
Re: [PATCH 02/20] staging: rtl8192u: r8192U_core: fix consistent spacing code style error
2015-08-18 1:02 GMT-04:00 Sudip Mukherjee : > since you are modifying these lines for consistent spacing, it will be > better to have: > (priv->ShortRetryLimit << TCR_SRL_OFFSET) | // Short retry limit > This should be: > priv->eeprom_CustomerID = eprom_read(dev, (EEPROM_Customer_ID>>1)) >> 8; Are you talking about spacing around the << and >> ? If so, shouldn't that last line be: priv->eeprom_CustomerID = eprom_read(dev, (EEPROM_Customer_ID >> 1)) >> 8; And should I thus apply that to the whole file? Thanks! Raphaël -- 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/
Re: provide more common DMA API functions V2
On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote: > 110254 bytes saved, shrinking the kernel by a whopping 0.17%. > Thoughts? Sounds fine to me. > > I'll merge these 5 patches for 4.3. That means I'll release them into > linux-next after 4.2 is released. So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the wrong way around? -- 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/
Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes
> > I had an unstable system when running latest Linus tree with Tejun's > > patch applied on top. Nothing fishy in the logs after rebooting without > > the patch, but remote access with ssh when patch applied did not work > > (as if /home partition could not be read). This system has / as ext4 and > > other partitions (including /home) as XFS. Trying to login on tty > > instead of X resulted in hang of X. I could reboot with sysrq, but can't > > do further tests at the moment. > > Back to same tree without the patch resulted in normal system. > > So just a heads up the patch doesn't seem OK in its current state. Hi Tejun, > Have you been able to reproduce the failure? That sounds like an > unlikely failure mode for the patch. Unfortunately (as it would be nice to understand what happened), no. I reapplied the patch on top of rc7 and could not reproduce the unstability after several reboots. I will continue running with the patch and report if anything strange appears again... -- Damien -- 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/
Re: [PATCH 12/20] staging: rtl8192u: r8192U_core: fix externs in .c file code style issue
On Sat, Aug 15, 2015 at 09:34:08PM -0400, Raphaël Beamonte wrote: > Externs should be avoided in .c files. These one were not useful and > are thus removed. These are not externs. These are forward declarations. regards sudip -- 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/
Re: [PATCHv3] staging: wilc1000: use netdev_* instead of printk
2015-08-18 0:24 GMT-04:00 Sudip Mukherjee :
>> + netdev_err("[Sendconfigpkt]Get Timed out\n");
> This will not compile. you can not just replace printk with
> netdev_*, you need to mention a net_device.
You're right! I'm making a lot of mistakes. It seems I called the make
command in the wrong git tree... Thanks for catching that, and taking
time to review!
I just saw there isn't any netdev_debug available. Do you know the
reason for that? Is there a replacement besides pr_debug?
Also, it seems that in all the functions where it's another netdev
that's available that I could use, I don't have access to the
net_device struct. Is there a general way to get that device
information? I saw an old lkml post talking about dev_*() functions to
do that? Would you have some hint on the matter?
Thanks a lot!
Raphaël
--
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/
Re: [v1 0/6] *** nps_enet fixups ***
From: Noam Camus Date: Tue, 18 Aug 2015 05:04:20 + > I followed "Hardware Architecture" section from: > http://www.linuxfoundation.org/collaborate/workgroups/networking/napi > and came up with "reduce processing latency" idea. That document has lots of incorrect advice, that's for sure. For one thing, it also says to count TX work against the budget, you absolutely should not do this. TX work is "free" compared to RX work (which is several orders of magnitude more expensive) and therefore should not count against the NAPI budget value. -- 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/
Re: [PATCH 07/20] staging: rtl8192u: r8192_core: whitespace neatening
On Sat, Aug 15, 2015 at 09:34:03PM -0400, Raphaël Beamonte wrote: > Signed-off-by: Raphaël Beamonte > --- > @@ -2182,30 +2182,30 @@ static void rtl8192_init_priv_variable(struct > net_device *dev) > priv->EarlyRxThreshold = 7; > priv->enable_gpio0 = 0; > priv->TransmitConfig = > - (TCR_MXDMA_2048< Tx DMA Burst, 7: reserved. > - (priv->ShortRetryLimit< limit > - (priv->LongRetryLimit< limit > + (TCR_MXDMA_2048 << TCR_MXDMA_OFFSET) | // Max DMA Burst Size > per Tx DMA Burst, 7: reserved. > + (priv->ShortRetryLimit << TCR_SRL_OFFSET) | // Short > retry limit > + (priv->LongRetryLimit << TCR_LRL_OFFSET) |// Long retry > limit > (false ? TCR_SAT : 0); // FALSE: HW provides PLCP length and > LENGEXT, TRUE: SW provides them > #ifdef TO_DO_LIST > if (Adapter->bInHctTest) > pHalData->ReceiveConfig = pHalData->CSMethod | > - RCR_AMF | RCR_ADF | > //accept management/data > + RCR_AMF | RCR_ADF | > //accept management/data > //guangan200710 > - RCR_ACF | //accept > control frame for SW AP needs PS-poll, 2005.07.07, by rcnjko. > - RCR_AB | RCR_AM | RCR_APM | > //accept BC/MC/UC > - RCR_AICV | RCR_ACRC32 | > //accept ICV/CRC error packet > - ((u32)7< Max DMA Burst Size per Rx DMA Burst, 7: unlimited. > - > (pHalData->EarlyRxThreshold< Rx threshold. > + RCR_ACF | //accept > control frame for SW AP needs PS-poll, 2005.07.07, by rcnjko. > + RCR_AB | RCR_AM | RCR_APM | > //accept BC/MC/UC > + RCR_AICV | RCR_ACRC32 | > //accept ICV/CRC error packet > + ((u32)7 << RCR_MXDMA_OFFSET) | > // Max DMA Burst Size per Tx DMA Burst, 7: reserved. looks like the comment has changed. copy paste error from previous lines? regards sudip -- 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/
Re: [PATCH 06/20] staging: rtl8192u: r8192U_core: fix missing struct leading to consistent spacing code style error
On Sat, Aug 15, 2015 at 09:34:02PM -0400, Raphaël Beamonte wrote: > A missing struct keyword in variable declaration triggered a > need consistent spacing around '*' code style error. struct rtl8192_rx_info is typedef as rtl8192_rx_info. This same file is having few more use of rtl8192_rx_info without struct. maybe you can change all of them and get rid of the typedef. regards sudip -- 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/
Re: [PATCH] ASoC: tegra: Convert to managed resources
On Tue, Aug 18, 2015 at 08:15:35AM +0530, Vaishali Thakkar wrote: > I think yes may be code was good before this. But devm_clk_put part should > work > fine as call of it is before PM stuff. So, can I send a patch > reverting the change > of component part or do you want me to send a patch reverting whole change? Just fixing the problematic part is fine. signature.asc Description: Digital signature
RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks to process hvsock connection
> -Original Message- > From: Dexuan Cui > Sent: Friday, August 7, 2015 3:27 AM > To: KY Srinivasan ; David Miller > > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > driverdev-de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > step...@networkplumber.org; stefa...@redhat.com; > net...@vger.kernel.org; a...@canonical.com; pebo...@tiscali.nl; > dan.carpen...@oracle.com > Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks > to process hvsock connection > > > -Original Message- > > From: KY Srinivasan > > Sent: Friday, August 7, 2015 2:28 > > To: Dexuan Cui ; David Miller > > > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > > driverdev-de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > > step...@networkplumber.org; stefa...@redhat.com; > net...@vger.kernel.org; > > a...@canonical.com; pebo...@tiscali.nl; dan.carpen...@oracle.com > > Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register > callbacks to > > process hvsock connection > > > > > -Original Message- > > > From: Dexuan Cui > > > Sent: Wednesday, August 5, 2015 9:54 PM > > > To: David Miller ; KY Srinivasan > > > > > > Cc: o...@aepfle.de; gre...@linuxfoundation.org; > jasow...@redhat.com; > > > driverdev-de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > > > step...@networkplumber.org; stefa...@redhat.com; > > > net...@vger.kernel.org; a...@canonical.com; pebo...@tiscali.nl; > > > dan.carpen...@oracle.com > > > Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register > callbacks > > > to process hvsock connection > > > > > > > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] > On > > > Behalf > > > > Of Dexuan Cui > > > > Sent: Thursday, July 30, 2015 18:20 > > > > To: David Miller ; KY Srinivasan > > > > > > > Cc: o...@aepfle.de; gre...@linuxfoundation.org; > jasow...@redhat.com; > > > > driverdev-de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > > > > step...@networkplumber.org; stefa...@redhat.com; > > > net...@vger.kernel.org; > > > > a...@canonical.com; pebo...@tiscali.nl; dan.carpen...@oracle.com > > > > Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register > > > callbacks to > > > > process hvsock connection > > > > > > > > > From: David Miller > > > > > Sent: Thursday, July 30, 2015 6:27 > > > > > > > > > > From: Dexuan Cui > > > > > Date: Tue, 28 Jul 2015 05:35:11 -0700 > > > > > > > > > > > With the 2 APIs supplied by the VMBus driver, the coming > net/hvsock > > > driver > > > > > > can register 2 callbacks and can know when a new hvsock > connection is > > > > > > offered by the host, and when a hvsock connection is being closed > by > > > the > > > > > > host. > > > > > > > > > > > This is an extremely terrible interface. > > > > > > > > > > It's an opaque hook that allows on registry, and it's solve purpose > > > > > is to allow a backdoor call into a foreign driver in another module. > > > > > > > > > > These are exactly the things we try to avoid. > > > > > > > > Hi David, > > > > Thanks a lot for your reviewing and the suggestion! > > > > > > > > > Why not create a real abstraction where clients register an object, > > > > > that can be contained as a sub-member inside of their own driver > > > > > private, that provides the callback registry mechanism. > > > > > > Hi David, > > > Can you please have a look at my below questions? > > > > > > I like your idea of a real abstraction. Your answer would definitely > > > help me to implement that correctly. > > > > > > > Please pardon me for my inexperience. > > > > Can you please be a bit more specific? > > > > I guess maybe you're referencing a common design pattern in the > driver > > > > code, so an example in some existing driver would be the best. :-) > > > > > > > > "clients register an object " -- > > > > does the "clients" mean the hvsock driver? > > > > and the "object" means the 2 callbacks? > > > > > > > > IMHO, here the vmbus driver has to synchronously pass the 2 events > > > > to the hvsock driver, so a "backdoor call into the hvsock driver" is > > > > inevitable anyway? > > > > > > > > e.g., in the path vmbus_process_offer() -> hvsock_process_offer(), the > > > > return value of the latter is important to the former, because on error > > > > the former needs to clean up some internal states of the vmbus driver > > > (that > > > > is, the "goto err_deq_chan"). > > > > > > > > > > > > > That way you can register multiple clients, do things like allow > > > > > AF_PACKET capturing of vmbus traffic, etc. > > > > > > > > I thought AF_PACKET can only capture IP packetsor Ethernet frames. > > > > Can it be used to capture AF_UNIX packet? > > > > If yes, I suppose we can consider making it work for AF_HYPERV too, > > > > if people ask for that. > > > > > > > > Dexuan, > > > > The notion of a channel on Hyper-V has been mapped to a device on Linux > and > > the mechanism we
Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On Mon, Aug 17, 2015 at 06:58:16PM -0500, Felipe Balbi wrote:
> On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote:
> > On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
> > > On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
> > > > + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
> > > Where the wm831x_pdata->usb_gadget is initialized?
> > It's platform data, it will be initialised by whatever registers the
> > platform data.
> passing pointers through pdata ?
It's a char * to a name, not a pointer to struct.
signature.asc
Description: Digital signature
RE: [v1 0/6] *** nps_enet fixups ***
From: David Miller [mailto:da...@davemloft.net] Sent: Monday, August 17, 2015 8:36 PM > You should not move TX completion out of NAPI handling, NAPI poll is exactly > where it belongs. > > If you handle it in hardware interrupt context you have to use > dev_kfree_skb_irq() which defers the operation to software interrupt context > anyways and is thus expensive. > Whereas if you keep TX completion in your NAPI handler the kfree is handled > synchronously and efficiently, as well as making SKB's potentially available > for RX reclaim. I followed "Hardware Architecture" section from: http://www.linuxfoundation.org/collaborate/workgroups/networking/napi and came up with "reduce processing latency" idea. Anyway, I will restore TX completion back to NAPI poll. > I'm not applying this series, you are doing with TX handling exactly what we > tell people not to do. I will come up with revised series in v2. Noam -- 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/
Re: [PATCH 02/20] staging: rtl8192u: r8192U_core: fix consistent spacing code style error
On Sat, Aug 15, 2015 at 09:33:58PM -0400, Raphaël Beamonte wrote: > Fix multiple occurences of the need consistent spacing code style error > > Signed-off-by: Raphaël Beamonte > --- > drivers/staging/rtl8192u/r8192U_core.c | 28 ++-- > 1 file changed, 14 insertions(+), 14 deletions(-) > > diff --git a/drivers/staging/rtl8192u/r8192U_core.c > b/drivers/staging/rtl8192u/r8192U_core.c > index 915493d..c4ab2a8 100644 > --- a/drivers/staging/rtl8192u/r8192U_core.c > +++ b/drivers/staging/rtl8192u/r8192U_core.c > @@ -2182,8 +2182,8 @@ static void rtl8192_init_priv_variable(struct > net_device *dev) > priv->EarlyRxThreshold = 7; > priv->enable_gpio0 = 0; > priv->TransmitConfig = > - (TCR_MXDMA_2048< Tx DMA Burst, 7: reserved. > - (priv->ShortRetryLimit< limit > + (TCR_MXDMA_2048< Tx DMA Burst, 7: reserved. > + (priv->ShortRetryLimit< limit since you are modifying these lines for consistent spacing, it will be better to have: (priv->ShortRetryLimit << TCR_SRL_OFFSET) | // Short retry limit > > @@ -2304,7 +2304,7 @@ static void rtl8192_read_eeprom_info(struct net_device > *dev) > tmpValue = eprom_read(dev, EEPROM_ChannelPlan>>1); > priv->eeprom_ChannelPlan = (tmpValue & 0xff00)>>8; > priv->btxpowerdata_readfromEEPORM = true; > - priv->eeprom_CustomerID = eprom_read(dev, > (EEPROM_Customer_ID>>1)) >>8; > + priv->eeprom_CustomerID = eprom_read(dev, > (EEPROM_Customer_ID>>1))>>8; This should be: priv->eeprom_CustomerID = eprom_read(dev, (EEPROM_Customer_ID>>1)) >> 8; regards sudip -- 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/
Re: [PATCH 1/3] mtd: nand: pxa3xx_nand: add register access debug
On 11 Aug 09:57 PM, Robert Jarzmik wrote:
> Add verbose debug for register accesses. This enables easier debugging
> by following where and how hardware is stimulated, and how it answers.
>
I really don't see why we want this patch. It's probably an useful hack to
use in some cases, but can't see why we would want it in mainline.
Feel free to prove me wrong.
> Signed-off-by: Robert Jarzmik
> ---
> drivers/mtd/nand/pxa3xx_nand.c | 22 +-
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
> index 1259cc558ce9..ed44bddcc43f 100644
> --- a/drivers/mtd/nand/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/pxa3xx_nand.c
> @@ -127,11 +127,23 @@
> #define EXT_CMD_TYPE_MONO0 /* Monolithic read/write */
>
> /* macros for registers read/write */
> -#define nand_writel(info, off, val) \
> - writel_relaxed((val), (info)->mmio_base + (off))
> -
> -#define nand_readl(info, off)\
> - readl_relaxed((info)->mmio_base + (off))
> +#define nand_writel(info, off, val) \
> + do {\
> + dev_vdbg(>pdev->dev, \
> + "%s():%d nand_writel(0x%x, %s)\n", \
> + __func__, __LINE__, (val), #off); \
> + writel_relaxed((val), (info)->mmio_base + (off)); \
> + } while (0)
> +
> +#define nand_readl(info, off)
> \
> + ({ \
> + unsigned int _v;\
> + _v = readl_relaxed((info)->mmio_base + (off)); \
> + dev_vdbg(>pdev->dev, \
> + "%s():%d nand_readl(%s): 0x%x\n", \
> + __func__, __LINE__, #off, _v); \
> + _v; \
> + })
>
> /* error code and state */
> enum {
> --
> 2.1.4
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
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/
Re: [PATCHv3] staging: wilc1000: use netdev_* instead of printk
On Mon, Aug 17, 2015 at 07:06:40PM -0400, Raphaël Beamonte wrote:
> Signed-off-by: Raphaël Beamonte
> ---
> drivers/staging/wilc1000/coreconfigurator.c | 4 ++--
> drivers/staging/wilc1000/linux_wlan.c| 8
> drivers/staging/wilc1000/linux_wlan_common.h | 28
> ++--
> drivers/staging/wilc1000/linux_wlan_sdio.c | 2 +-
> drivers/staging/wilc1000/linux_wlan_spi.c| 2 +-
> drivers/staging/wilc1000/wilc_debugfs.c | 16
> drivers/staging/wilc1000/wilc_exported_buf.c | 2 --
> 7 files changed, 30 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c
> b/drivers/staging/wilc1000/coreconfigurator.c
> index 16a0abc..9a36b78 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -2001,7 +2001,7 @@ s32 SendConfigPkt(u8 u8Mode, tstrWID *pstrWIDs,
>
> pstrWIDs[counter].u16WIDid,
> (counter ==
> u32WIDsCount - 1), drvHandler)) {
> ret = -1;
> - printk("[Sendconfigpkt]Get Timed out\n");
> + netdev_err("[Sendconfigpkt]Get Timed out\n");
This will not compile. you can not just replace printk with
netdev_*, you need to mention a net_device.
regards
sudip
--
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/
Re: [PATCH v3 33/51] resources: Make allocate_resource return just fit resource
On Mon, Jul 27, 2015 at 04:29:51PM -0700, Yinghai Lu wrote:
> Find all suitable empty slots and pick one just fit, so we could save
> the big slot for needed ones later when we have several pcie switches
> and some bridges get assigned bios and we need to assign others in kernel.
By "just fit," do you mean "best fit"? "Best fit" is a well-known term, so
if that's what you mean, let's use it.
I couldn't quite parse the PCIe switch stuff here. How is that relevant to
this change?
> Signed-off-by: Yinghai Lu
> ---
> kernel/resource.c | 81
> ++-
> 1 file changed, 68 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 67b58a5..697b8ca 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -48,6 +48,7 @@ struct resource_constraint {
> resource_size_t (*alignf)(void *, const struct resource *,
> resource_size_t, resource_size_t);
> void *alignf_data;
> + bool fit;
> };
>
> static DEFINE_RWLOCK(resource_lock);
> @@ -554,12 +555,15 @@ static void resource_clip(struct resource *res,
> resource_size_t min,
> * alignment constraints
> */
> static int __find_resource(struct resource *root, struct resource *old,
> - struct resource *new,
> + struct resource *new, struct resource *avail,
>resource_size_t size,
>struct resource_constraint *constraint)
> {
> struct resource *this = root->child;
> - struct resource tmp = *new, avail, alloc;
> + struct resource tmp = *new, availx, alloc;
> +
> + if (!avail || avail == new)
> + avail =
>
> tmp.start = root->start;
> /*
> @@ -583,15 +587,16 @@ static int __find_resource(struct resource *root,
> struct resource *old,
> arch_remove_reservations();
>
> /* Check for overflow after ALIGN() */
> - avail.start = ALIGN(tmp.start, constraint->align);
> - avail.end = tmp.end;
> - avail.flags = new->flags & ~IORESOURCE_UNSET;
> - if (avail.start >= tmp.start) {
> - alloc.flags = avail.flags;
> - alloc.start =
> constraint->alignf(constraint->alignf_data, ,
> + avail->start = ALIGN(tmp.start, constraint->align);
> + avail->end = tmp.end;
> + avail->flags = new->flags & ~IORESOURCE_UNSET;
> + if (avail->start >= tmp.start) {
> + alloc.flags = avail->flags;
> + alloc.start = constraint->alignf(
> + constraint->alignf_data, avail,
> size, constraint->align);
> alloc.end = alloc.start + size - 1;
> - if (resource_contains(, )) {
> + if (resource_contains(avail, )) {
> new->start = alloc.start;
> new->end = alloc.end;
> return 0;
> @@ -608,6 +613,11 @@ next:if (!this || this->end == root->end)
> return -EBUSY;
> }
>
> +struct good_resource {
> + struct list_head list;
> + struct resource avail;
> + struct resource new;
> +};
> /*
> * Find empty slot in the resource tree given range and alignment.
> */
> @@ -615,7 +625,49 @@ static int find_resource(struct resource *root, struct
> resource *new,
> resource_size_t size,
> struct resource_constraint *constraint)
> {
> - return __find_resource(root, NULL, new, size, constraint);
> + int ret = -1;
> + LIST_HEAD(head);
> + struct good_resource *good, *tmp;
> + resource_size_t avail_size = (resource_size_t)-1ULL;
> +
> + if (!constraint->fit)
> + return __find_resource(root, NULL, new, NULL, size,
> + constraint);
> +
> + /* find all suitable ones and add to the list */
> + for (;;) {
> + good = kzalloc(sizeof(*good), GFP_KERNEL);
> + if (!good)
> + break;
> +
> + good->new.start = new->start;
> + good->new.end = new->end;
> + good->new.flags = new->flags;
> + ret = __find_resource(root, NULL, >new, >avail,
> + size, constraint);
> + if (ret || __request_resource(root, >avail)) {
> + ret = -EBUSY;
> + kfree(good);
> + break;
> + }
> +
> + list_add(>list, );
> + }
Allocating memory and building a list in a function that allocates space
seems like a little bit of a hack. I think we're holding resource_lock
anyway; can't we just find a candidate, reserve it, look for another one,
reserve it, release the larger one, and repeat?
> + /* pick up
Re: [PATCH v3 32/51] resources: Split out __allocate_resource()
On Mon, Jul 27, 2015 at 04:29:50PM -0700, Yinghai Lu wrote:
> It will not hold lock, so we could use it in other functions that
> hold the resource lock already.
What's the benefit of this patch? Does it fix something? Does it add some
functionality we need?
>
> -v2: according to Linus, using "bool lock" as parameter
> aka "conditionally take lock" is *wrong*.
>
> Signed-off-by: Yinghai Lu
> Acked-by: Linus Torvalds
> ---
> kernel/resource.c | 70
> +++
> 1 file changed, 50 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/resource.c b/kernel/resource.c
> index fed052a..67b58a5 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -619,7 +619,7 @@ static int find_resource(struct resource *root, struct
> resource *new,
> }
>
> /**
> - * reallocate_resource - allocate a slot in the resource tree given range &
> alignment.
> + * __reallocate_resource - allocate a slot in the resource tree given range
> & alignment.
> * The resource will be relocated if the new size cannot be reallocated in
> the
> * current location.
> *
> @@ -628,7 +628,7 @@ static int find_resource(struct resource *root, struct
> resource *new,
> * @newsize: new size of the resource descriptor
> * @constraint: the size and alignment constraints to be met.
> */
> -static int reallocate_resource(struct resource *root, struct resource *old,
> +static int __reallocate_resource(struct resource *root, struct resource *old,
> resource_size_t newsize,
> struct resource_constraint *constraint)
> {
> @@ -636,8 +636,6 @@ static int reallocate_resource(struct resource *root,
> struct resource *old,
> struct resource new = *old;
> struct resource *conflict;
>
> - write_lock(_lock);
> -
> if ((err = __find_resource(root, old, , newsize, constraint)))
> goto out;
>
> @@ -662,14 +660,13 @@ static int reallocate_resource(struct resource *root,
> struct resource *old,
> BUG_ON(conflict);
> }
> out:
> - write_unlock(_lock);
> return err;
> }
>
> -
> /**
> - * allocate_resource - allocate empty slot in the resource tree given range
> & alignment.
> - * The resource will be reallocated with a new size if it was already
> allocated
> + * __allocate_resource - allocate empty slot in the resource tree given
> range & alignment.
> + * The resource will be reallocated with a new size if it was already
> + * allocated
> * @root: root resource descriptor
> * @new: resource descriptor desired by caller
> * @size: requested resource region size
> @@ -678,15 +675,17 @@ out:
> * @align: alignment requested, in bytes
> * @alignf: alignment function, optional, called if not NULL
> * @alignf_data: arbitrary data to pass to the @alignf function
> + *
> + * Caller need to hold resource_lock if needed.
> */
> -int allocate_resource(struct resource *root, struct resource *new,
> - resource_size_t size, resource_size_t min,
> - resource_size_t max, resource_size_t align,
> - resource_size_t (*alignf)(void *,
> - const struct resource *,
> - resource_size_t,
> - resource_size_t),
> - void *alignf_data)
> +static int __allocate_resource(struct resource *root, struct resource *new,
> + resource_size_t size, resource_size_t min,
> + resource_size_t max, resource_size_t align,
> + resource_size_t (*alignf)(void *,
> + const struct resource *,
> + resource_size_t,
> + resource_size_t),
> + void *alignf_data)
> {
> int err;
> struct resource_constraint constraint;
> @@ -700,20 +699,51 @@ int allocate_resource(struct resource *root, struct
> resource *new,
> constraint.alignf = alignf;
> constraint.alignf_data = alignf_data;
>
> - if ( new->parent ) {
> + if (new->parent) {
> /* resource is already allocated, try reallocating with
> the new constraints */
> - return reallocate_resource(root, new, size, );
> + return __reallocate_resource(root, new, size, );
> }
>
> - write_lock(_lock);
> err = find_resource(root, new, size, );
> if (err >= 0 && __request_resource(root, new))
> err = -EBUSY;
> - write_unlock(_lock);
> +
> return err;
> }
>
> +/**
> + * allocate_resource - allocate empty slot in the resource tree given range
> & alignment.
> + * The resource will be reallocated with a new size if it was already
> + * allocated
> + * @root: root
Re: [PATCH v3 28/51] PCI: Unifiy calculate_size for io port and mmio
On Mon, Jul 27, 2015 at 04:29:46PM -0700, Yinghai Lu wrote:
> We should check size+size1 with min_size for io port.
> For example, when hotplug bridge has two children bridges,
> every child bridge will need 0x1000, so size1 will be 0x2000
> and size is 0. The min_size for the hotplug bridge is 0x100.
A min_size of 0x100? Is that a typo?
> with old version calculate_iosize, we get 0x3000 for final
> size because we are using size to compare with min_size. That is
> not right, we should use 0x2000 instead.
If this fixes a bug, please make one patch that *only* fixes the bug,
and a separate one that unifies but doesn't change the behavior.
> After this change, calculate_memsize and calculate_iosize
> is the same.
>
> Change them to calculate_size.
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/setup-bus.c | 27 ++-
> 1 file changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 3db2838..aeed716 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1116,23 +1116,7 @@ static struct resource *find_free_bus_resource(struct
> pci_bus *bus,
> return NULL;
> }
>
> -static resource_size_t calculate_iosize(resource_size_t size,
> - resource_size_t min_size,
> - resource_size_t size1,
> - resource_size_t old_size,
> - resource_size_t align)
> -{
> - if (size < min_size)
> - size = min_size;
> - if (old_size == 1)
> - old_size = 0;
> - size = ALIGN(size + size1, align);
> - if (size < old_size)
> - size = old_size;
> - return size;
> -}
> -
> -static resource_size_t calculate_memsize(resource_size_t size,
> +static resource_size_t calculate_size(resource_size_t size,
> resource_size_t min_size,
> resource_size_t old_size,
> resource_size_t align)
> @@ -1257,14 +1241,15 @@ static void pbus_size_io(struct pci_bus *bus,
> resource_size_t min_size,
> }
>
> size = size_aligned_for_isa(size);
> - size0 = calculate_iosize(size, min_size, size1,
> + size += size1;
> + size0 = calculate_size(size, min_size,
> resource_size(b_res), min_align);
> sum_add_size = size_aligned_for_isa(sum_add_size);
> sum_add_size += sum_add_size1;
> if (sum_add_size < min_sum_size)
> sum_add_size = min_sum_size;
> size1 = !realloc_head ? size0 :
> - calculate_iosize(sum_add_size, min_size, 0,
> + calculate_size(sum_add_size, min_size,
> resource_size(b_res), min_align);
> if (!size0 && !size1) {
> if (b_res->start || b_res->end)
> @@ -1617,7 +1602,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
> long mask,
> if (size || min_size) {
> min_align = calculate_mem_align(_test_list, max_align,
> size, window_align);
> - size0 = calculate_memsize(size, min_size,
> + size0 = calculate_size(size, min_size,
> resource_size(b_res), min_align);
> }
> free_align_test_list(_test_list);
> @@ -1642,7 +1627,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
> long mask,
> min_add_align = calculate_mem_align(_test_add_list,
> max_add_align, sum_add_size,
> window_align);
> - size1 = calculate_memsize(sum_add_size, min_size,
> + size1 = calculate_size(sum_add_size, min_size,
>resource_size(b_res), min_add_align);
> }
> free_align_test_list(_test_add_list);
> --
> 1.8.4.5
>
--
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/
Re: [PATCH v3 27/51] PCI: Move ISA ioport align out of calculate_iosize
On Mon, Jul 27, 2015 at 04:29:45PM -0700, Yinghai Lu wrote: > So we could unify calculate_iosize and calculate_memsize later. Please make this a complete sentence, not just a continuation of the summary line. > when one bridge have several children devices, and every devices > have several io port resources and resource size < 0x400. This isn't a sentence either, so I'm not sure what this is supposed to mean. > We need to check size, and add extra size to make sure bit8/9 > to be zero. -- 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/
Re: [PATCH v3 25/51] PCI: Fix size calculation with old_size on rescan path
On Mon, Jul 27, 2015 at 04:29:43PM -0700, Yinghai Lu wrote: > On booting path, we don't pass realloc at first, and treat all optional just > as must, in some case we can smaller size/align with optional than must only. > > 04:00.0 has four child bridges: 05:01.0, 05:02.0, 05:03.0, 05:04.0 > pref layout after booting path like followings: > > pci :04:00.0: BAR 9: assigned [mem 0x8400-0x9fff 64bit pref] > pci :05:04.0: BAR 9: assigned [mem 0x8800-0x9fff 64bit pref] > pci :05:03.0: BAR 9: assigned [mem 0x8400-0x841f 64bit pref] > pci :07:00.0: BAR 0: assigned [mem 0x8120-0x8123 64bit] > pci :05:03.0: PCI bridge to [bus 08-0f] > pci :05:03.0: bridge window [mem 0x8400-0x841f 64bit pref] > pci :10:00.0: BAR 0: assigned [mem 0x9000-0x9fff 64bit pref] > pci :10:00.0: BAR 2: assigned [mem 0x8800-0x8800 64bit pref] > pci :05:04.0: PCI bridge to [bus 10] > pci :05:04.0: bridge window [mem 0x8800-0x9fff 64bit pref] > pci :04:00.0: PCI bridge to [bus 05-10] > pci :04:00.0: bridge window [mem 0x8400-0x9fff 64bit pref] Unless 07:00.0 and 10:00.0 are relevant, please remove them. > so the old size in rescan for 04:00.0 would be 0x1c00, and align is > 0x400 > > during remove and rescan: > > pci :05:03.0: bridge window [mem 0x-0x 64bit > pref] to [bus 08-0f] add_size 20 add_align 10 alt_size 0 alt_align 0 > must_size 0 must_align 0 What is "[mem 0x-0x 64bit pref]" telling us? Surely that's not an actual aperture, is it? -- 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/
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
Apologies for the repeat. Gmail ate its plain text setting for some reason. Shame bells. On Mon, Aug 17, 2015 at 9:02 PM, Paul Turner wrote: > > > On Wed, Aug 5, 2015 at 7:31 AM, Tejun Heo wrote: >> >> Hello, >> >> On Wed, Aug 05, 2015 at 11:10:36AM +0200, Peter Zijlstra wrote: >> > > I've been thinking about it and I'm now convinced that cgroups just is >> > > the wrong interface to require each application to be programming >> > > against. >> > >> > But people are doing it. So you must give them something. You cannot >> > just tell them to go away. >> >> Sure, more on specifics later, but, first of all, the transition to v2 >> is a gradual process. The new and old hierarchies can co-exist, so >> nothing forces abrupt transitions. Also, we do want to start as >> restricted as possible and then widen it gradually as necessary. >> >> > So where are the people doing this in this discussion? Or are you >> > one-sidedly forcing things? IIRC Google was doing this. >> >> We've been having those discussions for years in person and on the >> cgroup mailing list. IIRC, the google case was for blkcg where they >> have an IO proxy process which wanna issue IOs as different cgroups >> depending on who's the original issuer. They created multiple >> threads, put them in different cgroups and bounce the IOs to the >> matching one; however, this is already pretty silly as they have to >> bounce IOs to different threads. What makes a lot more sense here is >> the ability to tag an IO as coming from a specific cgroup (or a >> process's cgroup) and there was discussion of using an extra field in >> aio request to indicate this, which is an a lot better solution for >> the problem, can also express different IO priority and pretty easy to >> implement. >> > > So we have two major types of use that are relevant to this interface: > > 1) Proxy agents. When a control systems want to perform work on behalf of a > container, they will sometimes move the acting thread into the relevant > control groups so that it can be accounted on that container's behalf. > [This is more relevant for non-persistent resources such as CPU time or I/O > priorities than charges that will outlive the work such as memory > allocations.] > > I agree (1) is at best a bit of a hack and can be worked around on the type > of time-frame these interfaces move at. > > 2) Control within an address-space. For subsystems with fungible resources, > e.g. CPU, it can be useful for an address space to partition its own > threads. Losing the capability to do this against the CPU controller would > be a large set-back for instance. Occasionally, it is useful to share these > groupings between address spaces when processes are cooperative, but this is > less of a requirement. > > This is important to us. > > >> > The whole libvirt trainwreck also does this (the programming against >> > cgroups, not the per task thing afaik). >> >> AFAIK, libvirt is doing multiple backends anyway and as long as the >> delegation rules are clear, libvirt managing its own subhierarchy is >> not a problem. It's an administration software stack which requires >> fairly close integration with the userland part of operating system. >> >> > You also cannot mandate system-disease, not everybody will want to run >> > that monster. From what I understood last time, Google has no interest >> > what so ever of using it. >> >> But what would require tight coupling of individual applications and >> something like systemd is the kernel failing to set up a reasonable >> boundary between management and application interfaces. If the kernel >> provides a useable API for individual applications to use, they'll >> program against it and the management part can be whatever. If we >> fail to do that, individual applications will have to talk to external >> agent to coordinate access to management interface > > > It's notable here that for a managed system, the agent coordinating access > *must* be external > >> >> and that's what'll >> end up creating hard dependency on specific system agents from >> applications like apache or mysql or whatever. We really don't want >> that. The kernel *NEEDS* to clearly distinguish those two to prevent >> that from happening. >> >> > > I wrote this in the CAT thread too but cgroups may be an >> > > okay management / administration interface but is a horrible >> > > programming interface to be used by individual applications. >> > >> > Yeah, I need to catch up on that CAT thread, but the reality is, people >> > use it as a programming interface, whether you like it or not. >> >> And that's one of the major fuck ups on cgroup's part that must be >> rectified. Look at the interface being proposed there. It's exposing >> direct hardware details w/o much abstraction which is fine for a >> system management interface but at the same time it's intended to be >> exposed to individual applications. > > > FWIW this is something we've had no significant problems
linux-next: manual merge of the trivial tree with the v4l-dvb tree
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in:
drivers/media/v4l2-core/videobuf2-memops.c
between commit:
6690c8c78c74 ("[media] media: vb2: Remove unused functions")
from the v4l-dvb tree and commit:
e1c05067c323 ("treewide: fix typos in comment blocks")
from the trivial tree.
I fixed it up (the former removed the code modified by the latter)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/
[PATCH v2 6/6] mtd: nand: gpmi: support NAND on i.MX6UL
support GPMI NAND on i.MX6UL
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 6 --
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 362cf4c..adadac2 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -89,6 +89,12 @@ static const struct gpmi_devdata gpmi_devdata_imx7d = {
.max_chain_delay = 12,
};
+static const struct gpmi_devdata gpmi_devdata_imx6ul = {
+ .type = IS_MX6UL,
+ .bch_max_ecc_strength = 40,
+ .max_chain_delay = 12,
+};
+
static irqreturn_t bch_irq(int irq, void *cookie)
{
struct gpmi_nand_data *this = cookie;
@@ -2016,6 +2022,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
.compatible = "fsl,imx6sx-gpmi-nand",
.data = _devdata_imx6sx,
}, {
+ .compatible = "fsl,imx6ul-gpmi-nand",
+ .data = (void *)_devdata_imx6ul,
+ }, {
.compatible = "fsl,imx7d-gpmi-nand",
.data = (void *)_devdata_imx7d,
}
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 36ffeda..8428637 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -125,7 +125,8 @@ enum gpmi_type {
IS_MX6Q,
IS_MX6QP,
IS_MX6SX,
- IS_MX7D
+ IS_MX7D,
+ IS_MX6UL
};
struct gpmi_devdata {
@@ -310,8 +311,9 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
#define GPMI_IS_MX6QP(x) ((x)->devdata->type == IS_MX6QP)
#define GPMI_IS_MX6SX(x) ((x)->devdata->type == IS_MX6SX)
#define GPMI_IS_MX7D(x)((x)->devdata->type == IS_MX7D)
+#define GPMI_IS_MX6UL(x) ((x)->devdata->type == IS_MX6UL)
#define GPMI_IS_MX6(x) (GPMI_IS_MX6Q(x) || GPMI_IS_MX6QP(x)\
- || GPMI_IS_MX6SX(x))
+ || GPMI_IS_MX6SX(x) || GPMI_IS_MX6UL(x))
#define GPMI_IS_MX7(x) (GPMI_IS_MX7D(x))
#endif
--
1.9.1
--
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/
Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection
On Mon, Aug 17, 2015 at 7:57 PM, Shaohua Li wrote: > On Mon, Aug 17, 2015 at 03:17:28PM -0700, John Stultz wrote: >> That said, I agree the "should"s and other vague qualifiers in the >> commit description you point out should have more specifics to back >> things up. And I'm fine delaying this (and the follow-on) patch until >> those details are provided. > > It's not something I guess. We do see the issue from time to time. The > IPMI driver accesses some IO ports in softirq and hog cpu for a very > long time, then the watchdog alert. The false alert on the other hand > has very worse effect. It forces to use HPET as clocksource, which has > very big performance penality. We can't even manually switch back to TSC > as current interface doesn't allow us to do it, then we can only reboot > the system. I agree the driver should be fixed, but the watchdog has > false alert, we definitively should fix it. I think Thomas is requesting that some of the vague terms be quantified. Seeing the issue "from time to time" isn't super informative. When the IPMI driver hogs the cpu "for a very long time", how long does that actually take? You've provided the HPET frequency, and the wrapping interval on your hardware. Do these intervals all line up properly? I sympathize that the "show-your-work" math problem aspect of this request might be a little remedial and irritating, esp when the patch fixes the problem for you. But its important, so later on when some bug crops up in near by code, folks can easily repeat your calculation and know the problem isn't from your code. > The 1s interval is arbitary. If you think there is better way to fix the > issue, please let me know. I don't think 1s is necessarily arbitrary. Maybe not much conscious thought was put into it, but clearly .001 sec wasn't chosen, nor 10minutes for a reason. So given the intervals you're seeing the problem with, would maybe a larger max interval (say 30-seconds) make more or less sense? What would the tradeoffs be? (ie: Would that exclude clocksources with faster wraps from being used as watchdogs, with your patches?). I'm sure an good interval could be chosen with some thought, and the rational be explained. :) thanks -john -- 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/
[PATCH v2 4/6] mtd: nand: gpmi: add GPMI NAND support for i.MX7D
support GPMI NAND on i.MX7D
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/bch-regs.h | 14 +++---
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 10 ++
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 24
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 7 +--
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h
b/drivers/mtd/nand/gpmi-nand/bch-regs.h
index 05bb91f..53e58bc 100644
--- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -1,7 +1,7 @@
/*
* Freescale GPMI NAND Flash Driver
*
- * Copyright 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright 2008-2015 Freescale Semiconductor, Inc.
* Copyright 2008 Embedded Alley Solutions, Inc.
*
* This program is free software; you can redistribute it and/or modify
@@ -54,7 +54,7 @@
#define MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0 11
#define MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0 (0x1f << MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0)
#define BF_BCH_FLASH0LAYOUT0_ECC0(v, x)\
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT0_ECC0) \
& MX6Q_BM_BCH_FLASH0LAYOUT0_ECC0) \
: (((v) << BP_BCH_FLASH0LAYOUT0_ECC0) \
@@ -65,7 +65,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14 \
(0x1 << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14)
#define BF_BCH_FLASH0LAYOUT0_GF(v, x) \
- ((GPMI_IS_MX6(x) && ((v) == 14))\
+ (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\
? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT0_GF_13_14) \
& MX6Q_BM_BCH_FLASH0LAYOUT0_GF_13_14) \
: 0 \
@@ -77,7 +77,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE \
(0x3ff << BP_BCH_FLASH0LAYOUT0_DATA0_SIZE)
#define BF_BCH_FLASH0LAYOUT0_DATA0_SIZE(v, x) \
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT0_DATA0_SIZE) \
: ((v) & BM_BCH_FLASH0LAYOUT0_DATA0_SIZE) \
)
@@ -96,7 +96,7 @@
#define MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN 11
#define MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN (0x1f << MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN)
#define BF_BCH_FLASH0LAYOUT1_ECCN(v, x)\
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) << MX6Q_BP_BCH_FLASH0LAYOUT1_ECCN) \
& MX6Q_BM_BCH_FLASH0LAYOUT1_ECCN) \
: (((v) << BP_BCH_FLASH0LAYOUT1_ECCN) \
@@ -107,7 +107,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14 \
(0x1 << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14)
#define BF_BCH_FLASH0LAYOUT1_GF(v, x) \
- ((GPMI_IS_MX6(x) && ((v) == 14))\
+ (((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) && ((v) == 14))\
? (((1) << MX6Q_BP_BCH_FLASH0LAYOUT1_GF_13_14) \
& MX6Q_BM_BCH_FLASH0LAYOUT1_GF_13_14) \
: 0 \
@@ -119,7 +119,7 @@
#define MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE \
(0x3ff << BP_BCH_FLASH0LAYOUT1_DATAN_SIZE)
#define BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(v, x) \
- (GPMI_IS_MX6(x) \
+ ((GPMI_IS_MX6(x) || GPMI_IS_MX7(x)) \
? (((v) >> 2) & MX6Q_BM_BCH_FLASH0LAYOUT1_DATAN_SIZE) \
: ((v) & BM_BCH_FLASH0LAYOUT1_DATAN_SIZE) \
)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 43fa16b..6b37414 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -1,7 +1,7 @@
/*
* Freescale GPMI NAND Flash Driver
*
- * Copyright (C) 2008-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2008-2015 Freescale Semiconductor, Inc.
* Copyright (C) 2008 Embedded Alley Solutions, Inc.
*
* This program is free software; you can redistribute it and/or modify
@@ -971,7 +971,8 @@ int gpmi_extra_init(struct gpmi_nand_data *this)
struct nand_chip *chip = >nand;
/* Enable the asynchronous EDO feature. */
- if (GPMI_IS_MX6(this) && chip->onfi_version) {
+ if ((GPMI_IS_MX6(this) || GPMI_IS_MX7(this))
+ && chip->onfi_version) {
int mode = onfi_get_async_timing_mode(chip);
/* We only support the timing mode 4 and mode
[PATCH v2 3/6] mtd: nand: gpmi: may use minimum required ecc for 744 oobsize NAND
By default NAND driver will choose the highest ecc strength that oob
could contain, in this case, for some 8K+744 NAND flash, the ecc
strength will be up to 52bit, which beyonds the i.MX6QDL BCH capability
(40bit).
This patch allows the NAND driver try to use minimum required ecc
strength if it failed to use the highest ecc, even without explicitly
claiming "fsl,use-minimum-ecc" in dts.
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index dfd0ba1..01d24dd 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -136,7 +136,7 @@ static inline bool gpmi_check_ecc(struct gpmi_nand_data
*this)
*
* We may have available oob space in this case.
*/
-static bool set_geometry_by_ecc_info(struct gpmi_nand_data *this)
+static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
{
struct bch_geometry *geo = >bch_geometry;
struct mtd_info *mtd = >mtd;
@@ -145,7 +145,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data
*this)
unsigned int block_mark_bit_offset;
if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
- return false;
+ return -EINVAL;
switch (chip->ecc_step_ds) {
case SZ_512:
@@ -158,19 +158,19 @@ static bool set_geometry_by_ecc_info(struct
gpmi_nand_data *this)
dev_err(this->dev,
"unsupported nand chip. ecc bits : %d, ecc size : %d\n",
chip->ecc_strength_ds, chip->ecc_step_ds);
- return false;
+ return -EINVAL;
}
geo->ecc_chunk_size = chip->ecc_step_ds;
geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
if (!gpmi_check_ecc(this))
- return false;
+ return -EINVAL;
/* Keep the C >= O */
if (geo->ecc_chunk_size < mtd->oobsize) {
dev_err(this->dev,
"unsupported nand chip. ecc size: %d, oob size : %d\n",
chip->ecc_step_ds, mtd->oobsize);
- return false;
+ return -EINVAL;
}
/* The default value, see comment in the legacy_set_geometry(). */
@@ -242,7 +242,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data
*this)
+ ALIGN(geo->ecc_chunk_count, 4);
if (!this->swap_block_mark)
- return true;
+ return 0;
/* For bit swap. */
block_mark_bit_offset = mtd->writesize * 8 -
@@ -251,7 +251,7 @@ static bool set_geometry_by_ecc_info(struct gpmi_nand_data
*this)
geo->block_mark_byte_offset = block_mark_bit_offset / 8;
geo->block_mark_bit_offset = block_mark_bit_offset % 8;
- return true;
+ return 0;
}
static int legacy_set_geometry(struct gpmi_nand_data *this)
@@ -366,10 +366,12 @@ static int legacy_set_geometry(struct gpmi_nand_data
*this)
int common_nfc_set_geometry(struct gpmi_nand_data *this)
{
- if (of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc")
- && set_geometry_by_ecc_info(this))
- return 0;
- return legacy_set_geometry(this);
+
+ if ((of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc"))
+ || legacy_set_geometry(this))
+ return set_geometry_by_ecc_info(this);
+
+ return 0;
}
struct dma_chan *get_dma_chan(struct gpmi_nand_data *this)
--
1.9.1
--
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/
[PATCH v2 1/6] mtd: nand: gpmi: add gpmi dsm supend/resume support
From: Huang Shijie
i.MX6SX supports deep sleep mode(DSM) that may turn off GPMI/BCH power
during suspend, add gpmi nand suspend/resume function to release DMA
channel in suspend function and re-init GPMI/BCH controller during
resume function.
Although it is not necessary to restore GPMI/BCH registers value for
i.MX6QDL, the code doesn't distinguish different platforms to keep the
code simple.
Signed-off-by: Huang Shijie
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 45 +-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 1b8f350..dfd0ba1 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1,7 +1,7 @@
/*
* Freescale GPMI NAND Flash Driver
*
- * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2015 Freescale Semiconductor, Inc.
* Copyright (C) 2008 Embedded Alley Solutions, Inc.
*
* This program is free software; you can redistribute it and/or modify
@@ -2036,9 +2036,52 @@ static int gpmi_nand_remove(struct platform_device *pdev)
return 0;
}
+static int gpmi_pm_suspend(struct device *dev)
+{
+ struct gpmi_nand_data *this = dev_get_drvdata(dev);
+
+ release_dma_channels(this);
+ return 0;
+}
+
+static int gpmi_pm_resume(struct device *dev)
+{
+ struct gpmi_nand_data *this = dev_get_drvdata(dev);
+ int ret;
+
+ ret = acquire_dma_channels(this);
+ if (ret < 0)
+ return ret;
+
+ /* re-init the GPMI registers */
+ this->flags &= ~GPMI_TIMING_INIT_OK;
+ ret = gpmi_init(this);
+ if (ret) {
+ dev_err(this->dev, "Error setting GPMI : %d\n", ret);
+ return ret;
+ }
+
+ /* re-init the BCH registers */
+ ret = bch_set_geometry(this);
+ if (ret) {
+ dev_err(this->dev, "Error setting BCH : %d\n", ret);
+ return ret;
+ }
+
+ /* re-init others */
+ gpmi_extra_init(this);
+
+ return 0;
+}
+
+static const struct dev_pm_ops gpmi_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(gpmi_pm_suspend, gpmi_pm_resume)
+};
+
static struct platform_driver gpmi_nand_driver = {
.driver = {
.name = "gpmi-nand",
+ .pm = _pm_ops,
.of_match_table = gpmi_nand_id_table,
},
.probe = gpmi_nand_probe,
--
1.9.1
--
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/
[PATCH v2 5/6] mtd: nand: gpmi: correct bitflip for erased NAND page
i.MX6QP and i.MX7D BCH module integrated a new feature to detect the
bitflip number for erased NAND page. So for these two platform, set the
erase threshold to gf/2 and if bitflip detected, GPMI driver will
correct the data to all 0xFF.
Signed-off-by: Han Xu
---
drivers/mtd/nand/gpmi-nand/bch-regs.h | 10 ++
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 5 +
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 24 +++-
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 5 -
4 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/bch-regs.h
b/drivers/mtd/nand/gpmi-nand/bch-regs.h
index 53e58bc..a84d72b 100644
--- a/drivers/mtd/nand/gpmi-nand/bch-regs.h
+++ b/drivers/mtd/nand/gpmi-nand/bch-regs.h
@@ -30,7 +30,13 @@
#define BM_BCH_CTRL_COMPLETE_IRQ (1 << 0)
#define HW_BCH_STATUS0 0x0010
+
#define HW_BCH_MODE0x0020
+#define BP_BCH_MODE_ERASE_THRESHOLD0
+#define BM_BCH_MODE_ERASE_THRESHOLD(0xff << BP_BCH_MODE_ERASE_THRESHOLD)
+#define BF_BCH_MODE_ERASE_THRESHOLD(v) \
+ (((v) << BP_BCH_MODE_ERASE_THRESHOLD) & BM_BCH_MODE_ERASE_THRESHOLD)
+
#define HW_BCH_ENCODEPTR 0x0030
#define HW_BCH_DATAPTR 0x0040
#define HW_BCH_METAPTR 0x0050
@@ -125,4 +131,8 @@
)
#define HW_BCH_VERSION 0x0160
+#define HW_BCH_DEBUG1 0x0170
+#define BP_BCH_DEBUG1_ERASED_ZERO_COUNT0
+#define BM_BCH_DEBUG1_ERASED_ZERO_COUNT\
+ (0x1ff << BP_BCH_DEBUG1_ERASED_ZERO_COUNT)
#endif
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 6b37414..f00ce90 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -298,6 +298,11 @@ int bch_set_geometry(struct gpmi_nand_data *this)
| BF_BCH_FLASH0LAYOUT1_DATAN_SIZE(block_size, this),
r->bch_regs + HW_BCH_FLASH0LAYOUT1);
+ /* Set erase threshold to ecc_strength for mx6qp and mx7 */
+ if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+ writel(BF_BCH_MODE_ERASE_THRESHOLD(ecc_strength),
+ r->bch_regs + HW_BCH_MODE);
+
/* Set *all* chip selects to use layout 0. */
writel(0, r->bch_regs + HW_BCH_LAYOUTSELECT);
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 0462103..362cf4c 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -71,6 +71,12 @@ static const struct gpmi_devdata gpmi_devdata_imx6q = {
.max_chain_delay = 12,
};
+static const struct gpmi_devdata gpmi_devdata_imx6qp = {
+ .type = IS_MX6QP,
+ .bch_max_ecc_strength = 40,
+ .max_chain_delay = 12,
+};
+
static const struct gpmi_devdata gpmi_devdata_imx6sx = {
.type = IS_MX6SX,
.bch_max_ecc_strength = 62,
@@ -1010,6 +1016,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
{
struct gpmi_nand_data *this = chip->priv;
struct bch_geometry *nfc_geo = >bch_geometry;
+ void __iomem *bch_regs = this->resources.bch_regs;
void *payload_virt;
dma_addr_tpayload_phys;
void *auxiliary_virt;
@@ -1018,6 +1025,7 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
unsigned char *status;
unsigned int max_bitflips = 0;
int ret;
+ int flag = 0;
dev_dbg(this->dev, "page number is : %d\n", page);
ret = read_page_prepare(this, buf, nfc_geo->payload_size,
@@ -1050,9 +1058,16 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
- if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
+ if (*status == STATUS_GOOD)
continue;
+ if (*status == STATUS_ERASED) {
+ if (GPMI_IS_MX6QP(this) || GPMI_IS_MX7(this))
+ if (readl(bch_regs + HW_BCH_DEBUG1))
+ flag = 1;
+ continue;
+ }
+
if (*status == STATUS_UNCORRECTABLE) {
mtd->ecc_stats.failed++;
continue;
@@ -1081,6 +1096,10 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *chip,
nfc_geo->payload_size,
payload_virt, payload_phys);
+ /* if bitflip occurred in erased page, change data to all 0xff */
+ if (flag)
+ memset(buf, 0xff, nfc_geo->payload_size);
+
[PATCH v2 2/6] dmaengine: mxs: support i.MX7D and deep sleep mode
From: Huang Shijie
The patch support i.MX7D platform by adding extra DMA clock.
Deep Sleep Mode(dsm) turns off the power for APBH DMA module, add
suspend/resume function and re-init the APBH DMA during resume.
Signed-off-by: Huang Shijie
Signed-off-by: Han Xu
Signed-off-by: Adrian Alonso
---
drivers/dma/mxs-dma.c | 73 ++-
1 file changed, 67 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index 60de352..2b0915d 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011-2015 Freescale Semiconductor, Inc. All Rights Reserved.
*
* Refer to drivers/dma/imx-sdma.c
*
@@ -28,7 +28,6 @@
#include
#include
#include
-
#include
#include "dmaengine.h"
@@ -135,6 +134,7 @@ enum mxs_dma_devtype {
enum mxs_dma_id {
IMX23_DMA,
IMX28_DMA,
+ IMX7D_DMA,
};
struct mxs_dma_engine {
@@ -142,6 +142,7 @@ struct mxs_dma_engine {
enum mxs_dma_devtypetype;
void __iomem*base;
struct clk *clk;
+ struct clk *clk_io;
struct dma_device dma_device;
struct device_dma_parametersdma_parms;
struct mxs_dma_chan mxs_chans[MXS_DMA_CHANNELS];
@@ -167,6 +168,9 @@ static struct mxs_dma_type mxs_dma_types[] = {
}, {
.id = IMX28_DMA,
.type = MXS_DMA_APBX,
+ }, {
+ .id = IMX7D_DMA,
+ .type = MXS_DMA_APBH,
}
};
@@ -184,6 +188,9 @@ static const struct platform_device_id mxs_dma_ids[] = {
.name = "imx28-dma-apbx",
.driver_data = (kernel_ulong_t) _dma_types[3],
}, {
+ .name = "imx7d-dma-apbh",
+ .driver_data = (kernel_ulong_t) _dma_types[4],
+ }, {
/* end of list */
}
};
@@ -193,6 +200,7 @@ static const struct of_device_id mxs_dma_dt_ids[] = {
{ .compatible = "fsl,imx23-dma-apbx", .data = _dma_ids[1], },
{ .compatible = "fsl,imx28-dma-apbh", .data = _dma_ids[2], },
{ .compatible = "fsl,imx28-dma-apbx", .data = _dma_ids[3], },
+ { .compatible = "fsl,imx7d-dma-apbh", .data = _dma_ids[4], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_dma_dt_ids);
@@ -440,6 +448,12 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan
*chan)
if (ret)
goto err_clk;
+ if (mxs_dma->dev_id == IMX7D_DMA) {
+ ret = clk_prepare_enable(mxs_dma->clk_io);
+ if (ret)
+ goto err_clk_unprepare;
+ }
+
mxs_dma_reset_chan(chan);
dma_async_tx_descriptor_init(_chan->desc, chan);
@@ -450,6 +464,8 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan
*chan)
return 0;
+err_clk_unprepare:
+ clk_disable_unprepare(mxs_dma->clk);
err_clk:
free_irq(mxs_chan->chan_irq, mxs_dma);
err_irq:
@@ -471,6 +487,9 @@ static void mxs_dma_free_chan_resources(struct dma_chan
*chan)
dma_free_coherent(mxs_dma->dma_device.dev, CCW_BLOCK_SIZE,
mxs_chan->ccw, mxs_chan->ccw_phys);
+ if (mxs_dma->dev_id == IMX7D_DMA)
+ clk_disable_unprepare(mxs_dma->clk_io);
+
clk_disable_unprepare(mxs_dma->clk);
}
@@ -693,7 +712,7 @@ static enum dma_status mxs_dma_tx_status(struct dma_chan
*chan,
return mxs_chan->status;
}
-static int __init mxs_dma_init(struct mxs_dma_engine *mxs_dma)
+static int mxs_dma_init(struct mxs_dma_engine *mxs_dma)
{
int ret;
@@ -701,6 +720,12 @@ static int __init mxs_dma_init(struct mxs_dma_engine
*mxs_dma)
if (ret)
return ret;
+ if (mxs_dma->dev_id == IMX7D_DMA) {
+ ret = clk_prepare_enable(mxs_dma->clk_io);
+ if (ret)
+ goto err_out;
+ }
+
ret = stmp_reset_block(mxs_dma->base);
if (ret)
goto err_out;
@@ -803,9 +828,19 @@ static int __init mxs_dma_probe(struct platform_device
*pdev)
if (IS_ERR(mxs_dma->base))
return PTR_ERR(mxs_dma->base);
- mxs_dma->clk = devm_clk_get(>dev, NULL);
- if (IS_ERR(mxs_dma->clk))
- return PTR_ERR(mxs_dma->clk);
+ if (mxs_dma->dev_id == IMX7D_DMA) {
+ mxs_dma->clk = devm_clk_get(>dev, "dma_apbh_bch");
+ if (IS_ERR(mxs_dma->clk))
+ return PTR_ERR(mxs_dma->clk);
+ mxs_dma->clk_io = devm_clk_get(>dev, "dma_apbh_io");
+ if (IS_ERR(mxs_dma->clk_io))
+ return PTR_ERR(mxs_dma->clk_io);
+
+ } else {
+ mxs_dma->clk = devm_clk_get(>dev, NULL);
+ if (IS_ERR(mxs_dma->clk))
+ return
[PATCH v2 0/6] mtd: nand: gpmi: gpmi-nand DSM and bitflip support
send the patchs to Huang Shijie's latest e-mail address v1 ---> v2 change the erased page bitflip threshold to ecc strength in bitflip patch Han Xu (4): mtd: nand: gpmi: may use minimum required ecc for 744 oobsize NAND mtd: nand: gpmi: add GPMI NAND support for i.MX7D mtd: nand: gpmi: correct bitflip for erased NAND page mtd: nand: gpmi: support NAND on i.MX6UL Huang Shijie (2): mtd: nand: gpmi: add gpmi dsm supend/resume support dmaengine: mxs: support i.MX7D and deep sleep mode drivers/dma/mxs-dma.c | 73 +-- drivers/mtd/nand/gpmi-nand/bch-regs.h | 24 +-- drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 15 ++-- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 126 - drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 14 +++- 5 files changed, 215 insertions(+), 37 deletions(-) -- 1.9.1 -- 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/
[PATCH] video: fbdev: Use devm_clk_get
This patch introduces the use of managed resource function
devm_clk_get instead of clk_get and removes corresponding calls
to clk_put in the probe and remove functions.
To be compatible with the change various gotos are replaced with
direct returns, and unneeded label failed_put_clk is dropped.
Signed-off-by: Vaishali Thakkar
---
drivers/video/fbdev/pxa168fb.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
index e209b03..efb57c0 100644
--- a/drivers/video/fbdev/pxa168fb.c
+++ b/drivers/video/fbdev/pxa168fb.c
@@ -615,7 +615,7 @@ static int pxa168fb_probe(struct platform_device *pdev)
return -EINVAL;
}
- clk = clk_get(>dev, "LCDCLK");
+ clk = devm_clk_get(>dev, "LCDCLK");
if (IS_ERR(clk)) {
dev_err(>dev, "unable to get LCDCLK");
return PTR_ERR(clk);
@@ -624,21 +624,18 @@ static int pxa168fb_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(>dev, "no IO memory defined\n");
- ret = -ENOENT;
- goto failed_put_clk;
+ return -ENOENT;
}
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(>dev, "no IRQ defined\n");
- ret = -ENOENT;
- goto failed_put_clk;
+ return -ENOENT;
}
info = framebuffer_alloc(sizeof(struct pxa168fb_info), >dev);
if (info == NULL) {
- ret = -ENOMEM;
- goto failed_put_clk;
+ return -ENOMEM;
}
/* Initialize private data */
@@ -776,8 +773,6 @@ failed_free_fbmem:
info->screen_base, fbi->fb_start_dma);
failed_free_info:
kfree(info);
-failed_put_clk:
- clk_put(clk);
dev_err(>dev, "frame buffer device init failed with %d\n", ret);
return ret;
@@ -813,7 +808,6 @@ static int pxa168fb_remove(struct platform_device *pdev)
info->screen_base, info->fix.smem_start);
clk_disable(fbi->clk);
- clk_put(fbi->clk);
framebuffer_release(info);
--
1.9.1
--
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/
Re: [PATCH RESEND] powerpc/numa: initialize distance lookup table from drconf path
On Tue, 2015-08-11 at 15:25 +0530, Nikunj A Dadhania wrote: > Hi Michael, > > Nikunj A Dadhania writes: > > In some situations, a NUMA guest that supports > > ibm,dynamic-memory-reconfiguration node will end up having flat NUMA > > distances between nodes. This is because of two problems in the > > current code. > > > > 1) Different representations of associativity lists. > > > >There is an assumption about the associativity list in > >initialize_distance_lookup_table(). Associativity list has two forms: > > > >a) [cpu,memory]@x/ibm,associativity has following > > format: > > > > > >b) ibm,dynamic-reconfiguration-memory/ibm,associativity-lookup-arrays > > > > > >M = the number of associativity lists > >N = the number of entries per associativity list > > > >Fix initialize_distance_lookup_table() so that it does not assume > >"case a". And update the caller to skip the length field before > >sending the associativity list. > > > > 2) Distance table not getting updated from drconf path. > > > >Node distance table will not get initialized in certain cases as > >ibm,dynamic-reconfiguration-memory path does not initialize the > >lookup table. > > > >Call initialize_distance_lookup_table() from drconf path with > >appropriate associativity list. > > > > Reported-by: Bharata B Rao > > Signed-off-by: Nikunj A Dadhania > > Acked-by: Anton Blanchard > > Have you pulled this? Nope. Will add it now. cheers -- 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/
linux-next: manual merge of the block tree with the crypto tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
crypto/ccm.c
between commit:
81c4c35eb61a ("crypto: ccm - Convert to new AEAD interface")
from the crypto tree and commit:
c56f6d1270b9 ("crypto: replace scatterwalk_sg_chain with sg_chain")
from the block tree.
I fixed it up (the former removed all the calls to scatterwalk_sg_chain)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/
Re: [PATCH] ARM: keystone: add a work around to handle asynchronous external abort
Murali, On 8/17/15 3:12 PM, Murali Karicheri wrote: On 08/14/2015 05:56 PM, Russell King - ARM Linux wrote: On Fri, Aug 14, 2015 at 05:53:00PM -0400, Murali Karicheri wrote: We have spend some time already to debug the root cause. Do you have idea on how this was hunted down on OMAP that we can learn from? The bad address is NULL and it seems to happen very rarely and is not easily reproducible. Don't want to put this workaround, but we couldn't track it down either. So any help to debug this will be appreciated. If you try applying Lucas' patch, you should receive the abort earlier in the kernel boot up, which may help narrow down what is provoking it. Unfortunately, this patch causes boot to stop very early just after local_abt_enable() is called in early_trap_init(). Before and After applying the patch, here is what the boot log looks like. Do you see any issue with the patch diff shown below? Patch is applied on top of v4.2-rc7. I have some additional base port patches applied to boot kernel on my EVM based on a new SoC. From the logs this seems to be mostly clock related issue for some peripheral. If the bootloader clock enable all hack still exists, may be you can try that out. Another way to debug this is to start disabling peripheral drivers from the kernel 1 by 1 and see if the issue goes away. Regards, Santosh -- 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/
Re: linux-next: build failure after merge of the drm-exynos tree
Hi Inki, On Mon, 17 Aug 2015 16:08:36 +0900 Inki Dae wrote: > > And today, I re-based exynos-drm/for-next on top of mainline. Could you > update and try to build it again? It is OK in today's linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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/
Re: [PATCH 8/9] clocksource: Improve unstable clocksource detection
On Mon, Aug 17, 2015 at 03:17:28PM -0700, John Stultz wrote:
> On Mon, Aug 17, 2015 at 3:04 PM, Thomas Gleixner wrote:
> > On Mon, 17 Aug 2015, John Stultz wrote:
> >
> >> From: Shaohua Li
> >>
> >> >From time to time we saw TSC is marked as unstable in our systems, while
> >
> > Stray '>'
> >
> >> the CPUs declare to have stable TSC. Looking at the clocksource unstable
> >> detection, there are two problems:
> >> - watchdog clock source wrap. HPET is the most common watchdog clock
> >> source. It's 32-bit and runs in 14.3Mhz. That means the hpet counter
> >> can wrap in about 5 minutes.
> >> - threshold isn't scaled against interval. The threshold is 0.0625s in
> >> 0.5s interval. What if the actual interval is bigger than 0.5s?
> >>
> >> The watchdog runs in a timer bh, so hard/soft irq can defer its running.
> >> Heavy network stack softirq can hog a cpu. IPMI driver can disable
> >> interrupt for a very long time.
> >
> > And they hold off the timer softirq for more than a second? Don't you
> > think that's the problem which needs to be fixed?
>
> Though this is an issue I've experienced (and tried unsuccessfully to
> fix in a more complicated way) with the RT kernel, where high priority
> tasks blocked the watchdog long enough that we'd disqualify the TSC.
>
> Ideally that sort of high-priority RT busyness would be avoided, but
> its also a pain to have false positive trigger when doing things like
> stress testing.
>
>
> >> The first problem is mostly we are suffering I think.
> >
> > So you think that's the root cause and because your patch makes it go
> > away it's not necessary to know for sure, right?
> >
> >> Here is a simple patch to fix the issues. If the waterdog doesn't run
> >
> > waterdog?
>
> Allergen-free. :)
>
>
> >> for a long time, we ignore the detection.
> >
> > What's 'long time'? Please explain the numbers chosen.
> >
> >> This should work for the two
> >
> > Emphasis on 'should'?
> >
> >> problems. For the second one, we probably doen't need to scale if the
> >> interval isn't very long.
> >
> > -ENOPARSE
> >
> >> @@ -122,9 +122,10 @@ static int clocksource_watchdog_kthread(void *data);
> >> static void __clocksource_change_rating(struct clocksource *cs, int
> >> rating);
> >>
> >> /*
> >> - * Interval: 0.5sec Threshold: 0.0625s
> >> + * Interval: 0.5sec MaxInterval: 1s Threshold: 0.0625s
> >> */
> >> #define WATCHDOG_INTERVAL (HZ >> 1)
> >> +#define WATCHDOG_MAX_INTERVAL_NS (NSEC_PER_SEC)
> >> #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
> >>
> >> static void clocksource_watchdog_work(struct work_struct *work)
> >> @@ -217,7 +218,9 @@ static void clocksource_watchdog(unsigned long data)
> >> continue;
> >>
> >> /* Check the deviation from the watchdog clocksource. */
> >> - if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD)) {
> >> + if ((abs(cs_nsec - wd_nsec) > WATCHDOG_THRESHOLD) &&
> >> + cs_nsec < WATCHDOG_MAX_INTERVAL_NS &&
> >> + wd_nsec < WATCHDOG_MAX_INTERVAL_NS) {
> >
> > So that adds a new opportunity for undiscovered wreckage:
> >
> >clocksource_watchdog();
> > <--- SMI skews TSC
> >looong_irq_disabled_region();
> >
> >clocksource_watchdog(); <--- Does not detect skew
> >
> > and it will not detect it later on if that SMI was a one time event.
> >
> > So 'fixing' the watchdog is the wrong approach. Fixing the stuff which
> > prevents the watchdog to run is the proper thing to do.
>
> I'm not sure here. I feel like these delay-caused false positives
> (I've seen similar reports w/ VMs being stalled) are more common then
> one-off SMI TSC skews.
>
> There are hard lines in the timekeeping code, where we do say: Don't
> delay us past X or we can't really handle it, but in this case, the
> main clocksource is fine and the limit is being caused by the
> watchdog. So I think some sort of a solution to remove this
> restriction would be good. We don't want to needlessly punish fine
> hardware because our checks for bad hardware add extra restrictions.
>
> That said, I agree the "should"s and other vague qualifiers in the
> commit description you point out should have more specifics to back
> things up. And I'm fine delaying this (and the follow-on) patch until
> those details are provided.
It's not something I guess. We do see the issue from time to time. The
IPMI driver accesses some IO ports in softirq and hog cpu for a very
long time, then the watchdog alert. The false alert on the other hand
has very worse effect. It forces to use HPET as clocksource, which has
very big performance penality. We can't even manually switch back to TSC
as current interface doesn't allow us to do it, then we can only reboot
the system. I agree the driver should be fixed, but the watchdog has
false alert, we definitively should fix it.
The 1s interval is arbitary. If you think there is better way to fix the
issue,
RE: [Intel-wired-lan] [PATCH] e100: Add a check after pci_pool_create to avoid null pointer dereference
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jia-Ju Bai > Sent: Sunday, August 02, 2015 7:17 PM > To: Kirsher, Jeffrey T; Brandeburg, Jesse > Cc: net...@vger.kernel.org; Jia-Ju Bai; intel-wired-...@lists.osuosl.org; > linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] e100: Add a check after pci_pool_create > to avoid null pointer dereference > > The driver lacks the check of nic->cbs_pool after pci_pool_create > in e100_probe. When this function is failed, a null pointer dereference > occurs when pci_pool_alloc uses nic->cbs_pool in e100_alloc_cbs. > This patch adds a check and related error handling code to fix it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/intel/e100.c |7 +++ > 1 file changed, 7 insertions(+) Tested-by: Aaron Brown -- 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/
RE: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
>
> This patch will break ATN handling on the interfaces. So we can't do this.
I understand. So how about doing like this:
/* All states wait for ibf, so just do it here. */
- if (!check_ibf(kcs, status, time))
+ if (kcs->state != KCS_IDLE && !check_ibf(kcs, status, time))
return SI_SM_CALL_WITH_DELAY;
I think it is not necessary to wait IBF when the state is IDLE.
In this way, we can also handle the ATN case.
Regards,
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
>
> It's going to be extremely hard to recover if the BMC is not working
> correctly when a panic happens. I'm not sure what can be done, but if
> you can fix it another way it would be good.
>
> -corey
>
> On 07/27/2015 12:55 AM, Hidehiro Kawai wrote:
> > If a BMC is unresponsive for some reason, it ends up completing
> > the requested message as an error, then kcs_event() is called once
> > to advance the state machine. However, since the BMC is
> > unresponsive now, the status of the KCS interface may not be
> > idle. As the result, the state machine can continue to run and
> > comsume CPU time indefinitely even if there is no more request
> > message. Moreover, if this happens in run-to-completion mode
> > (i.e. context of panic_event()), the kernel hangs up.
> >
> > To fix this problem, this patch ignores kcs_event() call if there
> > is no request message to be processed.
> >
> > Signed-off-by: Hidehiro Kawai
> > ---
> > drivers/char/ipmi/ipmi_kcs_sm.c |4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c
> > b/drivers/char/ipmi/ipmi_kcs_sm.c
> > index 8c25f59..0e187fb 100644
> > --- a/drivers/char/ipmi/ipmi_kcs_sm.c
> > +++ b/drivers/char/ipmi/ipmi_kcs_sm.c
> > @@ -353,6 +353,10 @@ static enum si_sm_result kcs_event(struct si_sm_data
> > *kcs, long time)
> > if (kcs_debug & KCS_DEBUG_STATES)
> > printk(KERN_DEBUG "KCS: State = %d, %x\n", kcs->state, status);
> >
> > + /* We don't want to run the state machine when the state is IDLE */
> > + if (kcs->state == KCS_IDLE)
> > + return SI_SM_IDLE;
> > +
> > /* All states wait for ibf, so just do it here. */
> > if (!check_ibf(kcs, status, time))
> > return SI_SM_CALL_WITH_DELAY;
> >
> >
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [Intel-wired-lan] [PATCH] e100: Release skb when DMA mapping is failed in e100_xmit_prepare
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of Jia-Ju Bai > Sent: Sunday, August 02, 2015 7:41 PM > To: Kirsher, Jeffrey T; Brandeburg, Jesse > Cc: net...@vger.kernel.org; Jia-Ju Bai; intel-wired-...@lists.osuosl.org; > linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] e100: Release skb when DMA mapping is > failed in e100_xmit_prepare > > When pci_dma_mapping_error in e100_xmit_prepare is failed, the skb buffer > allocated by netdev_alloc_skb_ip_align in e100_rx_alloc_skb is not > released, which causes a possible resource leak. > This patch adds error handling code to fix it. > > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/intel/e100.c |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Tested-by: Aaron Brown -- 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/
Re: [PATCH v6 2/3] pwm: add MediaTek display PWM driver support
On Mon, 2015-08-17 at 15:23 +0200, Thierry Reding wrote:
> On Mon, Jul 20, 2015 at 04:17:16PM +0800, YH Huang wrote:
> > Add display PWM driver support to modify backlight for MT8173 and MT6595.
> > The PWM has one channel to control the brightness of the display.
> > When the (high_width / period) is closer to 1, the screen is brighter;
> > otherwise, it is darker.
> >
> > Signed-off-by: YH Huang
> > ---
> > drivers/pwm/Kconfig| 10 ++
> > drivers/pwm/Makefile | 1 +
> > drivers/pwm/pwm-mtk-disp.c | 232
> > +
> > 3 files changed, 243 insertions(+)
> > create mode 100644 drivers/pwm/pwm-mtk-disp.c
> >
> > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > index b1541f4..f5b03a4 100644
> > --- a/drivers/pwm/Kconfig
> > +++ b/drivers/pwm/Kconfig
> > @@ -211,6 +211,16 @@ config PWM_LPSS_PLATFORM
> > To compile this driver as a module, choose M here: the module
> > will be called pwm-lpss-platform.
> >
> > +config PWM_MTK_DISP
> > + tristate "MediaTek display PWM driver"
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
>
> This is going to break randconfig builds. From a quick look your driver
> will fail to build at least on architectures that don't set HAVE_IOMEM.
> I know that's quite exotic, but I've had to deal with fallout from
> things like this in the past. If you want || COMPILE_TEST you should at
> least add a "depends on HAVE_IOMEM".
>
> linux/clk.h seems to have stubs for all of the functions that you use,
> so those shouldn't be a problem.
>
I will add it and this will be like:
depends on ARCH_MEDIATEK || COMPILE_TEST
depends on HAS_IOMEM
> > + help
> > + Generic PWM framework driver for MediaTek disp-pwm device.
> > + The PWM is used to control the backlight brightness for display.
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called pwm-mtk-disp.
> > +
> > config PWM_MXS
> > tristate "Freescale MXS PWM support"
> > depends on ARCH_MXS && OF
> [...]
> > diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
> > new file mode 100644
> > index 000..69682a0
> > --- /dev/null
> > +++ b/drivers/pwm/pwm-mtk-disp.c
> > @@ -0,0 +1,232 @@
> > +/*
> > + * MediaTek display pulse-width-modulation controller driver.
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: YH Huang
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> The above two aren't correctly sorted.
>
Arrange like this:
#include
#include
> > +#include
> > +
> > +#define DISP_PWM_EN0x00
> > +#define PWM_ENABLE_MASKBIT(0)
> > +
> > +#define DISP_PWM_COMMIT0x08
> > +#define PWM_COMMIT_MASKBIT(0)
> > +
> > +#define DISP_PWM_CON_0 0x10
> > +#define PWM_CLKDIV_SHIFT 16
> > +#define PWM_CLKDIV_MAX 0x3ff
> > +#define PWM_CLKDIV_MASK(PWM_CLKDIV_MAX << PWM_CLKDIV_SHIFT)
> > +
> > +#define DISP_PWM_CON_1 0x14
> > +#define PWM_PERIOD_MASK0xfff
> > +/* Shift log2(PWM_PERIOD_MASK + 1) as divisor */
> > +#define PWM_PERIOD_BIT_SHIFT 12
>
> There are still two names for the same value here. I thought we had
> agreed on this becoming something like the below?
>
> #define PWM_PERIOD_BIT_SHIFT 12
> #define PWM_PERIOD_MASK ((1 << PWM_PERIOD_BIT_SHIFT) - 1)
>
> Although PWM_PERIOD_BIT_WIDTH would probably be a better name. Or
> PWM_PERIOD_BITS or similar.
>
I will revise to
#define PWM_PERIOD_BIT_WIDTH 12
#define PWM_PERIOD_MASK ((1 << PWM_PERIOD_BIT_WIDTH) - 1)
> > +static int mtk_disp_pwm_remove(struct platform_device *pdev)
> > +{
> > + struct mtk_disp_pwm *mdp = platform_get_drvdata(pdev);
> > + int ret = pwmchip_remove(>chip);
>
> I'd prefer this to be separate lines:
>
> int ret;
>
> ret = pwmchip_remove(>chip);
OK.
Thanks for your suggestions.
Regards,
YH Huang
--
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/
Re: [PATCH] ASoC: tegra: Convert to managed resources
On Tue, Aug 18, 2015 at 2:17 AM, Mark Brown wrote: > On Mon, Aug 17, 2015 at 03:02:29PM +0530, Vaishali Thakkar wrote: > >> I think you are right. I missed that. But now thing is , this patch is >> already >> applied here: >> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=topic/tegra > >> I am not sure if now I can change version 2 with the changes you suggested >> or not. Although I will not be able to test it after changing 'goto >> err_suspend' >> as I don't have hardware but may be someone else can test it. > > You can send an incremental update on top of what's there, or it may be > more sensible to just discard the change entirely. I suspect we're safe > with either PM vs component ordering though since we should support !PM > configurations anyway. I think yes may be code was good before this. But devm_clk_put part should work fine as call of it is before PM stuff. So, can I send a patch reverting the change of component part or do you want me to send a patch reverting whole change? -- Vaishali -- 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/
Re: [PATCH 1/2] Fixing vmx-crypto AES-CTR counter bug
On Fri, Aug 14, 2015 at 10:12:22AM -0300, Leonidas S Barbosa wrote: > AES-CTR is using a counter 8bytes-8bytes what miss match with > kernel specs. > > In the previous code a vadduwm was done to increment counter. > Replacing this for a vadduqm now considering both cases counter > 8-8 bytes and full 16bytes. > > Signed-off-by: Leonidas S Barbosa Both fixes applied but I'll push them after the merge window opens as they don't seem to be critical. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/
Re: [PATCH 2/2] crypto: qat - Don't move data inside output buffer
On Mon, Aug 17, 2015 at 06:05:04PM -0700, Tadeusz Struk wrote: > On 08/17/2015 01:50 AM, Herbert Xu wrote: > >> If you don't like the first option then we still need this, as you pointed > >> out. > > Yes this looks like the right fix for qat. Please add a sign-off. > > You might be able to just do it by replying to this thread, and > > patchwork may be able to pick it up and attach it to the patch. > > Signed-off-by: Tadeusz Struk Applied. Please also fix the software implementation when you get back. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/usb/qmi_wwan.c
between commit:
a8079092c1bb ("net: qmi_wwan: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module")
from the net tree and commit:
2070c48cf2b7 ("qmi_wwan: Add support for Dell Wireless 5809e 4G Modem")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/usb/qmi_wwan.c
index 64a60afbe50c,1f7a7cd97e50..
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@@ -785,7 -785,7 +785,8 @@@ static const struct usb_device_id produ
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)},/* Dell Wireless 5570e HSPA+
(42Mbps) Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a8, 8)},/* Dell Wireless 5808 Gobi(TM)
4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)},/* Dell Wireless 5808e Gobi(TM)
4G LTE Mobile Broadband Card */
+ {QMI_FIXED_INTF(0x413c, 0x81b1, 8)},/* Dell Wireless 5809e Gobi(TM)
4G LTE Mobile Broadband Card */
+ {QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+
Gobi 4G Module */
{QMI_FIXED_INTF(0x03f0, 0x581d, 4)},/* HP lt4112 LTE/HSPA+ Gobi 4G
Module (Huawei me906e) */
/* 4. Gobi 1000 devices */
--
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/
Re: [PATCH] ceph: remove redundant test of head->safe and silence static analysis warnings
> On Aug 17, 2015, at 09:05, Brad Hubbard wrote:
>
>ceph: remove redundant test of head->safe and silence static analysis
> warnings
>
>Signed-off-by: Brad Hubbard
> ---
> fs/ceph/mds_client.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> index 6aa07af..6e196ee 100644
> --- a/fs/ceph/mds_client.c
> +++ b/fs/ceph/mds_client.c
> @@ -2411,7 +2411,7 @@ static void handle_reply(struct ceph_mds_session
> *session, struct ceph_msg *msg)
>mutex_unlock(>mutex);
>goto out;
>}
> - if (req->r_got_safe && !head->safe) {
> + if (req->r_got_safe) {
>pr_warn("got unsafe after safe on %llu from mds%d\n",
> tid, mds);
>mutex_unlock(>mutex);
> --
added to our testing branch,
Thanks
Yan, Zheng--
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/
Re: linux-next: manual merge of the thermal-soc tree with the arm tree
Russell,
On Mon, Aug 17, 2015 at 12:55 AM, Russell King - ARM Linux
wrote:
> On Mon, Aug 17, 2015 at 12:17:54PM +1000, Stephen Rothwell wrote:
>> Hi Eduardo,
>>
>> Today's linux-next merge of the thermal-soc tree got a conflict in:
>>
>> drivers/thermal/cpu_cooling.c
>>
>> between commit:
>>
>> df6f527755a5 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
>>
>> from the arm tree and commits:
>>
>> 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
>> a24af233a1fd ("thermal/cpu_cooling: convert 'switch' block to 'if' block
>> in notifier")
>>
>> from the thermal-soc tree.
>>
>> I fixed it up (the first two look like two versions of the same patch,
>> so I used the version from the thermal-soc tree) and can carry the fix
>> as necessary (no action is required).
>>
>> Russell: that commit in your tree has no Signed-off-by :-(
>
> Yes it does. It's above the explanation of why it's there. However,
> now that Eduardo has taken patches to fix the long standing bug, I can
> drop this commit.
>
Thanks once again for the effort to push the fix. Once again, sorry for the
inconvenience.
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
--
Eduardo Bezerra Valentin
--
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/
Re: 0be964be0 "module: Sanitize RCU usage and locking" breaks symbol_put_addr?
On Mon, Aug 17, 2015 at 04:20:09PM -0700, Laura Abbott wrote: > Hi, > > We received a few bug backtraces: > > [ 41.536933] [ cut here ] > [ 41.537545] WARNING: CPU: 1 PID: 813 at kernel/module.c:291 > module_assert_mutex_or_preempt+0x49/0x90() > [ 41.538174] Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... > dvb_usb_v2 dvb_core rc_core ... > [ 41.542457] CPU: 1 PID: 813 Comm: systemd-udevd Not tainted > 4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1 > ... > [ 41.549994] [] module_assert_mutex_or_preempt+0x49/0x90 > [ 41.550664] [] __module_address+0x32/0x150 > [ 41.552684] [] __module_text_address+0x16/0x70 > [ 41.554701] [] symbol_put_addr+0x29/0x40 > [ 41.555392] [] dvb_frontend_detach+0x7d/0x90 [dvb_core] > Based on my understanding, this is spitting a warning that the module_mutex > isn't held. There's a nice comment in symbol_put_addr right before the call: > > /* module_text_address is safe here: we're supposed to have reference > * to module from symbol_get, so it can't go away. */ > modaddr = __module_text_address(a); > > so it looks like this is an erroneous warning which shouldn't need the mutex > held. > Any ideas or am I off base here? That comment is wrong, you still need either preempt disabled or hold the module mutex because you're going to iterate the data structure in order to look up the module. The fact that you hold a reference on the module you're going to (hopefully) find, doesn't stabilize the data structure. So I think maybe symbol_put_addr() is broken and it wants something like: --- kernel/module.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index b86b7bf1be38..8f051a106676 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -1063,11 +1063,15 @@ void symbol_put_addr(void *addr) if (core_kernel_text(a)) return; - /* module_text_address is safe here: we're supposed to have reference -* to module from symbol_get, so it can't go away. */ + /* +* Even though we hold a reference on the module; we still need to +* disable preemption in order to safely traverse the data structure. +*/ + preempt_disable(); modaddr = __module_text_address(a); BUG_ON(!modaddr); module_put(modaddr); + preempt_enable(); } EXPORT_SYMBOL_GPL(symbol_put_addr); -- 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/
Re: [PATCH] regulator: core: Use IS_ERR_OR_NULL()
On 17-08-15, 13:06, Mark Brown wrote: > On Mon, Aug 17, 2015 at 12:30:58PM +0530, Viresh Kumar wrote: > > Use IS_ERR_OR_NULL() rather than open coding it. > > Neither of the patches you sent today applied cleanly against current > code, please submit patches against the tree they're intended to be > applied on. That's the last I wanted to get ranted about, Sigh. I thought, my base is the latest linux-next/master, which will have your latest updates. But that wasn't the case. I was sitting on a slightly older base. Sorry about that. Will base out of your tree directly in future. -- viresh -- 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/
Re: 3.18: lockdep problems in cpufreq
Hi there, On Mon, Aug 17, 2015 at 6:32 PM, Rafael J. Wysocki wrote: > > Well, that's the situation as per MAINTAINERS today. You seem to be concerned > that it may not reflect the reality, but in that case I can only recommend > sending a patch against MAINTAINERS to remove Eduardo from there. > >> As I've said, I'm not bothering with this anymore, it's just far too >> much effort to play these stupid games. > > I'm not sure what you mean by "these stupid games" here. > >> The deadlock can stay for all I care. > > Fair enough. I applied the patch. And it has generated the conflict in linux-next, as was mentioned in this thread. I already sent the pull request. Yes, I missed the thread. Apologize for this and for the inconvenience I have caused. The deadlock will be taken care using Russel's patch. Thanks Viresh for notifying me. > > Thanks, > Rafael > BR, -- Eduardo Bezerra Valentin -- 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/
Re: Can I use static keys from asm?
On Mon, Aug 17, 2015 at 06:34:08PM -0700, Andy Lutomirski wrote: > 2. Context tracking enabled in config but completely disabled at > runtime. Distros do this. I want to nop out the context tracking > hooks. We have a static_key for this, but half the hooks are in asm. > To unsuck case 2, static keys in asm would help. Can I do that? It > would be even better if I could do that in 4.3. I think Anton did a number of patches to enable static_key usage in asm on PowerPC. x86 would need a bit of work but nothing makes it fundamentally impossible. -- 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/
Re: [PATCH v6 1/3] dt-bindings: pwm: add MediaTek display PWM bindings
On Mon, 2015-08-17 at 15:23 +0200, Thierry Reding wrote: > On Mon, Jul 20, 2015 at 04:17:15PM +0800, YH Huang wrote: > > Document the device-tree binding of MediatTek display PWM. > > I already mentioned this a while back: s/MediatTek/MediaTek/. > Sorry, I will correct it to "MediaTek". Regards, YH Huang -- 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/
Re: [PATCH] x86, suspend: Save/restore THERM_CONTROL register for suspend
Hi Pavel, thanks for your review, On 08/17/2015 09:27 PM, Pavel Machek wrote: On Mon 2015-08-17 12:11:15, Ingo Molnar wrote: * Chen Yu wrote: A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208) Access denied :-( Might need to register for accessing. What HW is this on? Intel Braswell and Broadwell, detail for Broadwell: Platform: MayanCity Processor: 2x BROADWELL BDX_EP A0 QHPR Chipset: Wellsburg B1 QR7E - So BIOS expects to control MSR_IA32_THERM_CONTROL . Now you suspend in hot enironment but resume in cool one. BIOS sets up MSR_IA32_THERM_CONTROL the right way, but you override it. As BIOS expects to control MSR_IA32_THERM_CONTROL and machine is kept cool, BIOS will not write new value to it, and machine will keep running slowly. Sorry, I can not quite catch up, do you mean we should let BIOS modifying MSR_IA32_THERM_CONTROL and leverage linux to adjust this value at runtime(after S3)? Doing this unconditionally is asking for trouble. Blacklist entry with affected BIOS info might be acceptable, but... Pavel you mean a quirk here(accroding to dmi info ,etc)? Best Regards, Yu -- 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/
[V2] rdmsr before the CPUID test produces KVM warning
If KVM does not support INTEL_PT, guest MSR_IA32_RTIT_CTL reading will
produce host warning like "kvm [2469]: vcpu0 unhandled rdmsr: 0x570".
Guest can determine whether the CPU supports Intel_PT according to CPUID,
so test_cpu_cap function is added before rdmsr,and it is more in line with
the code style.
Signed-off-by: Huaitong Han
Reviewed-by: Alexander Shishkin
--
ChangeLog:
V2:Update commit message.
--
diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c
b/arch/x86/kernel/cpu/perf_event_intel_pt.c
index 183de71..4cc6492 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_pt.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c
@@ -123,9 +123,6 @@ static int __init pt_pmu_hw_init(void)
long i;
attrs = NULL;
- ret = -ENODEV;
- if (!test_cpu_cap(_cpu_data, X86_FEATURE_INTEL_PT))
- goto fail;
for (i = 0; i < PT_CPUID_LEAVES; i++) {
cpuid_count(20, i,
@@ -1061,6 +1058,10 @@ static __init int pt_init(void)
int ret, cpu, prior_warn = 0;
BUILD_BUG_ON(sizeof(struct topa) > PAGE_SIZE);
+
+ if (!test_cpu_cap(_cpu_data, X86_FEATURE_INTEL_PT))
+ return -ENODEV;
+
get_online_cpus();
for_each_online_cpu(cpu) {
u64 ctl;
--
1.9.1
--
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/
RE: [PATCH 6/7] ipmi: Handle queued messages more certainly on panic
Hello Corey,
> -Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
> Sent: Wednesday, August 12, 2015 1:13 PM
> To: 河合英宏 / KAWAI，HIDEHIRO
> Cc: openipmi-develo...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 6/7] ipmi: Handle queued messages more certainly on panic
>
> On 07/27/2015 12:55 AM, Hidehiro Kawai wrote:
> > panic_event() called as a panic notifier tries to flush queued
> > messages, but it can't handle them if the kernel panic happens
> > while processing a message. What happens depends on when the
> > kernel panics.
>
> Sorry this took so long, I've been traveling.
No problem.
> I have queued the patches before this one. They all look good and
> necessary.
Thank you for reviewing!
> I'm not so sure about this patch. It looks like the only thing that is
> a real issue is #2 below.
> It's not so important to avoid dropping messages.
Initially I thought dropping middle of queued messages breaks
some consistencies if a message depends on the preceding dropped
message. However, userland tools normally issue request messages
in sequential manner, so the above situation wouldn't happen.
Now, I think dropping a message is OK.
> Can this be simplified somehow to work around the issue at panic time if
> intf->curr_msg is set and smi_info->waiting_msg is not?
There are two cases where intf->curr_msg is set and
smi_info->waiting_msg is not; one is before (2) and the other
is after (3). If we decide to drop intf->curr_msg in both cases,
I can simplify this patch somewhat.
Regards,
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
>
> Thank you,
>
> -corey
>
> >
> > Here is the summary of message sending process.
> >
> > smi_send()
> > smi_add_send_msg()
> > (1) intf->curr_msg = msg
> > sender()
> > (2) smi_info->waiting_msg = msg
> >
> >
> > check_start_timer_thread()
> > start_next_msg()
> > smi_info->curr_msg = smi_info->waiting_msg
> > (3) smi_info->waiting_msg = NULL
> > (4) smi_info->handlers->start_transaction()
> >
> >
> > smi_event_handler()
> > (5) handle_transaction_done()
> > smi_info->curr_msg = NULL
> > deliver_recv_msg()
> >ipmi_smi_msg_received()
> > intf->curr_msg = NULL
> >
> > If the kernel panics before (1), the requested message will be
> > lost. But it can't be helped.
> >
> > If the kernel panics before (2), new message sent by
> > send_panic_events() is queued to intf->xmit_msgs because
> > intf->curr_msg is non-NULL. But the new message will be never
> > sent because no one sends intf->curr_msg. As the result, the
> > kernel hangs up.
> >
> > If the kernel panics before (3), intf->curr_msg will be sent by
> > set_run_to_completion(). It's no problem.
> >
> > If the kernel panics before (4), intf->curr_msg will be lost.
> > However, messages on intf->xmit_msgs will be handled.
> >
> > If the kernel panics before (5), we try to continue running the
> > state machine. It may successfully complete.
> >
> > If the kernel panics after (5), we will miss the response message
> > handling, but it's not much problem in the panic context.
> >
> > This patch tries to handle messages in intf->curr_msg and
> > intf->xmit_msgs only once without losing them. To achieve this,
> > this patch does that:
> > - if a message is in intf->curr_msg or intf->xmit_msgs and
> > start_transaction() for the message hasn't been done yet,
> > resend it
> > - if start_transaction() for a message has been called,
> > just continue to run the state machine
> > - if the transaction has been completed, do nothing
> >
> > >From the perspective of implementation, these are done by keeping
> > smi_info->waiting_msg until start_transaction() is completed and
> > by keeping new flag IPMI_MSG_RESEND_ON_PANIC just before starting
> > the state machine.
> >
> > Signed-off-by: Hidehiro Kawai
> > ---
> > drivers/char/ipmi/ipmi_msghandler.c | 36
> > +++
> > drivers/char/ipmi/ipmi_si_intf.c|5 -
> > include/linux/ipmi_smi.h|5 +
> > 3 files changed, 45 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/ipmi/ipmi_msghandler.c
> > b/drivers/char/ipmi/ipmi_msghandler.c
> > index 5a2d9fe..3dcd814 100644
> > --- a/drivers/char/ipmi/ipmi_msghandler.c
> > +++ b/drivers/char/ipmi/ipmi_msghandler.c
> > @@ -1493,6 +1493,8 @@ static struct ipmi_smi_msg
> > *smi_add_send_msg(ipmi_smi_t intf,
> > struct ipmi_smi_msg *smi_msg,
> > int priority)
> > {
> > + smi_msg->flags |= IPMI_MSG_RESEND_ON_PANIC;
> > +
> > if (intf->curr_msg) {
> > if (priority > 0)
> > list_add_tail(_msg->link, >hp_xmit_msgs);
> > @@ -4223,6 +4225,7 @@ struct ipmi_smi_msg *ipmi_alloc_smi_msg(void)
> > rv->done = free_smi_msg;
> >
Re: [PATCH] x86, suspend: Save/restore THERM_CONTROL register for suspend
（not sure if previous reply has been sent out) Hi, Ingo, thanks for your review, On 08/17/2015 06:11 PM, Ingo Molnar wrote: * Chen Yu wrote: So what your changelog fails to mention: - You only add this code to the 64-bit kernel. Are 32-bit kernels not affected? I missed the 32-bit case, I'll adjust them to 32/64-bit common path. - the MSR read is done unconditionally. Is MSR_IA32_THERM_CONTROL available architecturally and readable (and has sensible values) on all 64-bit capable x86 CPUs that run this code path? MSR_IA32_THERM_CONTROL is avaliable on Intel Pentium 4, Xeon, Pentium M and later processors, so I think not all of the 32/64-bit x86 CPUs have this regiser. Maybe codes like this would be more reasonable? save: ctx->clock_modulation_saved = !rdmsrl_safe(MSR_IA32_THERM_CONTROL, >clock_modulation); retore: if (ctxt->clock_modulation_saved) wrmsrl(MSR_IA32_THERM_CONTROL, ctxt->clock_modulation); Best Regards, Yu Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-pm" 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-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/
Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()
On Mon, 2015-08-17 at 09:57 +0100, Will Deacon wrote: > On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote: > > On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote: > > > On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote: > > > I thought the end result of this thread was that we didn't *need* to > > > change the > > > powerpc lock semantics? Or did I read it wrong? > > > > > > ie. the docs now say that RELEASE+ACQUIRE is not a full barrier, which is > > > consistent with our current implementation. > > > > That change happened about 1.5 years ago, and I thought that the > > current discussion was about reversing it, based in part on the > > recent powerpc benchmarks of locking primitives with and without the > > sync instruction. But regardless, I clearly cannot remove either the > > smp_mb__after_unlock_lock() or the powerpc definition of it to be smp_mb() > > if powerpc unlock/lock is not strengthened. > > Yup. Peter and I would really like to get rid of smp_mb__after_unlock_lock > entirely, which would mean strengthening the ppc spinlocks. Moving the > barrier primitive into RCU is a good step to prevent more widespread usage > of the barrier, but we'd really like to go further if the performance impact > is deemed acceptable (which is what this thread is about). OK, sorry for completely missing the point, too many balls in the air here. I'll do some benchmarks and see what we come up with. cheers -- 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/
Re: [PATCH 2/3] QIB: Removing usage of pcie_set_mps()
On Mon, Aug 17, 2015 at 07:06:10PM -0500, Bjorn Helgaas wrote: > On Mon, Aug 17, 2015 at 5:50 PM, Jiang, Dave wrote: > > On Mon, 2015-08-17 at 17:30 -0500, Bjorn Helgaas wrote: > >> [+cc Mike, linux-rdma] > >> > >> On Wed, Jul 29, 2015 at 04:18:54PM -0600, Keith Busch wrote: > >> > From: Dave Jiang > >> > > >> > This is in perperation of un-exporting the pcie_set_mps() function > >> > symbol. A driver should not be changing the MPS as that is the > >> > responsibility of the PCI subsystem. > >> > >> Please explain the implications of removing this code. Does this > >> affect > >> performance of the device? If so, how do we get that performance > >> back? > > > > Honestly I don't know. But at the same time I think the driver > > shouldn't be touching the MPS at all. Shouldn't that be left to the > > PCIe subsystem and rely on the PCIe subsystem to set this to a sane > > value? > > Yes, I think in principle the PCI core should own this, but I also > don't want to introduce a performance regression, so I think we need > to understand whether there's a problem, and if there is, fix it. Making sure Mike is CC'd directly.. Mike: I see this has been cut and pasted to HFI1 too, I would be disappointed if HFI needs it as well. :( FWIW, I totally agree with the above. MPS/MRS and related have to do with root port capability, switches in the path and any platform bugs.. I'm not sure why a driver would ever want to mess with this, and since this code doesn't walk the bus toward the root port, it is technically wrong, right? I also find it strange that qib_pcie_caps defaults to zero which means the 'tuning' reduces the payload size to the minimums (??) > >> > /* > >> > * Now the Read Request size. > >> > * No field for max supported, but PCIe spec limits it to > >> > 4096, .. it has been a bit since I looked at this, but IIRC, MRRS is also something that should not be touched by a driver? Jason -- 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/
Re: [PATCH v2 2/3] gadget: Introduce the usb charger framework
On 18 August 2015 at 01:24, Mark Brown wrote: > On Mon, Aug 17, 2015 at 11:03:26AM +0800, Baolin Wang wrote: >> On 14 August 2015 at 23:27, Greg KH wrote: >> > On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote: > >> >> + * This program is free software; you can redistribute it and/or modify >> >> + * it under the terms of the GNU General Public License as published by >> >> + * the Free Software Foundation; either version 2 of the License, or >> >> + * (at your option) any later version. > >> > I have to ask, do you really mean "any later version"? > >> I think I did not get your point, could you explain it detailedly? > > Unlike a lot of userspace projects the kernel is normally just licensed > under GPLv2 without the option to relicense with a later version so the > "...or any later version" is a bit unusual. There is some controversy > about some of the changes in GPLv3. Make sense. Thanks a lot. -- Baolin.wang Best Regards -- 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/
Re: [Device-mainlining] [PATCH v2 2/3] gadget: Introduce the usb charger framework
On 17 August 2015 at 23:25, Tim Bird wrote: > > > On 08/16/2015 08:03 PM, Baolin Wang via device-mainlining wrote: >> On 14 August 2015 at 23:27, Greg KH wrote: >>> On Fri, Aug 14, 2015 at 05:47:45PM +0800, Baolin Wang wrote: + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. >>> >>> I have to ask, do you really mean "any later version"? >>> >> >> I think I did not get your point, could you explain it detailedly? > > The full kernel is licensed under v2 of the GPL only, not "any later version". > See the second paragraph at the top of the COPYING file in the root directory > of the kernel source tree. There are differences on individual files, but > having this file allow "any later version" makes it different from much of > rest of the kernel. > > Unless you have a specific reason to allow greater-than-V2 GPL licensing on > this > file, you should change the licensing clause. The following wording appears > to be pretty popular: > > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > * published by the Free Software Foundation. > Hi Tim, Make sense of it. Thanks for your explanation. > -- Tim -- Baolin.wang Best Regards -- 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/
Re: [PATCH] [v2] surface pro 3: Add support driver for Surface Pro 3 buttons
On 08/11/2015 10:45 AM, Darren Hart wrote: On Fri, Aug 07, 2015 at 08:48:18AM +, Chen, Yu C wrote: On Fri, 2015-08-07 at 01:27 -0700, Joe Perches wrote: On Fri, 2015-08-07 at 15:57 +0800, Chen Yu wrote: \ I think the older switch/case was easier to understand. OK, then let's keep the switch/case. thanks. Agreed. Hi, Darren and Joe, I'll send a V4 of this patch to add a method to exclude the load of Surface 3(no Pro), since Surface 3 also has a device name of MSHW0028, but it is not used for buttons. Thanks Best Regards, Yu -- 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/
Can I use static keys from asm?
I have the following silly problem: For kernels with context tracking compiled in, we need to call the context tracking hooks if context tracking is enabled. There are four interesting cases: 1. Context tracking disabled in config. This is easy to handle. 2. Context tracking enabled in config but completely disabled at runtime. Distros do this. I want to nop out the context tracking hooks. We have a static_key for this, but half the hooks are in asm. 3. Context tracking enabled in config but disabled on the current CPU. I don't care all that much. 4. Context tracking enabled for real. Performance will suck. I want to fix that, and I think my cleanups will make it a lot easier, but we're not there yet. To unsuck case 2, static keys in asm would help. Can I do that? It would be even better if I could do that in 4.3. FWIW, this might be unnecessary in the long run. As more of this spaghetti moves into C, the need for static keys in asm will be reduced :) --Andy -- 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/
Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver
On Tuesday, August 18, 2015 at 03:24:44 AM, Brian Norris wrote: > I'm not very helpful here, so hopefully Viet can be of more use: Yup :) > On Mon, Aug 17, 2015 at 07:53:23PM +0200, Marek Vasut wrote: > > On Monday, August 17, 2015 at 06:03:38 PM, Brian Norris wrote: > > Also, I cannot find any documentation for this IP block even if I search > > through Quartus/QSys, is there any proper documentation available > > anywhere? > > I never found proper documentation, but I didn't look too hard. I've > mostly been going off of Viet's comments and code. Me neither, and I looked through the altera stuff in fact. I'm trying to learn whether this is just an Soft IP, in which case it certainly can be fixed ; or if there is actually some chip shipping with this crap synthesised into actual silicon. > But FWIW, I did find some relevant info for the peculiar Altera EPCQ > flash here: > > https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ > hb/cfg/cfg_cf52012.pdf Altera EPCS/EPCQ flashes are just rebranded micron flashes, they just have different JEDEC ID and are a bit more expensive. Best regards, Marek Vasut -- 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/
Re: [PATCH] [PATCH v4] mtd:spi-nor: Add Altera Quad SPI Driver
I'm not very helpful here, so hopefully Viet can be of more use: On Mon, Aug 17, 2015 at 07:53:23PM +0200, Marek Vasut wrote: > On Monday, August 17, 2015 at 06:03:38 PM, Brian Norris wrote: > Also, I cannot find any documentation for this IP block even if I search > through > Quartus/QSys, is there any proper documentation available anywhere? I never found proper documentation, but I didn't look too hard. I've mostly been going off of Viet's comments and code. But FWIW, I did find some relevant info for the peculiar Altera EPCQ flash here: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf Brian -- 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/
Re: linux-next: rebase of the drm-exynos tree
Hi Stephen, On 2015년 08월 18일 07:50, Stephen Rothwell wrote: > Hi Inki, > > I noticed today that your tree > (git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next) > has been merged by Dave into his drm tree. Unfortunately, your tree > has also been rebased onto Linus's v4.2-rc7. So now the commits > 0cb600d9be30-f8f66412fa6c in your tree are duplicated of commits > d36b3004ca2c-2a8cb4894540 in Dave's. Please tidy this up (i.e. your > exynos-drm/for-next branch should be commit 2a8cb4894540 or something > later in Dave's tree) and you should continue your work from there. Right, I had requested git-pull. Will do re-base on top of Dave's tree. Thanks, Inki Dae > -- 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/
Re: [PATCH v4 5/5] PM / devfreq: drop comment about thermal setting max_freq
> The thermal infrastructure should use the devfreq cooling device, which > uses the OPP library to disable OPPs as necessary. > > Fix a couple of typos in the same comment while we are at it. > > Cc: MyungJoo Ham > Signed-off-by: Javi Merino > --- > drivers/devfreq/devfreq.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c Will be applied soon. Signed-off-by: MyungJoo Ham
Re: [PATCH 2/2] crypto: qat - Don't move data inside output buffer
On 08/17/2015 01:50 AM, Herbert Xu wrote: >> If you don't like the first option then we still need this, as you pointed >> out. > Yes this looks like the right fix for qat. Please add a sign-off. > You might be able to just do it by replying to this thread, and > patchwork may be able to pick it up and attach it to the patch. Signed-off-by: Tadeusz Struk -- 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/
linux-next: build failure after merge of the nfs tree
Hi Trond,
After merging the nfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function
'kiblnd_pmr_pool_map':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1828:2: error: implicit
declaration of function 'ib_reg_phys_mr' [-Werror=implicit-function-declaration]
pmr->pmr_mr = ib_reg_phys_mr(hdev->ibh_pd,
^
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1828:14: warning:
assignment makes pointer from integer without a cast
pmr->pmr_mr = ib_reg_phys_mr(hdev->ibh_pd,
^
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function
'kiblnd_hdev_setup_mrs':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2380:6: warning: assignment
makes pointer from integer without a cast
mr = ib_reg_phys_mr(hdev->ibh_pd, , 1, acflags, );
^
Caused by commit
1241d7bf2ac8 ("core: Remove the ib_reg_phys_mr() and ib_rereg_phys_mr()
verbs")
which noted this build failure would occur :-(
Since this commit is self comtained, I have reverted it until someone
provides a fix for the lustre code.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/
Re: Please revert 08439fec266c3cc5702953b4f54bdf5649357de0
On Mon, Aug 17, 2015 at 02:45:03PM -0500, Felipe Balbi wrote: > Hi Theodore, > > as you already know, commit 08439fec266c (ext4: remove > block_device_ejected) caused a regression for (at least) USB attached > storage devices. > > You provided a fix for the regression by reverting that commit in > b9e43f49f672 (Revert "ext4: remove block_device_ejected"). This > revert is, currently, on linux-next but broken commit is part of > v4.1-final and, thus, part of v4.1 LTS. > > Could you please mark your revert for v4.1+ stable ? If it's not too > late to get it in v4.2-final, that would be great, otherwise we a Cc > stable would suffice anyway. > > In summary, commit 08439fec266c needs to be reverted on both v4.1-stable > and v4.2. Already done. See the latest version of the dev branch. I noticed this morning that I needed to mark it for stable, and took care of it. - Ted -- 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/
Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"
On Mon, Aug 17, 2015 at 2:45 PM, Jerome Glisse wrote: > On Fri, Aug 14, 2015 at 07:11:27PM -0700, Dan Williams wrote: >> Although it does not offer perfect protection if device memory is at a >> physically lower address than RAM, skipping the update of these >> variables does seem to be what we want. For example /dev/mem would >> fail to allow write access to persistent memory if it fails a >> valid_phys_addr_range() check. Since /dev/mem does not know how to >> write to PMEM in a reliably persistent way, it should not treat a >> PMEM-pfn like RAM. > > So i attach is a patch that should keep ZONE_DEVICE out of consideration > for the buddy allocator. You might also want to keep page reserved and not > free inside the zone, you could replace the generic_online_page() using > set_online_page_callback() while hotpluging device memory. > Hmm, are we already protected by the fact that ZONE_DEVICE is not represented in the GFP_ZONEMASK? -- 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/
[git pull] drm fixes
Hi Linus, These came in late last week, I wanted to look over the mst one before forwarding, but it seems good. Just 3 i915 and one MST fix. Dave. The following changes since commit 45e38cff4fce8d6871b5fa5e734e4dc9814d6056: Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm (2015-08-14 17:27:52 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 7945dc5885c51d05d9368fd0066755adca73f009: Merge tag 'topic/drm-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel into drm-next (2015-08-15 14:52:12 +1000) Daniel Vetter (1): drm/i915: Only dither on 6bpc panels Dave Airlie (2): Merge tag 'drm-intel-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel into drm-next Merge tag 'topic/drm-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel into drm-next Maarten Lankhorst (3): drm/dp/mst: Remove port after removing connector. drm/i915: calculate primary visibility changes instead of calling from set_config drm/i915: Commit planes on each crtc separately. drivers/gpu/drm/drm_dp_mst_topology.c | 19 +++ drivers/gpu/drm/i915/intel_atomic.c | 45 +- drivers/gpu/drm/i915/intel_display.c | 59 +-- include/drm/drm_crtc.h| 2 -- 4 files changed, 36 insertions(+), 89 deletions(-) -- 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/
Re: [PATCHv2 1/4] mm: drop page->slab_page
On Mon, 17 Aug 2015, Kirill A. Shutemov wrote:
> Since 8456a648cf44 ("slab: use struct page for slab management") nobody
> uses slab_page field in struct page.
>
> Let's drop it.
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Joonsoo Kim
> Cc: Andi Kleen
> Cc: Christoph Lameter
Acked-by: David Rientjes
--
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/
Re: [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
On Mon, 17 Aug 2015, Jiang Liu wrote: > Function i40e_clean_rx_irq() tries to reuse memory pages allocated s/i40e_clean_rx_irq/i40e_clean_rx_irq_ps/ > from the nearest node. To better support memoryless node, use > numa_mem_id() instead of numa_node_id() to get the nearest node with > memory. > Out of curiosity, what prevents the cpu to be preempted and current_node to no longer match numa_mem_id()? > This change should only affect performance. > > Signed-off-by: Jiang Liu > --- > drivers/net/ethernet/intel/i40e/i40e_txrx.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c > b/drivers/net/ethernet/intel/i40e/i40e_txrx.c > index 9a4f2bc70cd2..a8f618cb8eb0 100644 > --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c > +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c > @@ -1516,7 +1516,7 @@ static int i40e_clean_rx_irq_ps(struct i40e_ring > *rx_ring, int budget) > unsigned int total_rx_bytes = 0, total_rx_packets = 0; > u16 rx_packet_len, rx_header_len, rx_sph, rx_hbo; > u16 cleaned_count = I40E_DESC_UNUSED(rx_ring); > - const int current_node = numa_node_id(); > + const int current_node = numa_mem_id(); > struct i40e_vsi *vsi = rx_ring->vsi; > u16 i = rx_ring->next_to_clean; > union i40e_rx_desc *rx_desc; -- 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/
[PATCH] mm: fix potential data race in SyS_swapon
While running KernelThreadSanitizer (ktsan) on upstream kernel with
trinity, we got a few reports from SyS_swapon, here is one of them:
Read of size 8 by thread T307 (K7621):
[< inlined>] SyS_swapon+0x3c0/0x1850 SYSC_swapon mm/swapfile.c:2395
[] SyS_swapon+0x3c0/0x1850 mm/swapfile.c:2345
[] ia32_do_call+0x1b/0x25
Looks like the swap_lock should be taken when iterating through the
swap_info array on lines 2392 - 2401: q->swap_file may be reset to
NULL by another thread before it is dereferenced for f_mapping.
But why is that iteration needed at all? Doesn't the claim_swapfile()
which follows do all that is needed to check for a duplicate entry -
FMODE_EXCL on a bdev, testing IS_SWAPFILE under i_mutex on a regfile?
Well, not quite: bd_may_claim() allows the same "holder" to claim the
bdev again, so we do need to use a different holder than "sys_swapon";
and we should not replace appropriate -EBUSY by inappropriate -EINVAL.
Index i was reused in a cpu loop further down: renamed cpu there.
Reported-by: Andrey Konovalov
Signed-off-by: Hugh Dickins
---
mm/swapfile.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
--- 4.2-rc7/mm/swapfile.c 2015-07-05 19:25:02.852131158 -0700
+++ linux/mm/swapfile.c 2015-08-16 21:30:22.694123923 -0700
@@ -2143,11 +2143,10 @@ static int claim_swapfile(struct swap_in
if (S_ISBLK(inode->i_mode)) {
p->bdev = bdgrab(I_BDEV(inode));
error = blkdev_get(p->bdev,
- FMODE_READ | FMODE_WRITE | FMODE_EXCL,
- sys_swapon);
+ FMODE_READ | FMODE_WRITE | FMODE_EXCL, p);
if (error < 0) {
p->bdev = NULL;
- return -EINVAL;
+ return error;
}
p->old_block_size = block_size(p->bdev);
error = set_blocksize(p->bdev, PAGE_SIZE);
@@ -2348,7 +2347,6 @@ SYSCALL_DEFINE2(swapon, const char __use
struct filename *name;
struct file *swap_file = NULL;
struct address_space *mapping;
- int i;
int prio;
int error;
union swap_header *swap_header;
@@ -2388,19 +2386,8 @@ SYSCALL_DEFINE2(swapon, const char __use
p->swap_file = swap_file;
mapping = swap_file->f_mapping;
-
- for (i = 0; i < nr_swapfiles; i++) {
- struct swap_info_struct *q = swap_info[i];
-
- if (q == p || !q->swap_file)
- continue;
- if (mapping == q->swap_file->f_mapping) {
- error = -EBUSY;
- goto bad_swap;
- }
- }
-
inode = mapping->host;
+
/* If S_ISREG(inode->i_mode) will do mutex_lock(>i_mutex); */
error = claim_swapfile(p, inode);
if (unlikely(error))
@@ -2433,6 +2420,8 @@ SYSCALL_DEFINE2(swapon, const char __use
goto bad_swap;
}
if (p->bdev && blk_queue_nonrot(bdev_get_queue(p->bdev))) {
+ int cpu;
+
p->flags |= SWP_SOLIDSTATE;
/*
* select a random position to start with to help wear leveling
@@ -2451,9 +2440,9 @@ SYSCALL_DEFINE2(swapon, const char __use
error = -ENOMEM;
goto bad_swap;
}
- for_each_possible_cpu(i) {
+ for_each_possible_cpu(cpu) {
struct percpu_cluster *cluster;
- cluster = per_cpu_ptr(p->percpu_cluster, i);
+ cluster = per_cpu_ptr(p->percpu_cluster, cpu);
cluster_set_null(>index);
}
}
--
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/
Re: [Patch V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
On Mon, 17 Aug 2015, Jiang Liu wrote:
> Function profile_cpu_callback() allocates memory without specifying
> __GFP_THISNODE flag, so replace cpu_to_mem() with cpu_to_node()
> because cpu_to_mem() may cause suboptimal memory allocation if
> there's no free memory on the node returned by cpu_to_mem().
>
Why is cpu_to_node() better with regard to free memory and NUMA locality?
> It's safe to use cpu_to_mem() because build_all_zonelists() also
> builds suitable fallback zonelist for memoryless node.
>
Why reference that cpu_to_mem() is safe if you're changing away from it?
> Signed-off-by: Jiang Liu
> ---
> kernel/profile.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/profile.c b/kernel/profile.c
> index a7bcd28d6e9f..d14805bdcc4c 100644
> --- a/kernel/profile.c
> +++ b/kernel/profile.c
> @@ -336,7 +336,7 @@ static int profile_cpu_callback(struct notifier_block
> *info,
> switch (action) {
> case CPU_UP_PREPARE:
> case CPU_UP_PREPARE_FROZEN:
> - node = cpu_to_mem(cpu);
> + node = cpu_to_node(cpu);
> per_cpu(cpu_profile_flip, cpu) = 0;
> if (!per_cpu(cpu_profile_hits, cpu)[1]) {
> page = alloc_pages_exact_node(node,
--
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/
Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
On Mon, 17 Aug 2015, Jiang Liu wrote: > Function xpc_create_gru_mq_uv() allocates memory with __GFP_THISNODE > flag set, which may cause permanent memory allocation failure on > memoryless node. So replace cpu_to_node() with cpu_to_mem() to better > support memoryless node. For node with memory, cpu_to_mem() is the same > as cpu_to_node(). > > Signed-off-by: Jiang Liu > --- > drivers/misc/sgi-xp/xpc_uv.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c > index 95c894482fdd..9210981c0d5b 100644 > --- a/drivers/misc/sgi-xp/xpc_uv.c > +++ b/drivers/misc/sgi-xp/xpc_uv.c > @@ -238,7 +238,7 @@ xpc_create_gru_mq_uv(unsigned int mq_size, int cpu, char > *irq_name, > > mq->mmr_blade = uv_cpu_to_blade_id(cpu); > > - nid = cpu_to_node(cpu); > + nid = cpu_to_mem(cpu); > page = alloc_pages_exact_node(nid, > GFP_KERNEL | __GFP_ZERO | __GFP_THISNODE, > pg_order); Why not simply fix build_zonelists_node() so that the __GFP_THISNODE zonelists are set up to reference the zones of cpu_to_mem() for memoryless nodes? It seems much better than checking and maintaining every __GFP_THISNODE user to determine if they are using a memoryless node or not. I don't feel that this solution is maintainable in the longterm. -- 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/
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management
Vikas, Tejun,
This is an updated interface. It addresses all comments made
so far and also covers all use-cases the cgroup interface
covers.
Let me know what you think. I'll proceed to writing
the test applications.
Usage model:
This document details how CAT technology is
exposed to userspace.
Each task has a list of task cache reservation entries (TCRE list).
The init process is created with empty TCRE list.
There is a system-wide unique ID space, each TCRE is assigned
an ID from this space. ID's can be reused (but no two TCREs
have the same ID at one time).
The interface accomodates transient and independent cache allocation
adjustments from applications, as well as static cache partitioning
schemes.
Allocation:
Usage of the system calls require CAP_SYS_CACHE_RESERVATION capability.
A configurable percentage is reserved to tasks with empty TCRE list.
On fork, the child inherits the TCR from its parent.
Semantics:
Once a TCRE is created and assigned to a task, that task has
guaranteed reservation on any CPU where its scheduled in,
for the lifetime of the TCRE.
A task can have its TCR list modified without notification.
FIXME: Add a per-task flag to not copy the TCR list of a task but delete
all TCR's on fork.
Interface:
enum cache_rsvt_flags {
CACHE_RSVT_ROUND_DOWN = (1 << 0),/* round "kbytes" down */
};
enum cache_rsvt_type {
CACHE_RSVT_TYPE_CODE = 0, /* cache reservation is for code */
CACHE_RSVT_TYPE_DATA, /* cache reservation is for data */
CACHE_RSVT_TYPE_BOTH, /* cache reservation is for code and data */
};
struct cache_reservation {
unsigned long kbytes;
int type;
int flags;
int trcid;
};
The following syscalls modify the TCR of a task:
* int sys_create_cache_reservation(struct cache_reservation *rsvt);
DESCRIPTION: Creates a cache reservation entry, and assigns
it to the current task.
returns -ENOMEM if not enough space, -EPERM if no permission.
returns 0 if reservation has been successful, copying actual
number of kbytes reserved to "kbytes", type to type, and tcrid.
* int sys_delete_cache_reservation(struct cache_reservation *rsvt);
DESCRIPTION: Deletes a cache reservation entry, deassigning it
from any task.
Backward compatibility for processors with no support for code/data
differentiation: by default code and data cache allocation types
fallback to CACHE_RSVT_TYPE_BOTH on older processors (and return the
information that they done so via "flags").
* int sys_attach_cache_reservation(pid_t pid, unsigned int tcrid);
DESCRIPTION: Attaches cache reservation identified by "tcrid" to
task by identified by pid.
returns 0 if successful.
* int sys_detach_cache_reservation(pid_t pid, unsigned int tcrid);
DESCRIPTION: Detaches cache reservation identified by "tcrid" to
task by identified pid.
The following syscalls list the TCRs:
* int sys_get_cache_reservations(size_t size, struct cache_reservation list[]);
DESCRIPTION: Return all cache reservations in the system.
Size should be set to the maximum number of items that can be stored
in the buffer pointed to by list.
* int sys_get_tcrid_tasks(unsigned int tcrid, size_t size, pid_t list[]);
DESCRIPTION: Return which pids are associated to tcrid.
* sys_get_pid_cache_reservations(pid_t pid, size_t size,
struct cache_reservation list[]);
DESCRIPTION: Return all cache reservations associated with "pid".
Size should be set to the maximum number of items that can be stored
in the buffer pointed to by list.
* sys_get_cache_reservation_info()
DESCRIPTION: ioctl to retrieve hardware info: cache round size, whether
code/data separation is supported.
--
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/
Re: [GIT PULL] x86 fixes
On Mon, Aug 17, 2015 at 5:06 PM, H. Peter Anvin wrote: > User space does not need to treat for FPU instructions, except for > performance reasons, because the kernel emulates the full x87 FPU. So it is > localized to the kernel. But user space needs to avoid SSE2 and such, I suspect. In general, I'd be surprised if things work well if we emulate the FPU (and set CR0.em? I haven't checked out Linux's FPU emulation works) if user code sees fancy instruction sets exposed and possibly even OSXSAVE. None of this matters except for testing, since it's very unlikely that any CPU exists that supports XSAVE, XMM, SSE2, etc but uses emulated x87. But if we emulate such a beast, things could break, and I bet that's what Ingo's seeing. (Also, lots of distros target "i686" these days, and that might cause its own set of problems.) --Andy -- 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/
Re: [Patch V3 4/9] openvswitch: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
On Sun, Aug 16, 2015 at 8:19 PM, Jiang Liu wrote: > Function ovs_flow_stats_update() allocates memory with __GFP_THISNODE > flag set, which may cause permanent memory allocation failure on > memoryless node. So replace cpu_to_node() with cpu_to_mem() to better > support memoryless node. For node with memory, cpu_to_mem() is the same > as cpu_to_node(). > > This change only affects performance and shouldn't affect functionality. > > Signed-off-by: Jiang Liu Acked-by: Pravin B Shelar -- 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/
Re: [PATCH 2/5] net: add Hisilicon Network Subsystem hnae framework support
Hi Kenneth,
just small minor question.
On Fri, Aug 14, 2015 at 1:30 PM, Kenneth Lee wrote:
> HNAE (Hisilicon Network Acceleration Engine) is a framework to provide a
> unified ring buffer interface for Hisilicon Network Acceleration Engines.
>
> With the interface, upper layer can work as ethernet driver, ODP driver or
> other service driver on purpose.
>
> Signed-off-by: Kenneth Lee
> Signed-off-by: Yisen Zhuang
> ---
> drivers/net/ethernet/hisilicon/Kconfig | 33 +-
> drivers/net/ethernet/hisilicon/Makefile | 1 +
> drivers/net/ethernet/hisilicon/hns/Makefile | 15 +
> drivers/net/ethernet/hisilicon/hns/hnae.c | 494 +++
> drivers/net/ethernet/hisilicon/hns/hnae.h | 582
>
> 5 files changed, 1124 insertions(+), 1 deletion(-)
> create mode 100644 drivers/net/ethernet/hisilicon/hns/Makefile
> create mode 100644 drivers/net/ethernet/hisilicon/hns/hnae.c
> create mode 100644 drivers/net/ethernet/hisilicon/hns/hnae.h
>
> diff --git a/drivers/net/ethernet/hisilicon/Kconfig
> b/drivers/net/ethernet/hisilicon/Kconfig
> index dead17b..1e4f5a7 100644
> --- a/drivers/net/ethernet/hisilicon/Kconfig
> +++ b/drivers/net/ethernet/hisilicon/Kconfig
> @@ -5,7 +5,7 @@
> config NET_VENDOR_HISILICON
> bool "Hisilicon devices"
> default y
> - depends on ARM
> + depends on ARM || ARM64
> ---help---
> If you have a network (Ethernet) card belonging to this class, say
> Y.
>
> @@ -31,4 +31,35 @@ config HIP04_ETH
> If you wish to compile a kernel for a hardware with hisilicon p04
> SoC and
> want to use the internal ethernet then you should answer Y to this.
>
> +config HNS
> + tristate "Hisilicon Network Subsystem Support (Framework)"
> + ---help---
> + This selects the framework support for Hisilicon Network Subsystem.
> It
> + is needed by any driver which provides HNS acceleration engine or
> make
> + use of the engine
> +
> +config HNS_DSAF
> + tristate "Hisilicon HNS DSAF device Support"
> + select HNS
> + select HNS_MDIO
> + ---help---
> + This selects the DSAF (Distributed System Area Frabric) network
> + acceleration engine support. The engine is used in Hisilicon P660,
> + Hi1610 and further ICT SoC
> +
> +config HNS_MDIO
> + tristate "Hisilicon HNS MDIO device Support"
> + select MDIO
> + ---help---
> + This selects the HNS MDIO support. It is needed by HNS_DSAF to
> access
> + the PHY
> +
> +config HNS_ENET
> + tristate "Hisilicon HNS Ethernet Device Support"
> + select PHYLIB
> + select HNS
> + ---help---
> + This selects the general ethernet driver for HNS. This module make
> + use of any HNS AE driver, such as HNS_DSAF
> +
> endif # NET_VENDOR_HISILICON
> diff --git a/drivers/net/ethernet/hisilicon/Makefile
> b/drivers/net/ethernet/hisilicon/Makefile
> index 6c14540..2503a9b 100644
> --- a/drivers/net/ethernet/hisilicon/Makefile
> +++ b/drivers/net/ethernet/hisilicon/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_HIX5HD2_GMAC) += hix5hd2_gmac.o
> obj-$(CONFIG_HIP04_ETH) += hip04_mdio.o hip04_eth.o
> +obj-$(CONFIG_HNS) += hns/
> diff --git a/drivers/net/ethernet/hisilicon/hns/Makefile
> b/drivers/net/ethernet/hisilicon/hns/Makefile
> new file mode 100644
> index 000..6680602
> --- /dev/null
> +++ b/drivers/net/ethernet/hisilicon/hns/Makefile
> @@ -0,0 +1,15 @@
> +#
> +# Makefile for the HISILICON network device drivers.
> +#
> +
> +obj-$(CONFIG_HNS) += hnae.o
> +
> +obj-$(CONFIG_HNS_DSAF) += hns_dsaf.o
> +hns_dsaf-objs = hns_ae_adapt.o hns_dsaf_gmac.o hns_dsaf_mac.o
> hns_dsaf_misc.o \
> + hns_dsaf_main.o hns_dsaf_ppe.o hns_dsaf_rcb.o hns_dsaf_xgmac.o
> +
> +obj-$(CONFIG_HNS_MDIO) += hns_mdio.o
> +hns_mdio-objs = hns_mdio_main.o
> +
> +obj-$(CONFIG_HNS_ENET) += hns_enet_drv.o
> +hns_enet_drv-objs = hns_enet.o hns_ethtool.o
> diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c
> b/drivers/net/ethernet/hisilicon/hns/hnae.c
> new file mode 100644
> index 000..fd09768
> --- /dev/null
> +++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
> @@ -0,0 +1,494 @@
> +/*
> + * Copyright (c) 2014-2015 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "hnae.h"
> +
> +#define cls_to_ae_dev(dev) container_of(dev, struct hnae_ae_dev, cls_dev)
> +
> +static struct class *hnae_class;
> +
> +static inline void hnae_list_add(spinlock_t *lock, struct list_head *node,
> +struct list_head *head)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(lock, flags);
Donation
This is Sandeep largest Mega Millions winner giving you $1,500,000 dollars reply with your full name and location. -- 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/
Re: [PATCH 2/3] QIB: Removing usage of pcie_set_mps()
On Mon, Aug 17, 2015 at 5:50 PM, Jiang, Dave wrote:
> On Mon, 2015-08-17 at 17:30 -0500, Bjorn Helgaas wrote:
>> [+cc Mike, linux-rdma]
>>
>> On Wed, Jul 29, 2015 at 04:18:54PM -0600, Keith Busch wrote:
>> > From: Dave Jiang
>> >
>> > This is in perperation of un-exporting the pcie_set_mps() function
>> > symbol. A driver should not be changing the MPS as that is the
>> > responsibility of the PCI subsystem.
>>
>> Please explain the implications of removing this code. Does this
>> affect
>> performance of the device? If so, how do we get that performance
>> back?
>
> Honestly I don't know. But at the same time I think the driver
> shouldn't be touching the MPS at all. Shouldn't that be left to the
> PCIe subsystem and rely on the PCIe subsystem to set this to a sane
> value?
Yes, I think in principle the PCI core should own this, but I also
don't want to introduce a performance regression, so I think we need
to understand whether there's a problem, and if there is, fix it.
>> I also cc'd the QIB maintainers for you:
>>
>> QIB DRIVER
>> M: Mike Marciniszyn
>> L: linux-r...@vger.kernel.org
>> F: drivers/infiniband/hw/qib/
>>
>> > Signed-off-by: Dave Jiang
>> > ---
>> > drivers/infiniband/hw/qib/qib_pcie.c | 27 +-
>> > -
>> > 1 file changed, 1 insertion(+), 26 deletions(-)
>> >
>> > diff --git a/drivers/infiniband/hw/qib/qib_pcie.c
>> > b/drivers/infiniband/hw/qib/qib_pcie.c
>> > index 4758a38..b8a2dcd 100644
>> > --- a/drivers/infiniband/hw/qib/qib_pcie.c
>> > +++ b/drivers/infiniband/hw/qib/qib_pcie.c
>> > @@ -557,12 +557,11 @@ static void qib_tune_pcie_coalesce(struct
>> > qib_devdata *dd)
>> > */
>> > static int qib_pcie_caps;
>> > module_param_named(pcie_caps, qib_pcie_caps, int, S_IRUGO);
>> > -MODULE_PARM_DESC(pcie_caps, "Max PCIe tuning: Payload (0..3),
>> > ReadReq (4..7)");
>> > +MODULE_PARM_DESC(pcie_caps, "Max PCIe tuning: ReadReq (4..7)");
>> >
>> > static void qib_tune_pcie_caps(struct qib_devdata *dd)
>> > {
>> > struct pci_dev *parent;
>> > - u16 rc_mpss, rc_mps, ep_mpss, ep_mps;
>> > u16 rc_mrrs, ep_mrrs, max_mrrs;
>> >
>> > /* Find out supported and configured values for parent
>> > (root) */
>> > @@ -575,30 +574,6 @@ static void qib_tune_pcie_caps(struct
>> > qib_devdata *dd)
>> > if (!pci_is_pcie(parent) || !pci_is_pcie(dd->pcidev))
>> > return;
>> >
>> > - rc_mpss = parent->pcie_mpss;
>> > - rc_mps = ffs(pcie_get_mps(parent)) - 8;
>> > - /* Find out supported and configured values for endpoint
>> > (us) */
>> > - ep_mpss = dd->pcidev->pcie_mpss;
>> > - ep_mps = ffs(pcie_get_mps(dd->pcidev)) - 8;
>> > -
>> > - /* Find max payload supported by root, endpoint */
>> > - if (rc_mpss > ep_mpss)
>> > - rc_mpss = ep_mpss;
>> > -
>> > - /* If Supported greater than limit in module param, limit
>> > it */
>> > - if (rc_mpss > (qib_pcie_caps & 7))
>> > - rc_mpss = qib_pcie_caps & 7;
>> > - /* If less than (allowed, supported), bump root payload */
>> > - if (rc_mpss > rc_mps) {
>> > - rc_mps = rc_mpss;
>> > - pcie_set_mps(parent, 128 << rc_mps);
>> > - }
>> > - /* If less than (allowed, supported), bump endpoint
>> > payload */
>> > - if (rc_mpss > ep_mps) {
>> > - ep_mps = rc_mpss;
>> > - pcie_set_mps(dd->pcidev, 128 << ep_mps);
>> > - }
>> > -
>> > /*
>> > * Now the Read Request size.
>> > * No field for max supported, but PCIe spec limits it to
>> > 4096,
--
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/
Re: [GIT PULL] x86 fixes
User space does not need to treat for FPU instructions, except for performance reasons, because the kernel emulates the full x87 FPU. So it is localized to the kernel. On August 17, 2015 4:59:18 PM PDT, Andy Lutomirski wrote: >On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar wrote: >> So when I re-introduced static allocations math-emu started working >again, to a >> limited degree: on a modern distro, trying to boot /bin/bash I got a >prompt, but >> various programs would segfault. I did not investigate it any deeper, >I suppose >> the FPU emulation does not go far enough for modern user-space, or >maybe it has >> more bugs. >> > >Were you testing with just no387 or did you run a VM with SSE2 and >such turned off? > >There's a *lot* of userspace that incorrectly checks for instructions >without checking for the state support. I've filed bugs against >libgcc for this and they're still not fixed IIRC. > >--Andy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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/
Re: Linux 4.2-rc6 regression: RIP: e030:[] [] detach_if_pending+0x18/0x80
On 08/17/2015 12:18 PM, Eric Dumazet wrote: From: Eric Dumazet Then can you try following fix as well ? Thanks ! [PATCH] timer: fix a race in __mod_timer() I have been running the latest code from git with the 2 patches in this thread applied. No issues so far. -Jon -- 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/
Re: [PATCH v3 22/51] PCI: Add alt_size allocation support
On Mon, Jul 27, 2015 at 04:29:40PM -0700, Yinghai Lu wrote: > On system with several pcie switches, BIOS allocate very tight resources > to the bridge bar, and it is not aligned to min_align as kernel allocation > code. I can't parse this. > For example: > 02:03.0---0c:00.0---0d:04.0---18:00.0 > 18:00.0 need 0x1000, and 0x0001. > BIOS only allocate 0x1010 to 0d:04.0 and above bridges. Do you mean the BIOS only allocated 0x1001? > Later after using /sys/bus/pci/devices/:0c:00.0/remove to remove 0c:00.0, > rescan with /sys/bus/pci/rescan can not allocate 0x1800 to 0c:00.0. > > another example: > 00:1c.0-[02-21]00.0-[03-21]--+-01.0-[04-12]00.0-[05-12]19.0-[06-12]00.0 > +-05.0-[13]-- > > +-07.0-[14-20]00.0-[15-20]--+-08.0-[16]--+-00.0 > | | > \-00.1 > | > +-14.0-[17]00.0 > | > \-19.0-[18-20]00.0 > \-09.0-[21]-- > 06:00.0 need 0x400 and 0x80. > BIOS only allocate 0x480 to 05:19.0 and 04:00.0. > when 05:19.0 get removed via /sys/bus/pci/devices/:05:19.0/remove, > rescan with /sys/bus/pci/rescan will fail. > pci :05:19.0: BAR 14: no space for [mem size 0x0600] > pci :05:19.0: BAR 14: failed to assign [mem size 0x0600] > pci :06:00.0: BAR 2: no space for [mem size 0x0400 64bit] > pci :06:00.0: BAR 2: failed to assign [mem size 0x0400 64bit] > pci :06:00.0: BAR 0: no space for [mem size 0x0080] > pci :06:00.0: BAR 0: failed to assign [mem size 0x0080] > current code try to use align 0x200 and size 0x600, but parent > bridge only have 0x480. I *think* you're saying: - BIOS assigned space for device X - We remove X via sysfs - We rescan via sysfs and discover X - We try to assign space for X - We fail because we don't use the same algorithm as BIOS did If there is an optimal way to assign space for an arbitrary number of BARs, we could just adopt it. I don't know what that is, and I don't know whether an optimal algorithm exists even in principle. If there is no single optimal algorithm, there will always be cases where we fail because we use a different algorithm than the firmware did. > Introduce alt_align/alt_size and store them in realloc list in addition > to addon info, and will try it after min_align/min_size allocation fails. What does "alt" mean? > The alt_align is max_align, and alt_size is aligned size with bridge > minimum window alignment. -- 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/
Re: [GIT PULL] x86 fixes
I ran a hacked Qemu with FPU off. On August 17, 2015 4:59:18 PM PDT, Andy Lutomirski wrote: >On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar wrote: >> So when I re-introduced static allocations math-emu started working >again, to a >> limited degree: on a modern distro, trying to boot /bin/bash I got a >prompt, but >> various programs would segfault. I did not investigate it any deeper, >I suppose >> the FPU emulation does not go far enough for modern user-space, or >maybe it has >> more bugs. >> > >Were you testing with just no387 or did you run a VM with SSE2 and >such turned off? > >There's a *lot* of userspace that incorrectly checks for instructions >without checking for the state support. I've filed bugs against >libgcc for this and they're still not fixed IIRC. > >--Andy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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/
Re: [GIT PULL] x86 fixes
On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar wrote: > So when I re-introduced static allocations math-emu started working again, to > a > limited degree: on a modern distro, trying to boot /bin/bash I got a prompt, > but > various programs would segfault. I did not investigate it any deeper, I > suppose > the FPU emulation does not go far enough for modern user-space, or maybe it > has > more bugs. > Were you testing with just no387 or did you run a VM with SSE2 and such turned off? There's a *lot* of userspace that incorrectly checks for instructions without checking for the state support. I've filed bugs against libgcc for this and they're still not fixed IIRC. --Andy -- 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/
Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote:
> On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
> > On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
>
> > > + 1500,
> > > + 1800,
> > > + 550,
> > > +};
>
> > Why 550 is the last, but not 1800?
>
> You'd have to ask the hardware engineers who designed the chip. I
> suspect it's because 550 was added at a late stage in the design process
> but I'm basically just guessing there.
>
> > > */
> > > @@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device
> > > *pdev)
> > > }
> > > }
>
> > > + if (wm831x_pdata && wm831x_pdata->usb_gadget) {
>
> > Where the wm831x_pdata->usb_gadget is initialized?
>
> It's platform data, it will be initialised by whatever registers the
> platform data.
passing pointers through pdata ?
--
balbi
signature.asc
Description: Digital signature
Re: [RESEND PATCH v5] clk: mediatek: Export CPU mux clocks for CPU frequency control
Quoting Pi-Cheng Chen (2015-08-17 01:56:45)
> From: "pi-cheng.chen"
>
> This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
> for intermediate clock source switching.
>
> Signed-off-by: Pi-Cheng Chen
> Reviewed-by: Daniel Kurtz
Looks OK to me. Can I expect an mtk clk pull request? I think that the
only mtk patches outstanding are this one and the 13MHz clk patch but I
want to double check with you guys.
Regards,
Mike
> ---
> Changes in v5:
> - Replace __initdata with __initconst to fix compiling error
>
> Changes in v4:
> - Fix some minor issues for v3
> - Rebase to the patch that adds 13mhz clock for MT8173[1]
>
> Changes in v3:
> - Rebase to 4.2-rc1
> - Fix some issues of v2
>
> Changes in v2:
> - Remove use of .determine_rate callback
>
> [1] http://patchwork.kernerl.xyz/patch/6777041/
> ---
> drivers/clk/mediatek/Makefile | 2 +-
> drivers/clk/mediatek/clk-cpumux.c | 127
> +
> drivers/clk/mediatek/clk-cpumux.h | 22 ++
> drivers/clk/mediatek/clk-mt8173.c | 23 ++
> include/dt-bindings/clock/mt8173-clk.h | 4 +-
> 5 files changed, 176 insertions(+), 2 deletions(-)
> create mode 100644 drivers/clk/mediatek/clk-cpumux.c
> create mode 100644 drivers/clk/mediatek/clk-cpumux.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 8e4b2a4..299917a 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += clk-mtk.o clk-pll.o clk-gate.o
> +obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-cpumux.o
> obj-$(CONFIG_RESET_CONTROLLER) += reset.o
> obj-y += clk-mt8135.o
> obj-y += clk-mt8173.o
> diff --git a/drivers/clk/mediatek/clk-cpumux.c
> b/drivers/clk/mediatek/clk-cpumux.c
> new file mode 100644
> index 000..fb04fe1
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-cpumux.c
> @@ -0,0 +1,127 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Author: Pi-Cheng Chen
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +#include "clk-cpumux.h"
> +
> +struct mtk_clk_cpumux {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + u32 reg;
> + u32 mask;
> + u8 shift;
> +};
> +
> +static inline struct mtk_clk_cpumux *to_clk_mux(struct clk_hw *_hw)
> +{
> + return container_of(_hw, struct mtk_clk_cpumux, hw);
> +}
> +
> +static u8 clk_cpumux_get_parent(struct clk_hw *hw)
> +{
> + struct mtk_clk_cpumux *mux = to_clk_mux(hw);
> + int num_parents = __clk_get_num_parents(hw->clk);
> + unsigned int val;
> +
> + regmap_read(mux->regmap, mux->reg, );
> +
> + val >>= mux->shift;
> + val &= mux->mask;
> +
> + if (val >= num_parents)
> + return -EINVAL;
> +
> + return val;
> +}
> +
> +static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_cpumux *mux = to_clk_mux(hw);
> + u32 mask, val;
> +
> + val = index << mux->shift;
> + mask = mux->mask << mux->shift;
> +
> + return regmap_update_bits(mux->regmap, mux->reg, mask, val);
> +}
> +
> +static const struct clk_ops clk_cpumux_ops = {
> + .get_parent = clk_cpumux_get_parent,
> + .set_parent = clk_cpumux_set_parent,
> +};
> +
> +static struct clk __init *mtk_clk_register_cpumux(const struct mtk_composite
> *mux,
> + struct regmap *regmap)
> +{
> + struct mtk_clk_cpumux *cpumux;
> + struct clk *clk;
> + struct clk_init_data init;
> +
> + cpumux = kzalloc(sizeof(*cpumux), GFP_KERNEL);
> + if (!cpumux)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = mux->name;
> + init.ops = _cpumux_ops;
> + init.parent_names = mux->parent_names;
> + init.num_parents = mux->num_parents;
> + init.flags = mux->flags;
> +
> + cpumux->reg = mux->mux_reg;
> + cpumux->shift = mux->mux_shift;
> + cpumux->mask = BIT(mux->mux_width) - 1;
> + cpumux->regmap = regmap;
> + cpumux->hw.init =
> +
> + clk = clk_register(NULL, >hw);
> + if (IS_ERR(clk))
> + kfree(cpumux);
> +
> + return clk;
> +}
> +
> +int __init mtk_clk_register_cpumuxes(struct device_node *node,
> + const struct mtk_composite *clks, int num,
> + struct clk_onecell_data *clk_data)
> +{
> + int i;
> + struct clk *clk;
> +
Re: [PATCH v3 20/51] PCI: Skip must+optional if there is no optional addon
On Mon, Jul 27, 2015 at 04:29:38PM -0700, Yinghai Lu wrote:
> If the bridge does not support hotplug or no child with sriov support
> we could get out early and don't try must+optional allocation.
You mention non-hotplug bridges and non-SR-IOV devices, but I can't figure
out how the patch itself relates to those. How can I connect them?
> Also in the loop that update res with optional add info, skip resource
> that add_size is 0.
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/setup-bus.c | 32 +---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index d1f9e19..64ef516 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -450,6 +450,24 @@ static bool pci_need_to_release(unsigned long mask,
> struct resource *res)
> return false; /* should not get here */
> }
>
> +static bool __has_addon(struct list_head *head,
> + struct list_head *realloc_head)
Why does this have a "__" prefix?
> +{
> + int add_count = 0;
> + struct pci_dev_resource *dev_res, *tmp_res;
> +
> + /* check if we have add really */
> + list_for_each_entry(dev_res, head, list) {
> + tmp_res = res_to_dev_res(realloc_head, dev_res->res);
> + if (!tmp_res || !tmp_res->add_size)
> + continue;
> +
> + add_count++;
> + }
> +
> + return add_count != 0;
> +}
> +
> static bool save_resources(struct list_head *head,
> struct list_head *save_head)
> {
> @@ -481,16 +499,24 @@ static bool __assign_resources_must_add_sorted(struct
> list_head *head,
> struct pci_dev_resource *save_res;
> struct pci_dev_resource *dev_res, *tmp_res;
> unsigned long fail_type;
> - resource_size_t add_align;
> + resource_size_t add_align, add_size;
> struct resource *res;
>
> + if (!__has_addon(head, realloc_head))
> + return false;
> +
> if (!save_resources(head, _head))
> return false;
>
> /* Update res in head list with add_size in realloc_head list */
> list_for_each_entry(dev_res, head, list) {
> res = dev_res->res;
> - res->end += get_res_add_size(realloc_head, res);
> + add_size = get_res_add_size(realloc_head, res);
> +
> + if (!add_size)
> + continue;
> +
> + res->end += add_size;
>
> /*
>* There are two kinds of additional resources in the list:
> @@ -578,7 +604,7 @@ static void __assign_resources_sorted(struct list_head
> *head,
>*/
>
> /* Check must+optional add */
> - if (realloc_head && !list_empty(realloc_head) &&
> + if (realloc_head &&
Why are you dropping the !list_empty() test?
> __assign_resources_must_add_sorted(head, realloc_head))
> return;
>
> --
> 1.8.4.5
>
--
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/
Re: [PATCH v3 13/51] PCI: Separate realloc list checking after allocation
On Mon, Jul 27, 2015 at 04:29:31PM -0700, Yinghai Lu wrote:
> We check the realloc list, as list must be empty after allocation.
>
> Separate the realloc list checking to another function.
>
> Add checking that is missed in acpiphp driver.
>
> Signed-off-by: Yinghai Lu
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> ---
> drivers/pci/hotplug/acpiphp_glue.c | 1 +
> drivers/pci/pci.h | 1 +
> drivers/pci/setup-bus.c| 11 ---
> 3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> b/drivers/pci/hotplug/acpiphp_glue.c
> index ff53856..134caee 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -507,6 +507,7 @@ static void enable_slot(struct acpiphp_slot *slot)
> }
> }
> __pci_bus_assign_resources(bus, _list, NULL);
> + __pci_bus_check_realloc(_list);
>
> acpiphp_sanitize_bus(bus);
> pcie_bus_configure_settings(bus);
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 4ff0ff1..2b83977 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -235,6 +235,7 @@ void __pci_bus_size_bridges(struct pci_bus *bus,
> void __pci_bus_assign_resources(const struct pci_bus *bus,
> struct list_head *realloc_head,
> struct list_head *fail_head);
> +void __pci_bus_check_realloc(struct list_head *realloc_head);
> bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
>
> void pci_reassigndev_resource_alignment(struct pci_dev *dev);
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 06664db..f30225c 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -350,6 +350,11 @@ out:
> }
> }
>
> +void __pci_bus_check_realloc(struct list_head *realloc_head)
> +{
> + BUG_ON(!list_empty(realloc_head));
I don't think this really improves readability. At least before, we could
see what we were looking for and we knew it might BUG().
> +}
> +
> /**
> * assign_requested_resources_sorted() - satisfy resource requests
> *
> @@ -1861,7 +1866,7 @@ again:
> /* Depth last, allocate resources and update the hardware. */
> __pci_bus_assign_resources(bus, add_list, _head);
> if (add_list)
> - BUG_ON(!list_empty(add_list));
> + __pci_bus_check_realloc(add_list);
> tried_times++;
>
> /* any device complain? */
> @@ -1936,7 +1941,7 @@ void pci_assign_unassigned_bridge_resources(struct
> pci_dev *bridge)
> again:
> __pci_bus_size_bridges(parent, _list);
> __pci_bridge_assign_resources(bridge, _list, _head);
> - BUG_ON(!list_empty(_list));
> + __pci_bus_check_realloc(_list);
> tried_times++;
>
> if (list_empty(_head))
> @@ -1995,6 +2000,6 @@ void pci_assign_unassigned_bus_resources(struct pci_bus
> *bus)
>_list);
> up_read(_bus_sem);
> __pci_bus_assign_resources(bus, _list, NULL);
> - BUG_ON(!list_empty(_list));
> + __pci_bus_check_realloc(_list);
> }
> EXPORT_SYMBOL_GPL(pci_assign_unassigned_bus_resources);
> --
> 1.8.4.5
>
--
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/
Re: [PATCH v3 09/51] PCI: Rename pdev_sort_resources to pdev_check_resources
On Mon, Jul 27, 2015 at 04:29:27PM -0700, Yinghai Lu wrote:
> We don't do sorting in those functions anymore, so change "sort" to "check"
> instead.
What *do* we do in those functions? "Check" doesn't tell me anything.
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/setup-bus.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 6642a60..292f2a5 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -206,8 +206,8 @@ static resource_size_t __pci_resource_alignment(
> return r_align;
> }
>
> -/* Sort resources by alignment */
> -static void pdev_sort_resources(struct pci_dev *dev,
> +/* check resources and save to the list */
> +static void pdev_check_resources(struct pci_dev *dev,
>struct list_head *realloc_head,
>struct list_head *head)
> {
> @@ -243,7 +243,7 @@ static void pdev_sort_resources(struct pci_dev *dev,
> }
> }
>
> -static void __dev_sort_resources(struct pci_dev *dev,
> +static void __dev_check_resources(struct pci_dev *dev,
>struct list_head *realloc_head,
>struct list_head *head)
> {
> @@ -261,7 +261,7 @@ static void __dev_sort_resources(struct pci_dev *dev,
> return;
> }
>
> - pdev_sort_resources(dev, realloc_head, head);
> + pdev_check_resources(dev, realloc_head, head);
> }
>
> static inline void reset_resource(struct resource *res)
> @@ -561,7 +561,7 @@ static void pdev_assign_resources_sorted(struct pci_dev
> *dev,
> {
> LIST_HEAD(head);
>
> - __dev_sort_resources(dev, add_head, );
> + __dev_check_resources(dev, add_head, );
> __assign_resources_sorted(, add_head, fail_head);
>
> }
> @@ -574,7 +574,7 @@ static void pbus_assign_resources_sorted(const struct
> pci_bus *bus,
> LIST_HEAD(head);
>
> list_for_each_entry(dev, >devices, bus_list)
> - __dev_sort_resources(dev, realloc_head, );
> + __dev_check_resources(dev, realloc_head, );
>
> __assign_resources_sorted(, realloc_head, fail_head);
> }
> --
> 1.8.4.5
>
--
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/
Re: [PATCH v3 07/51] PCI: Reorder resources list for must/optional resources
On Mon, Jul 27, 2015 at 04:29:25PM -0700, Yinghai Lu wrote:
> After we update size and alignment for must+optional resource, we
> reorder them with new alignment, but this is only for STARTALIGN.
>
> For SIZEALIGN type resource, after add back add_size, the alignment
> get changed, so need to do the sorting like STARTALIGN type resources.
>
> Also we need to reorder the sorting back after we restore
> resource to must only when must+optional fail to allocate for all.
>
> So move out the reordering code from the loop to separated function,
> and call it two times accordingly.
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/setup-bus.c | 62
> +
> 1 file changed, 37 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 7346bbf..6f2d508 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -287,6 +287,31 @@ static inline void reset_resource(struct resource *res)
> res->flags = 0;
> }
>
> +static void __sort_resources(struct list_head *head)
Why did you add "__" before the function name?
> +{
> + struct pci_dev_resource *res1, *tmp_res, *res2;
> +
> + list_for_each_entry_safe(res1, tmp_res, head, list) {
> + resource_size_t align1, size1, align2, size2;
> +
> + align1 = pci_resource_alignment(res1->dev, res1->res);
> + size1 = resource_size(res1->res);
> +
> + /* reorder it */
> + list_for_each_entry(res2, head, list) {
> + if (res2 == res1)
> + break;
> +
> + align2 = pci_resource_alignment(res2->dev, res2->res);
> + size2 = resource_size(res2->res);
> + if (is_before(align1, size1, align2, size2)) {
> + list_move_tail(>list, >list);
> + break;
> + }
> + }
> + }
> +}
--
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/
