Re: [PATCH 6/6] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
On Thu, Jul 30, 2015 at 04:35:58PM +0200, Maciej S. Szmigiero wrote:
> Adjust set DAI format function in fsl_ssi driver so it
> doesn't fail and clears RXDIR in AC'97 mode.
>
> Signed-off-by: Maciej Szmigiero
> ---
> sound/soc/fsl/fsl_ssi.c |8 +---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 8e5ff5e..37aabe3 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -900,14 +900,16 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev,
> scr &= ~CCSR_SSI_SCR_SYS_CLK_EN;
> break;
> default:
> - return -EINVAL;
> + if (!fsl_ssi_is_ac97(ssi_private))
> + return -EINVAL;
I think it would be better to add another case for the other mode which
is supported (AC97) instead of using the default case.
> }
>
> stcr |= strcr;
> srcr |= strcr;
>
> - if (ssi_private->cpu_dai_drv.symmetric_rates) {
> - /* Need to clear RXDIR when using SYNC mode */
> + if (ssi_private->cpu_dai_drv.symmetric_rates
> + || fsl_ssi_is_ac97(ssi_private)) {
Please fix this indention. Most of the driver is written with 2 tab
indention after a line break and the new policy seems to be to indent on
the opening bracket.
Regards,
Markus
> + /* Need to clear RXDIR when using SYNC or AC97 mode */
> srcr &= ~CCSR_SSI_SRCR_RXDIR;
> scr |= CCSR_SSI_SCR_SYN;
> }
>
> --
> 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/
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
Re: [PATCH V3 07/16] PM / OPP: Add support to parse "operating-points-v2" bindings
On 30-07-15, 22:51, Stephen Boyd wrote: > > + opp->u_volt = microvolt[0]; > > + opp->u_volt_min = microvolt[1]; > > + opp->u_volt_max = microvolt[2]; > > Should the default be 0 and ULONG_MAX for volt_min/volt_max when > there's on element? I am not still sure how the regulator API is going to look like for this target/min/max thing. So, lets defer it until that is resolved. For now they are initialized to 0. And, because the user has just passed in a target voltage, maybe all three must be == u_volt. :) -- 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: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
On Fri, Jul 31, 2015 at 07:27:19AM +0200, Markus Pargmann wrote:
> Hi,
>
> On Thu, Jul 30, 2015 at 04:34:19PM +0200, Maciej S. Szmigiero wrote:
> > AC'97 bus can support asymmetric playback/capture rates
> > so enable them in this case in fsl_ssi driver.
> >
> > Signed-off-by: Maciej Szmigiero
> > ---
> > sound/soc/fsl/fsl_ssi.c |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> > index a83b900..7f4f0b9 100644
> > --- a/sound/soc/fsl/fsl_ssi.c
> > +++ b/sound/soc/fsl/fsl_ssi.c
> > @@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
> >
> > /* Are the RX and the TX clocks locked? */
> > if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
> > - ssi_private->cpu_dai_drv.symmetric_rates = 1;
> > + if (!fsl_ssi_is_ac97(ssi_private))
> > + ssi_private->cpu_dai_drv.symmetric_rates = 1;
> > +
>
> Why don't you use the DT property that is parsed here to enable
> asymmetric rates?
Just found the last version of this series. Please use v2 and describe
changes for a new iteration of a series.
There is also a different setup with AC97 which does not use DMA. See
the long comment at the top of the file about how ac97 is already used.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
Re: [PATCH V3 07/16] PM / OPP: Add support to parse "operating-points-v2" bindings
On 07/29, Viresh Kumar wrote:
> This adds support in OPP library to parse and create list of OPPs from
> operating-points-v2 bindings. It takes care of most of the properties of
> new bindings (except shared-opp, which will be handled separately).
>
> For backward compatibility, we keep supporting earlier bindings. We try
> to search for the new bindings first, in case they aren't present we
> look for the old deprecated ones.
>
> There are few things marked as TODO:
> - Support for multiple OPP tables
> - Support for multiple regulators
>
> They should be fixed separately.
>
> Reviewed-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
One question below:
> @@ -679,6 +691,125 @@ static int _opp_add_dynamic(struct device *dev,
> unsigned long freq,
> return ret;
> }
>
> +/* TODO: Support multiple regulators */
> +static int opp_get_microvolt(struct dev_pm_opp *opp, struct device *dev)
> +{
> + u32 microvolt[3] = {0};
> + int count, ret;
> +
> + count = of_property_count_u32_elems(opp->np, "opp-microvolt");
> + if (!count)
> + return 0;
> +
> + /* There can be one or three elements here */
> + if (count != 1 && count != 3) {
> + dev_err(dev, "%s: Invalid number of elements in opp-microvolt
> property (%d)\n",
> + __func__, count);
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_u32_array(opp->np, "opp-microvolt", microvolt,
> + count);
> + if (ret) {
> + dev_err(dev, "%s: error parsing opp-microvolt: %d\n", __func__,
> + ret);
> + return -EINVAL;
> + }
> +
> + opp->u_volt = microvolt[0];
> + opp->u_volt_min = microvolt[1];
> + opp->u_volt_max = microvolt[2];
Should the default be 0 and ULONG_MAX for volt_min/volt_max when
there's on element?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand
Hello, Mel. On Mon, Jul 20, 2015 at 09:00:18AM +0100, Mel Gorman wrote: > From: Mel Gorman > > High-order watermark checking exists for two reasons -- kswapd high-order > awareness and protection for high-order atomic requests. Historically we > depended on MIGRATE_RESERVE to preserve min_free_kbytes as high-order free > pages for as long as possible. This patch introduces MIGRATE_HIGHATOMIC > that reserves pageblocks for high-order atomic allocations. This is expected > to be more reliable than MIGRATE_RESERVE was. I have some concerns on this patch. 1) This patch breaks intention of __GFP_WAIT. __GFP_WAIT is used when we want to succeed allocation even if we need to do some reclaim/compaction work. That implies importance of allocation success. But, reserved pageblock for MIGRATE_HIGHATOMIC makes atomic allocation (~__GFP_WAIT) more successful than allocation with __GFP_WAIT in many situation. It breaks basic assumption of gfp flags and doesn't make any sense. 2) Who care about success of high-order atomic allocation with this reliability? In case of allocation without __GFP_WAIT, requestor preare sufficient fallback method. They just want to success if it is easily successful. They don't want to succeed allocation with paying great cost that slow down general workload by this patch that can be accidentally reserve too much memory. > A MIGRATE_HIGHORDER pageblock is created when an allocation request steals > a pageblock but limits the total number to 10% of the zone. When steals happens, pageblock already can be fragmented and we can't fully utilize this pageblock without allowing order-0 allocation. This is very waste. > The pageblocks are unreserved if an allocation fails after a direct > reclaim attempt. > > The watermark checks account for the reserved pageblocks when the allocation > request is not a high-order atomic allocation. > > The stutter benchmark was used to evaluate this but while it was running > there was a systemtap script that randomly allocated between 1 and 1G worth > of order-3 pages using GFP_ATOMIC. In kernel 4.2-rc1 running this workload > on a single-node machine there were 339574 allocation failures. With this > patch applied there were 28798 failures -- a 92% reduction. On a 4-node > machine, allocation failures went from 76917 to 0 failures. There is some missing information to justify benchmark result. Especially, I'd like to know: 1) Detailed system setup (CPU, MEMORY, etc...) 2) Total number of attempt of GFP_ATOMIC allocation request I don't know how you modify stutter benchmark in mmtests but it looks like there is no delay when continually requesting GFP_ATOMIC allocation. 1G of order-3 allocation request without delay seems insane to me. Could you tell me how you modify that benchmark for this patch? > There are minor theoritical side-effects. If the system is intensively > making large numbers of long-lived high-order atomic allocations then > there will be a lot of reserved pageblocks. This may push some workloads > into reclaim until the number of reserved pageblocks is reduced again. This > problem was not observed in reclaim intensive workloads but such workloads > are also not atomic high-order intensive. I don't think this is theoritical side-effects. It can happen easily. Recently, network subsystem makes some of their high-order allocation request ~_GFP_WAIT (fb05e7a89f50: net: don't wait for order-3 page allocation). And, I've submitted similar patch for slub today (mm/slub: don't wait for high-order page allocation). That makes system atomic high-order allocation request more and this side-effect can be possible in many situation. Thanks. -- 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: Tree for Jul 31
Hi all, Changes since 20150730: The at91 tree gained a conflict against the arm-soc tree. The net-next tree gained a conflict against the net tree. Non-merge commits (relative to Linus' tree): 4897 4980 files changed, 244177 insertions(+), 113249 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 224 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (dbe08116b87c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (0871b7248113 ARM: fix __virt_to_idmap build error on !MMU) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (120d200a8627 macintosh/ans-lcd: fix build failure after module_init/exit relocation) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (990c9b347245 Merge branch 'r8152-fixes') Merging ipsec/master (158cd4af8ded packet: missing dev_put() in packet_do_bind()) Merging sound-current/for-linus (649ccd08534e ALSA: hda - Fix MacBook Pro 5,2 quirk) Merging pci-current/for-linus (c9ddbac9c891 PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition) Merging wireless-drivers/master (df2cd4586f17 Merge tag 'iwlwifi-for-kalle-2015-06-12' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging tty.current/tty-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging usb.current/usb-linus (e34d572a9268 Merge tag 'usb-serial-4.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus) Merging usb-gadget-fixes/fixes (4248bd7d3e2c usb: gadget: f_printer: actually limit the number of instances) Merging usb-serial-fixes/usb-linus (74472233233f USB: sierra: add 1199:68AB device ID) Merging staging.current/staging-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging char-misc.current/char-misc-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging input-current/for-linus (3213afb8bf5c Revert "Input: zforce - don't overwrite the stack") Merging crypto-current/master (17fb874dee09 hwrng: core - correct error check of kthread_run call) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (fe0d34d242fa module: weaken locking assertion for oops path.) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix futex_cmp_requeue_pi() error handling) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have branch tracer use recursive field of task struct) Merging drm-in
Re: [PATCH] Staging : wilc1000 :Remove typedef from struct
On Fri, 2015-07-31 at 11:02 +0530, Shraddha Barke wrote:
> This patch fixes the following checkpatch.pl warning:
>
> WARNING: do not add new typedefs
> Signed-off-by: Shraddha Barke
> ---
> drivers/staging/wilc1000/coreconfigurator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c
> b/drivers/staging/wilc1000/coreconfigurator.c
> index 0f31d63..54eb8a1 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -140,7 +140,7 @@ typedef enum {
> } tenuInfoElemID;
>
>
> -typedef struct {
> +struct {
> char *pcRespBuffer;
> s32 s32MaxRespBuffLen;
> s32 s32BytesRead;
You haven't compiled this.
--
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] dtb: Create a common home for cross-architecture dtsi files.
Hi. 2015-07-30 10:30 GMT+09:00 Masahiro Yamada : > Hi, > > > 2015-07-30 0:23 GMT+09:00 Rob Herring : >> On Wed, Jul 29, 2015 at 8:22 AM, Ian Campbell >> wrote: >>> On Wed, 2015-07-29 at 20:07 +0900, Masahiro Yamada wrote: Hi Ian, 2015-07-27 19:35 GMT+09:00 Ian Campbell : > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on > LogicTile Express 20MG" added a new dts file to arch/arm64 which > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a > .dtsi supplied by arch/arm. BTW, is there any chance to merge arch/arm64 and arch/arm in the future? For example, U-boot supports ARM64/32 in a single arch directory, arch/arm/. I guess, the cross-arch home directory for DTSI would be only used to share device trees between arm64 and arm32. -- Best Regards Masahiro Yamada -- 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/6] ASoC: fsl_ssi: instantiate AC'97 CODEC
On Thu, Jul 30, 2015 at 04:35:23PM +0200, Maciej S. Szmigiero wrote:
> Instantiate AC'97 CODEC in fsl_ssi driver AC'97 mode.
>
> Signed-off-by: Maciej Szmigiero
> ---
> sound/soc/fsl/fsl_ssi.c | 21 +
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index 154bcf6..8e5ff5e 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1460,6 +1460,27 @@ done:
> _fsl_ssi_set_dai_fmt(>dev, ssi_private,
>ssi_private->dai_fmt);
>
> + if (fsl_ssi_is_ac97(ssi_private)) {
> + u32 ssi_idx;
> +
> + ret = of_property_read_u32(np, "cell-index", _idx);
This property is not set anywhere in the imx* DTs.
> + if (ret) {
> + dev_err(>dev, "cannot get SSI index property\n");
> + goto error_sound_card;
> + }
> +
> + ssi_private->pdev =
> + platform_device_register_data(NULL,
> + "ac97-codec", ssi_idx, NULL, 0);
If you really want to create a device at this point you should use
PLATFORM_DEVID_AUTO. I would prefer something where this is created in
DT. On the other side it is a discoverable bus..
Regards,
Markus
> + if (IS_ERR(ssi_private->pdev)) {
> + ret = PTR_ERR(ssi_private->pdev);
> + dev_err(>dev,
> + "failed to register AC97 codec platform: %d\n",
> + ret);
> + goto error_sound_card;
> + }
> + }
> +
> return 0;
>
> error_sound_card:
>
> --
> 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/
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
Re: [PATCH V3 06/16] PM / OPP: Break _opp_add_dynamic() into smaller functions
On 07/29, Viresh Kumar wrote: > Later commits would add support for new OPP bindings and this would be > required then. So, lets do it in a separate patch to make it easily > reviewable. > > Another change worth noticing is INIT_LIST_HEAD(>node). We weren't > doing it earlier as we never tried to delete a list node before it is > added to list. But this wouldn't be the case anymore. We might try to > delete a node (just to reuse the same code paths), without it being > getting added to the list. > > Reviewed-by: Bartlomiej Zolnierkiewicz > Signed-off-by: Viresh Kumar > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] Staging:wilc1000 :Remove typedef from struct
This patch fixes the following checkpatch.pl warning:
WARNING: do not add new typedefs
Signed-off-by: Shraddha Barke
---
drivers/staging/wilc1000/coreconfigurator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 54eb8a1..d6ef6e1 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -88,7 +88,7 @@ typedef enum {
} tenuFrmSubtype;
/* Basic Frame Classes */
-typedef enum {
+enum {
CLASS1_FRAME_TYPE = 0x00,
CLASS2_FRAME_TYPE = 0x01,
CLASS3_FRAME_TYPE = 0x02,
--
2.1.0
--
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] Staging : wilc1000 :Remove typedef from struct
This patch fixes the following checkpatch.pl warning:
WARNING: do not add new typedefs
Signed-off-by: Shraddha Barke
---
drivers/staging/wilc1000/coreconfigurator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 0f31d63..54eb8a1 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -140,7 +140,7 @@ typedef enum {
} tenuInfoElemID;
-typedef struct {
+struct {
char *pcRespBuffer;
s32 s32MaxRespBuffLen;
s32 s32BytesRead;
--
2.1.0
--
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] Staging:wilc1000 :Remove braces for single statement blocks
On 31 Jul 2015 10:49, "Shraddha Barke" wrote:
>
> This patch fixes the following checkpatch.pl warning:
>
> WARNING: braces {} are not necessary for single statement blocks
There should be one line space between your commit log
and Signed-off-by line.
> Signed-off-by: Shraddha Barke
> ---
> drivers/staging/wilc1000/coreconfigurator.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c
> b/drivers/staging/wilc1000/coreconfigurator.c
> index 4d5bd1c..1143282 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -1055,10 +1055,8 @@ s32 DeallocateSurveyResults(wid_site_survey_reslts_s
> *pstrSurveyResults)
> {
> s32 s32Error = WILC_SUCCESS;
>
> - if (pstrSurveyResults != NULL) {
> + if (pstrSurveyResults != NULL)
> WILC_FREE(pstrSurveyResults);
> - }
> -
> return s32Error;
> }
> #endif
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates
Hi,
On Thu, Jul 30, 2015 at 04:34:19PM +0200, Maciej S. Szmigiero wrote:
> AC'97 bus can support asymmetric playback/capture rates
> so enable them in this case in fsl_ssi driver.
>
> Signed-off-by: Maciej Szmigiero
> ---
> sound/soc/fsl/fsl_ssi.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index a83b900..7f4f0b9 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -1377,7 +1377,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
>
> /* Are the RX and the TX clocks locked? */
> if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
> - ssi_private->cpu_dai_drv.symmetric_rates = 1;
> + if (!fsl_ssi_is_ac97(ssi_private))
> + ssi_private->cpu_dai_drv.symmetric_rates = 1;
> +
Why don't you use the DT property that is parsed here to enable
asymmetric rates?
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
[PATCH] Staging: wilc1000 :Insert blank line after declaration
This patch fixes the following checkpatch.pl warning:
WARNING: Missing a blank line after declarations
Signed-off-by: Shraddha Barke
---
drivers/staging/wilc1000/coreconfigurator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 1143282..0f31d63 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -1094,6 +1094,7 @@ void ProcessCharWid(char *pcPacket, s32 *ps32PktLen,
u8 *pu8val = (u8 *)ps8WidVal;
u8 u8val = 0;
s32 s32PktLen = *ps32PktLen;
+
if (pstrWID == NULL) {
PRINT_WRN(CORECONFIG_DBG, "Can't set CHAR val 0x%x ,NULL
structure\n", u8val);
return;
--
2.1.0
--
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: [tip:x86/platform] x86/uv/time: Migrate to new set-state interface
On 30-07-15, 15:04, Christoph Lameter wrote: > You need to CC someone at SGI for this I guess. Robin? Nate? Dimitri? > > I am definitely not the right guy to be on the CC list. Sorry about that. It happened because get_maintainers failed to identify those people. Probably MAINTAINERS need some update ? -- 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: [PATCH v3 00/11] Introduce Intel Trace Hub support
Alexander Shishkin writes: > Alexander Shishkin writes: > >> Alexander Shishkin writes: >> >>> Hi Greg and everybody, >> >> Seems like a polite nudge might be in order. :) > > Greg. Ping. -- 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] Staging:wilc1000 :Remove braces for single statement blocks
This patch fixes the following checkpatch.pl warning:
WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: Shraddha Barke
---
drivers/staging/wilc1000/coreconfigurator.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 4d5bd1c..1143282 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -1055,10 +1055,8 @@ s32 DeallocateSurveyResults(wid_site_survey_reslts_s
*pstrSurveyResults)
{
s32 s32Error = WILC_SUCCESS;
- if (pstrSurveyResults != NULL) {
+ if (pstrSurveyResults != NULL)
WILC_FREE(pstrSurveyResults);
- }
-
return s32Error;
}
#endif
--
2.1.0
--
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: Dealing with the NMI mess
On Thu, Jul 30, 2015 at 9:22 PM, Borislav Petkov wrote: > On Thu, Jul 30, 2015 at 02:22:06PM -0700, Andy Lutomirski wrote: >> Great. There's an opcode that invokes an interrupt gate that's not >> marked as allowing unprivileged access, and that opcode doesn't appear >> in the SDM. It appears in the APM opcode map with no explanation at >> all. >> >> Thanks, CPU vendors. > > Here's something better: > > http://www.rcollins.org/secrets/opcodes/ICEBP.html This instruction is awesome. Binutils can disassemble it (it's called "icebp") but it can't assemble it. KVM has special handling for it on VMX and actually reports it to QEMU on SVM (complete with a defined ABI). We have an asm macro so we can assemble it for 32-bit but not 64-bit, despite the fact that it works on 64-bit. The kernel instruction decoder can't decode it. Fortunately, it looks like the vm86 case is correct (or as correct as any of the vm86 junk can be), although I haven't tested it. I bet that icebp is like int3 in that it punches through vm86 mode instead of sending #GP. --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] drivers/usb/: Simplify return statements
Sure, I'll do that. Just wanted to know whether I should split the patches and send them in this same mail thread (may be something like [PATCH 01/04 V2]) or should I start new threads and send them separately to the respective maintainers. Thanks and Regards, Saurabh Karajgaonkar On Thu, Jul 30, 2015 at 11:25:27AM -0500, Felipe Balbi wrote: > On Thu, Jul 30, 2015 at 01:13:42PM +, Karajgaonkar, Saurabh (S.) wrote: > > From: Saurabh Karajgaonkar > > > > This patch is created using simple_return.cocci coccinelle script. > > It replaces the redundant instances where variables are assigned > > return value from functions and then used in return statements. > > > > Signed-off-by: Saurabh Karajgaonkar > > do you mind splitting this per-driver ? That makes it a lot easier for > different maintainers to take their part. For example, I would take > drivers/usb/phy/* and drivers/usb/musb/* > > Alan Stern would handle drivers/usb/host/[uoe]hci*.[ch] > > Mathias Nyman, driver/usb/host/xhci*.[ch] > > and so on. Thanks > > -- > balbi -- 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/6] mmc: sdhci-esdhc-imx: add tuning-step seting support
On Thu, Jul 30, 2015 at 06:25:06PM +0200, Jan Lübbe wrote: > On Mi, 2015-07-29 at 17:03 +0800, Haibo Chen wrote: > > tuning-step is the delay cell steps in tuning procedure. The default > > value of tuning-step is 1. For imx6 series usdhc, tuning procedure can > > be passed when the tuning-step value is 1. But imx7d usdhc need the > > tuning-step value as 2, otherwise it can't pass the tuning procedure. > > > > So this patch add the tuning-step setting in driver, so that user can > > set the tuning-step value in dts. > > From your description, the correct tuning-step value only depends on the > SoC. Why not derive it from the compatible string? > 'tuning-step' actually depends on board and card. The commit message should be reformed a bit. Regards Dong Aisheng > Regards, > Jan Lübbe > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > -- 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: [FYI] tux3: Core changes
Jan Kara writes: >> > Yes, if userspace truncates the file, the situation we end up with is >> > basically the same. However for truncate to happen some malicious process >> > has to come and truncate the file - a failure scenario that is acceptable >> > for most use cases since it doesn't happen unless someone is actively >> > trying to screw you. With page forking it is enough for flusher thread >> > to start writeback for that page to trigger the problem - event that is >> > basically bound to happen without any other userspace application >> > interfering. >> >> Acceptable conclusion is where came from? That pseudocode logic doesn't >> say about usage at all. And even if assume it is acceptable, as far as I >> can see, for example /proc/sys/vm/drop_caches is enough to trigger, or a >> page on non-exists block (sparse file. i.e. missing disk space check in >> your logic). And if really no any lock/check, there would be another >> races. > > So drop_caches won't cause any issues because it avoids mmaped pages. > Also page reclaim or page migration don't cause any issues because > they avoid pages with increased refcount (and increased refcount would stop > drop_caches from reclaiming the page as well if it was not for the mmaped > check before). Generally, elevated page refcount currently guarantees page > isn't migrated, reclaimed, or otherwise detached from the mapping (except > for truncate where the combination of mapping-index becomes invalid) and > your page forking would change that assumption - which IMHO has a big > potential for some breakage somewhere. Lifetime and visibility from user are different topic. The issue here is visibility. Of course, those has relation more or less though, refcount doesn't stop to drop page from radix-tree at all. Well, anyway, your claim seems to be assuming the userspace app workarounds the issues. And it sounds like still not workarounds the ENOSPC issue (validate at page fault/GUP) even if assuming userspace behave as perfect. Calling it as kernel assumption is strange. If you claim, there is strange logic widely used already, and of course, we can't simply break it because of compatibility. I would be able to agree. But your claim sounds like that logic is sane and well designed behavior. So I disagree. > And frankly I fail to see why you and Daniel care so much about this > corner case because from performance POV it's IMHO a non-issue and you > bother with page forking because of performance, don't you? Trying to penalize the corner case path, instead of normal path, should try at first. Penalizing normal path to allow corner case path is insane basically. Make normal path faster and more reliable is what we are trying. > So you can have a look for example at > drivers/media/v4l2-core/videobuf2-dma-contig.c which implements setting up > of a video device buffer at virtual address specified by user. Now I don't > know whether there really is any userspace video program that sets up the > video buffer in mmaped file. I would agree with you that it would be a > strange thing to do but I've seen enough strange userspace code that I > would not be too surprised. > > Another example of similar kind is at > drivers/infiniband/core/umem.c where we again set up buffer for infiniband > cards at users specified virtual address. And there are more drivers in > kernel like that. Unfortunately, I'm not looking those yet though. I guess those would be helpful to see the details. Thanks. -- OGAWA Hirofumi -- 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 RFC] rcu: Don't disable preemption for Tiny and Tree RCU readers
rcu: Don't disable preemption for Tiny and Tree RCU readers
Because preempt_disable() maps to barrier() for non-debug builds,
it forces the compiler to spill and reload registers. Because Tree
RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
barrier() instances generate needless extra code for each instance of
rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
RCU and bloats Tiny RCU (though probably not significantly).
This commit therefore removes the preempt_disable() and preempt_enable()
from the non-preemptible implementations of __rcu_read_lock() and
__rcu_read_unlock(), respectively.
Signed-off-by: Paul E. McKenney
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 78af46c98e55..927c5e60c1dd 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -298,12 +298,14 @@ void synchronize_rcu(void);
static inline void __rcu_read_lock(void)
{
- preempt_disable();
+ if (!IS_ENABLED(CONFIG_TINY_RCU))
+ preempt_disable();
}
static inline void __rcu_read_unlock(void)
{
- preempt_enable();
+ if (!IS_ENABLED(CONFIG_TINY_RCU))
+ preempt_enable();
}
static inline void synchronize_rcu(void)
--
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] inherited events not signalling parent on overflow
On Thu, 11 Jun 2015, Peter Zijlstra wrote: > Right, I had a peek earlier at how fasync worked but came away confused. > > Today I seem to have had better luck. Installing fasync allocates memory > and sets filp->f_flags |= FASYNC, which upon the demise of the file > descriptor ensures the allocation is freed. > > Now for perf, we can have the events stick around for a while after the > original FD is dead because of references from child events. With the > above patch these events would still have a pointer into this free'd > fasync. This is bad. > > A further problem with the patch is that if the parent changes its > fasync state the children might lag and again have pointers into dead > space. > > All is not lost though; does something like the below work? I had meant to reply to this earlier but maybe I forgot. I've been running with this patch for a month now and haven't had problems, and it fixes the issue of inherited signals. So it no one else has issues with the patch it would be nice if it could be pushed upstream. Thanks, Vince -- 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 net-next 0/3] net: Switch tag HW extraction/insertion
Hi Florian, On 07/31/2015 01:51 PM, Florian Fainelli wrote: > On 30/07/15 15:51, David Miller wrote: >> From: David Miller >> Date: Thu, 30 Jul 2015 14:19:35 -0700 (PDT) >> >>> This looks fine, series applied, thanks. >> >> I think your control block is too large, you'll need to rework this >> somehow. > > So napi_gro_cb really is 48 bytes on 64-bits architectures (had not > realized it was so big). > > What would you recommend to do here considering that this driver is > currently used on 32-bits platforms, but I see no reason why someone > would no want to use this feature on a 64-bit platform, I haven't read a lot of the detail in your patch series yet nor do I understand the ramifications of the error this has triggered. But I will stick my hand up for this point. We do have a router with a 64-bit CPU and a bcm L2 switch (b53 is the code name being flung around). None of this is upstream (yet) but the CPU vendor has at least come to the party and has landed patches in 4.2. We'd probably have to do the switch support ourselves (perhaps based on code from openWRT). > yet we are > competing with napi_gro_cb, and adding a new skbuff member is pretty > much a no-no? Would it be acceptable to have a new member which is ifdef > CONFIG_NET_DSA_TAG_BRCM? > > FWIW, this does provide a small 2-3% throughput increase for RX. I'll leaves this for the netdev folks to comment on. I just wanted to let you know that such a use-case _may_ exist. >> >> In function ‘dsa_copy_brcm_tag’, >> inlined from ‘bcm_sysport_desc_rx’ at >> drivers/net/ethernet/broadcom/bcmsysport.c:707:4, >> inlined from ‘bcm_sysport_poll’ at >> drivers/net/ethernet/broadcom/bcmsysport.c:864:12: >> include/linux/compiler.h:447:38: error: call to ‘__compiletime_assert_2016’ >> declared with attribute error: BUILD_BUG_ON failed: sizeof(skb->cb) - >> sizeof(struct napi_gro_cb) < BRCM_TAG_LEN >>_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) >>^ >> include/linux/compiler.h:430:4: note: in definition of macro >> ‘__compiletime_assert’ >> prefix ## suffix();\ >> ^ >> include/linux/compiler.h:447:2: note: in expansion of macro >> ‘_compiletime_assert’ >>_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) >>^ >> include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’ >> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) >> ^ >> include/linux/bug.h:74:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ >>BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) >>^ >> include/linux/netdevice.h:2016:2: note: in expansion of macro ‘BUILD_BUG_ON’ >>BUILD_BUG_ON(sizeof(skb->cb) - sizeof(struct napi_gro_cb) < BRCM_TAG_LEN); >>^ >> scripts/Makefile.build:264: recipe for target >> 'drivers/net/ethernet/broadcom/bcmsysport.o' failed >> > >
Re: Dealing with the NMI mess
On Thu, Jul 30, 2015 at 02:22:06PM -0700, Andy Lutomirski wrote: > Great. There's an opcode that invokes an interrupt gate that's not > marked as allowing unprivileged access, and that opcode doesn't appear > in the SDM. It appears in the APM opcode map with no explanation at > all. > > Thanks, CPU vendors. Here's something better: http://www.rcollins.org/secrets/opcodes/ICEBP.html -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] kthread: Export kthread functions
> On Jul 30, 2015, at 20:02, Neil Horman wrote: > > On Thu, Jul 30, 2015 at 11:48:17AM +0800, yalin wang wrote: >> >>> On Jul 29, 2015, at 18:34, Thomas Gleixner wrote: >>> >>> On Tue, 28 Jul 2015, Andrew Morton wrote: >>> On Tue, 28 Jul 2015 11:59:01 -0400 David Kershner wrote: > The s-Par visornic driver, currently in staging, processes a queue > being serviced by the an s-Par service partition. We can get a message > that something has happened with the Service Partition, when that > happens, we must not access the channel until we get a message that the > service partition is back again. > > The visornic driver has a thread for processing the channel, when we > get the message, we need to be able to park the thread and then resume > it when the problem clears. > > We can do this with kthread_park and unpark but they are not exported > from the kernel, this patch exports the needed functions. > > Signed-off-by: David Kershner Please accumulate the acked-by's and reviewed-by's in the changelog as they are received. I presently have Acked-by: Ingo Molnar Acked-by: Neil Horman Cc: Thomas Gleixner Cc: Richard Weinberger Cc: Tejun Heo I'll scoot this into mainline probably this week to make life simpler for the various trees. >>> >> i am curious why not make some tiny functions to be inline ? >> so that don’t need EXPORT_SYMOBLS , shrink the kernel size. >> Thanks > > Because exporting symbols isn't a big deal, and the compiler can decide when > its > best to inline these functions. As it is, they aren't that small, if you > expand > all their internals > > Neil > this is my test on arm64 arch, i think kthread_should_stop() kthread_should_park() kthread_data() should be inline : without inline: ffcd265c : ………. ffcd26a0: b9001a61str w1, [x19,#24] ffcd26a4: 97fff260bl ffccf024 ffcd26a8: 53001c00uxtbw0, w0 ffcd26ac: 35000c20cbnzw0, ffcd2830 ffcd26b0: 97fff4aabl ffccf958 ffcd26b4: 53001c00uxtbw0, w0 ffcd26b8: 34000320cbz w0, ffcd271c ffcd26bc: f9400a60ldr x0, [x19,#16] ffcd26c0: f91fstr xzr, [x0] ffccf958 : ffccf958: 910003e0mov x0, sp ffccf95c: 9272c400and x0, x0, #0xc000 ffccf960: f9400800ldr x0, [x0,#16] ffccf964: f9420400ldr x0, [x0,#1032] ffccf968: f85c8000ldr x0, [x0,#-56] ffccf96c: d3420800ubfxx0, x0, #2, #1 ffccf970: d65f03c0ret if i mark kthread_should_park to be inline : ffcd19ec : ffcd19ec: a9bc7bfdstp x29, x30, [sp,#-64]! ffcd19f0: 910003fdmov x29, sp ffcd19f4: a90153f3stp x19, x20, [sp,#16] ffcd19f8: aa0003f4mov x20, x0 ffcd19fc: 910003e0mov x0, sp ffcd1a00: a90363f7stp x23, x24, [sp,#48] ffcd1a04: a9025bf5stp x21, x22, [sp,#32] ffcd1a08: d2800035mov x21, #0x1 // #1 ffcd1a0c: 9272c413and x19, x0, #0xc000 ffcd1a10: f9400696ldr x22, [x20,#8] ffcd1a14: 2a1503f7mov w23, w21 ffcd1a18: 52800058mov w24, #0x2 // #2 ffcd1a1c: f9400a60ldr x0, [x19,#16] ffcd1a20: f915str x21, [x0] ffcd1a24: d5033bbfdmb ish ffcd1a28: b9401a61ldr w1, [x19,#24] ffcd1a2c: 11000421add w1, w1, #0x1 ffcd1a30: b9001a61str w1, [x19,#24] ffcd1a34: f9400a62ldr x2, [x19,#16] ffcd1a38: f9420441ldr x1, [x2,#1032] ffcd1a3c: f85c8020ldr x0, [x1,#-56] ffcd1a40: 37080a60tbnzw0, #1, ffcd1b8c ffcd1a44: f85c8020ldr x0, [x1,#-56] // kthread_should_park line ffcd1a48: 36100300tbz w0, #2, ffcd1aa8 // kthread_should_park line ffcd1a4c: f95fstr xzr, [x2] ffcd1a50: b9401a60ldr w0, [x19,#24] it is optimised to 2 instructions , this is my patch, hope can be merged : diff --git a/include/linux/kthread.h b/include/linux/kthread.h
Re: macintosh/ans-lcd: fix build failure after module_init/exit relocation
On Fri, 2015-17-07 at 13:20:31 UTC, Luis Henriques wrote:
> After commit 0fd972a7d91d ("module: relocate module_init from init.h to
> module.h")
> ans-lcd module fails to build with:
>
> drivers/macintosh/ans-lcd.c:201:1: warning: data definition has no type or
> storage class [enabled by default]
> module_init(anslcd_init);
> ^
> drivers/macintosh/ans-lcd.c:201:1: error: type defaults to 'int' in
> declaration of 'module_init' [-Werror=implicit-int]
> drivers/macintosh/ans-lcd.c:201:1: warning: parameter names (without types)
> in function declaration [enabled by default]
> drivers/macintosh/ans-lcd.c:202:1: warning: data definition has no type or
> storage class [enabled by default]
> module_exit(anslcd_exit);
> ^
> drivers/macintosh/ans-lcd.c:202:1: error: type defaults to 'int' in
> declaration of 'module_exit' [-Werror=implicit-int]
> drivers/macintosh/ans-lcd.c:202:1: warning: parameter names (without types)
> in function declaration [enabled by default]
> drivers/macintosh/ans-lcd.c:155:1: warning: 'anslcd_init' defined but not
> used [-Wunused-function]
> anslcd_init(void)
> ^
> drivers/macintosh/ans-lcd.c:195:1: warning: 'anslcd_exit' defined but not
> used [-Wunused-function]
> anslcd_exit(void)
> ^
>
> This commit fixes it by replacing linux/init.h by linux/module.h.
>
> Fixes: 0fd972a7d91d ("module: relocate module_init from init.h to module.h")
> Signed-off-by: Luis Henriques
> Acked-by: Paul Gortmaker
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/120d200a86273d1840d0
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: [kernel] powerpc/powernv/ioda2: Fix calculation for memory allocated for TCE table
On Mon, 2015-20-07 at 10:45:51 UTC, Alexey Kardashevskiy wrote: > The existing code stores the amount of memory allocated for a TCE table. > At the moment it uses @offset which is a virtual offset in the TCE table > which is only correct for a one level tables and it does not include > memory allocated for intermediate levels. When multilevel TCE table is > requested, WARN_ON in tce_iommu_create_table() prints a warning. > > This adds an additional counter to pnv_pci_ioda2_table_do_alloc_pages() > to count actually allocated memory. > > Signed-off-by: Alexey Kardashevskiy > Reviewed-by: David Gibson Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/3ba3a73e9f204ce7904c 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: Revisit AF_BUS: is it a better way to implement KDBUS?
On Thu, Jul 30, 2015 at 11:12:44AM -0700, Andy Lutomirski wrote: > On Thu, Jul 30, 2015 at 6:09 AM, cee1 wrote: > > Hi all, > > > > I'm interested in the idea of AF_BUS. > > > > There have already been varies discussions about it: > > * Missing the AF_BUS - https://lwn.net/Articles/504970/ > > * Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel - > > http://lwn.net/Articles/537021/ > > * presentation-kdbus - > > https://github.com/gregkh/presentation-kdbus/blob/master/kdbus.txt > > * Re: [GIT PULL] kdbus for 4.1-rc1 - https://lwn.net/Articles/641278/ > > * The kdbuswreck - https://lwn.net/Articles/641275/ > > > > I'm wondering whether it is a better way, that is, a general mechanism > > to implement varies __Bus__ orientated IPCs, such as Binder[1], > > DBus[2], etc. > > I find myself wondering whether an in-kernel *bus* is a good idea at > all. Creating a bus that unprivileged programs are allowed to > broadcast on (which is kind of the point) opens up big cans of worms. > Namely: what happens when producers produce data faster than the > consumers consume it? Keep in mind that, with a bus, this scales > pretty badly. Each producer's sends are multiplied by the number of > participants. > > At some point soon, I'm planning on playing with Fedora Rawhide with > kdbus. Anything's possible (maybe), but I'd be rather surprised if it > holds up under abuse of the bus. Just boot Fedora Rawhide with "kdbus=1" on the kernel command line and you should be set. If not, please let the kdbus developers know. thanks, greg k-h -- 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 1/2] extcon: fix hang and extcon_get/set_cable_state().
Hi Roger,
I add minor comment about code clean.
After I modified it by myself, I applied it on extcon-fixes.
Best Regards,
Chanwoo Choi
On 07/07/2015 10:06 PM, Roger Quadros wrote:
> Users of find_cable_index_by_name() will cause a kernel hang
> as the while loop counter is never incremented and end condition
> is never reached.
>
> extcon_get_cable_state() and extcon_set_cable_state() are broken
> because they use cable index instead of cable id. This causes
> the first cable state (cable.0) to be always invalid in sysfs
> or extcon_get_cable_state() users.
>
> Introduce a new function find_cable_id_by_name() that fixes
> both of the above issues.
>
> Fixes: commit 73b6ecdb93e8 ("extcon: Redefine the unique id of supported
> external connectors without 'enum extcon' type")
> Cc: Greg Kroah-Hartman
> Signed-off-by: Roger Quadros
> ---
> drivers/extcon/extcon.c | 38 +-
> 1 file changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 76157ab..987dd3c 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -124,22 +124,34 @@ static int find_cable_index_by_id(struct extcon_dev
> *edev, const unsigned int id
> return -EINVAL;
> }
>
> -static int find_cable_index_by_name(struct extcon_dev *edev, const char
> *name)
> +static int find_cable_id_by_name(struct extcon_dev *edev, const char *name)
> {
> - unsigned int id = EXTCON_NONE;
> + unsigned int id = -EINVAL;
> int i = 0;
>
> - if (edev->max_supported == 0)
> - return -EINVAL;
> -
> - /* Find the the number of extcon cable */
> + /* Find the id of extcon cable */
> while (extcon_name[i]) {
> if (!strncmp(extcon_name[i], name, CABLE_NAME_MAX)) {
> id = i;
> break;
> }
> +
Remove blank line.
> + i++;
> }
>
> + return id;
> +};
> +
> +static int find_cable_index_by_name(struct extcon_dev *edev, const char
> *name)
> +{
> + unsigned int id = EXTCON_NONE;
> +
> + if (edev->max_supported == 0)
> + return -EINVAL;
> +
> + /* Find the the number of extcon cable */
> + id = find_cable_id_by_name(edev, name);
> +
> if (id == EXTCON_NONE)
> return -EINVAL;
>
> @@ -228,9 +240,11 @@ static ssize_t cable_state_show(struct device *dev,
> struct extcon_cable *cable = container_of(attr, struct extcon_cable,
> attr_state);
>
> + int i = cable->cable_index;
> +
> return sprintf(buf, "%d\n",
> extcon_get_cable_state_(cable->edev,
> -cable->cable_index));
> +
> cable->edev->supported_cable[i]));
> }
>
> /**
> @@ -341,6 +355,9 @@ int extcon_get_cable_state_(struct extcon_dev *edev,
> const unsigned int id)
> {
> int index;
>
> + if (id == EXTCON_NONE)
> + return -EINVAL;
> +
This if statement don't be necessary.
Instead, I check the error value on extcon_get_cable_state() by checking the
return value of find_cable_id_by_name().
> index = find_cable_index_by_id(edev, id);
> if (index < 0)
> return index;
> @@ -361,7 +378,7 @@ EXPORT_SYMBOL_GPL(extcon_get_cable_state_);
> */
> int extcon_get_cable_state(struct extcon_dev *edev, const char *cable_name)
> {
> - return extcon_get_cable_state_(edev, find_cable_index_by_name
> + return extcon_get_cable_state_(edev, find_cable_id_by_name
> (edev, cable_name));
I modified it as following:
unsigned int id;
id = find_cable_id_by_name(edev, cable_name);
if (id < 0)
return id;
return extcon_get_cable_state_(edev, id);
> }
> EXPORT_SYMBOL_GPL(extcon_get_cable_state);
> @@ -380,6 +397,9 @@ int extcon_set_cable_state_(struct extcon_dev *edev,
> unsigned int id,
> u32 state;
> int index;
>
> + if (id == EXTCON_NONE)
> + return -EINVAL;
> +
ditto.
> index = find_cable_index_by_id(edev, id);
> if (index < 0)
> return index;
> @@ -404,7 +424,7 @@ EXPORT_SYMBOL_GPL(extcon_set_cable_state_);
> int extcon_set_cable_state(struct extcon_dev *edev,
> const char *cable_name, bool cable_state)
> {
> - return extcon_set_cable_state_(edev, find_cable_index_by_name
> + return extcon_set_cable_state_(edev, find_cable_id_by_name
> (edev, cable_name), cable_state);
ditto.
Thanks,
Chanwoo Choi
--
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 net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive()
On Thu, Jul 30, 2015 at 11:12 AM, Joe Stringer wrote: > Signed-off-by: Joe Stringer > --- > net/openvswitch/vport.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c > index d14f594..baa018f 100644 > --- a/net/openvswitch/vport.c > +++ b/net/openvswitch/vport.c > @@ -475,6 +475,9 @@ void ovs_vport_receive(struct vport *vport, struct > sk_buff *skb, > struct sw_flow_key key; > int error; > > + if (!skb->sk || (sock_net(skb->sk) != read_pnet(>dp->net))) > + skb_scrub_packet(skb, true); > + skb scrub drops dst which cause use-after-free bug for flow based tunnel devices. > stats = this_cpu_ptr(vport->percpu_stats); > u64_stats_update_begin(>syncp); > stats->rx_packets++; > -- > 2.1.4 > -- 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 2/3] x86/perf/hw_breakpoint: Improve range breakpoint validation
Range breakpoints will do the wrong thing if the address isn't aligned. While we're there, add comments about why it's safe for instruction breakpoints. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/hw_breakpoint.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c index 78f3e90c5659..6f345d302cf6 100644 --- a/arch/x86/kernel/hw_breakpoint.c +++ b/arch/x86/kernel/hw_breakpoint.c @@ -291,8 +291,18 @@ static int arch_build_bp_info(struct perf_event *bp) break; #endif default: + /* AMD range breakpoint */ if (!is_power_of_2(bp->attr.bp_len)) return -EINVAL; + if (bp->attr.bp_addr & (bp->attr.bp_len - 1)) + return -EINVAL; + /* +* It's impossible to use a range breakpoint to fake out +* user vs kernel detection because bp_len - 1 can't +* have the high bit set. If we ever allow range instruction +* breakpoints, then we'll have to check for kprobe-blacklisted +* addresses anywhere in the range. +*/ if (!cpu_has_bpext) return -EOPNOTSUPP; info->mask = bp->attr.bp_len - 1; -- 2.4.3 -- 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 0/3] perf: hw_breakpoint safety improvements
Hi, Peter- Here are some baby steps toward eliminating nested NMIs. What do you think? Andy Lutomirski (3): x86/perf/hw_breakpoint: Disallow kernel breakpoints unless kprobe-safe x86/perf/hw_breakpoint: Improve range breakpoint validation x86/perf/hw_breakpoint: Fix check for kernelspace breakpoints arch/x86/kernel/hw_breakpoint.c | 31 ++- include/linux/kprobes.h | 2 ++ kernel/kprobes.c| 2 +- 3 files changed, 33 insertions(+), 2 deletions(-) -- 2.4.3 -- 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 1/3] x86/perf/hw_breakpoint: Disallow kernel breakpoints unless kprobe-safe
Code on the kprobe blacklist doesn't want unexpected int3
exceptions. It probably doesn't want unexpected debug exceptions
either. Be safe: disallow breakpoints in nokprobes code.
On non-CONFIG_KPROBES kernels, there is no kprobe blacklist. In
that case, disallow kernel breakpoints entirely.
It will be particularly important to keep hw breakpoints out of the
entry and NMI code once we move debug exceptions off the IST stack.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/hw_breakpoint.c | 15 +++
include/linux/kprobes.h | 2 ++
kernel/kprobes.c| 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 7114ba220fd4..78f3e90c5659 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -243,6 +244,20 @@ static int arch_build_bp_info(struct perf_event *bp)
info->type = X86_BREAKPOINT_RW;
break;
case HW_BREAKPOINT_X:
+ /*
+* We don't allow kernel breakpoints in places that are not
+* acceptable for kprobes. On non-kprobes kernels, we don't
+* allow kernel breakpoints at all.
+*/
+ if (bp->attr.bp_addr >= TASK_SIZE_MAX) {
+#ifdef CONFIG_KPROBES
+ if (within_kprobe_blacklist(bp->attr.bp_addr))
+ return -EINVAL;
+#else
+ return -EINVAL;
+#endif
+ }
+
info->type = X86_BREAKPOINT_EXECUTE;
/*
* x86 inst breakpoints need to have a specific undefined len.
diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
index 1ab54754a86d..8f6849084248 100644
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -267,6 +267,8 @@ extern void show_registers(struct pt_regs *regs);
extern void kprobes_inc_nmissed_count(struct kprobe *p);
extern bool arch_within_kprobe_blacklist(unsigned long addr);
+extern bool within_kprobe_blacklist(unsigned long addr);
+
struct kprobe_insn_cache {
struct mutex mutex;
void *(*alloc)(void); /* allocate insn page */
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c90e417bb963..d10ab6b9b5e0 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1332,7 +1332,7 @@ bool __weak arch_within_kprobe_blacklist(unsigned long
addr)
addr < (unsigned long)__kprobes_text_end;
}
-static bool within_kprobe_blacklist(unsigned long addr)
+bool within_kprobe_blacklist(unsigned long addr)
{
struct kprobe_blacklist_entry *ent;
--
2.4.3
--
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 3/3] x86/perf/hw_breakpoint: Fix check for kernelspace breakpoints
The check looked wrong, although I think it was actually safe. TASK_SIZE is unnecessarily small for compat tasks, and it wasn't possible to make a range breakpoint so large it started in user space and ended in kernel space. Nonetheless, let's fix up the check for the benefit of future readers. A breakpoint is in the kernel if either end is in the kernel. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/hw_breakpoint.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c index 6f345d302cf6..50a3fad5b89f 100644 --- a/arch/x86/kernel/hw_breakpoint.c +++ b/arch/x86/kernel/hw_breakpoint.c @@ -180,7 +180,11 @@ int arch_check_bp_in_kernelspace(struct perf_event *bp) va = info->address; len = bp->attr.bp_len; - return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE); + /* +* We don't need to worry about va + len - 1 overflowing: +* we already require that va is aligned to a multiple of len. +*/ + return (va >= TASK_SIZE_MAX) || ((va + len - 1) >= TASK_SIZE_MAX); } int arch_bp_generic_fields(int x86_len, int x86_type, -- 2.4.3 -- 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, this is the fixes pull for -rc5, it has a bunch of nouveau fixes, as Ben has been hibernating and has lots of small fixes for lots of bugs across nouveau. radeon has one major fix for hdmi/dp audio regression that is larger than Alex would like, but seems to fix up a fair few bugs, along with some misc fixes. and a few msm fixes, one of which is also a bit large. But nothing in here seems insane or crazy for this stage, just more than I'd like. I'll send a follow up email as I'm on holidays for a couple of week starting after the follow up email. Dave. The following changes since commit cbfe8fa6cd672011c755c3cd85c9ffd4e2d10a6f: Linux 4.2-rc4 (2015-07-26 12:26:21 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to bdce3e7c729907e303396690b2b23b972c6717be: Merge branch 'msm-fixes-4.2' of git://people.freedesktop.org/~robclark/linux into drm-fixes (2015-07-30 12:41:44 +1000) Alex Deucher (4): drm/radeon: rework audio detect (v4) drm/radeon: rework audio modeset to handle non-audio hdmi features drm/radeon/combios: add some validation of lvds values drm/amdgpu: clean up init sequence for failures Alexandre Courbot (6): drm/nouveau/platform: fix compile error if !CONFIG_IOMMU drm/nouveau/ibus/gk20a: increase SM wait timeout drm/nouveau/fifo/gk104: kick channels when deactivating them drm/nouveau/gr/gf100: wait on bottom half of FE's pipeline drm/nouveau/gr/gf100: wait for GR idle after GO_IDLE bundle drm/nouveau/nouveau/ttm: fix tiled system memory with Maxwell Archit Taneja (1): drm/msm: mdp4: Fix drm_framebuffer dereference crash Ben Skeggs (1): drm/nouveau/kms/nv50-: guard against enabling cursor on disabled heads Dan Carpenter (1): drm/amdgpu: information leak in amdgpu_info_ioctl() Dave Airlie (4): Merge branch 'linux-4.2' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge branch 'linux-4.2' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Merge branch 'drm-fixes-4.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'msm-fixes-4.2' of git://people.freedesktop.org/~robclark/linux into drm-fixes Ilia Mirkin (5): drm/nouveau/bios: add 0x59 and 0x5a opcodes drm/nouveau/bios: add proper support for opcode 0x59 drm/nouveau/fbcon/nv11-: correctly account for ring space usage drm/nouveau/fbcon/gf100-: reduce RING_SPACE allocation drm/nouveau/fbcon/g80: reduce PUSH_SPACE alloc, fire ring on accel init Kamil Dudka (2): drm/nouveau: hold mutex when calling nouveau_abi16_fini() drm/nouveau/drm/nv04-nv40/instmem: protect access to priv->heap by mutex Michel Dänzer (2): drm/radeon: Drop drm/ prefix for including drm.h in radeon_drm.h drm/amdgpu: Drop drm/ prefix for including drm.h in amdgpu_drm.h Rob Clark (1): drm/msm: fix msm_gem_prime_get_sg_table() Roy Spliet (1): drm/nouveau/clk/gt215: u32->s32 for difference in req. and set clock Samuel Pitoiset (2): drm/nouveau/pm: prevent freeing the wrong engine context drm/nouveau/pm: fix a potential race condition when creating an engine context Thierry Reding (2): drm/nouveau: Do not leak client objects drm/nouveau/disp: Use NULL for pointers Wentao Xu (2): drm/msm: change to uninterruptible wait in atomic commit drm/msm/mdp5: release SMB (shared memory blocks) in various cases monk.liu (3): drm/amdgpu: different emit_ib for gfx and compute drm/amdgpu: hdp_flush is not needed for inside IB drm/amdgpu: add new parameter to seperate map and unmap drivers/gpu/drm/amd/amdgpu/amdgpu.h| 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 38 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 6 +- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 46 +++-- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 47 +++-- drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 4 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 13 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h| 2 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 33 ++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c| 87 +++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h| 1 + drivers/gpu/drm/msm/msm_atomic.c | 8 +- drivers/gpu/drm/msm/msm_drv.c | 13 +- drivers/gpu/drm/msm/msm_drv.h | 4 +- drivers/gpu/drm/msm/msm_gem.c | 2 +- drivers/gpu/drm/msm/msm_gem_prime.c| 8 +- drivers/gpu/drm/nouveau/nouveau_drm.c |
[PATCH 1/1] scsi: cxgbi: delete useless DIV_ROUND_UP definition
The common kernel.h has already supplied it. Signed-off-by: Peter Chen --- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c index de6feb8..908399a 100644 --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c @@ -158,7 +158,6 @@ static struct scsi_transport_template *cxgb4i_stt; * open/close/abort and data send/receive. */ -#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d)) #define RCV_BUFSIZ_MASK0x3FFU #define MAX_IMM_TX_PKT_LEN 128 -- 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 net-next] r8152: disable the capability of zero length
The UEFI driver would enable zero length, and the Linux driver doesn't need it. Zero length let the hw complete the transfer with length 0, when there is no received packet. It would add the load of USB host controller and reduce the performance. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 57b72ec..348652a 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -339,6 +339,7 @@ /* USB_USB_CTRL */ #define RX_AGG_DISABLE 0x0010 +#define RX_ZERO_EN 0x0080 /* USB_U2P3_CTRL */ #define U2P3_ENABLE0x0001 @@ -2705,7 +2706,7 @@ static void r8153_first_init(struct r8152 *tp) /* rx aggregation */ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL); - ocp_data &= ~RX_AGG_DISABLE; + ocp_data &= ~(RX_AGG_DISABLE | RX_ZERO_EN); ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data); } @@ -3227,7 +3228,7 @@ static void r8152b_init(struct r8152 *tp) /* enable rx aggregation */ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL); - ocp_data &= ~RX_AGG_DISABLE; + ocp_data &= ~(RX_AGG_DISABLE | RX_ZERO_EN); ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data); } -- 2.4.2 -- 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] thermal/cpu_cooling: remove local cooling state variable
Thanks. I will try to add more layman terms here to map cooling state with frequencies. So, the cooling state 0 maps to the highest frequency the cpufreq table supports, and the highest cooling state n maps to the lowest frequency. Right ? On 30-07-15, 13:21, Radivoje Jovanovic wrote: > In this case both userspace thermal solution and cpu_cooling are > changing policy->max and the userspace solution will let governor or HW > (depends on architecture) decide the clipped-freq. Now let us say that > cpu_cooling has 4 available states 0-3 Lets say: 0 == 1.2 GHz 1 == 1.1 GHz 2 == 1 GHz 3 == 800 MHz > and let us say that cpu_cooling > has set the state 1 as the last state. i.e. cpu_cooling says "don't go over 1.1 GHz".. > Now userspace component comes in > and changes the state of the system that matches cpu_cooling state 0. So, policy->max reaches 1.2 GHz and that is not in sync with cpu_cooling. Right ? > cpu_cooling is unaware of this change and does not change the local > cur_state. That's where I think you one of us might be incorrect. At this point when policy->max is changed to 1.2 GHz, a notifier will get issued to cpu_cooling, which will bring policy->max again to 1.1 GHz and so things will be back in control. > Now the temperature changes and cpu_cooling should change > the system state to 1 (userspace component malfunctioned and is not > picking up this change) but since the cur_state is already at 1 > cpu_cooling will not do anything since it believes it is in the correct > state. Hope this explains it better -- 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: [PATCH 4/6] pci: altera: Add Altera PCIe MSI driver
On Wed, Jul 29, 2015 at 5:15 PM, Marc Zyngier wrote:
>
> On 29/07/15 09:52, Ley Foon Tan wrote:
> > On Wed, Jul 29, 2015 at 1:58 AM, Marc Zyngier wrote:
> >> Hi Ley,
> >>
> >> On 28/07/15 11:45, Ley Foon Tan wrote:
> >>> This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> >>> number of vectors, which is a dts parameter.
> >>
> >> Can't you read this configuration from the HW?
> > No, we can't read from HW.
>
> Ah, that's a shame. Specially on HW that is configurable by design.
>
> [...]
>
> >>> +
> >>> + irq = irq_find_mapping(msi->msi_domain->parent,
> >>> offset);
> >>
> >> This would tend to indicate that you don't really need to store the
> >> msi_domain pointer, but the inner_domain pointer instead.
> > Will store the inner_domain pointer. But, I think we still need
> > msi_domain for irq_domain_remove.
> > Or do we have any way to retrieve msi_domain from inner_domain?
>
> Do you have any case where you remove the domains, aside from the
> obvious error cases?
Yes, if there is error in _probe().
> [...]
>
> >>> +
> >>> +static struct msi_domain_info altera_msi_domain_info = {
> >>> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
> >>
> >> So you don't support MSIX? That's a bit weird.
> > Yes, this MSI IP doesn't support it.
>
> This is not really a function of the MSI IP, but of the PCI device. In
> your case, this is just a set of doorbells, so I hardly see what would
> prevent MSI-X to be supported. Multi-MSI, I can see why.
Yes, you are right. Will add MSI_FLAG_PCI_MSIX flag here.
>
> [...]
>
> >>> +static int altera_msi_set_affinity(struct irq_data *irq_data,
> >>> + const struct cpumask *mask, bool force)
> >>> +{
> >>> + return irq_set_affinity(irq_data->hwirq, mask);
> >>
> >> There is no way this can be right. irq_data->hwirq can *never* be passed
> >> as a Linux IRQ. This really should be the IRQ to the GIC.
> >>
> >> Which raises another issue: as you only have a single interrupt to the
> >> GIC, changing the affinity of a single MSI is going to affect all the
> >> other MSIs as well. This doesn't seem like a desirable behaviour.
> > Do we must provide '.irq_set_affinity" callback to msi domain? I have
> > tried set it to NULL,
> > but kernel got the NULL pointer deference error from
> > msi_domain_set_affinity().
> > Recently, I saw this new patch for pci-tegra.c from [1], it doesn't
> > set the ".irq_set_affinity".
> > Just wonder how it can work.
> >
> > Do you have any recommendation way for this?
> >
> > [1]
> > https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/drivers/pci/host?h=irq/gsi-irq-domain-v2=17c22fc4e60e6ad54c7e3b73868cbc057360fa63
>
> Please realize that I *never* tested this patch (I don't think I ever
> posted it officially, I just keep here for convenience), and I wouldn't
> take it as a reference.
>
> When it comes to msi_domain_set_affinity issue, this look more like an
> oversight. I'll cook a patch for that.
>
> Anyway, whichever way you want to do it, you need to fix this. You could
> always return -EINVAL in the meantime,
Will add -EINVAL for now.
Thanks for reviewing.
Regards
Ley Foon
--
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 1/5] pwm: add the Berlin pwm controller driver
Hi,
On Thu, 30 Jul 2015 11:23:17 +0200
Antoine Tenart wrote:
> Add a PWM controller driver for the Marvell Berlin SoCs. This PWM
> controller has 4 channels.
>
> Signed-off-by: Antoine Tenart
> ---
> drivers/pwm/Kconfig | 9 +++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-berlin.c | 207
> +++
> 3 files changed, 217 insertions(+)
> create mode 100644 drivers/pwm/pwm-berlin.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index b1541f40fd8d..1773da8145b8 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -92,6 +92,15 @@ config PWM_BCM2835
> To compile this driver as a module, choose M here: the module
> will be called pwm-bcm2835.
>
> +config PWM_BERLIN
> + tristate "Berlin PWM support"
> + depends on ARCH_BERLIN
> + help
> + PWM framework driver for Berlin.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-berlin.
> +
> config PWM_BFIN
> tristate "Blackfin PWM support"
> depends on BFIN_GPTIMERS
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index ec50eb5b5a8f..670c5fce8bbb 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM) += pwm-atmel-hlcdc.o
> obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
> obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
> obj-$(CONFIG_PWM_BCM2835)+= pwm-bcm2835.o
> +obj-$(CONFIG_PWM_BERLIN) += pwm-berlin.o
> obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
> obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
> obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
> diff --git a/drivers/pwm/pwm-berlin.c b/drivers/pwm/pwm-berlin.c
> new file mode 100644
> index ..786990c1c750
> --- /dev/null
> +++ b/drivers/pwm/pwm-berlin.c
> @@ -0,0 +1,207 @@
> +/*
> + * Marvell Berlin PWM driver
> + *
> + * Copyright (C) 2015 Marvell Technology Group Ltd.
> + *
> + * Antoine Tenart
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BERLIN_PWM_EN0x0
> +#define BERLIN_PWM_CONTROL 0x4
> +#define BERLIN_PWM_DUTY 0x8
> +#define BERLIN_PWM_TCNT 0xc
> +
> +#define BERLIN_PWM_CLK_RATE 1
All PWMs in SoC use cfgclk as clock source, this is missed in BSP we provided
to you. So We could get clk rate rather than hardcoding as this. And we need to
clk_prepare_enable cfgclk in proper point.
> +#define BERLIN_PWM_PRESCALE_MASK 0x7
> +#define BERLIN_PWM_PRESCALE_MAX 4096
> +
> +struct berlin_pwm_chip {
> + struct pwm_chip chip;
> + void __iomem *base;
> + spinlock_t lock;
> +};
> +
> +#define to_berlin_pwm_chip(chip) \
> + container_of((chip), struct berlin_pwm_chip, chip)
> +
> +#define berlin_pwm_readl(chip, channel, offset) \
> + readl((chip)->base + (channel) * 0x10 + offset)
could we use relaxed version?
> +#define berlin_pwm_writel(val, chip, channel, offset)\
> + writel(val, (chip)->base + (channel) * 0x10 + offset)
ditto
> +
> +static const u32 prescaler_table[] = {
> + 1,
> + 4,
> + 8,
> + 16,
> + 64,
> + 256,
> + 1024,
> + 4096,
> +};
> +
> +static int berlin_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + int duty_ns, int period_ns)
> +{
> + struct berlin_pwm_chip *berlin_chip = to_berlin_pwm_chip(chip);
> + int prescale;
> + u32 val, duty, period;
> + u64 tmp;
> +
> + for (prescale = 0; prescale < ARRAY_SIZE(prescaler_table); prescale++) {
> + tmp = BERLIN_PWM_CLK_RATE;
> + do_div(tmp, prescaler_table[prescale]);
> + tmp *= period_ns;
> + do_div(tmp, NSEC_PER_SEC);
> +
> + if (tmp - 1 <= BERLIN_PWM_PRESCALE_MAX)
> + break;
> + }
> +
> + if (tmp - 1 > BERLIN_PWM_PRESCALE_MAX)
> + return -EINVAL;
> +
> + period = tmp;
> + tmp *= duty_ns;
> + do_div(tmp, period_ns);
> + duty = tmp;
> +
> + spin_lock(_chip->lock);
Any reason to take spinlock?
> +
> + val = berlin_pwm_readl(berlin_chip, pwm->hwpwm, BERLIN_PWM_CONTROL);
> + val &= ~BERLIN_PWM_PRESCALE_MASK;
> + val |= prescale;
> + berlin_pwm_writel(val, berlin_chip, pwm->hwpwm, BERLIN_PWM_CONTROL);
> +
> + berlin_pwm_writel(duty, berlin_chip, pwm->hwpwm, BERLIN_PWM_DUTY);
> + berlin_pwm_writel(period, berlin_chip, pwm->hwpwm, BERLIN_PWM_TCNT);
> +
> + spin_unlock(_chip->lock);
> +
> + return 0;
> +}
> +
> +static int berlin_pwm_set_polarity(struct pwm_chip *chip,
> +struct
Re: [PATCH v6 2/4] x86/ldt: Make modify_ldt synchronous
On Thu, Jul 30, 2015 at 3:50 PM, Andrew Cooper wrote: > On 30/07/2015 22:31, Andy Lutomirski wrote: >> Note to -stable maintainers: by itself, this patch makes a >> pre-existing Xen bug much easier to trigger; on a 32-bit Xen guest, >> the new ldt_gdt selftest is likely to OOPS. Even without this >> patch, the test can OOPS, but it's much less likely to happen. The >> Xen maintainers should have a fix for that issue shortly. > > All Xen issues should be fixed by patch 1 now. > Whoops, right. That paragraph in the changelog can be deleted. > ~Andrew -- Andy Lutomirski AMA Capital Management, LLC -- 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 v8 6/6] block: loop: support DIO & AIO
On Thu, Jul 30, 2015 at 12:42 PM, Christoph Hellwig wrote:
> On Thu, Jul 30, 2015 at 07:36:24AM -0400, Ming Lei wrote:
>> + /*
>> + * When working at direct I/O, under very unusual cases,
>> + * such as unaligned direct I/O from application and
>> + * access to loop block device with 'unaligned' offset & size,
>> + * we have to fallback to non-dio mode.
>> + *
>> + * During the switch between dio and non-dio, page cache
>> + * has to be flushed to the backing file.
>> + */
>> + if (unlikely(lo->use_dio && lo->last_use_dio != cmd->use_aio))
>> + vfs_fsync(lo->lo_backing_file, 0);
>
> Filesystems do the cache flushing for you.
If it depends on specific filesystem, it is better to do that here explicitly
and the page cache is still written back just one time(either here or
filesystem).
>
>> +static inline bool req_dio_aligned(struct loop_device *lo,
>> + const struct request *rq)
>> +{
>> + return !((blk_rq_pos(rq) << 9) & lo->dio_align) &&
>> + !(blk_rq_bytes(rq) & lo->dio_align);
>> +}
>> +
>> static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
>> const struct blk_mq_queue_data *bd)
>> {
>> @@ -1554,6 +1658,13 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
>> if (lo->lo_state != Lo_bound)
>> return -EIO;
>>
>> + if (lo->use_dio && !lo->transfer &&
>> + req_dio_aligned(lo, bd->rq) &&
>> + !(cmd->rq->cmd_flags & (REQ_FLUSH | REQ_DISCARD)))
>> + cmd->use_aio = true;
>> + else
>> + cmd->use_aio = false;
>
> But honestly run time switching between buffered I/O and direct I/O from
> the same I/O stream is almost asking for triggering every possible
> race in the dio vs buffered I/O synchronization. And there have been
> a lot of those..
Yes, I agree, that is why I am a bit reluctant to do runtime switch
in v7.
I think of another way to aovid the race by serializing dio/buffered I/O
strictly:
- before switching to buffered I/O from dio, wait for completion of all
pending dio
- run fsync()
- switch to buffered I/O
Then concurrent dio and buffered I/O can't be possible, what do you
think about this approach?
>
> I'd feel much more comfortable with a setup time check.
Yes, that is what v7 did. But during setup time, we can't know
the request's size and offset, and the simplest way is to just
support 512-byte sector size of backing device for avoding
runtime switching.
Christoph and Dave, or do you have other better idea?
Thanks,
--
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 1/5] clocksource: mediatek: do not enable GPT_CLK_EVT when setup
On Wed, 2015-07-22 at 16:14 +0800, Yingjoe Chen wrote: > Spurious mtk timer interrupt is noticed at boot and cause kernel > crash. It seems if GPT is enabled, it will latch irq status even > when its IRQ is disabled. When irq is enabled afterward, we see > spurious interrupt. > Change init flow to only enable GPT_CLK_SRC at mtk_timer_init. > > Acked-by: Matthias Brugger > Reviewed-by: Daniel Kurtz > Signed-off-by: Yingjoe Chen > --- > Update to my patch [1], added __init as Daniel suggest. This is the > only patch that need to change in that series, so I only sent this one. > > http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001545.html Hi Daniel, Thomas, Any suggestions for mtk_timer fixes in this series? Should I resend and add tags from the reviewers? Joe.C -- 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] CMA: Don't return a valid cma for non-cma dev
Hi Michal Nazarewicz,
Thanks for the review.
On Thu, 2015-07-30 at 15:59 +0200, Michal Nazarewicz wrote:
> On Thu, Jul 30 2015, Feng Tang wrote:
> > When system(one x86 soc) boot, we saw many normal dma allocation requests
> > goes to cma area. The call chain is
> > dma_generic_alloc_coherent
> > dma_alloc_from_contiguous -- arch/x86/kernel/pci-dma.c
> > cma_alloc(dev_get_cma_area(dev), count, align)
> >
> > Current dev_get_cma_area() will return a valid "cma" anyway. Then all
> > these requests will be taken as valid cma request, and get pages from
> > cma area, which has 2 problems:
> > 1. make the cma area fragmented
> > 2. confuse the cma reservation, usually cma memory size is set according
> >to the expectation of system scenario, these unexpected requests
> >will affect the designed cma usage.
> >
> > So this patch will enforce the judgement, and only return valid "cma"
> > for real cma user, thus make normal user like IO device driver not
> > abuse cma reserved region.
>
> Just don’t set dma_contiguous_default_area. This patch defeats the
> purpose of a *default* area.
Yes! This is exactly what I tried when I first saw this problem, but
this failed as there 2 places inside drivers/base/dma-contiguous.c
which set the dma_contiguous_default_area
1)
void __init dma_contiguous_reserve(phys_addr_t limit)
{
dma_contiguous_reserve_area(selected_size, selected_base,
selected_limit,
_contiguous_default_area,
fixed);
}
2)
static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
...
if (of_get_flat_dt_prop(node, "linux,cma-default", NULL))
dma_contiguous_set_default(cma);
...
}
Are you suggesting me to remove them?
Thanks,
Feng
Re: [PATCH 1/2] media: atmel-isi: setup the ISI_CFG2 register directly
Hi, list
Ping..., any feedback for this series?
Best Regards,
Josh Wu
On 6/17/2015 6:39 PM, Josh Wu wrote:
In the function configure_geometry(), we will setup the ISI CFG2
according to the sensor output format.
It make no sense to just read back the CFG2 register and just set part
of it.
So just set up this register directly makes things simpler.
Currently only support YUV format from camera sensor.
Signed-off-by: Josh Wu
---
drivers/media/platform/soc_camera/atmel-isi.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 9070172..8bc40ca 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -105,24 +105,25 @@ static u32 isi_readl(struct atmel_isi *isi, u32 reg)
static int configure_geometry(struct atmel_isi *isi, u32 width,
u32 height, u32 code)
{
- u32 cfg2, cr;
+ u32 cfg2;
+ /* According to sensor's output format to set cfg2 */
switch (code) {
/* YUV, including grey */
case MEDIA_BUS_FMT_Y8_1X8:
- cr = ISI_CFG2_GRAYSCALE;
+ cfg2 = ISI_CFG2_GRAYSCALE;
break;
case MEDIA_BUS_FMT_VYUY8_2X8:
- cr = ISI_CFG2_YCC_SWAP_MODE_3;
+ cfg2 = ISI_CFG2_YCC_SWAP_MODE_3;
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
- cr = ISI_CFG2_YCC_SWAP_MODE_2;
+ cfg2 = ISI_CFG2_YCC_SWAP_MODE_2;
break;
case MEDIA_BUS_FMT_YVYU8_2X8:
- cr = ISI_CFG2_YCC_SWAP_MODE_1;
+ cfg2 = ISI_CFG2_YCC_SWAP_MODE_1;
break;
case MEDIA_BUS_FMT_YUYV8_2X8:
- cr = ISI_CFG2_YCC_SWAP_DEFAULT;
+ cfg2 = ISI_CFG2_YCC_SWAP_DEFAULT;
break;
/* RGB, TODO */
default:
@@ -130,17 +131,10 @@ static int configure_geometry(struct atmel_isi *isi, u32
width,
}
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
-
- cfg2 = isi_readl(isi, ISI_CFG2);
- /* Set YCC swap mode */
- cfg2 &= ~ISI_CFG2_YCC_SWAP_MODE_MASK;
- cfg2 |= cr;
/* Set width */
- cfg2 &= ~(ISI_CFG2_IM_HSIZE_MASK);
cfg2 |= ((width - 1) << ISI_CFG2_IM_HSIZE_OFFSET) &
ISI_CFG2_IM_HSIZE_MASK;
/* Set height */
- cfg2 &= ~(ISI_CFG2_IM_VSIZE_MASK);
cfg2 |= ((height - 1) << ISI_CFG2_IM_VSIZE_OFFSET)
& ISI_CFG2_IM_VSIZE_MASK;
isi_writel(isi, ISI_CFG2, cfg2);
--
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] proc: change proc_subdir_lock to a rwlock
On 07/30/2015 10:16 PM, Waiman Long wrote: On 07/29/2015 06:21 PM, Eric W. Biederman wrote: Two quick questions. - What motivates this work? Are you seeing lots of parallel reads on proc? The micro-benchmark that I used was artificial, but it was used to reproduce an exit hanging problem that I saw in real application. In fact, only allow one task to do a lookup seems too limiting to me. - Why not rcu? Additions and removal of proc generic files is very rare. Conversion to rcu for reads should perform better and not take much more work. RCU is harder to verify its correctness, whereas rwlock is easier to use and understand. If it is really a performance critical path where every extra bit of performance counts, I will certainly think RCU may be the right choice. However, in this particular case, I don't think using RCU will give any noticeable performance gain compared with a rwlock. One more thing, RCU is typically used with linked list. It is not easy to use RCU with rbtree and may require major changes to the code. Another alternative is to use seqlock + RCU, but it will still need more code changes than rwlock. Cheers, Longman -- 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] KVM: x86: set TMR when the interrupt is accepted
On Thu, Jul 30, 2015 at 11:26:28PM +, Zhang, Yang Z wrote:
> Paolo Bonzini wrote on 2015-07-29:
> > Do not compute TMR in advance. Instead, set the TMR just before the
> > interrupt is accepted into the IRR. This limits the coupling between
> > IOAPIC and LAPIC.
> >
>
> Uh.., it back to original way which is wrong. You cannot modify the apic
> page(here is the TMR reg) directly when the corresponding VMCS may be used at
> same time.
Oh... Yeah. That's a damn good point, given that the interrupt can be injected
from another thread while one is in that guest vcpu.
Easiest time to update the TMR should be on guest entry through
vcpu_scan_ioapic, as before.
The best way to go is probably to ditch the new per vcpu EOI exit bitmap, and
just update/use the TMR. There's no reason to duplicate that data in the
representation of the apic (I suspect that the duplication was inspired by my
mistaken notion of the TMR). The IOAPIC exit check can use the TMR instead.
Based upon my reading of the SDM, the only reason that the eoi exit bitmaps are
not the exact same as the TMR is that it is possible to have virtual-interrupt
delivery enabled /without/ an apic access page (Note: V-ID => EOI exit bitmap
enabled).
Yang, do you happen to know if that is the case?
[Note: Just looked back at the old code for updating the EOI exit bitmaps,
which for some reason was configured to trigger EOI exits for all IOAPIC
interrupts, not just level-triggered IOAPIC interrupts. Which is weird, and I
believe totally unecessary.]
>
>
> > Signed-off-by: Paolo Bonzini
> > ---
> > arch/x86/kvm/ioapic.c | 9 ++---
> > arch/x86/kvm/ioapic.h | 3 +--
> > arch/x86/kvm/lapic.c | 19 ++-
> > arch/x86/kvm/lapic.h | 1 -
> > arch/x86/kvm/x86.c| 5 +
> > 5 files changed, 14 insertions(+), 23 deletions(-)
> > diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> > index 856f79105bb5..eaf4ec38d980 100644
> > --- a/arch/x86/kvm/ioapic.c
> > +++ b/arch/x86/kvm/ioapic.c
> > @@ -246,8 +246,7 @@ static void update_handled_vectors(struct kvm_ioapic
> > *ioapic)
> > smp_wmb();
> > }
> > -void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap,
> > - u32 *tmr)
> > +void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> > {
> > struct kvm_ioapic *ioapic = vcpu->kvm->arch.vioapic;
> > union kvm_ioapic_redirect_entry *e;
> > @@ -260,13 +259,9 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu,
> > u64 *eoi_exit_bitmap,
> > kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC,
> > index) ||
> > index == RTC_GSI) { if
> > (kvm_apic_match_dest(vcpu, NULL, 0,
> > - e->fields.dest_id, e->fields.dest_mode)) {
> > + e->fields.dest_id, e->fields.dest_mode))
> > __set_bit(e->fields.vector,
> > (unsigned long *)eoi_exit_bitmap);
> > - if (e->fields.trig_mode == IOAPIC_LEVEL_TRIG)
> > - __set_bit(e->fields.vector, -
> > (unsigned long *)tmr); -
> > }
> > }
> > }
> > spin_unlock(>lock);
> > diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> > index ca0b0b4e6256..3dbd0e2aac4e 100644
> > --- a/arch/x86/kvm/ioapic.h
> > +++ b/arch/x86/kvm/ioapic.h
> > @@ -120,7 +120,6 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct
> > kvm_lapic *src,
> > struct kvm_lapic_irq *irq, unsigned long *dest_map);
> > int kvm_get_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> > int kvm_set_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> > -void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap,
> > - u32 *tmr);
> > +void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
> >
> > #endif
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 2a5ca97c263b..9be64c77d6db 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -551,15 +551,6 @@ static void pv_eoi_clr_pending(struct kvm_vcpu
> > *vcpu)
> > __clear_bit(KVM_APIC_PV_EOI_PENDING, >arch.apic_attention);
> > }
> > -void kvm_apic_update_tmr(struct kvm_vcpu *vcpu, u32 *tmr)
> > -{
> > - struct kvm_lapic *apic = vcpu->arch.apic;
> > - int i;
> > -
> > - for (i = 0; i < 8; i++)
> > - apic_set_reg(apic, APIC_TMR + 0x10 * i, tmr[i]);
> > -}
> > -
> > static void apic_update_ppr(struct kvm_lapic *apic)
> > {
> > u32 tpr, isrv, ppr, old_ppr;
> > @@ -781,6 +772,9 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
> > delivery_mode,
> > case APIC_DM_LOWEST:
> > vcpu->arch.apic_arb_prio++;
> > case APIC_DM_FIXED:
> > + if (unlikely(trig_mode && !level))
> > + break;
> > +
> >
Re: [PATCH v4 0/3] Add Mediatek SPI bus driver
On Thu, 2015-07-30 at 21:29 +0200, Jonas Gorski wrote: > Hi, > > On Wed, Jul 29, 2015 at 1:04 PM, Leilk Liu wrote: > > Change in v4: > > 1. fix Mark Brown review comment. > > You should say what you actually fixed/changed, not just that you > changed something. Also the individual patches should contain > changelogs as well (under the tear-off line (--), so one knows if > something was changed between > versions. > OK, I will fix them in future versions. > > Jonas -- 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 1/3] dt-binding: spi: Mediatek: Document devicetree bindings for spi bus
Hi Jonas,
On Thu, 2015-07-30 at 21:27 +0200, Jonas Gorski wrote:
> Hi,
>
> On Wed, Jul 29, 2015 at 1:04 PM, Leilk Liu wrote:
> > Signed-off-by: Leilk Liu
> > ---
> > .../devicetree/bindings/spi/spi-mt65xx.txt | 38
> > ++
> > 1 file changed, 38 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> > b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> > new file mode 100644
> > index 000..f8005d6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> > @@ -0,0 +1,38 @@
> > +MTK SPI device
>
> You are calling it "MediaTek SPI controller" in the Kconfig entry, so
> you should call it that here as well.
>
OK, I will fix it.
> > +
> > +Required properties:
> > +- compatible: should be one of the following.
> > +- mediatek,mt8173-spi: for mt8173 platforms
> > +- mediatek,mt8135-spi: for mt8135 platforms
> > +- mediatek,mt6589-spi: for mt6589 platforms
> > +
> > +- #address-cells: should be 1.
> > +
> > +- #size-cells: should be 0.
> > +
> > +- reg: Address and length of the register set for the device
> > +
> > +- interrupts: Should contain spi interrupt
> > +
> > +- clocks: phandles to input clocks.
> > +
> > +- clock-names: tuple listing input clock names.
> > + Required elements: "main"
> > +
> > +- pad-select: should specify spi pad used, only required for MT8173.
> > +This value should be 0~3.
>
> As already commented on the v3, this is a vendor property, and must
> have a vendor prefix, so it must be called "mediatek,pad-select".
>
OK, I will fix it on the next version.
> > +
> > +Example:
> > +
> > +- SoC Specific Portion:
> > +spi: spi@1100a000 {
> > + compatible = "mediatek,mt8173-spi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0 0x1100a000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CLK_PERI_SPI0>;
> > + clock-names = "main";
> > + pad-select = <0>;
> > + status = "disabled";
> > +};
>
>
> Jonas
--
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/
I have good news for you
Hello I have good news for you. Your long awaited package containing $10.5 Million is en-route your address. It will be delivered via Diplomatic Armored Vehicle. The Diplomatic Armored Company has delegated an official to effect the delivery of the package to you. So, you need to confirm the following information 1. Address where you want the package delivered to 2. Mobile Telephone Number. The Telephone number is very important and but its essential that you provide a number that can receive and send text messages. It will be used to give the official delivering the package to you directions to the address you want the funds delivered. So, provide the telephone & mobile numbers asap. Regards, David Louw -- 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] proc: change proc_subdir_lock to a rwlock
On 07/29/2015 06:21 PM, Eric W. Biederman wrote: Two quick questions. - What motivates this work? Are you seeing lots of parallel reads on proc? The micro-benchmark that I used was artificial, but it was used to reproduce an exit hanging problem that I saw in real application. In fact, only allow one task to do a lookup seems too limiting to me. - Why not rcu? Additions and removal of proc generic files is very rare. Conversion to rcu for reads should perform better and not take much more work. RCU is harder to verify its correctness, whereas rwlock is easier to use and understand. If it is really a performance critical path where every extra bit of performance counts, I will certainly think RCU may be the right choice. However, in this particular case, I don't think using RCU will give any noticeable performance gain compared with a rwlock. Cheers, Longman -- 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/
[added to the 3.18 stable tree] ARC: make sure instruction_pointer() returns unsigned value
From: Alexey Brodkin
This patch has been added to the 3.18 stable tree. If you have any
objections, please let us know.
===
[ Upstream commit f51e2f1911122879eefefa4c592dea8bf794b39c ]
Currently instruction_pointer() returns pt_regs->ret and so return value
is of type "long", which implicitly stands for "signed long".
While that's perfectly fine when dealing with 32-bit values if return
value of instruction_pointer() gets assigned to 64-bit variable sign
extension may happen.
And at least in one real use-case it happens already.
In perf_prepare_sample() return value of perf_instruction_pointer()
(which is an alias to instruction_pointer() in case of ARC) is assigned
to (struct perf_sample_data)->ip (which type is "u64").
And what we see if instuction pointer points to user-space application
that in case of ARC lays below 0x8000_ "ip" gets set properly with
leading 32 zeros. But if instruction pointer points to kernel address
space that starts from 0x8000_ then "ip" is set with 32 leadig
"f"-s. I.e. id instruction_pointer() returns 0x8100_, "ip" will be
assigned with 0x___8100_. Which is obviously wrong.
In particular that issuse broke output of perf, because perf was unable
to associate addresses like 0x___8100_ with anything from
/proc/kallsyms.
That's what we used to see:
--->8--
6.27% ls [unknown][k] 0x8046c5cc
2.96% ls libuClibc-0.9.34-git.so [.] memcpy
2.25% ls libuClibc-0.9.34-git.so [.] memset
1.66% ls [unknown][k] 0x80666536
1.54% ls libuClibc-0.9.34-git.so [.] 0x000224d6
1.18% ls libuClibc-0.9.34-git.so [.] 0x00022472
--->8--
With that change perf output looks much better now:
--->8--
8.21% ls [kernel.kallsyms][k] memset
3.52% ls libuClibc-0.9.34-git.so [.] memcpy
2.11% ls libuClibc-0.9.34-git.so [.] malloc
1.88% ls libuClibc-0.9.34-git.so [.] memset
1.64% ls [kernel.kallsyms][k] _raw_spin_unlock_irqrestore
1.41% ls [kernel.kallsyms][k] __d_lookup_rcu
--->8--
Signed-off-by: Alexey Brodkin
Cc: arc-linux-...@synopsys.com
Cc: sta...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta
Signed-off-by: Sasha Levin
---
arch/arc/include/asm/ptrace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
index 1bfeec2..2a58af7 100644
--- a/arch/arc/include/asm/ptrace.h
+++ b/arch/arc/include/asm/ptrace.h
@@ -63,7 +63,7 @@ struct callee_regs {
long r25, r24, r23, r22, r21, r20, r19, r18, r17, r16, r15, r14, r13;
};
-#define instruction_pointer(regs) ((regs)->ret)
+#define instruction_pointer(regs) (unsigned long)((regs)->ret)
#define profile_pc(regs) instruction_pointer(regs)
/* return 1 if user mode or 0 if kernel mode */
--
2.1.4
--
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 v3] PCI: Only enable IO window if supported
The PCI subsystem always assumes that I/O is supported on PCIe bridges
and tries to assign an I/O window to each child bus even if that is not
the case.
This may result in messages such as:
pcieport :02:00.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size
1000
pcieport :02:00.0: BAR 7: no space for [io size 0x1000]
pcieport :02:00.0: BAR 7: failed to assign [io size 0x1000]
for each bridge port, even if a bus or its parent does not support I/O in
the first place.
To avoid this message, check if a bus supports I/O before trying to enable
it. Also check if the root bus has an IO window assigned; if not, it does
not make sense to try to assign one to any of its child busses.
Cc: Lorenzo Pieralisi
Cc: Yinghai Lu
Signed-off-by: Guenter Roeck
---
v3: Reverse order of new flag, and name it PCI_BUS_FLAGS_SUPPORTS_IO
instead of PCI_BUS_FLAGS_NO_IO.
Don't use bool in pci_bridge_supports_io.
Drop pci_root_has_io_resource(). Instead, determine if the root bus
has an io window in pci_create_root_bus(), and clear
PCI_BUS_FLAGS_SUPPORTS_IO in its bus flags if it doesn't.
v2: Use a new bus flag to indicate if IO is supported on a bus or not.
Using IORESOURCE_DISABLED in resource flags turned out to be futile,
since the term "!res->flags" is widely used to detect if a resource
window is enabled or not, and setting IORESOURCE_DISABLED would
affect all this code.
This patch depends on 'PCI: move pci_read_bridge_bases to the generic
PCI layer' by Lorenzo Pieralisi; without it, pci_read_bridge_io()
is not always called.
---
drivers/pci/probe.c | 34 ++
drivers/pci/setup-bus.c | 9 +
include/linux/pci.h | 1 +
3 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cefd636681b6..d9e02ba34035 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -332,6 +332,24 @@ static void pci_read_bases(struct pci_dev *dev, unsigned
int howmany, int rom)
}
}
+static int pci_bridge_supports_io(struct pci_dev *bridge)
+{
+ u16 io;
+
+ pci_read_config_word(bridge, PCI_IO_BASE, );
+ if (io)
+ return 1;
+
+ /* IO_BASE/LIMIT is either hard-wired to zero or programmed to zero */
+ pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
+ pci_read_config_word(bridge, PCI_IO_BASE, );
+ pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
+ if (io)
+ return 1;
+
+ return 0;
+}
+
static void pci_read_bridge_io(struct pci_bus *child)
{
struct pci_dev *dev = child->self;
@@ -340,6 +358,15 @@ static void pci_read_bridge_io(struct pci_bus *child)
struct pci_bus_region region;
struct resource *res;
+ if (!(child->bus_flags & PCI_BUS_FLAGS_SUPPORTS_IO))
+ return;
+
+ if (!pci_bridge_supports_io(dev)) {
+ dev_printk(KERN_DEBUG, >dev, " no I/O window\n");
+ child->bus_flags &= ~PCI_BUS_FLAGS_SUPPORTS_IO;
+ return;
+ }
+
io_mask = PCI_IO_RANGE_MASK;
io_granularity = 0x1000;
if (dev->io_window_1k) {
@@ -496,6 +523,7 @@ static struct pci_bus *pci_alloc_bus(struct pci_bus *parent)
INIT_LIST_HEAD(>resources);
b->max_bus_speed = PCI_SPEED_UNKNOWN;
b->cur_bus_speed = PCI_SPEED_UNKNOWN;
+ b->bus_flags = PCI_BUS_FLAGS_SUPPORTS_IO;
#ifdef CONFIG_PCI_DOMAINS_GENERIC
if (parent)
b->domain_nr = parent->domain_nr;
@@ -1938,6 +1966,7 @@ struct pci_bus *pci_create_root_bus(struct device
*parent, int bus,
resource_size_t offset;
char bus_addr[64];
char *fmt;
+ bool has_io = false;
b = pci_alloc_bus(NULL);
if (!b)
@@ -2016,8 +2045,13 @@ struct pci_bus *pci_create_root_bus(struct device
*parent, int bus,
} else
bus_addr[0] = '\0';
dev_info(>dev, "root bus resource %pR%s\n", res, bus_addr);
+ if (resource_type(res) == IORESOURCE_IO)
+ has_io = true;
}
+ if (!has_io)
+ b->bus_flags &= ~PCI_BUS_FLAGS_SUPPORTS_IO;
+
down_write(_bus_sem);
list_add_tail(>node, _root_buses);
up_write(_bus_sem);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 508cc56130e3..c3fdace30faf 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -744,7 +744,6 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int i)
base/limit registers must be read-only and read as 0. */
static void pci_bridge_check_ranges(struct pci_bus *bus)
{
- u16 io;
u32 pmem;
struct pci_dev *bridge = bus->self;
struct resource *b_res;
@@ -752,13 +751,7 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
b_res = >resource[PCI_BRIDGE_RESOURCES];
b_res[1].flags |= IORESOURCE_MEM;
-
[GIT PULL] xfs: updates for 4.2-rc4
Hi Linus, Can you please pull the XFS fixes from the tag below? There are a couple of recently found, long standing remote attribute corruption fixes caused by log recovery getting confused after a crash, and the new DAX code in XFS (merged in 4.2-rc1) needs to actually use the DAX fault path on read faults. Thanks! -Dave. The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git tags/xfs-for-linus-4.2-rc4 for you to fetch changes up to df150ed102baa0e78c06e08e975dfb47147dd677: xfs: remote attributes need to be considered data (2015-07-29 11:48:02 +1000) xfs: updates for 4.2-rc4 - remote attribute log recovery corruption fixes - DAX page faults need to use direct mappings, not a page cache mapping. Dave Chinner (3): xfs: call dax_fault on read page faults for DAX xfs: remote attribute headers contain an invalid LSN xfs: remote attributes need to be considered data fs/dax.c| 14 +++-- fs/xfs/libxfs/xfs_attr_remote.c | 44 ++- fs/xfs/xfs_file.c | 21 +-- fs/xfs/xfs_log_recover.c| 11 +++--- 4 files changed, 69 insertions(+), 21 deletions(-) -- Dave Chinner da...@fromorbit.com -- 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 tip/core/rcu 19/19] rcu: Add fastpath bypassing funnel locking
On 07/30/2015 10:44 AM, Peter Zijlstra wrote:
On Fri, Jul 17, 2015 at 04:29:24PM -0700, Paul E. McKenney wrote:
/*
+* First try directly acquiring the root lock in order to reduce
+* latency in the common case where expedited grace periods are
+* rare. We check mutex_is_locked() to avoid pathological levels of
+* memory contention on ->exp_funnel_mutex in the heavy-load case.
+*/
+ rnp0 = rcu_get_root(rsp);
+ if (!mutex_is_locked(>exp_funnel_mutex)) {
+ if (mutex_trylock(>exp_funnel_mutex)) {
+ if (sync_exp_work_done(rsp, rnp0, NULL,
+ >expedited_workdone0, s))
+ return NULL;
+ return rnp0;
+ }
+ }
So our 'new' locking primitives do things like:
static __always_inline int queued_spin_trylock(struct qspinlock *lock)
{
if (!atomic_read(>val)&&
(atomic_cmpxchg(>val, 0, _Q_LOCKED_VAL) == 0))
return 1;
return 0;
}
mutexes do not do this.
Now I suppose the question is, does that extra read slow down the
(common) uncontended case? (remember, we should optimize locks for the
uncontended case, heavy lock contention should be fixed with better
locking schemes, not lock implementations).
I suppose the extra read may slow down the uncontended case, but I am
not sure by how much as I haven't run any test to quantify this.
However, there are use cases where it is advantageous to do a read
first, like when the lock cacheline is likely to be hot (in the
slowpath, for example). So it depends on how the trylock is being used.
Cheers,
Longman
--
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] netfilter: xtables: Add helper macro for xt_match boilerplate
On Thu, Jul 30, 2015 at 5:54 PM, Pablo Neira Ayuso wrote: > On Sun, Jul 26, 2015 at 05:27:37PM +0530, Vaishali Thakkar wrote: >> For simple modules that contain a single xt_match without any >> additional setup code then ends up being a block of duplicated >> boilerplate. This patch adds a new macro, module_xt_match(), >> which replaces the module_init()/module_exit() registrations with >> template functions. > > I prefer not to use this macro, we may need to add something to the > module_init()/module_exit() path in the future to these netfilter > extensions and then we'll have to revert the follow up conversions > patches that you will likely send. Ok. This makes sense. I think in that case you can drop the patch. Thank You. > Thanks anyway. -- 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 net-next 0/3] net: Switch tag HW extraction/insertion
On 30/07/15 15:51, David Miller wrote: > From: David Miller > Date: Thu, 30 Jul 2015 14:19:35 -0700 (PDT) > >> This looks fine, series applied, thanks. > > I think your control block is too large, you'll need to rework this > somehow. So napi_gro_cb really is 48 bytes on 64-bits architectures (had not realized it was so big). What would you recommend to do here considering that this driver is currently used on 32-bits platforms, but I see no reason why someone would no want to use this feature on a 64-bit platform, yet we are competing with napi_gro_cb, and adding a new skbuff member is pretty much a no-no? Would it be acceptable to have a new member which is ifdef CONFIG_NET_DSA_TAG_BRCM? FWIW, this does provide a small 2-3% throughput increase for RX. > > In function ‘dsa_copy_brcm_tag’, > inlined from ‘bcm_sysport_desc_rx’ at > drivers/net/ethernet/broadcom/bcmsysport.c:707:4, > inlined from ‘bcm_sysport_poll’ at > drivers/net/ethernet/broadcom/bcmsysport.c:864:12: > include/linux/compiler.h:447:38: error: call to ‘__compiletime_assert_2016’ > declared with attribute error: BUILD_BUG_ON failed: sizeof(skb->cb) - > sizeof(struct napi_gro_cb) < BRCM_TAG_LEN > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^ > include/linux/compiler.h:430:4: note: in definition of macro > ‘__compiletime_assert’ > prefix ## suffix();\ > ^ > include/linux/compiler.h:447:2: note: in expansion of macro > ‘_compiletime_assert’ > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^ > include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’ > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^ > include/linux/bug.h:74:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) > ^ > include/linux/netdevice.h:2016:2: note: in expansion of macro ‘BUILD_BUG_ON’ > BUILD_BUG_ON(sizeof(skb->cb) - sizeof(struct napi_gro_cb) < BRCM_TAG_LEN); > ^ > scripts/Makefile.build:264: recipe for target > 'drivers/net/ethernet/broadcom/bcmsysport.o' failed > -- Florian -- 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] input: cyapa: add regulator vcc support
Dmitry,
Thank your very much.
Thanks,
Dudley
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 2015?7?31? 2:33
> To: Dudley Du
> Cc: mark.rutl...@arm.com; robh...@kernel.org; ble...@google.com;
> jmmah...@gmail.com; devicet...@vger.kernel.org; linux-in...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] input: cyapa: add regulator vcc support
>
> On Fri, Jul 24, 2015 at 01:05:57PM +0800, Dudley Du wrote:
> > Add power management regulator vcc support.
> > It's described to be supported in the cypress,cyapa.txt document.
> >
> > Signed-off-by: Dudley Du
>
> It looks like we were missing linux/regulator/consumer.h include, I
> added it and applied.
>
> Thanks.
>
> > ---
> > drivers/input/mouse/cyapa.c | 28
> > drivers/input/mouse/cyapa.h | 1 +
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> > index 6195ccb..2159c5e 100644
> > --- a/drivers/input/mouse/cyapa.c
> > +++ b/drivers/input/mouse/cyapa.c
> > @@ -1241,6 +1241,13 @@ static void cyapa_remove_sysfs_group(void *data)
> > sysfs_remove_group(>client->dev.kobj, _sysfs_group);
> > }
> >
> > +static void cyapa_disable_regulator(void *data)
> > +{
> > +struct cyapa *cyapa = data;
> > +
> > +regulator_disable(cyapa->vcc);
> > +}
> > +
> > static int cyapa_probe(struct i2c_client *client,
> > const struct i2c_device_id *dev_id)
> > {
> > @@ -1274,6 +1281,27 @@ static int cyapa_probe(struct i2c_client *client,
> > sprintf(cyapa->phys, "i2c-%d-%04x/input0", client->adapter->nr,
> > client->addr);
> >
> > +cyapa->vcc = devm_regulator_get(dev, "vcc");
> > +if (IS_ERR(cyapa->vcc)) {
> > +error = PTR_ERR(cyapa->vcc);
> > +dev_err(dev, "failed to get vcc regulator: %d\n", error);
> > +return error;
> > +}
> > +
> > +error = regulator_enable(cyapa->vcc);
> > +if (error) {
> > +dev_err(dev, "failed to enable regulator: %d\n", error);
> > +return error;
> > +}
> > +
> > +error = devm_add_action(dev, cyapa_disable_regulator, cyapa);
> > +if (error) {
> > +cyapa_disable_regulator(cyapa);
> > +dev_err(dev, "failed to add disable regulator action: %d\n",
> > +error);
> > +return error;
> > +}
> > +
> > error = cyapa_initialize(cyapa);
> > if (error) {
> > dev_err(dev, "failed to detect and initialize tp device.\n");
> > diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
> > index af12536..b812bba 100644
> > --- a/drivers/input/mouse/cyapa.h
> > +++ b/drivers/input/mouse/cyapa.h
> > @@ -321,6 +321,7 @@ struct cyapa {
> > u8 status[BL_STATUS_SIZE];
> > bool operational; /* true: ready for data reporting; false: not. */
> >
> > +struct regulator *vcc;
> > struct i2c_client *client;
> > struct input_dev *input;
> > char phys[32];/* Device physical location */
> > --
> > 1.9.1
> >
> >
> > ---
> > This message and any attachments may contain Cypress (or its
> > subsidiaries) confidential information. If it has been received
> > in error, please advise the sender and immediately delete this
> > message.
> > ---
> >
>
> --
> Dmitry
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
--
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] rtc: mt6397: implement suspend/resume function in rtc-mt6397 driver
On Thu, 2015-07-30 at 22:53 +0800, Henry Chen wrote:
> Implement the suspend/resume function in order to control rtc's irq_wake flag
> and handle as wakeup source.
>
> Signed-off-by: Henry Chen
> ---
> drivers/rtc/rtc-mt6397.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index c0090b6..9f6c9f8 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -373,6 +373,31 @@ static int mtk_rtc_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int mt6397_rtc_suspend(struct device *dev)
> +{
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(rtc->irq);
> +
> + return 0;
> +}
> +
> +static int mt6397_rtc_resume(struct device *dev)
> +{
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(rtc->irq);
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
> + mt6397_rtc_resume);
> +
> static const struct of_device_id mt6397_rtc_of_match[] = {
> { .compatible = "mediatek,mt6397-rtc", },
> { }
> @@ -382,6 +407,7 @@ static struct platform_driver mtk_rtc_driver = {
> .driver = {
> .name = "mt6397-rtc",
> .of_match_table = mt6397_rtc_of_match,
> + .pm = _pm_ops,
> },
> .probe = mtk_rtc_probe,
> .remove = mtk_rtc_remove,
It looks good to me.
Acked-by: Eddie 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 3.10 ~ 3.14] efi: fix the efi 32bit boot failed problem
On 07/31/2015 12:59 AM, Greg KH wrote:
On Thu, Jul 30, 2015 at 05:45:44PM +0100, Matt Fleming wrote:
On Thu, 30 Jul, at 09:31:02AM, Greg KH wrote:
Why isn't this an issue in newer kernel releases? Did this already get
fixed by some other patch? If so, why can't we just take that patch?
If not, why not?
The commit 35d5134b7d5a ("x86/efi: Correct EFI boot stub use of
code32_start") only exists in the stable trees in that form because
there was quite a lot of churn in that area in Linus tree that didn't
get backported.
So the code in Linus' tree never looked like the code in the stable does
right now.
I _REALLY_ don't like taking patches that are not already in Linus's
tree, as it almost always turns out to be the wrong solution.
Yeah, I think this issue verifies that.
Ugh, what a mess. Ok, if you get something that works and is in a
format that I can apply it, please resend it properly so that we can do
so.
Hi, Matt
Will you take care of this patch or I send a V2?
Thanks!
Fupan
thanks,
greg k-h
--
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/
[RFCv3 2/4] dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.
Signed-off-by: Moritz Fischer
---
arch/arm/boot/dts/zynq-7000.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 0691508..6bebf02 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2015 National Instruments Corp.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -258,6 +259,13 @@
reg = <0x100 0x100>;
};
+ rstc: rstc@200 {
+ compatible = "xlnx,zynq-reset";
+ reg = <0x200 0x48>;
+ #reset-cells = <1>;
+ syscon = <>;
+ };
+
pinctrl0: pinctrl@700 {
compatible = "xlnx,pinctrl-zynq";
reg = <0x700 0x200>;
--
2.4.3
--
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/
[RFCv3 4/4] ARM: zynq: Select ARCH_HAS_RESET_CONTROLLER
Signed-off-by: Moritz Fischer --- arch/arm/mach-zynq/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig index 78e5e00..77d7df7 100644 --- a/arch/arm/mach-zynq/Kconfig +++ b/arch/arm/mach-zynq/Kconfig @@ -1,5 +1,6 @@ config ARCH_ZYNQ bool "Xilinx Zynq ARM Cortex A9 Platform" if ARCH_MULTI_V7 + select ARCH_HAS_RESET_CONTROLLER select ARCH_SUPPORTS_BIG_ENDIAN select ARM_AMBA select ARM_GIC -- 2.4.3 -- 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/
[RFCv3 3/4] reset: reset-zynq: Adding support for Xilinx Zynq reset controller.
This adds a reset controller driver to control the Xilinx Zynq
AP-SoC's various resets.
Signed-off-by: Moritz Fischer
---
drivers/reset/Makefile | 1 +
drivers/reset/reset-zynq.c | 155 +
2 files changed, 156 insertions(+)
create mode 100644 drivers/reset/reset-zynq.c
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..3fe50e7 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
diff --git a/drivers/reset/reset-zynq.c b/drivers/reset/reset-zynq.c
new file mode 100644
index 000..89318a5
--- /dev/null
+++ b/drivers/reset/reset-zynq.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (c) 2015, National Instruments Corp.
+ *
+ * Xilinx Zynq Reset controller driver
+ *
+ * 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; version 2 of the License.
+ *
+ * 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
+#include
+#include
+
+struct zynq_reset_data {
+ struct regmap *slcr;
+ struct reset_controller_dev rcdev;
+ u32 offset;
+};
+
+#define to_zynq_reset_data(p) \
+ container_of((p), struct zynq_reset_data, rcdev)
+
+static int zynq_reset_assert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+ struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
+
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+
+ pr_debug("%s: %s reset bank %u offset %u\n", KBUILD_MODNAME, __func__,
+bank, offset);
+
+ return regmap_update_bits(priv->slcr,
+ priv->offset + (bank * 4),
+ BIT(offset),
+ BIT(offset));
+}
+
+static int zynq_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
+
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+
+ pr_debug("%s: %s reset bank %u offset %u\n", KBUILD_MODNAME, __func__,
+bank, offset);
+
+ return regmap_update_bits(priv->slcr,
+ priv->offset + (bank * 4),
+ BIT(offset),
+ ~BIT(offset));
+}
+
+static int zynq_reset_status(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+ struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
+
+ int bank = id / BITS_PER_LONG;
+ int offset = id % BITS_PER_LONG;
+ int ret;
+ u32 reg;
+
+ pr_debug("%s: %s reset bank %u offset %u\n", KBUILD_MODNAME, __func__,
+bank, offset);
+
+ ret = regmap_read(priv->slcr, priv->offset + (bank * 4), );
+ if (ret)
+ return ret;
+
+ return !!(reg & BIT(offset));
+}
+
+static struct reset_control_ops zynq_reset_ops = {
+ .assert = zynq_reset_assert,
+ .deassert = zynq_reset_deassert,
+ .status = zynq_reset_status,
+};
+
+static int zynq_reset_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct zynq_reset_data *priv;
+
+ priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, priv);
+
+ priv->slcr = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+"syscon");
+ if (IS_ERR(priv->slcr)) {
+ dev_err(>dev, "unable to get zynq-slcr regmap");
+ return PTR_ERR(priv->slcr);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(>dev, "missing IO resource\n");
+ return -ENODEV;
+ }
+
+ priv->offset = res->start;
+
+ priv->rcdev.owner = THIS_MODULE;
+ priv->rcdev.nr_resets = resource_size(res) / 4 * BITS_PER_LONG;
+ priv->rcdev.ops = _reset_ops;
+ priv->rcdev.of_node = pdev->dev.of_node;
+ reset_controller_register(>rcdev);
+
+ return 0;
+}
+
+static int zynq_reset_remove(struct platform_device *pdev)
+{
+ struct zynq_reset_data *priv = platform_get_drvdata(pdev);
+
+ reset_controller_unregister(>rcdev);
+
+ return 0;
+}
+
+static const
[RFCv3 1/4] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
Signed-off-by: Moritz Fischer
---
.../devicetree/bindings/reset/zynq-reset.txt | 68 ++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/zynq-reset.txt
b/Documentation/devicetree/bindings/reset/zynq-reset.txt
new file mode 100644
index 000..498c037a
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/zynq-reset.txt
@@ -0,0 +1,68 @@
+Xilinx Zynq Reset Manager
+
+The Zynq AP-SoC has several different resets.
+
+See Chapter 26 of the Zynq TRM (UG585) for more information about Zynq resets.
+
+Required properties:
+- compatible: "xlnx,zynq-reset"
+- reg: SLCR offset and size taken via syscon <0x200 0x48>
+- syscon: <>
+ This should be a phandle to the Zynq's SLCR register.
+- #reset-cells: Must be 1
+
+The Zynq Reset Manager needs to be a childnode of the SLCR.
+
+Example:
+ rstc: rstc@200 {
+ compatible = "xlnx,zynq-reset";
+ reg = <0x200 0x48>;
+ #reset-cells = <1>;
+ syscon = <>;
+ };
+
+Reset outputs:
+ 0 : soft reset
+ 32 : ddr reset
+ 64 : topsw reset
+ 96 : dmac reset
+ 128: usb0 reset
+ 129: usb1 reset
+ 160: gem0 reset
+ 161: gem1 reset
+ 164: gem0 rx reset
+ 165: gem1 rx reset
+ 166: gem0 ref reset
+ 167: gem1 ref reset
+ 192: sdio0 reset
+ 193: sdio1 reset
+ 196: sdio0 ref reset
+ 197: sdio1 ref reset
+ 224: spi0 reset
+ 225: spi1 reset
+ 226: spi0 ref reset
+ 227: spi1 ref reset
+ 256: can0 reset
+ 257: can1 reset
+ 258: can0 ref reset
+ 259: can1 ref reset
+ 288: i2c0 reset
+ 289: i2c1 reset
+ 320: uart0 reset
+ 321: uart1 reset
+ 322: uart0 ref reset
+ 323: uart1 ref reset
+ 352: gpio reset
+ 384: lqspi reset
+ 385: qspi ref reset
+ 416: smc reset
+ 417: smc ref reset
+ 448: ocm reset
+ 512: fpga0 out reset
+ 513: fpga1 out reset
+ 514: fpga2 out reset
+ 515: fpga3 out reset
+ 544: a9 reset 0
+ 545: a9 reset 1
+ 552: peri reset
+
--
2.4.3
--
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/
[RFCv3 0/4] Adding support for Zynq Reset Controller
Hi all, I made another RFC addressing most of the feedback that I got so far. I haven't completly given up on Sören's idea of getting rid of having some sort of protection against people using wrong bits by accident, but haven't come up with a clean way to do so yet (especially when looking at the possiblity of also supporting the upcoming Zynq's reset controller). I changed the reg property to <0x200 0x48> but I'm not sure if that's correct. At 0x24C there's the RS_AWDT_CTRL which is not a reset. The last legit one is A9_CPU_RST_CTRL at 0x244. As Michal requested I removed the #include syntax from the devicetree bindings. Thanks for your reviews, Moritz Moritz Fischer (4): docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings. dts: zynq: Add devicetree entry for Xilinx Zynq reset controller. reset: reset-zynq: Adding support for Xilinx Zynq reset controller. ARM: zynq: Select ARCH_HAS_RESET_CONTROLLER .../devicetree/bindings/reset/zynq-reset.txt | 68 + arch/arm/boot/dts/zynq-7000.dtsi | 8 ++ arch/arm/mach-zynq/Kconfig | 1 + drivers/reset/Makefile | 1 + drivers/reset/reset-zynq.c | 155 + 5 files changed, 233 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset.txt create mode 100644 drivers/reset/reset-zynq.c -- 2.4.3 -- 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: regulator: Question about the buck_volt_range and MT6311_MAX_UV setting
On Thu, 2015-07-30 at 21:10 +0800, Axel Lin wrote: Hi Axel, Oh..it was 1.4V on data sheet, but I think you're right, MT6311_MAX_UV should be 1393750 was more precisely, I will change that. Thanks. > Hi Henry, > Seems something wrong in either buck_volt_range or MT6311_MAX_UV setting. > > .n_voltages = (MT6311_MAX_UV - MT6311_MIN_UV) / MT6311_STEP_UV + 1 > (140 - 60) / 6250 + 1 = 129 > So .n_voltages = 129. > > From the buck_volt_range: > The linear range has min_sel: 0, max_sel: 0x7f > (0 ~ 127, so 128 selector in this range) > And the max voltage is > 60 + 0x7f * 6250 = 1393750 > > I don't have the datasheet, so can you double check this? > Thank, > Axel > > -- 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/slub: don't wait for high-order page allocation
Almost description is copied from commit fb05e7a89f50
("net: don't wait for order-3 page allocation").
I saw excessive direct memory reclaim/compaction triggered by slub.
This causes performance issues and add latency. Slub uses high-order
allocation to reduce internal fragmentation and management overhead. But,
direct memory reclaim/compaction has high overhead and the benefit of
high-order allocation can't compensate the overhead of both work.
This patch makes auxiliary high-order allocation atomic. If there is
no memory pressure and memory isn't fragmented, the alloction will still
success, so we don't sacrifice high-order allocation's benefit here.
If the atomic allocation fails, direct memory reclaim/compaction will not
be triggered, allocation fallback to low-order immediately, hence
the direct memory reclaim/compaction overhead is avoided. In the
allocation failure case, kswapd is waken up and trying to make high-order
freepages, so allocation could success next time.
Following is the test to measure effect of this patch.
System: QEMU, CPU 8, 512 MB
Mem: 25% memory is allocated at random position to make fragmentation.
Memory-hogger occupies 150 MB memory.
Workload: hackbench -g 20 -l 1000
Average result by 10 runs (Base va Patched)
elapsed_time(s): 4.3468 vs 2.9838
compact_stall: 461.7 vs 73.6
pgmigrate_success: 28315.9 vs 7256.1
Signed-off-by: Joonsoo Kim
---
mm/slub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/slub.c b/mm/slub.c
index 257283f..2d02a36 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1364,6 +1364,8 @@ static struct page *allocate_slab(struct kmem_cache *s,
gfp_t flags, int node)
* so we fall-back to the minimum order allocation.
*/
alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
+ if ((alloc_gfp & __GFP_WAIT) && oo_order(oo) > oo_order(s->min))
+ alloc_gfp = alloc_gfp & ~__GFP_WAIT;
page = alloc_slab_page(s, alloc_gfp, node, oo);
if (unlikely(!page)) {
--
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] dell-smm-hwmon: Blacklist Dell Studio XPS 8100
On 07/30/2015 11:41 AM, Pali Rohár wrote: CPU fan speed going up and down on Dell Studio XPS 8100 for unknown reason. Without future debuggning on affected machine it is not possible to detect where is problem. For more see: https://bugzilla.kernel.org/show_bug.cgi?id=100121 Signed-off-by: Pali Rohár Tested-by: Jan C Peters Cc: sta...@vger.kernel.org # before v4.2 apply to file drivers/char/i8k.c Applied, after fixing up description and comments. After it is applied to mainline, you'll probably get a note from Greg, asking you to back-port the patch to 4.1. Thanks, Guenter -- 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/1] Documentation: describe how to add a system call
On Thu, Jul 30, 2015 at 06:02:34PM -0700, Josh Triplett wrote:
> On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
> > On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett
> > wrote:
> > > On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
> > >> I like this, it's a good description of both options. I'm still biased
> > >> about the approach: I prefer flags, since pointers to user structures
> > >> complicate syscall filtering. ;)
> > >
> > > Seems like we should do two things to make that easier:
> > >
> > > 1) Create a standardized kernel mechanism for parameter-struct handling,
> > >implementing the recommendations mentioned here.
> >
> > It's been suggested in the past that nlmsg is appropriate for such a
> > thing, but I remain suspicious. :)
>
> Likewise. :)
>
> > > 2) Integrate into that mechanism a way to filter the resulting parameter
> > >struct with BPF *after* it has been copied to kernel space (and thus
> > >can no longer be tampered with).
> >
> > Yeah, this is a irritating part: the structures operated on are copied
> > from userspace adhoc in each syscall. Doing argument checking would
> > mean double copies initially, and perhaps teaching syscalls about
> > optional "already copied" arguments or something as an optimization.
>
> No, double copies can't work for security reasons. Because otherwise
> you could race the kernel from another thread, substituting different
> values after the check and before the use.
>
> I think the right API looks *roughly* like this:
>
> int _copy_param_struct(size_t kernel_len, void *kernel_struct, size_t
> user_len, void __user *user_struct)
> {
> if (user_len > kernel_len)
> return -EINVAL;
> if (user_len && copy_from_user(kernel_struct, user_struct, user_len))
> return -EFAULT;
> if (user_len < kernel_len)
> memset(kernel_struct + user_len, 0, kernel_len - user_len);
> return 0;
> }
>
> #define copy_param_struct(kernel_struct, user_len, user_struct)
> _copy_param_struct( \
> sizeof(*kernel_struct) +
> BUILD_BUG_ON_ZERO(!__same_type(*kernel_struct, *user_struct)), \
> kernel_struct, user_len, user_struct)
>
>
> Then the syscall looks like this:
>
> SYSCALL_DEFINEn(xyzzy, ..., ..., size_t user_params_len, struct xyzzy_params
> __user *user_params)
Missed a couple of commas here (after the types and before the names).
> {
> int ret;
> struct xyzzy_params params;
>
> ret = copy_param_struct(, user_params_len, user_params);
> if (ret)
> return ret;
> ...
>
>
> And you could then hook copy_params_struct to add arbitrary additional
> syscall parameter validation. Bonus if there's some way to make the
> copy and validation occur before the syscall is ever invoked, rather
> than inside the syscall, but that would require adding fancier syscall
> definition mechanisms that autogenerate such code.
>
> - Josh Triplett
--
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/1] Documentation: describe how to add a system call
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
> On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett wrote:
> > On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
> >> I like this, it's a good description of both options. I'm still biased
> >> about the approach: I prefer flags, since pointers to user structures
> >> complicate syscall filtering. ;)
> >
> > Seems like we should do two things to make that easier:
> >
> > 1) Create a standardized kernel mechanism for parameter-struct handling,
> >implementing the recommendations mentioned here.
>
> It's been suggested in the past that nlmsg is appropriate for such a
> thing, but I remain suspicious. :)
Likewise. :)
> > 2) Integrate into that mechanism a way to filter the resulting parameter
> >struct with BPF *after* it has been copied to kernel space (and thus
> >can no longer be tampered with).
>
> Yeah, this is a irritating part: the structures operated on are copied
> from userspace adhoc in each syscall. Doing argument checking would
> mean double copies initially, and perhaps teaching syscalls about
> optional "already copied" arguments or something as an optimization.
No, double copies can't work for security reasons. Because otherwise
you could race the kernel from another thread, substituting different
values after the check and before the use.
I think the right API looks *roughly* like this:
int _copy_param_struct(size_t kernel_len, void *kernel_struct, size_t user_len,
void __user *user_struct)
{
if (user_len > kernel_len)
return -EINVAL;
if (user_len && copy_from_user(kernel_struct, user_struct, user_len))
return -EFAULT;
if (user_len < kernel_len)
memset(kernel_struct + user_len, 0, kernel_len - user_len);
return 0;
}
#define copy_param_struct(kernel_struct, user_len, user_struct)
_copy_param_struct( \
sizeof(*kernel_struct) +
BUILD_BUG_ON_ZERO(!__same_type(*kernel_struct, *user_struct)), \
kernel_struct, user_len, user_struct)
Then the syscall looks like this:
SYSCALL_DEFINEn(xyzzy, ..., ..., size_t user_params_len, struct xyzzy_params
__user *user_params)
{
int ret;
struct xyzzy_params params;
ret = copy_param_struct(, user_params_len, user_params);
if (ret)
return ret;
...
And you could then hook copy_params_struct to add arbitrary additional
syscall parameter validation. Bonus if there's some way to make the
copy and validation occur before the syscall is ever invoked, rather
than inside the syscall, but that would require adding fancier syscall
definition mechanisms that autogenerate such code.
- Josh Triplett
--
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 2/3] selftests:vm: Point to libhugetlbfs for regression testing
The hugetlb selftests provide minimal coverage. Have run script point people at libhugetlbfs for better regression testing. Signed-off-by: Mike Kravetz --- tools/testing/selftests/vm/run_vmtests | 4 1 file changed, 4 insertions(+) diff --git a/tools/testing/selftests/vm/run_vmtests b/tools/testing/selftests/vm/run_vmtests index 9837a3f..9e5df58 100755 --- a/tools/testing/selftests/vm/run_vmtests +++ b/tools/testing/selftests/vm/run_vmtests @@ -75,6 +75,10 @@ else echo "[PASS]" fi +echo "NOTE: The above hugetlb tests provide minimal coverage. Use" +echo " https://github.com/libhugetlbfs/libhugetlbfs.git for" +echo " hugetlb regression testing." + echo "" echo "running userfaultfd" echo "" -- 2.1.0 -- 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 1/3] Reverted "selftests: add hugetlbfstest"
This manually reverts 7e50533d4b84289e4f01de56d6f98e9c64e2229e
The hugetlbfstest test depends on hugetlb pages being counted
in a task's rss. This functionality is not in the kernel, so
the test will always fail. Remove test to avoid confusion.
Signed-off-by: Mike Kravetz
---
tools/testing/selftests/vm/Makefile| 2 +-
tools/testing/selftests/vm/hugetlbfstest.c | 86 --
tools/testing/selftests/vm/run_vmtests | 11
3 files changed, 1 insertion(+), 98 deletions(-)
delete mode 100644 tools/testing/selftests/vm/hugetlbfstest.c
diff --git a/tools/testing/selftests/vm/Makefile
b/tools/testing/selftests/vm/Makefile
index f900e27..1b700f8 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,7 +1,7 @@
# Makefile for vm selftests
CFLAGS = -Wall
-BINARIES = hugepage-mmap hugepage-shm map_hugetlb thuge-gen hugetlbfstest
+BINARIES = hugepage-mmap hugepage-shm map_hugetlb thuge-gen
BINARIES += mlock2-tests
BINARIES += on-fault-limit
BINARIES += transhuge-stress
diff --git a/tools/testing/selftests/vm/hugetlbfstest.c
b/tools/testing/selftests/vm/hugetlbfstest.c
deleted file mode 100644
index 02e1072..000
--- a/tools/testing/selftests/vm/hugetlbfstest.c
+++ /dev/null
@@ -1,86 +0,0 @@
-#define _GNU_SOURCE
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-typedef unsigned long long u64;
-
-static size_t length = 1 << 24;
-
-static u64 read_rss(void)
-{
- char buf[4096], *s = buf;
- int i, fd;
- u64 rss;
-
- fd = open("/proc/self/statm", O_RDONLY);
- assert(fd > 2);
- memset(buf, 0, sizeof(buf));
- read(fd, buf, sizeof(buf) - 1);
- for (i = 0; i < 1; i++)
- s = strchr(s, ' ') + 1;
- rss = strtoull(s, NULL, 10);
- return rss << 12; /* assumes 4k pagesize */
-}
-
-static void do_mmap(int fd, int extra_flags, int unmap)
-{
- int *p;
- int flags = MAP_PRIVATE | MAP_POPULATE | extra_flags;
- u64 before, after;
- int ret;
-
- before = read_rss();
- p = mmap(NULL, length, PROT_READ | PROT_WRITE, flags, fd, 0);
- assert(p != MAP_FAILED ||
- !"mmap returned an unexpected error");
- after = read_rss();
- assert(llabs(after - before - length) < 0x4 ||
- !"rss didn't grow as expected");
- if (!unmap)
- return;
- ret = munmap(p, length);
- assert(!ret || !"munmap returned an unexpected error");
- after = read_rss();
- assert(llabs(after - before) < 0x4 ||
- !"rss didn't shrink as expected");
-}
-
-static int open_file(const char *path)
-{
- int fd, err;
-
- unlink(path);
- fd = open(path, O_CREAT | O_RDWR | O_TRUNC | O_EXCL
- | O_LARGEFILE | O_CLOEXEC, 0600);
- assert(fd > 2);
- unlink(path);
- err = ftruncate(fd, length);
- assert(!err);
- return fd;
-}
-
-int main(void)
-{
- int hugefd, fd;
-
- fd = open_file("/dev/shm/hugetlbhog");
- hugefd = open_file("/hugepages/hugetlbhog");
-
- system("echo 100 > /proc/sys/vm/nr_hugepages");
- do_mmap(-1, MAP_ANONYMOUS, 1);
- do_mmap(fd, 0, 1);
- do_mmap(-1, MAP_ANONYMOUS | MAP_HUGETLB, 1);
- do_mmap(hugefd, 0, 1);
- do_mmap(hugefd, MAP_HUGETLB, 1);
- /* Leak the last one to test do_exit() */
- do_mmap(-1, MAP_ANONYMOUS | MAP_HUGETLB, 0);
- printf("oll korrekt.\n");
- return 0;
-}
diff --git a/tools/testing/selftests/vm/run_vmtests
b/tools/testing/selftests/vm/run_vmtests
index cc5a973..9837a3f 100755
--- a/tools/testing/selftests/vm/run_vmtests
+++ b/tools/testing/selftests/vm/run_vmtests
@@ -76,17 +76,6 @@ else
fi
echo ""
-echo "running hugetlbfstest"
-echo ""
-./hugetlbfstest
-if [ $? -ne 0 ]; then
- echo "[FAIL]"
- exitcode=1
-else
- echo "[PASS]"
-fi
-
-echo ""
echo "running userfaultfd"
echo ""
./userfaultfd 128 32
--
2.1.0
--
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 3/3] Documentation: update libhugetlbfs location and use for testing
The URL for libhugetlbfs has changed. Also, put a stronger emphasis on using libgugetlbfs for hugetlb regression testing. Signed-off-by: Mike Kravetz --- Documentation/vm/hugetlbpage.txt | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 030977f..54dd9b9 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt @@ -329,7 +329,14 @@ Examples 3) hugepage-mmap: see tools/testing/selftests/vm/hugepage-mmap.c -4) The libhugetlbfs (http://libhugetlbfs.sourceforge.net) library provides a - wide range of userspace tools to help with huge page usability, environment - setup, and control. Furthermore it provides useful test cases that should be - used when modifying code to ensure no regressions are introduced. +4) The libhugetlbfs (https://github.com/libhugetlbfs/libhugetlbfs) library + provides a wide range of userspace tools to help with huge page usability, + environment setup, and control. + +Kernel development regression testing += + +The most complete set of hugetlb tests are in the libhugetlbfs repository. +If you modify any hugetlb related code, use the libhugetlbfs test suite +to check for regressions. In addition, if you add any new hugetlb +functionality, please add appropriate tests to libhugetlbfs. -- 2.1.0 -- 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 0/3] vm hugetlb selftest cleanup
As a followup to discussions of hugetlbfs fallocate, this provides cleanup the vm hugetlb selftests. Remove hugetlbfstest as it tests functionality not present in the kernel. Emphasize that libhugetlbfs test suite should be used for hugetlb regression testing. Mike Kravetz (3): Reverted "selftests: add hugetlbfstest" selftests:vm: Point to libhugetlbfs for regression testing Documentation: update libhugetlbfs location and use for testing Documentation/vm/hugetlbpage.txt | 15 -- tools/testing/selftests/vm/Makefile| 2 +- tools/testing/selftests/vm/hugetlbfstest.c | 86 -- tools/testing/selftests/vm/run_vmtests | 13 ++--- 4 files changed, 15 insertions(+), 101 deletions(-) delete mode 100644 tools/testing/selftests/vm/hugetlbfstest.c -- 2.1.0 -- 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 18/27] hwmon: (g762) Export OF module alias information
On 07/30/2015 09:18 AM, Javier Martinez Canillas wrote: The I2C core always reports the MODALIAS uevent as "i2c: Applied. Thanks, Guenter -- 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: [lm-sensors] [PATCH 14/27] hwmon: (nct7904) Export I2C module alias information
On 07/30/2015 09:18 AM, Javier Martinez Canillas wrote: The I2C core always reports the MODALIAS uevent as "i2c: Applied. Thanks, Guenter -- 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] serial: 8250: omap: restore registers on shutdown
Hi John,
On 07/30/2015 06:54 PM, John Ogness wrote:
> If DMA is active during a shutdown, a delayed restore of the
> registers may be pending. The restore must be performed after
> the DMA is stopped, otherwise the delayed restore remains
> pending and will fire upon the first DMA TX complete of a
> totally different serial session.
>
> Signed-off-by: John Ogness
> ---
> drivers/tty/serial/8250/8250_omap.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c
> b/drivers/tty/serial/8250/8250_omap.c
> index 5b39892..25f6255 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -657,9 +657,15 @@ static void omap_8250_shutdown(struct uart_port *port)
> up->ier = 0;
> serial_out(up, UART_IER, 0);
>
> - if (up->dma)
> + if (up->dma) {
> serial8250_release_dma(up);
>
> + if (priv->delayed_restore) {
> + priv->delayed_restore = 0;
> + omap8250_restore_regs(up);
> + }
I was never really a fan of the deferred set_termios();
I think it's more appropriate to wait for tx dma to
complete in omap_8250_set_termios().
Regards,
Peter Hurley
> + }
> +
> /*
>* Disable break condition and FIFOs
>*/
>
--
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/ethernet/ti/netcp_ethss.c
between commit:
31a184b7acbc ("net: netcp: ethss: cleanup gbe_probe() and gbe_remove()
functions")
from the net tree and commit:
489e8a2f09d7 ("net: netcp: Fixes to CPSW statistics collection")
from the net-next tree.
I fixed it up (using the error path from the former) 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 char-misc-next 10/19] lib: convert iova.c into a library
On Tue, Jul 28 2015 at 01:40:19 PM, Andrew Morton wrote: > On Mon, 27 Jul 2015 16:57:32 -0700 Ashutosh Dixit > wrote: > >> From: Harish Chegondi >> >> This patch converts iova.c into a library, moving it from >> drivers/iommu/ to lib/, and exports its virtual address allocation >> and management functions so that other modules can reuse them. > > From the following emails it is unclear to me whether we'll actually > be going ahead with this, but whatever. It's a chance to do some code > reading. Thanks for the review. Either us or the IOMMU team will submit a patch incorporating your suggestions. Ashutosh -- 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: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848
On Thu, Jul 30 2015 at 7:14pm -0400, Josh Boyer wrote: > On Thu, Jul 30, 2015 at 7:27 AM, Josh Boyer wrote: > > On Wed, Jul 29, 2015 at 8:29 PM, Ming Lei wrote: > >> On Wed, Jul 29, 2015 at 12:36 PM, Josh Boyer > >> wrote: > >>> On Wed, Jul 29, 2015 at 11:32 AM, Ming Lei wrote: > On Wed, Jul 29, 2015 at 9:51 AM, Johannes Weiner > wrote: > > On Wed, Jul 29, 2015 at 09:27:16AM -0400, Josh Boyer wrote: > >> Hi All, > >> > >> We've gotten a report[1] that any of the upcoming Fedora 23 install > >> images are all failing on 32-bit VMs/machines. Looking at the first > >> instance of the oops, it seems to be a bad page state where a page is > >> still charged to a group and it is trying to be freed. The oops > >> output is below. > >> > >> Has anyone seen this in their 32-bit testing at all? Thus far nobody > >> can recreate this on a 64-bit machine/VM. > >> > >> josh > >> > >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382 > >> > >> [9.026738] systemd[1]: Switching root. > >> [9.036467] systemd-journald[149]: Received SIGTERM from PID 1 > >> (systemd). > >> [9.082262] BUG: Bad page state in process kworker/u5:1 pfn:372ac > >> [9.083989] page:f3d32ae0 count:0 mapcount:0 mapping:f2252178 > >> index:0x16a > >> [9.085755] flags: 0x40020021(locked|lru|mappedtodisk) > >> [9.087284] page dumped because: page still charged to cgroup > >> [9.088772] bad because of flags: > >> [9.089731] flags: 0x21(locked|lru) > >> [9.090818] page->mem_cgroup:f2c3e400 > > > > It's also still locked and on the LRU. This page shouldn't have been > > freed. > > > >> [9.117848] Call Trace: > >> [9.118738] [] dump_stack+0x41/0x52 > >> [9.120034] [] bad_page.part.80+0xaa/0x100 > >> [9.121461] [] free_pages_prepare+0x3b9/0x3f0 > >> [9.122934] [] free_hot_cold_page+0x22/0x160 > >> [9.124400] [] ? copy_to_iter+0x1af/0x2a0 > >> [9.125750] [] ? mempool_free_slab+0x13/0x20 > >> [9.126840] [] __free_pages+0x37/0x50 > >> [9.127849] [] mempool_free_pages+0xd/0x10 > >> [9.128908] [] mempool_free+0x26/0x80 > >> [9.129895] [] bounce_end_io+0x56/0x80 > > > > The page state looks completely off for a bounce buffer page. Did > > somebody mess with a bounce bio's bv_page? > > Looks the page isn't touched in both lo_read_transfer() and > lo_read_simple(). > > Maybe it is related with aa4d86163e4e(block: loop: switch to VFS > ITER_BVEC), > or it might be helpful to run 'git bisect' if reverting aa4d86163e4e > can't > fix the issue, suppose the issue can be reproduced easily. > >>> > >>> I can try reverting that and getting someone to test it. It is > >>> somewhat complicated by having to spin a new install ISO, so a report > >>> back will be somewhat delayed. In the meantime, I'm also asking > >>> people to track down the first kernel build that hits this, so > >>> hopefully that gives us more of a clue as well. > > The revert of that patch did not fix the issue. > > >>> It is odd that only 32-bit hits this issue though. At least from what > >>> we've seen thus far. > >> > >> Page bounce may be just valid on 32-bit, and I will try to find one ARM > >> box to see if it can be reproduced easily. > >> > >> BTW, are there any extra steps for reproducing the issue? Such as > >> cgroup operations? > > > > I'm not entirely sure what the install environment on the ISOs is > > doing, but nobody sees this issue with a kernel after install. Thus > > far recreate efforts have focused on recreating the install ISOs using > > various kernels. That is working, but I don't expect other people to > > easily be able to do that. > > > > Also, our primary tester seems to have narrowed it down to breaking > > somewhere between 4.1-rc5 (good) and 4.1-rc6 (bad). I'll be working > > with him today to isolate it further, but the commit you pointed out > > was in 4.1-rc1 and that worked. He still needs to test a 4.2-rc4 > > kernel with it reverted, but so far it seems to be something else that > > came in with the 4.1 kernel. > > After doing some RPM bisecting, we've narrowed it down to the > following commit range: > > [jwboyer@vader linux]$ git log --pretty=oneline c2102f3d73d8..0f1e5b5d19f6 > 0f1e5b5d19f6c06fe2078f946377db9861f3910d Merge tag 'dm-4.1-fixes-3' of > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm > 1c220c69ce0dcc0f234a9f263ad9c0864f971852 dm: fix casting bug in > dm_merge_bvec() > 15b94a690470038aa08247eedbebbe7e2218d5ee dm: fix reload failure of 0 > path multipath mapping on blk-mq devices > e5d8de32cc02a259e1a237ab57cba00f2930fa6a dm: fix false warning in > free_rq_clone() for unmapped requests > 45714fbed4556149d7f1730f5bae74f81d5e2cd5 dm: requeue from blk-mq > dm_mq_queue_rq() using
Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times
On 30/07/15 22:45, Peter Hurley wrote: [ +cc Debian maintainer ] On 07/30/2015 11:26 AM, Emil Velikov wrote: On 30 July 2015 at 16:02, Ilia Mirkin wrote: On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue wrote: On 30/07/15 15:52, Bryan O'Donoghue wrote: On 30/07/15 15:49, Peter Hurley wrote: On 07/30/2015 10:12 AM, Ilia Mirkin wrote: Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one. What's the freedesktop bugzilla # for reference? Regards, Peter Hurley I believe it's this one https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19 Not really a world of choice on ubuntu to fix it though... deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate :( That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you. Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it: http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c788c61f546294 Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix. Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60 several days ago without this fix. I repackaged libdrm 2.4.60 with only the bug fix above and confirm the patch above fixes the observed behavior in freedesktop bug# 89842/ debian bug# 789759. I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm Hopefully the Debian maintainer grabs this fix and updates the official distribution version soon. Regards, Peter Hurley Yep. Dropping down to 2.4.56-1~ubuntu2 definitely removes the nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x)/GPC0/(unknown enum 0x000f) on channel 0x007f80c000 [unknown] and hard lock-up of X. I'll update these guys with the fix http://tinyurl.com/orvbzf3 -- 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] ipsec:Fix error handling in the function xfrm6_get_addr
On Thu, Jul 30, 2015 at 12:20:40PM -0400, Nicholas Krause wrote: > > diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c > index ed0583c..f60c670 100644 > --- a/net/ipv6/xfrm6_policy.c > +++ b/net/ipv6/xfrm6_policy.c > @@ -61,7 +61,9 @@ static int xfrm6_get_saddr(struct net *net, > return -EHOSTUNREACH; > > dev = ip6_dst_idev(dst)->dev; > - ipv6_dev_get_saddr(dev_net(dev), dev, >in6, 0, >in6); > + if (ipv6_dev_get_saddr(dev_net(dev), dev, >in6, 0, >in6)) > + return -EADDRNOTAVAIL; > + > dst_release(dst); You're leaking dst. Cheers, -- 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 03/13] mm: meminit: Only set page reserved in the memblock region
Hi,
While testing builds containing this change (commit id:
92923ca3aacef63c92dc297a75ad0c6dfe4eab37), I've observed that memory fails to
come online in the hotplug case. When attempting to bring the hot added pages
online (via udev rules or manually writing to sysfs); it's failing with -EBUSY
error because the hot added pages no longer have the Reserved flag set.
The reserved bit is being checked in memory_block_action() in
drivers/base/memory.c:
switch (action) {
case MEM_ONLINE:
if (!pages_correctly_reserved(start_pfn))
return -EBUSY;
Should the reserved bit be set in some other place? Or should the above test be
removed from sysfs memory device?
--
Alex Ng
--
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: samples/kdbus/kdbus-workers.c and cross compiling MIPS
Hi Paul, On Thu, 30 Jul 2015 11:32:05 -0400 Paul Gortmaker wrote: > > Well, it only shows up when we cross compile for mips. It does not > seem to be showing up for any other arch (and we cover ~10 of them). > Nor does it show up for x86 builds. Also note that the main linux-next > build machine is actually a PowerPC host. Actually I do my linux-next builds on an x86_64 host, and the overnight builds are spread between that and a PowerPC host. > > Please note that this is HOSTCC running, so it does *NOT* require the > > toolchain for your cross-compiled architecture. > > > > Also, please tell me why your system has "linux/memfd.h" available, > > but __NR_memfd_create is undefined? > > My local system is a bog standard ubuntu 14.10 and it sees it. I dont > know what distro the linux-next IBM powerpc builder is based on but it > also sees it Our build hosts are running Debian stable and Ubuntu (I think - I will check on this latter). -- 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 1/3] serial: 8250: unlock port for uart_write_wakeup()
On 07/30/2015 07:15 PM, Peter Hurley wrote: > On 07/30/2015 06:54 PM, John Ogness wrote: >> uart_write_wakeup() should be called without holding the port lock. >> Otherwise a possible recursive spinlock issue can occur, such as >> the following callchain: >> >> 8250_core.c:serial8250_tx_chars() - called with port locked >> serial_core.c:uart_write_wakeup() >> tty_io.c:tty_wakeup() >>st_core.c:st_tty_wakeup() >> st_core.c:st_tx_wakeup() >> st_core.c:st_int_write() >> serial_core.c:uart_write() - locks port > > NAK. > > This is a bug in the N_TI_WL line discipline, specifically in the > st_tx_wakeup() function, which cannot perform the write synchronously. > > This is a common line discipline bug, and typically fixed by performing > the wakeup operations from a kworker instead. Also, seriously consider if you want to use that TI line discipline at all. If you're using it only for bluetooth w/ kernel bluetooth stack, you don't need btwilink + st_drv anyway. Regards, Peter Hurley -- 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 0/3] genirq, serial: 8250: Workaround to avoid irq=0 for console
On 07/30/2015 06:12 PM, Thomas Gleixner wrote: > On Thu, 30 Jul 2015, Peter Hurley wrote: >> Honestly, I'm not too sure this is the way to go. >> >> Messing around with irqsoff tracer for 30 mins turned up: >> 3.664ms in intel_unmap_page >> - iotlb flush, spinlock contention on iova_rbtree_lock >> 1.726ms in intel_map_page() >> - iommu core @ __alloc_and_insert_iova_range() >> 1.859ms in syslog_print_all() >> - which is holding the logbuf_lock so that's pretty bad anyway >> 387us in nouveau @ nv50_vm_flush() >> - gpu tlb flush >> >> I have irqsoff trace reports for all of these if anyone is interested. >> >> Looks like lockdep would need to be off as well because I saw but >> failed to capture a save_trace() in the 300us range. >> >> I think this is just the tip of the iceberg for irqsoff. > > I agree. > >> I'm not saying these don't need fixing as well, but there's no way >> irq probe will ever be reliable with this approach. > > irq probe is a known to be unreliable heuristic endavour anyway and it > cannot ever become truly reliable, except you put a gazillion of > restrictions to the system state on it. Yep, totally agree. As you note below, this functionality is completely disabled on every known distro kernel. >> Going back to the RFC idea of pinning the irq affinity to the cpu >> actually doing the probing (which is in a known context), what about >> that is broken on UP? Just the implementation or is it the fundamental >> concept? > > First of all, there is no guarantee that you can affine these > interrupts at all. We have interrupt controllers which cannot set the > affinity and they deliver to cpus in a round robin scheme or whatever > hardware designers thought would be clever. > > Second, what prevents the following scenario on UP or the affine core: > > probe_start() > interrupt > looong running handler (usb is an obvious candidate) >printk() > > That will swallow your uart state and ruin detection as well. Yeah, ok, so fundamentally broken concept to pin the irqs for probing. Thanks for clarifying that. > So for the problem at hand, we really need to prevent that something > is fiddling with the uart in the first place and the most obvious way > is to serialize against printk. I'm ok with just the original patch 1 (which I reviewed some time ago). > We can debate whether the autoprobe code is the right place or not, we > can actually stick it into the 8250 driver and be done with it > because: > > If you look at the actual autoprobe users aside of 8250. That's really > all ancient ISA hardware and hardly interesting. So all we really care > about are the 8250 serial ports. > > Now lets look at the 8250 serial ports. I just checked the random > collection of machines I have access to: > > In 100% of all cases ttyS0 is on irq4 and ttyS1 is on irq3 > > All of the machines have even a correct PNP entry of the irq resource > for the serial ports. And there is pretty old crap in that lot. > > So the real question is: Why would we autoprobe in the first place? > > Debian, Fedora, OpenSuse, SLES have: > ># CONFIG_SERIAL_8250_DETECT_IRQ is not set > > and so do my kernels. > > I just built one with that option enabled for the fun of it and it > still uses the PNP information. No autoprobing. > > So why are you interested in that serial irq autoprobe crap at all? Agree, but I guess the hardware in question is non-PNP serial-over-LAN. It's Taichi's hardware so he can be more specific. Also, this problem would not apply to 8250 ports @ the ISA addresses (3f8,irq 4 & 2f8,irq 3) because those are predefined on the platform. Taichi's original proposal was to add module parameters for the serial driver, which I am dead set against, having just struggled to deal with ancient module parameters while splitting the 8250 driver. I also noted in reviewing that proposal that user-space tools (setserial) can reset the irq to a known value after driver load. Ubuntu, for one, runs setserial as part of boot (to restore serial hardware to known-working configuration). Regards, Peter Hurley -- 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: char: make misc_deregister a void function
On Thu, Jul 30 2015 at 6:59pm -0400, Greg Kroah-Hartman wrote: > From: Greg Kroah-Hartman > > With well over 200+ users of this api, there are a mere 12 users that > actually cheked the return value of this function. And all of them > really didn't do anything with that information as the system or module > was shutting down no matter what. > > So stop pretending like it matters, and just return void from > misc_deregister(). If something goes wrong in the call, you will get a > WARNING splat in the syslog so you know how to fix up your driver. > Other than that, there's nothing that can go wrong. > > Cc: Alasdair Kergon > Cc: Mike Snitzer > Cc: Neil Brown > Cc: Alessandro Zummo > Cc: Alexandre Belloni > Cc: Oleg Drokin > Cc: Andreas Dilger > Cc: "Michael S. Tsirkin" > Cc: Wim Van Sebroeck > Cc: Christine Caulfield > Cc: David Teigland > Cc: Mark Fasheh > Cc: Joel Becker > Signed-off-by: Greg Kroah-Hartman > > --- > > If the different subsystem maintainers want to give me an ack for this, > I'd appreciate it. I'd like to just take the single patch in through > the char-misc tree in one piece. For DM: Acked-by: Mike Snitzer -- 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] KVM: x86: set TMR when the interrupt is accepted
Paolo Bonzini wrote on 2015-07-29:
> Do not compute TMR in advance. Instead, set the TMR just before the
> interrupt is accepted into the IRR. This limits the coupling between
> IOAPIC and LAPIC.
>
Uh.., it back to original way which is wrong. You cannot modify the apic
page(here is the TMR reg) directly when the corresponding VMCS may be used at
same time.
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/ioapic.c | 9 ++---
> arch/x86/kvm/ioapic.h | 3 +--
> arch/x86/kvm/lapic.c | 19 ++-
> arch/x86/kvm/lapic.h | 1 -
> arch/x86/kvm/x86.c| 5 +
> 5 files changed, 14 insertions(+), 23 deletions(-)
> diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> index 856f79105bb5..eaf4ec38d980 100644
> --- a/arch/x86/kvm/ioapic.c
> +++ b/arch/x86/kvm/ioapic.c
> @@ -246,8 +246,7 @@ static void update_handled_vectors(struct kvm_ioapic
> *ioapic)
> smp_wmb();
> }
> -void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap,
> - u32 *tmr)
> +void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> {
> struct kvm_ioapic *ioapic = vcpu->kvm->arch.vioapic;
> union kvm_ioapic_redirect_entry *e;
> @@ -260,13 +259,9 @@ void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu,
> u64 *eoi_exit_bitmap,
> kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC,
> index) ||
> index == RTC_GSI) { if
> (kvm_apic_match_dest(vcpu, NULL, 0,
> - e->fields.dest_id, e->fields.dest_mode)) {
> + e->fields.dest_id, e->fields.dest_mode))
> __set_bit(e->fields.vector,
> (unsigned long *)eoi_exit_bitmap);
> - if (e->fields.trig_mode == IOAPIC_LEVEL_TRIG)
> - __set_bit(e->fields.vector, -
> (unsigned long *)tmr); -
> }
> }
> }
> spin_unlock(>lock);
> diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
> index ca0b0b4e6256..3dbd0e2aac4e 100644
> --- a/arch/x86/kvm/ioapic.h
> +++ b/arch/x86/kvm/ioapic.h
> @@ -120,7 +120,6 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct
> kvm_lapic *src,
> struct kvm_lapic_irq *irq, unsigned long *dest_map);
> int kvm_get_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> int kvm_set_ioapic(struct kvm *kvm, struct kvm_ioapic_state *state);
> -void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap,
> - u32 *tmr);
> +void kvm_ioapic_scan_entry(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap);
>
> #endif
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 2a5ca97c263b..9be64c77d6db 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -551,15 +551,6 @@ static void pv_eoi_clr_pending(struct kvm_vcpu
> *vcpu)
> __clear_bit(KVM_APIC_PV_EOI_PENDING, >arch.apic_attention);
> }
> -void kvm_apic_update_tmr(struct kvm_vcpu *vcpu, u32 *tmr)
> -{
> - struct kvm_lapic *apic = vcpu->arch.apic;
> - int i;
> -
> - for (i = 0; i < 8; i++)
> - apic_set_reg(apic, APIC_TMR + 0x10 * i, tmr[i]);
> -}
> -
> static void apic_update_ppr(struct kvm_lapic *apic)
> {
> u32 tpr, isrv, ppr, old_ppr;
> @@ -781,6 +772,9 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
> delivery_mode,
> case APIC_DM_LOWEST:
> vcpu->arch.apic_arb_prio++;
> case APIC_DM_FIXED:
> + if (unlikely(trig_mode && !level))
> + break;
> +
> /* FIXME add logic for vcpu on reset */
> if (unlikely(!apic_enabled(apic)))
> break;
> @@ -790,6 +784,13 @@ static int __apic_accept_irq(struct kvm_lapic *apic,
> int delivery_mode,
> if (dest_map)
> __set_bit(vcpu->vcpu_id, dest_map);
> + if (apic_test_vector(vector, apic->regs + APIC_TMR) !=
> !!trig_mode) {
> + if (trig_mode)
> + apic_set_vector(vector, apic->regs + APIC_TMR);
> + else
> + apic_clear_vector(vector, apic->regs +
> APIC_TMR);
> + }
> +
> if (kvm_x86_ops->deliver_posted_interrupt)
> kvm_x86_ops->deliver_posted_interrupt(vcpu, vector);
> else {
> diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> index 764037991d26..eb46d6bcaa75 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -57,7 +57,6 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64
> value);
> u64 kvm_lapic_get_base(struct kvm_vcpu *vcpu);
> void kvm_apic_set_version(struct kvm_vcpu *vcpu);
> -void kvm_apic_update_tmr(struct kvm_vcpu *vcpu, u32 *tmr);
> void __kvm_apic_update_irr(u32 *pir, void *regs);
> void
Re: [PATCH 2/3] serial: 8250: move rx_running out of the bitfield
On 07/30/2015 06:54 PM, John Ogness wrote:
> That bitfield is modified by read + or + write operation. If someone
> sets any of the other two bits it might render the lock useless.
Good catch.
Let's just make all of the fields not bitfield though.
Regards,
Peter Hurley
> Signed-off-by: John Ogness
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/tty/serial/8250/8250.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
> index c43f74c..78f5e3a 100644
> --- a/drivers/tty/serial/8250/8250.h
> +++ b/drivers/tty/serial/8250/8250.h
> @@ -44,7 +44,7 @@ struct uart_8250_dma {
>
> unsigned char tx_running:1;
> unsigned char tx_err: 1;
> - unsigned char rx_running:1;
> + unsigned char rx_running;
> };
>
> struct old_serial_port {
>
--
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 net-next 0/3] net: Switch tag HW extraction/insertion
On 30/07/15 15:51, David Miller wrote: > From: David Miller > Date: Thu, 30 Jul 2015 14:19:35 -0700 (PDT) > >> This looks fine, series applied, thanks. > > I think your control block is too large, you'll need to rework this > somehow. Interesting, this only seems to show up with 64-bits build, which is why I did not catch this earlier (building for ARMv7 typically), sorry about that, I will come up with a fix. > > In function ‘dsa_copy_brcm_tag’, > inlined from ‘bcm_sysport_desc_rx’ at > drivers/net/ethernet/broadcom/bcmsysport.c:707:4, > inlined from ‘bcm_sysport_poll’ at > drivers/net/ethernet/broadcom/bcmsysport.c:864:12: > include/linux/compiler.h:447:38: error: call to ‘__compiletime_assert_2016’ > declared with attribute error: BUILD_BUG_ON failed: sizeof(skb->cb) - > sizeof(struct napi_gro_cb) < BRCM_TAG_LEN > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^ > include/linux/compiler.h:430:4: note: in definition of macro > ‘__compiletime_assert’ > prefix ## suffix();\ > ^ > include/linux/compiler.h:447:2: note: in expansion of macro > ‘_compiletime_assert’ > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) > ^ > include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’ > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^ > include/linux/bug.h:74:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) > ^ > include/linux/netdevice.h:2016:2: note: in expansion of macro ‘BUILD_BUG_ON’ > BUILD_BUG_ON(sizeof(skb->cb) - sizeof(struct napi_gro_cb) < BRCM_TAG_LEN); > ^ > scripts/Makefile.build:264: recipe for target > 'drivers/net/ethernet/broadcom/bcmsysport.o' failed > -- Florian -- 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 net-next 1/9] openvswitch: Scrub packet in ovs_vport_receive()
On 30 July 2015 at 11:40, Thomas Graf wrote: > On 07/30/15 at 11:12am, Joe Stringer wrote: >> Signed-off-by: Joe Stringer > > Can you write a few lines on why this is needed? I have flows which > use the mark to communicate with netfilter through internal ports. The problem I was seeing is when packets come from a different namespace on the localhost, they still have conntrack data associated. This doesn't make sense, so the intention is to perform nf_reset(). However, it seems like we should actually be doing a bit more - at least the skb_dst_drop() and perhaps some of the other stuff in skb_scrub_packet(). Do you want to retain the mark when transitioning between namespaces? Perhaps something like the below incremental would be sufficient: diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c index 8a63df6..82844e6 100644 --- a/net/openvswitch/vport.c +++ b/net/openvswitch/vport.c @@ -475,7 +475,9 @@ void ovs_vport_receive(struct vport *vport, struct sk_buff *skb, struct sw_flow_key key; int error; - if (!skb->sk || (sock_net(skb->sk) != read_pnet(>dp->net))) + if (!skb->sk) + skb_scrub_packet(skb, false); + else if (sock_net(skb->sk) != read_pnet(>dp->net)) skb_scrub_packet(skb, true); stats = this_cpu_ptr(vport->percpu_stats); -- 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] serial: 8250: unlock port for uart_write_wakeup()
On 07/30/2015 06:54 PM, John Ogness wrote: > uart_write_wakeup() should be called without holding the port lock. > Otherwise a possible recursive spinlock issue can occur, such as > the following callchain: > > 8250_core.c:serial8250_tx_chars() - called with port locked > serial_core.c:uart_write_wakeup() > tty_io.c:tty_wakeup() >st_core.c:st_tty_wakeup() > st_core.c:st_tx_wakeup() > st_core.c:st_int_write() > serial_core.c:uart_write() - locks port NAK. This is a bug in the N_TI_WL line discipline, specifically in the st_tx_wakeup() function, which cannot perform the write synchronously. This is a common line discipline bug, and typically fixed by performing the wakeup operations from a kworker instead. Regards, Peter Hurley -- 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: cgroup/loop Bad page state oops in Linux v4.2-rc3-136-g45b4b782e848
On Thu, Jul 30, 2015 at 7:27 AM, Josh Boyer wrote: > On Wed, Jul 29, 2015 at 8:29 PM, Ming Lei wrote: >> On Wed, Jul 29, 2015 at 12:36 PM, Josh Boyer >> wrote: >>> On Wed, Jul 29, 2015 at 11:32 AM, Ming Lei wrote: On Wed, Jul 29, 2015 at 9:51 AM, Johannes Weiner wrote: > On Wed, Jul 29, 2015 at 09:27:16AM -0400, Josh Boyer wrote: >> Hi All, >> >> We've gotten a report[1] that any of the upcoming Fedora 23 install >> images are all failing on 32-bit VMs/machines. Looking at the first >> instance of the oops, it seems to be a bad page state where a page is >> still charged to a group and it is trying to be freed. The oops >> output is below. >> >> Has anyone seen this in their 32-bit testing at all? Thus far nobody >> can recreate this on a 64-bit machine/VM. >> >> josh >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382 >> >> [9.026738] systemd[1]: Switching root. >> [9.036467] systemd-journald[149]: Received SIGTERM from PID 1 >> (systemd). >> [9.082262] BUG: Bad page state in process kworker/u5:1 pfn:372ac >> [9.083989] page:f3d32ae0 count:0 mapcount:0 mapping:f2252178 >> index:0x16a >> [9.085755] flags: 0x40020021(locked|lru|mappedtodisk) >> [9.087284] page dumped because: page still charged to cgroup >> [9.088772] bad because of flags: >> [9.089731] flags: 0x21(locked|lru) >> [9.090818] page->mem_cgroup:f2c3e400 > > It's also still locked and on the LRU. This page shouldn't have been > freed. > >> [9.117848] Call Trace: >> [9.118738] [] dump_stack+0x41/0x52 >> [9.120034] [] bad_page.part.80+0xaa/0x100 >> [9.121461] [] free_pages_prepare+0x3b9/0x3f0 >> [9.122934] [] free_hot_cold_page+0x22/0x160 >> [9.124400] [] ? copy_to_iter+0x1af/0x2a0 >> [9.125750] [] ? mempool_free_slab+0x13/0x20 >> [9.126840] [] __free_pages+0x37/0x50 >> [9.127849] [] mempool_free_pages+0xd/0x10 >> [9.128908] [] mempool_free+0x26/0x80 >> [9.129895] [] bounce_end_io+0x56/0x80 > > The page state looks completely off for a bounce buffer page. Did > somebody mess with a bounce bio's bv_page? Looks the page isn't touched in both lo_read_transfer() and lo_read_simple(). Maybe it is related with aa4d86163e4e(block: loop: switch to VFS ITER_BVEC), or it might be helpful to run 'git bisect' if reverting aa4d86163e4e can't fix the issue, suppose the issue can be reproduced easily. >>> >>> I can try reverting that and getting someone to test it. It is >>> somewhat complicated by having to spin a new install ISO, so a report >>> back will be somewhat delayed. In the meantime, I'm also asking >>> people to track down the first kernel build that hits this, so >>> hopefully that gives us more of a clue as well. The revert of that patch did not fix the issue. >>> It is odd that only 32-bit hits this issue though. At least from what >>> we've seen thus far. >> >> Page bounce may be just valid on 32-bit, and I will try to find one ARM >> box to see if it can be reproduced easily. >> >> BTW, are there any extra steps for reproducing the issue? Such as >> cgroup operations? > > I'm not entirely sure what the install environment on the ISOs is > doing, but nobody sees this issue with a kernel after install. Thus > far recreate efforts have focused on recreating the install ISOs using > various kernels. That is working, but I don't expect other people to > easily be able to do that. > > Also, our primary tester seems to have narrowed it down to breaking > somewhere between 4.1-rc5 (good) and 4.1-rc6 (bad). I'll be working > with him today to isolate it further, but the commit you pointed out > was in 4.1-rc1 and that worked. He still needs to test a 4.2-rc4 > kernel with it reverted, but so far it seems to be something else that > came in with the 4.1 kernel. After doing some RPM bisecting, we've narrowed it down to the following commit range: [jwboyer@vader linux]$ git log --pretty=oneline c2102f3d73d8..0f1e5b5d19f6 0f1e5b5d19f6c06fe2078f946377db9861f3910d Merge tag 'dm-4.1-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm 1c220c69ce0dcc0f234a9f263ad9c0864f971852 dm: fix casting bug in dm_merge_bvec() 15b94a690470038aa08247eedbebbe7e2218d5ee dm: fix reload failure of 0 path multipath mapping on blk-mq devices e5d8de32cc02a259e1a237ab57cba00f2930fa6a dm: fix false warning in free_rq_clone() for unmapped requests 45714fbed4556149d7f1730f5bae74f81d5e2cd5 dm: requeue from blk-mq dm_mq_queue_rq() using BLK_MQ_RQ_QUEUE_BUSY 4c6dd53dd3674c310d7379c6b3273daa9fd95c79 dm mpath: fix leak of dm_mpath_io structure in blk-mq .queue_rq error path 3a1407559a593d4360af12dd2df5296bf8eb0d28 dm: fix NULL pointer when clone_and_map_rq returns !DM_MAPIO_REMAPPED
Re: [PATCH v2] net/phy: micrel: Reenable interrupts during resume
On Thu, Jul 30, 2015 at 10:00:34AM -0700, David Miller wrote: > From: Nathan Sullivan > Date: Thu, 30 Jul 2015 10:15:48 -0500 > > > Changes for V2: Actually make sure it compiles this time. > > If V1 didn't compile, even for you, then I have a big problem. > > And that problem is that you didn't test this change at all. Sorry about that, I have tested it against 3.14, which is why I had the older interrupt function in v1. On HEAD, the phy no longer suspends when ethernet goes down on our hardware - I'm still working on figuring out why. I'm also surprised no one noticed this behavior before I did, but if the phy never goes into suspend you wouldn't. -- 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/9] x86/intel_rdt: Cache Allocation documentation and cgroup usage guide
On Thu, 30 Jul 2015, Marcelo Tosatti wrote: On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote: Marcello, On Wed, 29 Jul 2015, Marcelo Tosatti wrote: How about this: desiredclos (closid p1 p2 p3 p4) 1 1 0 0 0 2 0 0 0 1 3 0 1 1 0 #1 Currently in the rdt cgroup , the root cgroup always has all the bits set and cant be changed (because the cgroup hierarchy would by default make this to have all bits as all the children need to have a subset of the root's bitmask). So if the user creates a cgroup and not put any task in it , the tasks in the root cgroup could be still using that part of the cache. Thats the reason i say we can have really 'exclusive' masks. Or in other words - there is always a desired clos (0) which has all parts set which acts like a default pool. Also the parts can overlap. Please apply this for all the below comments which will change the way they work. p means part. I am assuming p = (a contiguous cache capacity bit mask) closid 1 is a exclusive cgroup. closid 2 is a "cache hog" class. closid 3 is "default closid". Desiredclos is what user has specified. Transition 1: desiredclos --> effectiveclos Clean all bits of unused closid's (that must be updated whenever a closid1 cgroup goes from empty->nonempty and vice-versa). effectiveclos (closid p1 p2 p3 p4) 1 0 0 0 0 2 0 0 0 1 3 0 1 1 0 Transition 2: effectiveclos --> expandedclos expandedclos (closid p1 p2 p3 p4) 1 0 0 0 0 2 0 0 0 1 3 1 1 1 0 Then you have different inplacecos for each CPU (see pseudo-code below): On the following events. - task migration to new pCPU: - task creation: id = smp_processor_id(); for (part = desiredclos.p1; ...; part++) /* if my cosid is set and any other cosid is clear, for the part, synchronize desiredclos --> inplacecos */ if (part[mycosid] == 1 && part[any_othercosid] == 0) wrmsr(part, desiredclos); Currently the root cgroup would have all the bits set which will act like a default cgroup where all the otherwise unused parts (assuming they are a set of contiguous cache capacity bits) will be used. Right, but we don't want to place tasks in there in case one cgroup wants exclusive cache access. So whenever you want an exclusive cgroup you'd do: create cgroup-exclusive; reserve desired part of the cache for it. create cgroup-default; reserved all cache minus that of cgroup-exclusive for it. place tasks that belong to cgroup-exclusive into it. place all other tasks (including init) into cgroup-default. Is that right? Yes you could do that. You can create cgroups to have masks which are exclusive in todays implementation, just that you could also created more cgroups to overlap the masks again.. iow we dont have an exclusive flag for the cgroup mask. Is that a common use case in the server environment that you need to prevent other cgroups from using a certain mask ? (since the root user should control these allocations .. he should know?) -- 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 net] net: sk_clone_lock() should only do get_net() if the parent is not a kernel socket
From: Sowmini Varadhan
Date: Thu, 30 Jul 2015 15:50:36 +0200
>
>
> The newsk returned by sk_clone_lock should hold a get_net()
> reference if, and only if, the parent is not a kernel socket
> (making this similar to sk_alloc()).
>
> E.g,. for the SYN_RECV path, tcp_v4_syn_recv_sock->..inet_csk_clone_lock
> sets up the syn_recv newsk from sk_clone_lock. When the parent (listen)
> socket is a kernel socket (defined in sk_alloc() as having
> sk_net_refcnt == 0), then the newsk should also have a 0 sk_net_refcnt
> and should not hold a get_net() reference.
>
> Fixes: 26abe14379f8 ("net: Modify sk_alloc to not reference count the
> netns of kernel sockets.")
> Acked-by: Eric Dumazet
> Cc: Eric W. Biederman
> Signed-off-by: Sowmini Varadhan
> ---
> v2: pulled patch #3 out of the RFC patch-set for RDS-TCP netns fixes;
> Added Fixes, Acked-by, Cc fields based on mailing list feedback
> from Eric Dumazet.
Applied, thanks everyone.
--
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: Dealing with the NMI mess
On Thu, 30 Jul 2015, Andy Lutomirski wrote: > On Thu, Jul 30, 2015 at 8:41 AM, Paolo Bonzini wrote: > > > > > > On 24/07/2015 23:08, Andy Lutomirski wrote: > >> user_icebp is set if int $0x01 happens, except it isn't because user > >> code can't actually do that -- it'll cause #GP instead. > >> > >> user_icebp is also set if the user has a bloody in-circuit emulator, > >> given the name. But who on Earth has one of those on a system new > >> enough to run Linux and, even if they have one, why on Earth are they > >> using it to send SIGTRAP. > > > > You do not need either "int $0x01" or an ICE to set user_icebp = 1. You > > can use the 0xf1 opcode, which is kinda like 0xcc but generates #DB > > instead of #BP. > > Great. There's an opcode that invokes an interrupt gate that's not > marked as allowing unprivileged access, and that opcode doesn't appear > in the SDM. It appears in the APM opcode map with no explanation at > all. The only SDM reference I found is: "The opcodes D6 and F1 are undefined opcodes reserved by the Intel 64 and IA-32 architectures. These opcodes, even though undefined, do not generate an invalid opcode exception." D6 is actually something useful: if (carry flag set) AL = FF else AL = 0 It's been there since i386. It has been conveniant for return code magic from ASM to C. I haven't thought of it for at least a decade :) So all we need to worry about is F1, but thats bad enough :( Thanks, tglx -- 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] char: make misc_deregister a void function
From: Greg Kroah-Hartman
With well over 200+ users of this api, there are a mere 12 users that
actually cheked the return value of this function. And all of them
really didn't do anything with that information as the system or module
was shutting down no matter what.
So stop pretending like it matters, and just return void from
misc_deregister(). If something goes wrong in the call, you will get a
WARNING splat in the syslog so you know how to fix up your driver.
Other than that, there's nothing that can go wrong.
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Neil Brown
Cc: Alessandro Zummo
Cc: Alexandre Belloni
Cc: Oleg Drokin
Cc: Andreas Dilger
Cc: "Michael S. Tsirkin"
Cc: Wim Van Sebroeck
Cc: Christine Caulfield
Cc: David Teigland
Cc: Mark Fasheh
Cc: Joel Becker
Signed-off-by: Greg Kroah-Hartman
---
If the different subsystem maintainers want to give me an ack for this,
I'd appreciate it. I'd like to just take the single patch in through
the char-misc tree in one piece.
drivers/char/misc.c |9 +++--
drivers/md/dm-ioctl.c |4 +---
drivers/misc/vmw_vmci/vmci_host.c |5 +
drivers/rtc/rtc-ds1374.c |5 ++---
drivers/staging/android/ashmem.c |5 +
drivers/staging/android/ion/ion_test.c|3 ++-
drivers/staging/lustre/lustre/libcfs/module.c |4 +---
drivers/vhost/scsi.c |4 ++--
drivers/watchdog/at91rm9200_wdt.c |5 ++---
drivers/watchdog/ks8695_wdt.c |9 +++--
drivers/watchdog/ts72xx_wdt.c |3 ++-
fs/dlm/user.c |9 +++--
fs/ocfs2/stack_user.c |9 +
include/linux/miscdevice.h|2 +-
14 files changed, 25 insertions(+), 51 deletions(-)
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -243,17 +243,15 @@ int misc_register(struct miscdevice * mi
* @misc: device to unregister
*
* Unregister a miscellaneous device that was previously
- * successfully registered with misc_register(). Success
- * is indicated by a zero return, a negative errno code
- * indicates an error.
+ * successfully registered with misc_register().
*/
-int misc_deregister(struct miscdevice *misc)
+void misc_deregister(struct miscdevice *misc)
{
int i = DYNAMIC_MINORS - misc->minor - 1;
if (WARN_ON(list_empty(>list)))
- return -EINVAL;
+ return;
mutex_lock(_mtx);
list_del(>list);
@@ -261,7 +259,6 @@ int misc_deregister(struct miscdevice *m
if (i < DYNAMIC_MINORS && i >= 0)
clear_bit(i, misc_minors);
mutex_unlock(_mtx);
- return 0;
}
EXPORT_SYMBOL(misc_register);
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1919,9 +1919,7 @@ int __init dm_interface_init(void)
void dm_interface_exit(void)
{
- if (misc_deregister(&_dm_misc) < 0)
- DMERR("misc_deregister failed for control device");
-
+ misc_deregister(&_dm_misc);
dm_hash_exit();
}
--- a/drivers/misc/vmw_vmci/vmci_host.c
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -1035,10 +1035,7 @@ void __exit vmci_host_exit(void)
vmci_host_device_initialized = false;
- error = misc_deregister(_host_miscdev);
- if (error)
- pr_warn("Error unregistering character device: %d\n", error);
-
+ misc_deregister(_host_miscdev);
vmci_ctx_destroy(host_context);
vmci_qp_broker_exit();
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -666,9 +666,8 @@ static int ds1374_remove(struct i2c_clie
#ifdef CONFIG_RTC_DRV_DS1374_WDT
int res;
- res = misc_deregister(_miscdev);
- if (!res)
- ds1374_miscdev.parent = NULL;
+ misc_deregister(_miscdev);
+ ds1374_miscdev.parent = NULL;
unregister_reboot_notifier(_wdt_notifier);
#endif
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -867,10 +867,7 @@ static void __exit ashmem_exit(void)
unregister_shrinker(_shrinker);
- ret = misc_deregister(_misc);
- if (unlikely(ret))
- pr_err("failed to unregister misc device!\n");
-
+ misc_deregister(_misc);
kmem_cache_destroy(ashmem_range_cachep);
kmem_cache_destroy(ashmem_area_cachep);
--- a/drivers/staging/android/ion/ion_test.c
+++ b/drivers/staging/android/ion/ion_test.c
@@ -269,7 +269,8 @@ static int ion_test_remove(struct platfo
if (!testdev)
return -ENODATA;
- return misc_deregister(>misc);
+ misc_deregister(>misc);
+ return 0;
}
static struct platform_device *ion_test_pdev;
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -467,9 +467,7 @@ static void
