[PATCH] reset: remove unnecessary local variable initialization from of_reset_control_get_by_index
There is no need to initialize rstc, as it is unconditionally
assigned the return value of a kzalloc call before use.
Signed-off-by: Philipp Zabel
---
drivers/reset/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 8737663..4a63b37 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(reset_control_status);
struct reset_control *of_reset_control_get_by_index(struct device_node *node,
int index)
{
- struct reset_control *rstc = ERR_PTR(-EPROBE_DEFER);
+ struct reset_control *rstc;
struct reset_controller_dev *r, *rcdev;
struct of_phandle_args args;
int rstc_id;
--
2.6.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: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3
Hi Peter, On Tue, Dec 08, 2015 at 04:20:06AM +0100, Peter Rosin wrote: > From: Peter Rosin > > Hi! > > I have a signal connected to a gpio pin which is the output of > a comparator. By changing the level of one of the inputs to the > comparator, I can detect the envelope of the other input to > the comparator by using a series of measurements much in the > same maner a manual ADC works, but watching for changes on the > comparator over a period of time instead of only the immediate > output. > > Now, the input signal to the comparator might have a high frequency, > which will cause the output from the comparator (and thus the GPIO > input) to change rapidly. > > A common(?) idiom for this is to use the interrupt status register > to catch the glitches, but then not have any interrupt tied to > the pin as that could possibly generate pointless bursts of > (expensive) interrupts. > Well I don't know if this use case as already been considered. I understand you don't want to be overwhelmed by interrupts but why not using the interrupt to start polling the PDSR (Pin Data Status Register)? I am really not confortable about exposing the ISR since there is a clean on read. You have taken precautions by checking the IMR before but if there is a single driver using a gpio as an irq, you will never get the ISR. Regards Ludovic > So, these two patches expose an interface to the PIO_ISR register > of the pio controllers on the platform I'm targetting. The first > patch adds some infrastructure to the gpio core and the second > patch hooks up "my" pin controller. > > But hey, this seems like an old problem and I was surprised that > I had to touch the source to do it. Which makes me wonder what I'm > missing and what others needing to see short pulses on a pin but not > needing/wanting interrupts are doing? > > Yes, there needs to be a way to select the interrupt edge w/o > actually arming the interrupt, that is missing. And probably > other things too, but I didn't want to do more work in case this > is a dead end for some reason... > > Cheers, > Peter > > Peter Rosin (2): > gpio: Add isr property of gpio pins > pinctrl: at91: expose the isr bit > > Documentation/gpio/sysfs.txt | 12 ++ > drivers/gpio/gpiolib-sysfs.c | 30 > drivers/gpio/gpiolib.c | 15 > drivers/pinctrl/pinctrl-at91.c | 50 > > include/linux/gpio/consumer.h |1 + > include/linux/gpio/driver.h|2 ++ > 6 files changed, 106 insertions(+), 4 deletions(-) > > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-gpio" 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 v2] usb: Use memdup_user to reuse the code
Hello Alan,
Should I resend this patch version with the tear line correction?
Regards
Rahul Pathak
From: Alan Stern
Sent: Tuesday, December 8, 2015 8:53 PM
To: Pathak, Rahul (R.)
Cc: gre...@linuxfoundation.org; kbo...@gmail.com; dan.carpen...@oracle.com;
chasemetzge...@gmail.com; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] usb: Use memdup_user to reuse the code
On Tue, 8 Dec 2015, Pathak, Rahul (R.) wrote:
> From: Rahul Pathak
>
> Fixing coccicheck warning which recommends to use memdup_user instead
> to reimplement its code, using memdup_user simplifies the code
>
> ./drivers/usb/core/devio.c:1398:11-18: WARNING opportunity for memdup_user
>
> Changes after v1: setting isopkt=NULL for proper kfree() call
This line belongs below the "---" tear line, so that it doesn't show up
in the final commit changelog. People reading the final commit won't
care about earlier versions of the patch.
> Signed-off-by: Rahul Pathak
> ---
> drivers/usb/core/devio.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 38ae877c..844407c 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -1395,11 +1395,10 @@ static int proc_do_submiturb(struct usb_dev_state
> *ps, struct usbdevfs_urb *uurb
> number_of_packets = uurb->number_of_packets;
> isofrmlen = sizeof(struct usbdevfs_iso_packet_desc) *
> number_of_packets;
> - isopkt = kmalloc(isofrmlen, GFP_KERNEL);
> - if (!isopkt)
> - return -ENOMEM;
> - if (copy_from_user(isopkt, iso_frame_desc, isofrmlen)) {
> - ret = -EFAULT;
> + isopkt = memdup_user(iso_frame_desc, isofrmlen);
> + if (IS_ERR(isopkt)) {
> + ret = PTR_ERR(isopkt);
> + isopkt = NULL;
> goto error;
> }
> for (totlen = u = 0; u < number_of_packets; u++) {
Aside from that,
Acked-by: Alan Stern
Alan Stern
--
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 14/14] perf tools: Move subcommand framework and related utils to libapi
* Josh Poimboeuf wrote: > > > wouldn't necessarily be a clean split. It would also possibly create > > > more > > > room for error for the users of libapi, since there would then be three > > > config interfaces instead of one. > > > > Humm, and now that you talk... libapi was supposed to be just sugar coating > > kernel APIs, perhaps we need to put it somewhere else in tools/lib/ than in > > tools/lib/api/? > > Ah, I didn't realize libapi was a kernel API abstraction library. Shall we > put > it in tools/lib/util instead? Yay, naming discussion! ;-) So if this is about abstracting out the (Git derived) command-line option parsing UI and help system, 'util' sounds a bit too generic. We could call it something like 'lib/cmdline', 'lib/options'? The (old) argument against making too finegrained user-space libraries was that shared libraries do have extra runtime costs - this thinking resulted in catch-all super-libraries like libgtk: size /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 textdata bss dec hex filename 7199789 57712 15128 7272629 6ef8b5 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 But in tools/ we typically link the libraries statically so there's no shared library cost to worry about. (Build time linking is a good idea anyway, should we ever want to make use of link-time optimizations. It also eliminates version skew and library compatibility breakage.) The other reason for the emergence of super-libraries was the high setup cost of new libraries: it's a lot easier to add yet another unrelated API to libgtk than to start up a whole new project and a new library. But this setup cost is very low in tools/ - one of the advantage of shared repositories. So I think in tools/lib/ we can continue to do a clean topical separation of libraries, super-libraries are not needed. Thanks, Ingo -- 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: [Questions] perf c2c: What's the current status of perf c2c?
On Wed, Dec 09, 2015 at 12:06:44PM +0800, Yunlong Song wrote: > Hi, Don, > I am interested in the perf c2c tool, which is introduced in: > http://lwn.net/Articles/588866/ > However, I found that this tool has not been applied to the mainline tree of > perf, Why? It was first > introduced in Feb. 2014. What's its current status now? Does it have a new > version or a repository > somewhere else? And does it support Haswell? hi, not sure Don made any progress on this field, but I'm having his c2c sources rebased current perf sources ATM. I changed the tool a little to run over new DATALA events added in Haswell (in addition to ldlat events) and it seems to work. the plan for me is to to use it some more to prove it's useful and kick it to be merged with perf at some point jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] ARM: dts: exynos542x: add GSCL block parent clock management to pm domain
Add support for restoring GScaler parent clocks configuration when GSCL
power domain is turned on.
Signed-off-by: Marek Szyprowski
---
arch/arm/boot/dts/exynos5420.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 1b3d6c7..5d00c18 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -252,8 +252,10 @@
compatible = "samsung,exynos4210-pd";
reg = <0x10044000 0x20>;
#power-domain-cells = <0>;
- clocks = <&clock CLK_GSCL0>, <&clock CLK_GSCL1>;
- clock-names = "asb0", "asb1";
+ clocks = <&clock CLK_FIN_PLL>,
+<&clock CLK_MOUT_USER_ACLK300_GSCL>,
+<&clock CLK_GSCL0>, <&clock CLK_GSCL1>;
+ clock-names = "oscclk", "clk0", "asb0", "asb1";
};
isp_pd: power-domain@10044020 {
--
1.9.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 1/2] null_blk: Remove null block from list in error path
On 12/09/2015 06:21 AM, Minfei Huang wrote: Ping. Any comment is appreciate. Thanks Minfei That'll work. Thanks for fixing up my mistake. -- 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: piping core dump to a program escapes container
On 12/09/2015 02:32 PM, Eric W. Biederman wrote: Dongsheng Yang writes: On 12/09/2015 11:29 AM, Eric W. Biederman wrote: Dongsheng Yang writes: [...] There has not yet been an obvious namespace in which to stick core_pattern, and even worse exactly how to appropriate launch a process in a container has not been figured out. If those tricky problems can be solved we can have a core_pattern in a container. What we have now is the best we have been able to figure out so far. Thanx Eric, but if I want to make docker works rely on this behaviour, is that reliable? I mean, I want to make a docker container to dump the core file to a specified path in host by a pipe way. But I am afraid this behaviour would be changed later. Any suggestion? The kernel rules say if there is a behavior someone depends on and that behavior changes and breaks userspace that is a regression and it is not allowed. As developers we try not to create regressions. But some days it requires someone testing/using the functional enough to catdch an issue. That said the real issue you are likely to run into when developing this as part of docker is that docker doesn't get to own the core pattern. It doesn't make sense for any one application to, as it is a kernel wide setting. Agreed. To have different app or container specific policies for core dumping likely requires either solving the problems I mentioned with containers or in userspace a solution so there can be an /etc/core_pattern.d/ with different configuration and different scripts that somehow know how to select which core files they want and dump them sanely. We would try to solve the problems you mentioned, but sound not easy. Anyway, I need to read some old discussion at first I think. Thanx Yang Eric -- 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 00/25] mtd: nand: refactor the NAND subsystem (part 1)
Hi Brian,
On Tue, 8 Dec 2015 16:36:24 -0800
Brian Norris wrote:
> Hi,
>
> On Tue, Dec 01, 2015 at 12:02:57PM +0100, Boris Brezillon wrote:
> > Hello,
> >
> > This huge series aims at clarifying the relationship between the mtd and
> > nand_chip structures and hiding NAND framework internals to NAND
> > controller drivers.
> >
> > The first part of the series provide an mtd_to_nand() helper to hide the
> > way mtd and nand_chip are linked together.
> >
> > The second part of the series embeds the mtd structure into the nand_chip
> > one so that NAND controller drivers don't have to bother allocating the
> > MTD device and linking it with the NAND chip.
> >
> > The last part of the series hides accesses to the chip->priv field behind
> > two helper functions.
> >
> > This allows removal of some of the boilerplate code done in all NAND
> > controller drivers, but most importantly, it unifies a bit the way NAND
> > chip structures are instantiated (even though we still have two different
> > kinds of drivers: those embedding the nand_chip struct into their private
> > nand chip representation, and those allocating two different structures
> > and linking them together with the chip->priv field).
> >
> > As said in the title, this refactoring is only the first step. I plan to
> > rework the NAND controller / NAND chip separation for pretty much the same
> > reasons: clarifying the separation between the two concepts, and getting
> > rid of more boilerplate code in NAND controller drivers.
> >
> > Stay tuned ;-).
> >
> > Best Regards,
> >
> > Boris
> >
> > Changes since v1:
> > - dropped already applied patches
> > - fixed some typos
> > - manually fixed some modifications omitted by the coccinelle scripts
> > - manually reworked modifactions done by coccinelle scripts to improve
> > readability and fix coding style issues
> >
> > Boris Brezillon (25):
> > ARM: nand: make use of mtd_to_nand() where appropriate
>
> I've sent this (+ the introduction of mtd_to_nand()) in a pull request
> to arm-soc, as well as to l2-mtd.git.
>
> > blackfin: nand: make use of mtd_to_nand() where appropriate
> > cris: nand: make use of mtd_to_nand() where appropriate
> > mips: nand: make use of mtd_to_nand() where appropriate
>
> I've based these on v4.4-rc1 and brought them into l2-mtd.git, in case
> any arch/{blackfin,cris,mips}/ people want to pull them in too.
>
> > sh: nand: make use of mtd_to_nand() where appropriate
> > mtd: nand: make use of mtd_to_nand() in NAND core code
> > mtd: nand: make use of mtd_to_nand() in NAND drivers
> > staging: mt29f_spinand: make use of mtd_to_nand()
> > mtd: nand: embed an mtd_info structure into nand_chip
> > mtd: nand: add nand_to_mtd() helper
>
> Pulled the rest up to here into l2-mtd.git.
Okay, thanks.
>
> > coccinelle: nand: detect and correct drivers embedding an mtd_info
> > object
>
> I believe Julia had comments on this. That probably would go through the
> kbuild tree in the end anyway (?).
Julia proposed to generate this script using sgen, so I guess this will
come later through a different tree.
>
> > mtd: nand: use the mtd instance embedded in struct nand_chip
>
> There's still at least one problem in this patch (commented on the
> patch). It touches a lot of drivers, so any extra review would be great.
Yep, I think I'll resend the series and split the modification so that
you can pick changes independently (as you suggested a few days ago).
Anyway, reviews from other people would be much appreciated. As I said,
most of changes have been automated with coccinelle, but some of them
have been made manually done, and this is the case for all drivers using
the following pattern:
var = kzalloc(sizeof(struct mtd_info) +
sizeof(struct nand_chip) + ... ,...);
because I failed to find a pattern common enough to match the cases I
had, and manually fixing them was easier for me...
>
> > mtd: nand: update the documentation to reflect framework changes
> > staging: mt29f_spinand: use the mtd instance embedded in struct
> > nand_chip
> > cris: nand: use the mtd instance embedded in struct nand_chip
> > mtd: nand: update mtd_to_nand()
> > mtd: nand: remove useless mtd->priv = chip assignments
> > cris: nand: remove useless mtd->priv = chip assignments
> > staging: mt29f_spinand: remove useless mtd->priv = chip assignment
> > mtd: nand: simplify nand_dt_init() usage
> > mtd: nand: kill the chip->flash_node field
> > mtd: nand: add helpers to access ->priv
> > ARM: make use of nand_set/get_controller_data() helpers
> > mtd: nand: make use of nand_set/get_controller_data() helpers
> > staging: mt29f_spinand: make use of nand_set/get_controller_data()
> > helpers
>
> All the rest look good to me. I'll wait until I get a good copy of patch
> 12 before taking them.
Sure.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
Re: [Questions] perf c2c: What's the current status of perf c2c?
On 2015/12/9 16:04, Jiri Olsa wrote: On Wed, Dec 09, 2015 at 12:06:44PM +0800, Yunlong Song wrote: Hi, Don, I am interested in the perf c2c tool, which is introduced in: http://lwn.net/Articles/588866/ However, I found that this tool has not been applied to the mainline tree of perf, Why? It was first introduced in Feb. 2014. What's its current status now? Does it have a new version or a repository somewhere else? And does it support Haswell? hi, not sure Don made any progress on this field, but I'm having his c2c sources rebased current perf sources ATM. Do you have a git repository so we can fetch the code of it? Thank you. -- 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] ARM: dts: imx: Fix the assigned-clock mismatch issue on imx6q/dl
The 'assigned-clock-parents' and 'assigned-clock-rates' list
should corresponding to the 'assigned-clocks' property clock list.
Signed-off-by: Bai Ping
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 5a26173..dd92279 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -113,14 +113,14 @@
&clks {
assigned-clocks = <&clks IMX6QDL_PLL4_BYPASS_SRC>,
<&clks IMX6QDL_PLL4_BYPASS>,
- <&clks IMX6QDL_CLK_PLL4_POST_DIV>,
<&clks IMX6QDL_CLK_LDB_DI0_SEL>,
- <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>,
+ <&clks IMX6QDL_CLK_PLL4_POST_DIV>;
assigned-clock-parents = <&clks IMX6QDL_CLK_LVDS2_IN>,
<&clks IMX6QDL_PLL4_BYPASS_SRC>,
<&clks IMX6QDL_CLK_PLL3_USB_OTG>,
<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
- assigned-clock-rates = <0>, <0>, <24576000>;
+ assigned-clock-rates = <0>, <0>, <0>, <0>, <24576000>;
};
&ecspi1 {
--
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 for 4.4 1/2] dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type
This change makes the DT file to be easier to read since the memcpy
channels array does not need the '/bits/ 16' to be specified, which might
confuse some people.
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 ++---
drivers/dma/edma.c| 22 ++
include/linux/platform_data/edma.h| 2 +-
3 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index d3d0a4fb1c73..ae8b8f1d6e69 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -22,8 +22,7 @@ Required properties:
Optional properties:
- ti,hwmods: Name of the hwmods associated to the eDMA CC
- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy,
iow
- these channels will be SW triggered channels. The list must
- contain 16 bits numbers, see example.
+ these channels will be SW triggered channels. See example.
- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
the driver, they are allocated to be used by for example the
DSP. See example.
@@ -56,7 +55,7 @@ edma: edma@4900 {
ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 7>, <&edma_tptc2 0>;
/* Channel 20 and 21 is allocated for memcpy */
- ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+ ti,edma-memcpy-channels = <20 21>;
/* The following PaRAM slots are reserved: 35-45 and 100-110 */
ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
/bits/ 16 <100 10>;
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2af8f32bba0b..89fc17f3a6ff 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1752,16 +1752,14 @@ static enum dma_status edma_tx_status(struct dma_chan
*chan,
return ret;
}
-static bool edma_is_memcpy_channel(int ch_num, u16 *memcpy_channels)
+static bool edma_is_memcpy_channel(int ch_num, s32 *memcpy_channels)
{
- s16 *memcpy_ch = memcpy_channels;
-
if (!memcpy_channels)
return false;
- while (*memcpy_ch != -1) {
- if (*memcpy_ch == ch_num)
+ while (*memcpy_channels != -1) {
+ if (*memcpy_channels == ch_num)
return true;
- memcpy_ch++;
+ memcpy_channels++;
}
return false;
}
@@ -1775,7 +1773,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool
legacy_mode)
{
struct dma_device *s_ddev = &ecc->dma_slave;
struct dma_device *m_ddev = NULL;
- s16 *memcpy_channels = ecc->info->memcpy_channels;
+ s32 *memcpy_channels = ecc->info->memcpy_channels;
int i, j;
dma_cap_zero(s_ddev->cap_mask);
@@ -1996,16 +1994,16 @@ static struct edma_soc_info
*edma_setup_info_from_dt(struct device *dev,
prop = of_find_property(dev->of_node, "ti,edma-memcpy-channels", &sz);
if (prop) {
const char pname[] = "ti,edma-memcpy-channels";
- size_t nelm = sz / sizeof(s16);
- s16 *memcpy_ch;
+ size_t nelm = sz / sizeof(s32);
+ s32 *memcpy_ch;
- memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s16),
+ memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s32),
GFP_KERNEL);
if (!memcpy_ch)
return ERR_PTR(-ENOMEM);
- ret = of_property_read_u16_array(dev->of_node, pname,
-(u16 *)memcpy_ch, nelm);
+ ret = of_property_read_u32_array(dev->of_node, pname,
+(u32 *)memcpy_ch, nelm);
if (ret)
return ERR_PTR(ret);
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 105700e62ea1..0a533f94438f 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -76,7 +76,7 @@ struct edma_soc_info {
struct edma_rsv_info*rsv;
/* List of channels allocated for memcpy, terminated with -1 */
- s16 *memcpy_channels;
+ s32 *memcpy_channels;
s8 (*queue_priority_mapping)[2];
const s16 (*xbar_chans)[2];
--
2.6.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 for 4.4 2/2] dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type
This change makes the DT file to be easier to read since the reserved slots
array does not need the '/bits/ 16' to be specified, which might confuse
some people.
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 ++--
drivers/dma/edma.c| 31 ++-
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index ae8b8f1d6e69..079b42a81d7c 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -56,9 +56,8 @@ edma: edma@4900 {
/* Channel 20 and 21 is allocated for memcpy */
ti,edma-memcpy-channels = <20 21>;
- /* The following PaRAM slots are reserved: 35-45 and 100-110 */
- ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
- /bits/ 16 <100 10>;
+ /* The following PaRAM slots are reserved: 35-44 and 100-109 */
+ ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
};
edma_tptc0: tptc@4980 {
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 89fc17f3a6ff..a0f217349c07 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2015,31 +2015,50 @@ static struct edma_soc_info
*edma_setup_info_from_dt(struct device *dev,
&sz);
if (prop) {
const char pname[] = "ti,edma-reserved-slot-ranges";
+ u32 (*tmp)[2];
s16 (*rsv_slots)[2];
- size_t nelm = sz / sizeof(*rsv_slots);
+ size_t nelm = sz / sizeof(*tmp);
struct edma_rsv_info *rsv_info;
+ int i;
if (!nelm)
return info;
+ tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return ERR_PTR(-ENOMEM);
+
rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
- if (!rsv_info)
+ if (!rsv_info) {
+ kfree(tmp);
return ERR_PTR(-ENOMEM);
+ }
rsv_slots = devm_kcalloc(dev, nelm + 1, sizeof(*rsv_slots),
GFP_KERNEL);
- if (!rsv_slots)
+ if (!rsv_slots) {
+ kfree(tmp);
return ERR_PTR(-ENOMEM);
+ }
- ret = of_property_read_u16_array(dev->of_node, pname,
-(u16 *)rsv_slots, nelm * 2);
- if (ret)
+ ret = of_property_read_u32_array(dev->of_node, pname,
+(u32 *)tmp, nelm * 2);
+ if (ret) {
+ kfree(tmp);
return ERR_PTR(ret);
+ }
+ for (i = 0; i < nelm; i++) {
+ rsv_slots[i][0] = tmp[i][0];
+ rsv_slots[i][1] = tmp[i][1];
+ }
rsv_slots[nelm][0] = -1;
rsv_slots[nelm][1] = -1;
+
info->rsv = rsv_info;
info->rsv->rsv_slots = (const s16 (*)[2])rsv_slots;
+
+ kfree(tmp);
}
return info;
--
2.6.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 for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit
Hi, Based on the discussion regarding to (convert am33xx to use the new eDMA bindings): https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html This two patch will convert the new eDMA binding to not use 16bit arrays for memcpy channel selection and for marking slots reserved. The '/bits/ 16' seams to be causing confusion so it is probably better to just use standard type for the arrays. The new bindings for the eDMA is introduced for 4.4 and we do not have users of it, which means that we can still change it w/o the risk of breaking anything and we do not need to maintain the compatibility with 16bit arrays. The changes in the eDMA driver is local to the DT parsing and should not conflict with other changes (like the filter function mapping support). Hrm, there might be trivial conflict in the include/linux/platform_data/edma.h with the "dmaengine 'universal' API". Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches are going to be handled? I would like to send the updated am33xx/am437x conversion for 4.5 based on these changes. Thanks and regards, Peter --- Peter Ujfalusi (2): dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type Documentation/devicetree/bindings/dma/ti-edma.txt | 10 ++--- drivers/dma/edma.c| 53 +++ include/linux/platform_data/edma.h| 2 +- 3 files changed, 40 insertions(+), 25 deletions(-) -- 2.6.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: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects
On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> Otherwise check_timings fails and we get a "has no modes" message
> from xrandr.
>
> This fix makes the venc assume PAL and NTSC timings that match the
> timings synthetized by copy_timings_drm_to_omap() from omapdrm
> mode settings so that check_timings() succeeds.
>
> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>
> Signed-off-by: H. Nikolaus Schaller
> ---
> drivers/video/fbdev/omap2/dss/venc.c | 12
> 1 file changed, 12 insertions(+)
I've picked this up.
With this patch and the one below I can get tv-out working on my very old
beagleboard, and it seems to work with X also. It doesn't start automatically
as the connection state is unknown, but doing "xrandr --output None-1 --auto"
was all I needed to enable it.
Tomi
From a4274600a5a67256b91266b0d2624b9c9028909b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen
Date: Tue, 8 Dec 2015 18:32:14 +0200
Subject: [PATCH] drm/omap: fix fbdev pix format to support all platforms
omap_fbdev always creates a framebuffer with ARGB pixel format. On
OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
OMAP2 none of the overlays support ARGB888.
This patch changes the omap_fbdev's fb to XRGB, which is supported
by all platforms.
Signed-off-by: Tomi Valkeinen
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b8e4cdec28c3..24f92bea39c7 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
dma_addr_t paddr;
int ret;
- /* only doing ARGB32 since this is what is needed to alpha-blend
-* with video overlays:
-*/
sizes->surface_bpp = 32;
- sizes->surface_depth = 32;
+ sizes->surface_depth = 24;
DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
sizes->surface_height, sizes->surface_bpp,
signature.asc
Description: OpenPGP digital signature
RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts
Hi Radim,
> -Original Message-
> From: Radim Krčmář [mailto:rkrc...@redhat.com]
> Sent: Tuesday, November 17, 2015 3:03 AM
> To: Wu, Feng
> Cc: pbonz...@redhat.com; k...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-
> interrupts
>
> 2015-11-09 10:46+0800, Feng Wu:
> > Use vector-hashing to handle lowest-priority interrupts for
> > posted-interrupts. As an example, modern Intel CPUs use this
> > method to handle lowest-priority interrupts.
>
> (I don't think it's a good idea that the algorithm differs from non-PI
> lowest priority delivery. I'd make them both vector-hashing, which
> would be "fun" to explain to people expecting round robin ...)
>
> > Signed-off-by: Feng Wu
> > ---
> > diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
> > +/*
> > + * This routine handles lowest-priority interrupts using vector-hashing
> > + * mechanism. As an example, modern Intel CPUs use this method to handle
> > + * lowest-priority interrupts.
> > + *
> > + * Here is the details about the vector-hashing mechanism:
> > + * 1. For lowest-priority interrupts, store all the possible destination
> > + *vCPUs in an array.
> > + * 2. Use "guest vector % max number of destination vCPUs" to find the
> > right
> > + *destination vCPU in the array for the lowest-priority interrupt.
> > + */
>
> (Is Skylake i7-6700 a modern Intel CPU?
> I didn't manage to get hashing ... all interrupts always went to the
> lowest APIC ID in the set :/
> Is there a simple way to verify the algorithm?)
>
> > +struct kvm_vcpu *kvm_intr_vector_hashing_dest(struct kvm *kvm,
> > + struct kvm_lapic_irq *irq)
> > +
> > +{
> > + unsigned long dest_vcpu_bitmap[BITS_TO_LONGS(KVM_MAX_VCPUS)];
> > + unsigned int dest_vcpus = 0;
> > + struct kvm_vcpu *vcpu;
> > + unsigned int i, mod, idx = 0;
> > +
> > + vcpu = kvm_intr_vector_hashing_dest_fast(kvm, irq);
> > + if (vcpu)
> > + return vcpu;
>
> I think the rest of this function shouldn't be implemented:
> - Shorthands are only for IPIs and hence don't need to be handled,
> - Lowest priority physical broadcast is not supported,
> - Lowest priority cluster logical broadcast is not supported,
> - No point in optimizing mixed xAPIC and x2APIC mode,
I read your comments again, and don't quite understand why we
don't need PI optimization for mixed xAPIC and x2APIC mode.
BTW, can we have mixed flat and cluster mode?
Thanks,
Feng
> - The rest is handled by kvm_intr_vector_hashing_dest_fast().
>(Even lowest priority flat logical "broadcast".)
> - We do the work twice when vcpu == NULL means that there is no
>matching destination.
>
> Is there a valid case that can be resolved by going through all vcpus?
>
> > +
> > + memset(dest_vcpu_bitmap, 0, sizeof(dest_vcpu_bitmap));
> > +
> > + kvm_for_each_vcpu(i, vcpu, kvm) {
> > + if (!kvm_apic_present(vcpu))
> > + continue;
> > +
> > + if (!kvm_apic_match_dest(vcpu, NULL, irq->shorthand,
> > + irq->dest_id, irq->dest_mode))
> > + continue;
> > +
> > + __set_bit(vcpu->vcpu_id, dest_vcpu_bitmap);
> > + dest_vcpus++;
> > + }
> > +
> > + if (dest_vcpus == 0)
> > + return NULL;
> > +
> > + mod = irq->vector % dest_vcpus;
> > +
> > + for (i = 0; i <= mod; i++) {
> > + idx = find_next_bit(dest_vcpu_bitmap, KVM_MAX_VCPUS, idx) +
> 1;
> > + BUG_ON(idx >= KVM_MAX_VCPUS);
> > + }
> > +
> > + return kvm_get_vcpu(kvm, idx - 1);
> > +}
> > +EXPORT_SYMBOL_GPL(kvm_intr_vector_hashing_dest);
> > +
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > @@ -816,6 +816,63 @@ out:
> > +struct kvm_vcpu *kvm_intr_vector_hashing_dest_fast(struct kvm *kvm,
> > + struct kvm_lapic_irq *irq)
>
> We now have three very similar functions :(
>
> kvm_irq_delivery_to_apic_fast
> kvm_intr_is_single_vcpu_fast
> kvm_intr_vector_hashing_dest_fast
>
> By utilizing the gcc optimizer, they can be merged without introducing
> many instructions to the hot path, kvm_irq_delivery_to_apic_fast.
> (I would eventually do it, so you can save time by ignoring this.)
>
> 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/
[PATCH V2] ACPI: Support D3 COLD device in old BIOS for ZPODD
D3cold is only regarded as valid if the "_PR3" object is
present for the given device after the commit 20dacb71ad28
("ACPI/PM: Rework device power management to follow ACPI 6").
But some old BIOS only defined "_PS3" for the D3COLD device,
such as ZPODD device. And old kernel also believes the device with
"_PS3" is a D3COLD device.
So, add some logics for supporting D3 COLD device with old BIOS
which is compatible with earlier ACPI spec and kernel behavior.
Reference:
http://marc.info/?l=linux-acpi&m=144946938709759&w=2
Signed-off-by: Ken Xue
Reported-and-tested-by: Gang Long
---
include/acpi/acpi_bus.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ad0a5ff..9894b75 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -631,7 +631,9 @@ static inline bool acpi_device_can_wakeup(struct
acpi_device *adev)
static inline bool acpi_device_can_poweroff(struct acpi_device *adev)
{
- return adev->power.states[ACPI_STATE_D3_COLD].flags.valid;
+ return adev->power.states[ACPI_STATE_D3_COLD].flags.valid ||
+ ((acpi_gbl_FADT.header.revision < 6) &&
+ adev->power.states[ACPI_STATE_D3_HOT].flags.explicit_set);
}
#else /* CONFIG_ACPI */
--
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] sh64: fix __NR_fgetxattr
CC akpm
On Wed, Dec 9, 2015 at 4:16 AM, Dmitry V. Levin wrote:
> According to arch/sh/kernel/syscalls_64.S and common sense,
> __NR_fgetxattr has to be defined to 259, but it doesn't.
> Instead, it's defined to 269, which is of course used
> by another syscall, __NR_sched_setaffinity in this case.
>
> This bug was found by strace test suite.
>
> Signed-off-by: Dmitry V. Levin
> Cc: sta...@vger.kernel.org
Acked-by: Geert Uytterhoeven
> ---
> arch/sh/include/uapi/asm/unistd_64.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/include/uapi/asm/unistd_64.h
> b/arch/sh/include/uapi/asm/unistd_64.h
> index e6820c8..47ebd5b 100644
> --- a/arch/sh/include/uapi/asm/unistd_64.h
> +++ b/arch/sh/include/uapi/asm/unistd_64.h
> @@ -278,7 +278,7 @@
> #define __NR_fsetxattr 256
> #define __NR_getxattr 257
> #define __NR_lgetxattr 258
> -#define __NR_fgetxattr 269
> +#define __NR_fgetxattr 259
> #define __NR_listxattr 260
> #define __NR_llistxattr261
> #define __NR_flistxattr262
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver
Hi, On Mon, Nov 16, 2015 at 2:42 PM, wrote: > From: Rameshwar Prasad Sahu > > This patch implements support for APM X-Gene SoC CRC32C h/w accelerator driver > and adds CRC32C computations support in dmaengine framework. APM X-Gene SoC > has > DMA engine capable of performing CRC32C computations. > > v2 changes: > 1. Added helper function in dmaengine framework > 2. Documented CRC32C support in Documentations/dmaengine/provider.txt > 3. Fixed algo name > 4. Fixed coding style issues > > Signed-off-by: Rameshwar Prasad Sahu > --- > > Rameshwar Prasad Sahu (3): > dmaengine: Add support for new feature CRC32C computations > dmaengine: xgene-dma: Add support for CRC32C computations via DMA > engine > Crypto: Add support for APM X-Gene SoC CRC32C h/w accelerator driver > > Documentation/dmaengine/provider.txt |3 + > drivers/crypto/Kconfig |8 + > drivers/crypto/Makefile |1 + > drivers/crypto/xgene-crc32c.c| 234 + > drivers/dma/dmaengine.c |2 + > drivers/dma/xgene-dma.c | 314 > -- > include/linux/dmaengine.h| 13 ++ > 7 files changed, 560 insertions(+), 15 deletions(-) > create mode 100755 drivers/crypto/xgene-crc32c.c Any comments on above patch ?? -- 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] clear file privilege bits when mmap writing
On Mon 07-12-15 16:40:14, Kees Cook wrote: > On Mon, Dec 7, 2015 at 2:42 PM, Kees Cook wrote: > > On Thu, Dec 3, 2015 at 5:45 PM, yalin wang wrote: > >> > >>> On Dec 2, 2015, at 16:03, Kees Cook wrote: > >>> > >>> Normally, when a user can modify a file that has setuid or setgid bits, > >>> those bits are cleared when they are not the file owner or a member > >>> of the group. This is enforced when using write and truncate but not > >>> when writing to a shared mmap on the file. This could allow the file > >>> writer to gain privileges by changing a binary without losing the > >>> setuid/setgid/caps bits. > >>> > >>> Changing the bits requires holding inode->i_mutex, so it cannot be done > >>> during the page fault (due to mmap_sem being held during the fault). > >>> Instead, clear the bits if PROT_WRITE is being used at mmap time. > >>> > >>> Signed-off-by: Kees Cook > >>> Cc: sta...@vger.kernel.org > >>> — > >> > >> is this means mprotect() sys call also need add this check? > >> mprotect() can change to PROT_WRITE, then it can write to a > >> read only map again , also a secure hole here . > > > > Yes, good point. This needs to be added. I will send a new patch. Thanks! > > This continues to look worse and worse. > > So... to check this at mprotect time, I have to know it's MAP_SHARED, > but that's in the vma_flags, which I can only see after holding > mmap_sem. > > The best I can think of now is to strip the bits at munmap time, since > you can't execute an mmapped file until it closes. > > Jan, thoughts on this? Umm, so we actually refuse to execute a file while someone has it open for writing (deny_write_access() in do_open_execat()). So dropping the suid / sgid bits when closing file for writing could be plausible. Grabbing i_mutex from __fput() context is safe (it gets called from task_work context when returning to userspace). That way we could actually remove the checks done for each write. To avoid unexpected removal of suid/sgid bits when someone just opens & closes the file, we could mark the file as needing suid/sgid treatment by a flag in inode->i_flags when file gets written to or mmaped and then check for this in __fput(). I've added Al Viro to CC just in case he is aware of some issues with this... Honza -- Jan Kara SUSE Labs, CR -- 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 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver
On Wed, Dec 09, 2015 at 01:55:55PM +0530, Rameshwar Sahu wrote: > > Any comments on above patch ?? My concern that there aren't going to be any in-kernel users remains. 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: [tip:perf/core] perf/x86: Use INST_RETIRED.PREC_DIST for cycles: ppp
* Peter Zijlstra wrote: > On Tue, Dec 08, 2015 at 09:57:07AM +0100, Peter Zijlstra wrote: > > On Tue, Dec 08, 2015 at 09:50:26AM +0100, Peter Zijlstra wrote: > > > On Tue, Dec 08, 2015 at 06:36:04AM +0100, Ingo Molnar wrote: > > > > > > > So I checked my NHM box with your latest queue and it now works > > > > correctly. Do you > > > > have any idea what the difference is/was? > > > > > > Sadly, no clue :/ > > > > > > I went over those patches and cannot find anything that should affect > > > NHM (or <=SNB in fact). > > > > Oh wait, I spoke too soon, the two new patches affect everything with > > PEBS. And esp. the latter one: > > > > lkml.kernel.org/r/1449177740-5422-2-git-send-email-a...@firstfloor.org > > > > If that is the patch that makes your NHM go again, then running 2 > concurrent perf-top sessions should make it all go dark again. Hm, so I tried again your latest perf/urgent (1221fc3b3e3a) merged into tip:master (c9586e904a68), and booted it on the NHM, but 'perf top' refuses to break. One thing that was special about my first NHM test was that it conducted an about 24 hours perf stress. OTOH 'cycles:p' did work, it was only 'cycles:pp' that was producing no events whatsoever - so it wasn't a total breakage, only :pp related. Weird ... Thanks, Ingo -- 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: x86 fpu: command-line parameters broken post-FPU-rewrite
* Dave Hansen wrote: > Hey Ingo, > > We were starting to look at reenabling XSAVES support and tried to use the > 'noxsave' and 'noxsaves' kernel command-line options. The rewrite moved the > FPU > initialization to before we even are parsing command-line options, even the > early_param()s. > > Do you have any preferences on how it gets fixed? > > The most obvious thing would be to just defer as much of the FPU setup as we > can > until after parse_early_param() has happened. The only other think I can > think > of doing would be to try to do some *really* early, simple, command-line > parsing > to look for 'noxsave' and friends. > > Thoughts? Hm, so given that having the FPU operational is key to a functioning kernel (and other kernel subsystems may make use of FPU functionality), I'd rather bring option parsing earlier than change the FPU setup sequence. FPU setup should be done when we identify the CPU - not 'very late' as we used to. Thanks, Ingo -- 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:perf/core] perf: Add pmu specific data for perf task context
On Wed, Feb 18, 2015 at 09:15:06AM -0800, tip-bot for Yan, Zheng wrote:
> +find_get_context(struct pmu *pmu, struct task_struct *task,
> + struct perf_event *event)
> {
> struct perf_event_context *ctx, *clone_ctx = NULL;
> struct perf_cpu_context *cpuctx;
> + void *task_ctx_data = NULL;
> unsigned long flags;
> int ctxn, err;
> + int cpu = event->cpu;
>
> if (!task) {
> /* Must be root to operate on a CPU event: */
> @@ -3342,11 +3354,24 @@ find_get_context(struct pmu *pmu, struct task_struct
> *task, int cpu)
> if (ctxn < 0)
> goto errout;
>
> + if (event->attach_state & PERF_ATTACH_TASK_DATA) {
> + task_ctx_data = kzalloc(pmu->task_ctx_size, GFP_KERNEL);
> + if (!task_ctx_data) {
> + err = -ENOMEM;
> + goto errout;
> + }
> + }
> +
> retry:
> ctx = perf_lock_task_context(task, ctxn, &flags);
> if (ctx) {
> clone_ctx = unclone_ctx(ctx);
> ++ctx->pin_count;
> +
> + if (task_ctx_data && !ctx->task_ctx_data) {
> + ctx->task_ctx_data = task_ctx_data;
> + task_ctx_data = NULL;
> + }
> raw_spin_unlock_irqrestore(&ctx->lock, flags);
>
> if (clone_ctx)
> @@ -3357,6 +3382,11 @@ retry:
> if (!ctx)
> goto errout;
>
> + if (task_ctx_data) {
> + ctx->task_ctx_data = task_ctx_data;
> + task_ctx_data = NULL;
> + }
> +
> err = 0;
> mutex_lock(&task->perf_event_mutex);
> /*
> @@ -3383,9 +3413,11 @@ retry:
> }
> }
>
> + kfree(task_ctx_data);
> return ctx;
>
> errout:
> + kfree(task_ctx_data);
> return ERR_PTR(err);
> }
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 36babfd..97aa610 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3508,11 +3515,6 @@ retry:
if (!ctx)
goto errout;
- if (task_ctx_data) {
- ctx->task_ctx_data = task_ctx_data;
- task_ctx_data = NULL;
- }
-
err = 0;
mutex_lock(&task->perf_event_mutex);
/*
@@ -3526,6 +3528,10 @@ retry:
else {
get_ctx(ctx);
++ctx->pin_count;
+ if (task_ctx_data) {
+ ctx->task_ctx_data = task_ctx_data;
+ task_ctx_data = NULL;
+ }
rcu_assign_pointer(task->perf_event_ctxp[ctxn], ctx);
}
mutex_unlock(&task->perf_event_mutex);
Does that make sense? No point in setting task_ctx_data if we're going
to free the ctx and try again.
--
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 bis 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip
Hi Brian,
On Tue, 8 Dec 2015 16:17:41 -0800
Brian Norris wrote:
>
> > diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
> > index 43bded6..84d027e 100644
> > --- a/drivers/mtd/nand/cmx270_nand.c
> > +++ b/drivers/mtd/nand/cmx270_nand.c
> > @@ -160,10 +160,8 @@ static int __init cmx270_init(void)
> > gpio_direction_input(GPIO_NAND_RB);
> >
> > /* Allocate memory for MTD device structure and private data */
> > - cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
> > - sizeof(struct nand_chip),
> > - GFP_KERNEL);
> > - if (!cmx270_nand_mtd) {
> > + this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> > + if (!this) {
> > ret = -ENOMEM;
> > goto err_kzalloc;
> > }
> > @@ -175,8 +173,7 @@ static int __init cmx270_init(void)
> > goto err_ioremap;
> > }
> >
> > - /* Get pointer to private data */
> > - this = (struct nand_chip *)(&cmx270_nand_mtd[1]);
> > + cmx270_nand_mtd = nand_to_mtd(this);
>
> So, you make cmx270_nand_mtd no longer kzalloc()'d, but I still see the
> cmx270_init() function end with:
>
> err_scan:
> iounmap(cmx270_nand_io);
> err_ioremap:
> kfree(cmx270_nand_mtd); <- *** this! ***
Oh, crap.
> err_kzalloc:
> gpio_free(GPIO_NAND_RB);
> err_gpio_request:
> gpio_free(GPIO_NAND_CS);
>
> return ret;
>
> }
>
> I have a feeling there's a failing in your coccinelle script somewhere.
These changes are not automated, because it's kind of hard to address
all the different cases where the following pattern is employed;
var = kzalloc(sizeof(struct mtd_info) +
sizeof(struct nand_chip) + ..., ...);
Sometime var is an mtd_info pointer, sometime it's a nand_chip pointer
or directly a pointer to the private struct.
I'm pretty sure we could come up with a valid coccinelle script, but
given the number of drivers using this approach I'm not sure it is
worth it...
>
> Given that I was only through 10 of 49 files changes, I think you might
> need to take a comb over your patch better.
I'll go over those changes one more time, but from my experience, these
kind of bugs are spotted more easily by people who didn't write the
code, so other reviews are more than welcome.
Also, as you suggested, I'll split the changes in several commits (one
per driver) so that you can pick them independently.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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] ARM: multi_v7_defconfig: Enable some drivers for LS1021A
> On Tuesday 08 December 2015 16:38:03 Alison Wang wrote: > > This patch enables some drivers for LS1021A, such as GIANFAR, > > WATCHDOG, AUDIO, QSPI, I2C, ESDHC, EDMA, FTM. > > QorIQ Clock Framework and Ramdisk support is also enabled. > > > > Signed-off-by: Alison Wang > > --- > > I think most of these can be made loadable modules, please do that and > only leave as much built-in as you need for booting. > > Otherwise looks ok. > > [Alison Wang] Thanks for your advice. I will change most drivers as loadable modules in v2. Best Regards, Alison Wang -- 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 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver
On Wed, Dec 9, 2015 at 1:57 PM, Herbert Xu wrote: > On Wed, Dec 09, 2015 at 01:55:55PM +0530, Rameshwar Sahu wrote: >> >> Any comments on above patch ?? > > My concern that there aren't going to be any in-kernel users remains. Yes, we are not upstream in-kernel users right now, but later client ma upstream there patches. > > 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: piping core dump to a program escapes container
On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote: > Dongsheng Yang writes: > > > On 12/09/2015 10:26 AM, Dongsheng Yang wrote: > >> On 10/25/2015 05:54 AM, Shayan Pooya wrote: > >>> I noticed the following core_pattern behavior in my linux box while > >>> running docker containers. I am not sure if it is bug, but it is > >>> inconsistent and not documented. > >>> > >>> If the core_pattern is set on the host, the containers will observe > >>> and use the pattern for dumping cores (there is no per cgroup > >>> core_pattern). According to core(5) for setting core_pattern one can: > >>> > >>> 1. echo "/tmp/cores/core.%e.%p" > /proc/sys/kernel/core_pattern > >>> 2. echo "|/bin/custom_core /tmp/cores/ %e %p " > > >>> /proc/sys/kernel/core_pattern > >>> > >>> The former pattern evaluates the /tmp/cores path in the container's > >>> filesystem namespace. Which means, the host does not see a core file > >>> in /tmp/cores. > >>> > >>> However, the latter evaluates the /bin/custom_core path in the global > >>> filesystem namespace. Moreover, if /bin/core decides to write the core > >>> to a path (/tmp/cores in this case as shown by the arg to > >>> custom_core), the path will be evaluated in the global filesystem > >>> namespace as well. > >>> > >>> The latter behaviour is counter-intuitive and error-prone as the > >>> container can fill up the core-file directory which it does not have > >>> direct access to (which means the core is also not accessible for > >>> debugging if someone only has access to the container). > > From a container perspective it is perhaps counter intuitive from > the perspective of the operator of the machine nothing works specially > about core_pattern and it works as designed with no unusual danages. > > >> Hi Shayan, > >> We found the same problem with what you described here. > >> Is there any document for this behaviour? I want to know is > >> that intentional or as you said a 'bug'. Maybe that's intentional > >> to provide a way for admin to collect core dumps from all containers as > >> Richard said. I am interested in it too. > >> > >> Anyone can help here? > > > > In addition, is that a good idea to make core_pattern to be seperated > > in different namespace? > > The behavior was the best we could do at the time last time this issue > was examined.There is enough information available to be able to > write a core dumping program that can reliably place your core dumps > in your container. > > There has not yet been an obvious namespace in which to stick > core_pattern, and even worse exactly how to appropriate launch a process > in a container has not been figured out. > > If those tricky problems can be solved we can have a core_pattern in a > container. What we have now is the best we have been able to figure out > so far. Isn't the second option dangerous if its run in global namespace and settable from some other namespace/container? If a process inside a container can set /proc/sys/kernel/core_pattern then it could e.g. set it to echo "|/bin/rm -rf / /tmp/cores/ %e %p " > /proc/sys/kernel/core_pattern and kill the host (eventually itself included). Other command lines could do different bad things. Something that would sound reasonable is to have the core dumping helper process run under the namespaces the process which wrote to /proc/sys/kernel/core_pattern had. When some of those namespaces are gone, falling back to the namespaces of the process for which core is to be dumped might seem reasonable (or just not dumping core at all as is done when core_pipe_limit is exceeded). The value of core_pattern (and other core_* sysctls) should probably belong to the mount namespace the proc filesystem used for setting its value was in - or the matching namespace of calling process when set via syscall. Bruno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] UML fixes for 4.4-rc5
Linus,
Am 09.12.2015 um 02:35 schrieb Linus Torvalds:
> On Tue, Dec 8, 2015 at 1:39 PM, Richard Weinberger wrote:
>>
>> This pull request contains various bug fixes, most of them are
>> fall out from the merge window.
>>
>> Richard Weinberger (2):
>> um: Fix fpstate handling
>
> Ugh. This is very ugly. It's apparently the result of commit
> 530e5c827182 ("x86/headers: Make sigcontext pointers bit independent")
> and apparently nobody noticed the uml fallout.
>
> I've pulled, but I wanted the x86 people involved to be aware of this
> ugly corner. I wonder if there might be some way for uml to continue
> to use that fpstate entry as a pointer, at least when the wordsize
> matches (which it will)?
I agree. One way to get rid of the ugliness would be rewriting UML's
FP code. The code is very old and doing it like x86 does would be a
good thing anyway. But that's nothing I'll do at this stage of development.
That's material for the next merge window.
Thanks,
//richard
--
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 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver
On Wed, Dec 09, 2015 at 02:13:32PM +0530, Rameshwar Sahu wrote: > > Yes, we are not upstream in-kernel users right now, but later client > ma upstream there patches. Well I'd prefer to not take any crypto drivers that don't have in-kernel users. 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 2/3] regmap: add 64-bit mode support
On Thursday 03 December 2015 17:31:52 Xiubo Li wrote:
> @@ -2488,11 +2581,17 @@ int regmap_bulk_read(struct regmap *map, unsigned int
> reg, void *val,
> * we assume that the values are native
> * endian.
> */
> + u64 *u64 = val;
> u32 *u32 = val;
> u16 *u16 = val;
> u8 *u8 = val;
>
> switch (map->format.val_bytes) {
> +#ifdef CONFIG_64BIT
> + case 8:
> + u64[i] = ival;
> + break;
> +#endif
> case 4:
> u32[i] = ival;
> break;
>
This now gives me:
drivers/base/regmap/regmap.c: In function 'regmap_bulk_read':
drivers/base/regmap/regmap.c:2584:10: warning: unused variable 'u64'
[-Wunused-variable]
u64 *u64 = val;
^
Arnd
--
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] misc: Introduce reboot_reason driver
On Tue, Dec 08, 2015 at 04:13:35PM -0800, John Stultz wrote:
> On Tue, Dec 8, 2015 at 1:52 PM, Arnd Bergmann wrote:
> >
> > On Tuesday 08 December 2015 13:29:22 John Stultz wrote:
> >
> > > diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > > b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > > index 5183d18..ee5dcb7 100644
> > > --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > > +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> > > @@ -282,6 +282,15 @@
> > > };
> > > };
> > >
> > > + reboot_reason: reboot_reason@2a03f65c {
> > > + compatible = "reboot_reason";
> >
> > This is not a good compatible string. There should generally be a vendor
> > name associated with it (use "linux," if nothing else, and you should have
> > '-' instead of '_'.
>
>
> Ack.
>
>
> >
> >
> > > + reg = <0x2A03F65C 0x4>;
> >
> > This may easily conflict with the device it is part of. We should have
> > non-overlapping register areas in general. For the example you are
> > looking at, which register block is this?
>
> So Bjorn says its IMEM, but I was assuming it was just a reserved
> magic phys addr from the bootloader.
>
> Ideally I'm hoping to use this same driver for another device, which
> plans to reserve a page from memory that the bootloader won't clear.
>
>
> > > +/* Types of reasons */
> > > +static enum {
> > > + NONE,
> > > + BOOTLOADER,
> > > + RECOVERY,
> > > + OEM,
> > > + MAX_REASONS
> > > +} __maybe_unused reason_types;
> >
> > The variable seems to always be unused, not just "__maybe_unused". Maybe
> > remove it?
>
>
> Yea. I initially just had the empty enum, but the compiler was giving
> me "useless class storage specifier in empty declaration" warnings. So
> I added a variable to it, but then I got unused variable warnings. So
> I ended up with this. :P
>
> Is there a better way? Are enums for array indexes out of fashion?
They are not, but you have declared a variable (reason_types) which you
don't use. You probably meant to create a enum named reason_types, like
this:
enum reason_types {
NONE,
BOOTLOADER,
RECOVERY,
OEM,
MAX_REASONS
};
Sascha
--
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: [PATCH] mfd: wm831x: fix broken wm831x_unique_id_show
On Sun, 06 Dec 2015, Rasmus Villemoes wrote:
> wm831x_unique_id_show currently displays an interesting pattern of '0'
> and '3' characters which isn't very useful (figuring out why is left
> as an exercise for the reader). Presumably "buf[i]" should have been
> "id[i] & 0xff".
>
> But while there, it is much simpler to simply use %phN and do all the
> formatting at once.
>
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/mfd/wm831x-otp.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/wm831x-otp.c b/drivers/mfd/wm831x-otp.c
> index b90f3e06b6c9..ebac0027f8e0 100644
> --- a/drivers/mfd/wm831x-otp.c
> +++ b/drivers/mfd/wm831x-otp.c
> @@ -47,20 +47,14 @@ static ssize_t wm831x_unique_id_show(struct device *dev,
>struct device_attribute *attr, char *buf)
> {
> struct wm831x *wm831x = dev_get_drvdata(dev);
> - int i, rval;
> + int rval;
> char id[WM831X_UNIQUE_ID_LEN];
> - ssize_t ret = 0;
>
> rval = wm831x_unique_id_read(wm831x, id);
> if (rval < 0)
> return 0;
>
> - for (i = 0; i < WM831X_UNIQUE_ID_LEN; i++)
> - ret += sprintf(&buf[ret], "%02x", buf[i]);
> -
> - ret += sprintf(&buf[ret], "\n");
> -
> - return ret;
> + return sprintf(buf, "%*phN\n", WM831X_UNIQUE_ID_LEN, id);
> }
>
> static DEVICE_ATTR(unique_id, 0444, wm831x_unique_id_show, NULL);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: [RFCv6 PATCH 09/10] sched: deadline: use deadline bandwidth in scale_rt_capacity
adding Lucas
On 9 December 2015 at 07:19, Steve Muckle wrote:
> From: Vincent Guittot
>
> Instead of monitoring the exec time of deadline tasks to evaluate the
> CPU capacity consumed by deadline scheduler class, we can directly
> calculate it thanks to the sum of utilization of deadline tasks on the
> CPU. We can remove deadline tasks from rt_avg metric and directly use
> the average bandwidth of deadline scheduler in scale_rt_capacity.
>
> Based in part on a similar patch from Luca Abeni .
>
> Signed-off-by: Vincent Guittot
> Signed-off-by: Steve Muckle
> ---
> kernel/sched/deadline.c | 33 +++--
> kernel/sched/fair.c | 8
> kernel/sched/sched.h| 2 ++
> 3 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 8b0a15e..9d9eb50 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -43,6 +43,24 @@ static inline int on_dl_rq(struct sched_dl_entity *dl_se)
> return !RB_EMPTY_NODE(&dl_se->rb_node);
> }
>
> +static void add_average_bw(struct sched_dl_entity *dl_se, struct dl_rq
> *dl_rq)
> +{
> + u64 se_bw = dl_se->dl_bw;
> +
> + dl_rq->avg_bw += se_bw;
> +}
> +
> +static void clear_average_bw(struct sched_dl_entity *dl_se, struct dl_rq
> *dl_rq)
> +{
> + u64 se_bw = dl_se->dl_bw;
> +
> + dl_rq->avg_bw -= se_bw;
> + if (dl_rq->avg_bw < 0) {
> + WARN_ON(1);
> + dl_rq->avg_bw = 0;
> + }
> +}
> +
> static inline int is_leftmost(struct task_struct *p, struct dl_rq *dl_rq)
> {
> struct sched_dl_entity *dl_se = &p->dl;
> @@ -494,6 +512,9 @@ static void update_dl_entity(struct sched_dl_entity
> *dl_se,
> struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
> struct rq *rq = rq_of_dl_rq(dl_rq);
>
> + if (dl_se->dl_new)
> + add_average_bw(dl_se, dl_rq);
> +
> /*
> * The arrival of a new instance needs special treatment, i.e.,
> * the actual scheduling parameters have to be "renewed".
> @@ -741,8 +762,6 @@ static void update_curr_dl(struct rq *rq)
> curr->se.exec_start = rq_clock_task(rq);
> cpuacct_charge(curr, delta_exec);
>
> - sched_rt_avg_update(rq, delta_exec);
> -
> dl_se->runtime -= dl_se->dl_yielded ? 0 : delta_exec;
> if (dl_runtime_exceeded(dl_se)) {
> dl_se->dl_throttled = 1;
> @@ -1241,6 +1260,8 @@ static void task_fork_dl(struct task_struct *p)
> static void task_dead_dl(struct task_struct *p)
> {
> struct dl_bw *dl_b = dl_bw_of(task_cpu(p));
> + struct dl_rq *dl_rq = dl_rq_of_se(&p->dl);
> + struct rq *rq = rq_of_dl_rq(dl_rq);
>
> /*
> * Since we are TASK_DEAD we won't slip out of the domain!
> @@ -1249,6 +1270,8 @@ static void task_dead_dl(struct task_struct *p)
> /* XXX we should retain the bw until 0-lag */
> dl_b->total_bw -= p->dl.dl_bw;
> raw_spin_unlock_irq(&dl_b->lock);
> +
> + clear_average_bw(&p->dl, &rq->dl);
> }
>
> static void set_curr_task_dl(struct rq *rq)
> @@ -1556,7 +1579,9 @@ retry:
> }
>
> deactivate_task(rq, next_task, 0);
> + clear_average_bw(&next_task->dl, &rq->dl);
> set_task_cpu(next_task, later_rq->cpu);
> + add_average_bw(&next_task->dl, &later_rq->dl);
> activate_task(later_rq, next_task, 0);
> ret = 1;
>
> @@ -1644,7 +1669,9 @@ static void pull_dl_task(struct rq *this_rq)
> resched = true;
>
> deactivate_task(src_rq, p, 0);
> + clear_average_bw(&p->dl, &src_rq->dl);
> set_task_cpu(p, this_cpu);
> + add_average_bw(&p->dl, &this_rq->dl);
> activate_task(this_rq, p, 0);
> dmin = p->dl.deadline;
>
> @@ -1750,6 +1777,8 @@ static void switched_from_dl(struct rq *rq, struct
> task_struct *p)
> if (!start_dl_timer(p))
> __dl_clear_params(p);
>
> + clear_average_bw(&p->dl, &rq->dl);
> +
> /*
> * Since this might be the only -deadline task on the rq,
> * this is the right place to try to pull some other one
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4c49f76..ce05f61 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6203,6 +6203,14 @@ static unsigned long scale_rt_capacity(int cpu)
>
> used = div_u64(avg, total);
>
> + /*
> +* deadline bandwidth is defined at system level so we must
> +* weight this bandwidth with the max capacity of the system.
> +* As a reminder, avg_bw is 20bits width and
> +* scale_cpu_capacity is 10 bits width
> +*/
> + used += div_u64(rq->dl.avg_bw, arch_scale_cpu_capacity(NULL, cpu));
> +
> if (likely(used < SCHED_CAPACITY_SCALE))
> return SCHED_CAPACITY_SCALE - used;
>
> di
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
Hi John,
Only a small comment
On Tue, Dec 08, 2015 at 01:29:22PM -0800, John Stultz wrote:
> +static int reboot_reason_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + u32 val;
> + int i;
> +
> + /* initialize the reasons */
> + for (i = 0; i < MAX_REASONS; i++)
> + reasons[i] = -1;
> +
> + /* Try to grab the reason io address */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reboot_reason_addr = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(reboot_reason_addr))
> + return PTR_ERR(reboot_reason_addr);
> +
> + /* initialize specified reasons from DT */
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", &val))
> + reasons[NONE] = val;
can be simplified to:
of_property_read_u32(pdev->dev.of_node, "reason,none", &reasons[NONE]);
No need to check first, &reasons[NONE] will only be modified when the
property exists.
Sascha
--
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: [RESEND RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3
Hi! On 2015-12-09 09:01, Ludovic Desroches wrote: > Hi Peter, > > On Tue, Dec 08, 2015 at 04:20:06AM +0100, Peter Rosin wrote: >> From: Peter Rosin >> >> Hi! >> >> I have a signal connected to a gpio pin which is the output of >> a comparator. By changing the level of one of the inputs to the >> comparator, I can detect the envelope of the other input to >> the comparator by using a series of measurements much in the >> same maner a manual ADC works, but watching for changes on the >> comparator over a period of time instead of only the immediate >> output. >> >> Now, the input signal to the comparator might have a high frequency, >> which will cause the output from the comparator (and thus the GPIO >> input) to change rapidly. >> >> A common(?) idiom for this is to use the interrupt status register >> to catch the glitches, but then not have any interrupt tied to >> the pin as that could possibly generate pointless bursts of >> (expensive) interrupts. >> > > Well I don't know if this use case as already been considered. I > understand you don't want to be overwhelmed by interrupts but why not > using the interrupt to start polling the PDSR (Pin Data Status > Register)? That scheme will not work for me. There might be only one short glitch, and there might be a flood. I need to catch both. What could be made to work is some kind of one-off interrupt thingy. I.e. an interrupt that disabled itself when hit (if that is possibly without lockup?). That could be a small generic driver not specific to gpio, I suppose, but where should such a beast live and what user space interface should it have? And while that is generic and will probably work in more cases, it seems complicated and quite a bit of a detour compared to simply reading the same info from a register. Are there really noone else using ISR type registers like this with Linux? In my mind that was pretty standard practice... > I am really not comfortable about exposing the ISR since there is a > clean on read. You have taken precautions by checking the IMR before but > if there is a single driver using a gpio as an irq, you will never get > the ISR. Yes, I'm aware of the limitation, but in my case that's not a problem, obviously. I have no (other) interrupt sources on the gpios covered by the ISR register in question. I take it that your major concern is the non-generality, i.e. that it is not possible to safely get at the ISR when there are interrupts enabled, and not the complication/overhead of the new lock? Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 9
Hello, On (12/09/15 18:19), Stephen Rothwell wrote: > > Changes since 20151208: > corrupts low memory: [ 60.459441] Corrupted low memory at 88001000 (1000 phys) = 0001 [ 60.459445] Corrupted low memory at 88001008 (1008 phys) = 81a816b8 [ 60.459446] Corrupted low memory at 88001020 (1020 phys) = 817e509f [ 60.459448] Corrupted low memory at 88001028 (1028 phys) = 880037962098 [ 60.459449] Corrupted low memory at 88001030 (1030 phys) = 8180ce74 [ 60.459450] Corrupted low memory at 88001038 (1038 phys) = 880037962d48 [ 60.459452] Corrupted low memory at 88001058 (1058 phys) = 01adad40 [ 60.459453] Corrupted low memory at 88001060 (1060 phys) = 81620b20 [ 60.459454] Corrupted low memory at 88001070 (1070 phys) = 1000 [ 60.459456] Corrupted low memory at 88001080 (1080 phys) = 81a816a0 [ 60.459457] Corrupted low memory at 88001088 (1088 phys) = 21eb81240152 [ 60.459458] Corrupted low memory at 88001098 (1098 phys) = 0001 [ 60.459459] Corrupted low memory at 880010a0 (10a0 phys) = 81a816e8 [ 60.459461] Corrupted low memory at 880010b8 (10b8 phys) = 817e509f [ 60.459462] Corrupted low memory at 880010c0 (10c0 phys) = 880037962098 [ 60.459463] Corrupted low memory at 880010c8 (10c8 phys) = 8180715d [ 60.459465] Corrupted low memory at 880010d0 (10d0 phys) = 880037962169 [ 60.459466] Corrupted low memory at 880010e0 (10e0 phys) = 88001168 [ 60.459467] Corrupted low memory at 880010f0 (10f0 phys) = 56a89f6d [ 60.459469] Corrupted low memory at 880010f8 (10f8 phys) = 81620b20 [ 60.459470] Corrupted low memory at 88001108 (1108 phys) = 1000 [ 60.459471] Corrupted low memory at 88001118 (1118 phys) = 81a816d0 [ 60.459473] Corrupted low memory at 88001120 (1120 phys) = 21ec81240152 [ 60.459474] Corrupted low memory at 88001130 (1130 phys) = 0001 [ 60.459475] Corrupted low memory at 88001138 (1138 phys) = 81a81718 [ 60.459476] Corrupted low memory at 88001150 (1150 phys) = 817e509f [ 60.459478] Corrupted low memory at 88001158 (1158 phys) = 880037962098 [ 60.459479] Corrupted low memory at 88001160 (1160 phys) = 81806d8f [ 60.459480] Corrupted low memory at 88001168 (1168 phys) = 880010d0 [ 60.459482] Corrupted low memory at 88001188 (1188 phys) = 5436156b [ 60.459483] Corrupted low memory at 88001190 (1190 phys) = 81620b20 [ 60.459484] Corrupted low memory at 880011a0 (11a0 phys) = 1000 [ 60.459486] Corrupted low memory at 880011b0 (11b0 phys) = 81a81700 [ 60.459487] Corrupted low memory at 880011b8 (11b8 phys) = 21ed81a40152 [ 60.459488] Corrupted low memory at 880011c8 (11c8 phys) = 0001 [ 60.459490] Corrupted low memory at 880011d0 (11d0 phys) = 81a81748 [ 60.459491] Corrupted low memory at 880011e8 (11e8 phys) = 817e509f [ 60.459492] Corrupted low memory at 880011f0 (11f0 phys) = 880037962098 [ 60.459494] Corrupted low memory at 880011f8 (11f8 phys) = 817d21d8 [ 60.459495] Corrupted low memory at 88001200 (1200 phys) = 88001298 [ 60.459496] Corrupted low memory at 88001220 (1220 phys) = 137e7407 [ 60.459498] Corrupted low memory at 88001228 (1228 phys) = 81620b20 [ 60.459499] Corrupted low memory at 88001238 (1238 phys) = 1000 [ 60.459500] Corrupted low memory at 88001248 (1248 phys) = 81a81730 [ 60.459501] Corrupted low memory at 88001250 (1250 phys) = 21ee81a40152 [ 60.459503] Corrupted low memory at 88001260 (1260 phys) = 0001 [ 60.459504] Corrupted low memory at 88001268 (1268 phys) = 81a81778 [ 60.459505] Corrupted low memory at 88001280 (1280 phys) = 817e509f [ 60.459507] Corrupted low memory at 88001288 (1288 phys) = 880037962098 [ 60.459508] Corrupted low memory at 88001290 (1290 phys) = 81807164 [ 60.459509] Corrupted low memory at 88001298 (1298 phys) = 880037962299 [ 60.459511] Corrupted low memory at 880012a0 (12a0 phys) = 880037962ae8 [ 60.459512] Corrupted low memory at 880012a8 (12a8 phys) = 88001200 [ 60.459513] Corrupted low memory at 880012b8 (12b8 phys) = 1ed682f4 [ 60.459515] Corrupted low memory at 880012c0 (12c0 phys) = 81620b20 [ 60.459516] Corrupted low memory at 880012d0 (12d0 phys) = 1000 [ 60.459517] Corrupted low memory at 880012e0 (12e0 phys) = 81a81760 [ 60.459518] Corrupted l
Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ?
On Dec 9, 2015 2:18 AM, "Thomas Gleixner" wrote: > > On Tue, 8 Dec 2015, Aniroop Mathur wrote: > > On Tue, Dec 8, 2015 at 4:18 PM, Thomas Gleixner wrote: > > > The initialization process is hardly something critical, so why would > > > the delay need to be precise? What's the point of having data 10ms > > > earlier? > > > > As I know, the chip initialisation process is critical. > > Consider the case for an android mobile phone. When the phone is > > resumed from suspend state, all the earlier enabled devices need to > > be re-initialised. Normally, we have two sleeps during device > > initialisation and we need to re-initialize more than 25 devices on > > board. So if single msleep delays by 10 ms, then the android phone > > resume is delayed by 10*2*25 = 500 ms, which is quite a big time. > > > > Also more importantly, during booting the phone as well, if every > > device sleeps for extra 20 ms and we have to probe 25 devices, > > booting is delayed by 500 ms. > > You are optimizing for something which is simply stupid. WHY do you > need to (re)initialize all devices before you can do something useful? > > Just because Android is implemented that way? That's silly. > > If you really care about boot time / user experience you initialize > only the really important drivers in the boot/resume process and > initialize the reset in the background. It does not matter whether the > temperatur app shows the updated value one second later or not, but it > matters for the user that the GUI is functional. > In case of android suspend, first lcd and touch turns off, then system devices are turned off. The same process I found in laptop as well. I could see clearly, first lcd went off and then wifi light was off, bluetooth light was off, mouse light was off. In resume, reverse process is followed in both. So LCD is turned on in last. In my opinion, this makes sense as we do not want user to use the gui or perform any operation untill the system is ready to operate. In case of booting, almost all devices are embedded in the android phone, so probe is called during booting. In every probe I have seen the prevention code of checking chipID or some other prevention code. For this, chip is powered on and initialized, next i2c operation is performed to read slave address. If slave address does not match or i2c operation fails, probe fails and chip is de-initialized. Also, if probe success, chip is de-initialized. So basically in probe, chip is always initialized and de-initialized finally. And in initialization part, we need to add delays. And so saving time in initialization part can save time of booting till home screen. > > My point is to use single consistent sleep api in driver code > > instead of two as we need to use it many places in a single driver > > code. This way, the code looks better. > > It's not about better. It's about using the right interfaces for the > right job. usleep_range() and msleep() use different facilities. As I > explained before: If you need a precise limit, use usleep_range(). If > not use msleep(). > Sure. I understand this part. However, my main concern is still incomplete. Could you please provide the answer to my earlier two queries: 1. If we choose usleep_range to acheive accuracy, are cpu and power usage of any concern? 2. If we use msleep(40), is it possible that process could wake up at 60 ms or 70 ms or 100 ms or more ? BR, Aniroop Mathur > Thanks, > > tglx
Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit
On Wednesday 09 December 2015 10:18:09 Peter Ujfalusi wrote: > Hi, > > Based on the discussion regarding to (convert am33xx to use the new eDMA > bindings): > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html > > This two patch will convert the new eDMA binding to not use 16bit arrays for > memcpy channel selection and for marking slots reserved. > The '/bits/ 16' seams to be causing confusion so it is probably better to just > use standard type for the arrays. > > The new bindings for the eDMA is introduced for 4.4 and we do not have users > of > it, which means that we can still change it w/o the risk of breaking anything > and we do not need to maintain the compatibility with 16bit arrays. > > The changes in the eDMA driver is local to the DT parsing and should not > conflict with other changes (like the filter function mapping support). Hrm, > there might be trivial conflict in the include/linux/platform_data/edma.h with > the "dmaengine 'universal' API". Both patches Acked-by: Arnd Bergmann > Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches > are > going to be handled? I would like to send the updated am33xx/am437x conversion > for 4.5 based on these changes. I'd suggest you send a pull request with these two patches on top of 4.4-rc1, and then either Vinod or I send it to Linus, and you base your other changes on top of the same branch. I think Vinod's tree is slightly more fitting for the 4.4 merge, but if he prefers me to take them instead, I will. Arnd -- 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] misc: Introduce reboot_reason driver
Hi John, On Tue, Dec 08, 2015 at 01:29:22PM -0800, John Stultz wrote: > This patch adds a basic driver to allow for commands like > "reboot bootloader" and "reboot recovery" to communicate this > reboot-reason to the bootloader. > > This is commonly done on Android devices, in order to reboot > the device into fastboot or recovery mode. It also supports > custom OEM specific commands, via "reboot oem-". > > This driver pulls the phys memory address from DT as well as > the magic reason values that are written to the address for > each mode. > > For an example, this patch also adds the DT support for > the nexus7 device via its dts (which is not yet upstream). > > Thoughts and feedback would be appreciated! I wonder if 'reason' is the correct word. This driver says nothing about the reason why we reboot, but more what we should do next. Maybe something like purpose, scope or intention is more appropriate? Sascha -- 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: [PATCH 1/8] mm: memcontrol: drop unused @css argument in memcg_init_kmem
On Tue, Dec 08, 2015 at 01:34:18PM -0500, Johannes Weiner wrote: > Signed-off-by: Johannes Weiner Acked-by: Vladimir Davydov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] regmap: add 64-bit mode support
On 09/12/2015 16:45, Arnd Bergmann wrote:
On Thursday 03 December 2015 17:31:52 Xiubo Li wrote:
@@ -2488,11 +2581,17 @@ int regmap_bulk_read(struct regmap *map, unsigned int
reg, void *val,
* we assume that the values are native
* endian.
*/
+ u64 *u64 = val;
u32 *u32 = val;
u16 *u16 = val;
u8 *u8 = val;
switch (map->format.val_bytes) {
+#ifdef CONFIG_64BIT
+ case 8:
+ u64[i] = ival;
+ break;
+#endif
case 4:
u32[i] = ival;
break;
This now gives me:
drivers/base/regmap/regmap.c: In function 'regmap_bulk_read':
drivers/base/regmap/regmap.c:2584:10: warning: unused variable 'u64'
[-Wunused-variable]
u64 *u64 = val;
^
I will fix this.
Thanks for your catch.
BRs
Arnd
--
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 v1 0/8] This serial of patches add dts/pinctrl/clock-tree/doc for rk3228
platform, with these patches, my evb board could boot into initramfs. Jeffy Chen (8): pinctrl: rockchip: add support for the rk3228 clk: rockchip: add dt-binding header for rk3228 rockchip: add clock controller for rk3228 dt-bindings: add documentation of rk3228 clock controller clk: rockchip: allow more than 2 parents for cpuclk ARM: rockchip: enable support for RK3228 SoCs ARM: dts: rockchip: add core rk3228 dtsi ARM: dts: rockchip: add rk3228-evb board .../bindings/clock/rockchip,rk3228-cru.txt | 58 ++ .../bindings/pinctrl/rockchip,pinctrl.txt | 3 +- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3228-evb.dts | 56 ++ arch/arm/boot/dts/rk3228.dtsi | 478 + arch/arm/mach-rockchip/rockchip.c | 1 + drivers/clk/rockchip/Makefile | 1 + drivers/clk/rockchip/clk-cpu.c | 4 +- drivers/clk/rockchip/clk-rk3228.c | 762 + drivers/clk/rockchip/clk.h | 11 +- drivers/pinctrl/pinctrl-rockchip.c | 53 ++ include/dt-bindings/clock/rk3228-cru.h | 220 ++ 12 files changed, 1644 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt create mode 100644 arch/arm/boot/dts/rk3228-evb.dts create mode 100644 arch/arm/boot/dts/rk3228.dtsi create mode 100644 drivers/clk/rockchip/clk-rk3228.c create mode 100644 include/dt-bindings/clock/rk3228-cru.h -- 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 v1 2/8] clk: rockchip: add dt-binding header for rk3228
Add the dt-bindings header for the rk3228, that gets shared between the clock controller and the clock references in the dts. Signed-off-by: Jeffy Chen --- include/dt-bindings/clock/rk3228-cru.h | 220 + 1 file changed, 220 insertions(+) create mode 100644 include/dt-bindings/clock/rk3228-cru.h diff --git a/include/dt-bindings/clock/rk3228-cru.h b/include/dt-bindings/clock/rk3228-cru.h new file mode 100644 index 000..a78dd89 --- /dev/null +++ b/include/dt-bindings/clock/rk3228-cru.h @@ -0,0 +1,220 @@ +/* + * Copyright (c) 2015 Rockchip Electronics Co. Ltd. + * Author: Jeffy Chen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * 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. + */ + +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3228_H +#define _DT_BINDINGS_CLK_ROCKCHIP_RK3228_H + +/* core clocks */ +#define PLL_APLL 1 +#define PLL_DPLL 2 +#define PLL_CPLL 3 +#define PLL_GPLL 4 +#define ARMCLK 5 + +/* sclk gates (special clocks) */ +#define SCLK_SPI0 65 +#define SCLK_NANDC 67 +#define SCLK_SDMMC 68 +#define SCLK_SDIO 69 +#define SCLK_EMMC 71 +#define SCLK_UART0 77 +#define SCLK_UART1 78 +#define SCLK_UART2 79 +#define SCLK_I2S0 80 +#define SCLK_I2S1 81 +#define SCLK_I2S2 82 +#define SCLK_SPDIF 83 +#define SCLK_TIMER085 +#define SCLK_TIMER186 +#define SCLK_TIMER287 +#define SCLK_TIMER388 +#define SCLK_TIMER489 +#define SCLK_TIMER590 +#define SCLK_I2S_OUT 113 +#define SCLK_SDMMC_DRV 114 +#define SCLK_SDIO_DRV 115 +#define SCLK_EMMC_DRV 117 +#define SCLK_SDMMC_SAMPLE 118 +#define SCLK_SDIO_SAMPLE 119 +#define SCLK_EMMC_SAMPLE 121 + +/* aclk gates */ +#define ACLK_DMAC 194 +#define ACLK_PERI 210 + +/* pclk gates */ +#define PCLK_GPIO0 320 +#define PCLK_GPIO1 321 +#define PCLK_GPIO2 322 +#define PCLK_GPIO3 323 +#define PCLK_GRF 329 +#define PCLK_I2C0 332 +#define PCLK_I2C1 333 +#define PCLK_I2C2 334 +#define PCLK_I2C3 335 +#define PCLK_SPI0 338 +#define PCLK_UART0 341 +#define PCLK_UART1 342 +#define PCLK_UART2 343 +#define PCLK_PWM 350 +#define PCLK_TIMER 353 +#define PCLK_PERI 363 + +/* hclk gates */ +#define HCLK_NANDC 453 +#define HCLK_SDMMC 456 +#define HCLK_SDIO 457 +#define HCLK_EMMC 459 +#define HCLK_PERI 478 + +#define CLK_NR_CLKS(HCLK_PERI + 1) + +/* soft-reset indices */ +#define SRST_CORE0_PO 0 +#define SRST_CORE1_PO 1 +#define SRST_CORE2_PO 2 +#define SRST_CORE3_PO 3 +#define SRST_CORE0 4 +#define SRST_CORE1 5 +#define SRST_CORE2 6 +#define SRST_CORE3 7 +#define SRST_CORE0_DBG 8 +#define SRST_CORE1_DBG 9 +#define SRST_CORE2_DBG 10 +#define SRST_CORE3_DBG 11 +#define SRST_TOPDBG12 +#define SRST_ACLK_CORE 13 +#define SRST_NOC 14 +#define SRST_L2C 15 + +#define SRST_CPUSYS_H 18 +#define SRST_BUSSYS_H 19 +#define SRST_SPDIF 20 +#define SRST_INTMEM21 +#define SRST_ROM 22 +#define SRST_OTG_ADP 23 +#define SRST_I2S0 24 +#define SRST_I2S1 25 +#define SRST_I2S2 26 +#define SRST_ACODEC_P 27 +#define SRST_DFIMON28 +#define SRST_MSCH 29 +#define SRST_EFUSE1024 30 +#define SRST_EFUSE256 31 + +#define SRST_GPIO0 32 +#define SRST_GPIO1 33 +#define SRST_GPIO2 34 +#define SRST_GPIO3 35 +#define SRST_PERIPH_NOC_A 36 +#define SRST_PERIPH_NOC_BUS_H 37 +#define SRST_PERIPH_NOC_P 38 +#define SRST_UART0 39 +#define SRST_UART1 40 +#define SRST_UART2 41 +#define SRST_PHYNOC42 +#define SRST_I2C0 43 +#define SRST_I2C1 44 +#define SRST_I2C2 45 +#define SRST_I2C3 46 + +#define SRST_PWM 48 +#define SRST_A53_GIC 49 +#define SRST_DAP 51 +#define
Re: [PATCH 2/8] mm: memcontrol: remove double kmem page_counter init
On Tue, Dec 08, 2015 at 01:34:19PM -0500, Johannes Weiner wrote: > The kmem page_counter's limit is initialized to PAGE_COUNTER_MAX > inside mem_cgroup_css_online(). There is no need to repeat this > from memcg_propagate_kmem(). > > Signed-off-by: Johannes Weiner Acked-by: Vladimir Davydov -- 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: use-after-free in __perf_install_in_context
On Tue, Dec 08, 2015 at 07:57:38PM +0100, Ingo Molnar wrote: > Btw., could we add more redundancy / debug code to the refcounting code? It > seems > to be a frequent source of very hard to find/fix races/bugs - so it should be > ripe > for some extra debug infrastructure ... I'll try, but its not easy. The biggest problem so far is the ctx::parent relation. We cannot easily track the reverse of that because of locking (we'd need to hold two ctx->lock, and we cannot because perf_event_context_sched_out()). The other two relations we have reverse maps for: task->perf_event_ctxp[] <-> ctx->task event->ctx <-> ctx->event_list Also, all 3 relations are (more or less) protected under ctx->lock: - unclone_ctx(): removes the ctx->parent link, with ctx->lock held - perf_remove_from_context(): removes the event from ctx::event_list, with ctx->lock held; leaves event->ctx set, because nasty games with ctx migration, it will get set to the new context, but can never be NULL. - perf_event_exit_task_context(): clears task->perf_event_ctxp[], with ctx->lock held; leaves ctx->task set, still looking into 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/
[PATCH v1 6/8] ARM: rockchip: enable support for RK3228 SoCs
Add a rockchip,rk3228 compatible.
Signed-off-by: Jeffy Chen
---
arch/arm/mach-rockchip/rockchip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-rockchip/rockchip.c
b/arch/arm/mach-rockchip/rockchip.c
index 608b31c..0cd4313 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -92,6 +92,7 @@ static const char * const rockchip_board_dt_compat[] = {
"rockchip,rk3066a",
"rockchip,rk3066b",
"rockchip,rk3188",
+ "rockchip,rk3228",
"rockchip,rk3288",
NULL,
};
--
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 v1 7/8] ARM: dts: rockchip: add core rk3228 dtsi
Initial release for rk3228 shared dtsi.
Signed-off-by: Jeffy Chen
---
arch/arm/boot/dts/rk3228.dtsi | 478 ++
1 file changed, 478 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3228.dtsi
diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
new file mode 100644
index 000..d6b3e40
--- /dev/null
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -0,0 +1,478 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "rockchip,rk3228";
+
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x6000 0x4000>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@f00 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf00>;
+ resets = <&cru SRST_CORE0>;
+ operating-points = <
+ /* KHzuV */
+816000 100
+ >;
+ clock-latency = <4>;
+ clocks = <&cru ARMCLK>;
+ };
+
+ cpu1: cpu@f01 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf01>;
+ resets = <&cru SRST_CORE1>;
+ };
+
+ cpu2: cpu@f02 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf02>;
+ resets = <&cru SRST_CORE2>;
+ };
+
+ cpu3: cpu@f03 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf03>;
+ resets = <&cru SRST_CORE3>;
+ };
+ };
+
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma: pdma@110f {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x110f 0x4000>;
+ interrupts = ,
+;
+ #dma-cells = <1>;
+ clocks = <&cru ACLK_DMAC>;
+ clock-names = "apb_pclk";
+ };
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
[PATCH v1 8/8] ARM: dts: rockchip: add rk3228-evb board
Initial release for rk3228 sdk board.
Signed-off-by: Jeffy Chen
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3228-evb.dts | 56
2 files changed, 57 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3228-evb.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2d8b9e0..0223846 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -521,6 +521,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
rk3188-radxarock.dtb \
+ rk3228-evb.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
rk3288-firefly-beta.dtb \
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
new file mode 100644
index 000..eb4621a
--- /dev/null
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -0,0 +1,56 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3228.dtsi"
+
+/ {
+ model = "Rockchip RK3228 Evaluation board";
+ compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+};
+
+&emmc {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
--
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/
Re: [PATCH mmotm] memcg: Ignore partial THP when moving task
Dohh, forgot to git add after s@PageCoumpound@PageTransCompound@
Updated patch is below:
---
>From efff9d4696cbce6710827a8422a5b285bf9b8052 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Fri, 4 Dec 2015 08:30:22 +0100
Subject: [PATCH] memcg: Ignore partial THP when moving task
After "mm: rework mapcount accounting to enable 4k mapping of THPs"
it is possible to have a partial THP accessible via ptes. Memcg task
migration code is not prepared for this situation and uncharges the tail
page from the original memcg while the original THP is still charged via
the head page which is not mapped to the moved task. The page counter
of the origin memcg will underflow when the whole THP is uncharged later
on and lead to:
WARNING: CPU: 0 PID: 1340 at mm/page_counter.c:26
page_counter_cancel+0x34/0x40()
reported by Minchan Kim.
This patch prevents from the underflow by skipping any partial THP pages
in mem_cgroup_move_charge_pte_range. PageTransCompound is checked when
we do pte walk. This means that a process might leave a partial THP
behind in the original memcg if there is no other process mapping it via
pmd but this is considered acceptable because it shouldn't happen often
and this is not considered a memory leak because the original THP is
still accessible and reclaimable. Moreover the task migration has always
been racy and never guaranteed to move all pages.
Reported-by: Minchan Kim
Acked-by: Johannes Weiner
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 8
1 file changed, 8 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 79a29d564bff..4cecefa4a3b0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4895,6 +4895,14 @@ static int mem_cgroup_move_charge_pte_range(pmd_t *pmd,
switch (get_mctgt_type(vma, addr, ptent, &target)) {
case MC_TARGET_PAGE:
page = target.page;
+ /*
+* We can have a part of the split pmd here. Moving it
+* can be done but it would be too convoluted so simply
+* ignore such a partial THP and keep it in original
+* memcg. There should be somebody mapping the head.
+*/
+ if (PageTransCompound(page))
+ goto put;
if (isolate_lru_page(page))
goto put;
if (!mem_cgroup_move_account(page, false,
--
2.6.2
--
Michal Hocko
SUSE Labs
--
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 v1 5/8] clk: rockchip: allow more than 2 parents for cpuclk
RK3228's armclk has 3 parents, so allow cpuclk to have
more than 2 parents.
Signed-off-by: Jeffy Chen
---
drivers/clk/rockchip/clk-cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-cpu.c b/drivers/clk/rockchip/clk-cpu.c
index 330870a..d07374f 100644
--- a/drivers/clk/rockchip/clk-cpu.c
+++ b/drivers/clk/rockchip/clk-cpu.c
@@ -242,8 +242,8 @@ struct clk *rockchip_clk_register_cpuclk(const char *name,
struct clk *clk, *cclk;
int ret;
- if (num_parents != 2) {
- pr_err("%s: needs two parent clocks\n", __func__);
+ if (num_parents < 2) {
+ pr_err("%s: needs at least two parent clocks\n", __func__);
return ERR_PTR(-EINVAL);
}
--
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 v1 1/8] pinctrl: rockchip: add support for the rk3228
The pinctrl of rk3228 is much the same as rk3288's, but
without pmu.
Signed-off-by: Jeffy Chen
---
.../bindings/pinctrl/rockchip,pinctrl.txt | 3 +-
drivers/pinctrl/pinctrl-rockchip.c | 53 ++
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index 391ef4b..0cd701b 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -21,7 +21,8 @@ defined as gpio sub-nodes of the pinmux controller.
Required properties for iomux controller:
- compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
"rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
- "rockchip,rk3288-pinctrl", "rockchip,rk3368-pinctrl"
+ "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
+ "rockchip,rk3368-pinctrl"
- rockchip,grf: phandle referencing a syscon providing the
"general register files"
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index a065112..faab36e 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -614,6 +614,40 @@ static void rk3288_calc_drv_reg_and_bit(struct
rockchip_pin_bank *bank,
}
}
+#define RK3228_PULL_OFFSET 0x100
+
+static void rk3228_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
+ int pin_num, struct regmap **regmap,
+ int *reg, u8 *bit)
+{
+ struct rockchip_pinctrl *info = bank->drvdata;
+
+ *regmap = info->regmap_base;
+ *reg = RK3228_PULL_OFFSET;
+ *reg += bank->bank_num * RK3188_PULL_BANK_STRIDE;
+ *reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
+
+ *bit = (pin_num % RK3188_PULL_PINS_PER_REG);
+ *bit *= RK3188_PULL_BITS_PER_PIN;
+}
+
+#define RK3228_DRV_GRF_OFFSET 0x200
+
+static void rk3228_calc_drv_reg_and_bit(struct rockchip_pin_bank *bank,
+ int pin_num, struct regmap **regmap,
+ int *reg, u8 *bit)
+{
+ struct rockchip_pinctrl *info = bank->drvdata;
+
+ *regmap = info->regmap_base;
+ *reg = RK3228_DRV_GRF_OFFSET;
+ *reg += bank->bank_num * RK3288_DRV_BANK_STRIDE;
+ *reg += ((pin_num / RK3288_DRV_PINS_PER_REG) * 4);
+
+ *bit = (pin_num % RK3288_DRV_PINS_PER_REG);
+ *bit *= RK3288_DRV_BITS_PER_PIN;
+}
+
#define RK3368_PULL_GRF_OFFSET 0x100
#define RK3368_PULL_PMU_OFFSET 0x10
@@ -2143,6 +2177,23 @@ static struct rockchip_pin_ctrl rk3188_pin_ctrl = {
.pull_calc_reg = rk3188_calc_pull_reg_and_bit,
};
+static struct rockchip_pin_bank rk3228_pin_banks[] = {
+ PIN_BANK(0, 32, "gpio0"),
+ PIN_BANK(1, 32, "gpio1"),
+ PIN_BANK(2, 32, "gpio2"),
+ PIN_BANK(3, 32, "gpio3"),
+};
+
+static struct rockchip_pin_ctrl rk3228_pin_ctrl = {
+ .pin_banks = rk3228_pin_banks,
+ .nr_banks = ARRAY_SIZE(rk3228_pin_banks),
+ .label = "RK3228-GPIO",
+ .type = RK3288,
+ .grf_mux_offset = 0x0,
+ .pull_calc_reg = rk3228_calc_pull_reg_and_bit,
+ .drv_calc_reg = rk3228_calc_drv_reg_and_bit,
+};
+
static struct rockchip_pin_bank rk3288_pin_banks[] = {
PIN_BANK_IOMUX_FLAGS(0, 24, "gpio0", IOMUX_SOURCE_PMU,
IOMUX_SOURCE_PMU,
@@ -2220,6 +2271,8 @@ static const struct of_device_id
rockchip_pinctrl_dt_match[] = {
.data = (void *)&rk3066b_pin_ctrl },
{ .compatible = "rockchip,rk3188-pinctrl",
.data = (void *)&rk3188_pin_ctrl },
+ { .compatible = "rockchip,rk3228-pinctrl",
+ .data = (void *)&rk3228_pin_ctrl },
{ .compatible = "rockchip,rk3288-pinctrl",
.data = (void *)&rk3288_pin_ctrl },
{ .compatible = "rockchip,rk3368-pinctrl",
--
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 v1 3/8] rockchip: add clock controller for rk3228
Add the clock tree definition for the new rk3228 SoC.
Signed-off-by: Jeffy Chen
---
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-rk3228.c | 762 ++
drivers/clk/rockchip/clk.h| 11 +-
3 files changed, 773 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/rockchip/clk-rk3228.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index d599829..80b9a37 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -12,5 +12,6 @@ obj-$(CONFIG_RESET_CONTROLLER)+= softrst.o
obj-y += clk-rk3036.o
obj-y += clk-rk3188.o
+obj-y += clk-rk3228.o
obj-y += clk-rk3288.o
obj-y += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-rk3228.c
b/drivers/clk/rockchip/clk-rk3228.c
new file mode 100644
index 000..eb3701e
--- /dev/null
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -0,0 +1,762 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Heiko Stuebner
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Jeffy Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 "clk.h"
+
+#define RK3228_GRF_SOC_STATUS0 0x480
+
+enum rk3228_plls {
+ apll, dpll, cpll, gpll,
+};
+
+static struct rockchip_pll_rate_table rk3228_pll_rates[] = {
+ /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+ RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+ RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+ RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+ RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+ RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+ RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+ RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+ RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+ RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+ RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+ RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+ RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+ RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+ RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+ RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+ RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+ RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+ RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+ RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+ RK3036_PLL_RATE(11, 12, 550, 1, 1, 1, 0),
+ RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+ RK3036_PLL_RATE(10, 6, 500, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 98400, 1, 82, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 96000, 1, 80, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 93600, 1, 78, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 91200, 1, 76, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 9, 4, 300, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 88800, 1, 74, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 86400, 1, 72, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 84000, 1, 70, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 81600, 1, 68, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 8, 6, 400, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 7, 6, 350, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 69600, 1, 58, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 6, 1, 75, 3, 1, 1, 0),
+ RK3036_PLL_RATE( 59400, 2, 99, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 50400, 1, 63, 3, 1, 1, 0),
+ RK3036_PLL_RATE( 5, 6, 250, 2, 1, 1, 0),
+ RK3036_PLL_RATE( 40800, 1, 68, 2, 2, 1, 0),
+ RK3036_PLL_RATE( 31200, 1, 52, 2, 2, 1, 0),
+ RK3036_PLL_RATE( 21600, 1, 72, 4, 2, 1, 0),
+ RK3036_PLL_RATE( 9600, 1, 64, 4, 4, 1, 0),
+ { /* sentinel */ },
+};
+
+#define RK3228_DIV_CPU_MASK0x1f
+#define RK3228_DIV_CPU_SHIFT 8
+
+#define RK3228_DIV_PERI_MASK 0xf
+#define RK3228_DIV_PERI_SHIFT 0
+#define RK3228_DIV_ACLK_MASK 0x7
+#define RK3228_DIV_ACLK_SHIFT 4
+#define RK3228_DIV_HCLK_MASK 0x3
+#define RK3228_DIV_HCLK_SHIFT 8
+#define RK3228_DIV_PCLK_MASK 0x7
+#define RK3228_DIV_PCLK_SHIFT 12
+
+#define RK3228_CLKSEL1(_core_peri_div) \
+ {
\
+ .reg =
[PATCH v1 4/8] dt-bindings: add documentation of rk3228 clock controller
Add the devicetree binding for the cru on the rk3228 which quite similar
structured as previous clock controllers.
Signed-off-by: Jeffy Chen
---
.../bindings/clock/rockchip,rk3228-cru.txt | 58 ++
1 file changed, 58 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt
new file mode 100644
index 000..f323048
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt
@@ -0,0 +1,58 @@
+* Rockchip RK3228 Clock and Reset Unit
+
+The RK3228 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3228-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3228-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+ - "ext_hsadc" - external HSADC clock - optional
+ - "phy_50m_out" - output clock of the pll in the mac phy
+
+Example: Clock controller node:
+
+ cru: cru@2000 {
+ compatible = "rockchip,rk3228-cru";
+ reg = <0x2000 0x1000>;
+ rockchip,grf = <&grf>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@1011 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x1011 0x100>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART0>;
+ };
--
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/
Re: [PATCH 3/8] mm: memcontrol: give the kmem states more descriptive names
On Tue, Dec 08, 2015 at 01:34:20PM -0500, Johannes Weiner wrote: > On any given memcg, the kmem accounting feature has three separate > states: not initialized, structures allocated, and actively accounting > slab memory. These are represented through a combination of the > kmem_acct_activated and kmem_acct_active flags, which is confusing. > > Convert to a kmem_state enum with the states NONE, ALLOCATED, and > ONLINE. Then rename the functions to modify the state accordingly. > This follows the nomenclature of css object states more closely. > > Signed-off-by: Johannes Weiner Acked-by: Vladimir Davydov -- 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: [Questions] perf c2c: What's the current status of perf c2c?
On Wed, Dec 09, 2015 at 04:12:36PM +0800, Wangnan (F) wrote: > > > On 2015/12/9 16:04, Jiri Olsa wrote: > >On Wed, Dec 09, 2015 at 12:06:44PM +0800, Yunlong Song wrote: > >>Hi, Don, > >> I am interested in the perf c2c tool, which is introduced in: > >> http://lwn.net/Articles/588866/ > >>However, I found that this tool has not been applied to the mainline tree > >>of perf, Why? It was first > >>introduced in Feb. 2014. What's its current status now? Does it have a new > >>version or a repository > >>somewhere else? And does it support Haswell? > >hi, > >not sure Don made any progress on this field, but I'm having > >his c2c sources rebased current perf sources ATM. > > Do you have a git repository so we can fetch the > code of it? yes, but it makes my eyes bleed ;-) I have some hacks on top of Don's changes which I'm ashamed to share ATM let me kick it into some reasonable shape first jirka -- 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/8] mm: memcontrol: group kmem init and exit functions together
On Tue, Dec 08, 2015 at 01:34:21PM -0500, Johannes Weiner wrote: > Put all the related code to setup and teardown the kmem accounting > state into the same location. No functional change intended. > > Signed-off-by: Johannes Weiner Acked-by: Vladimir Davydov -- 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 v5 08/11] ARM: STi: Register CPUFreq device
On Tuesday 08 December 2015 14:32:01 Lee Jones wrote:
> @@ -161,3 +166,11 @@ struct smp_operations __initdata sti_smp_ops = {
> .smp_secondary_init = sti_secondary_init,
> .smp_boot_secondary = sti_boot_secondary,
> };
> +
> +/**
> + * CPUFreq Registration
> + */
> +void init_cpufreq(void)
> +{
> + platform_device_register_simple("sti-cpufreq", -1, NULL, 0);
> +}
>
Can you please do this under drivers/cpufreq somewhere?
I really don't want to any more of these in platform code. Requiring a
device to be created just to probe the driver is really silly.
Arnd
--
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: use-after-free in __perf_install_in_context
On Tue, Dec 8, 2015 at 8:56 PM, Alexei Starovoitov wrote: > On Tue, Dec 08, 2015 at 07:35:20PM +0100, Dmitry Vyukov wrote: >> On Tue, Dec 8, 2015 at 7:05 PM, Alexei Starovoitov >> wrote: >> > On Tue, Dec 08, 2015 at 06:56:23PM +0100, Dmitry Vyukov wrote: >> >> On Tue, Dec 8, 2015 at 6:54 PM, Alexei Starovoitov >> >> wrote: >> >> > On Tue, Dec 08, 2015 at 05:12:04PM +0100, Dmitry Vyukov wrote: >> >> >> On Tue, Dec 8, 2015 at 4:24 AM, Alexei Starovoitov >> >> >> wrote: >> >> >> > On Mon, Dec 07, 2015 at 05:09:21PM +0100, Dmitry Vyukov wrote: >> >> >> >> > So it would be _awesome_ if we could somehow extend this >> >> >> >> > callchain to >> >> >> >> > include the site that calls call_rcu(). >> >> >> >> >> >> >> >> We have a patch for KASAN in works that adds so-called stack depot >> >> >> >> which allows to map a stack trace onto uint32 id. Then we can plumb >> >> >> > >> >> >> > I was hacking something similar to categorize stack traces with u32 >> >> >> > id. >> >> >> > How are you planning to limit the number of such stack traces ? >> >> >> > and what is the interface for user space to get stack trace from an >> >> >> > id? >> >> >> >> >> >> >> >> >> We don't limit number of stack traces. Kernel does not seem to use >> >> >> data-driven recursion extensively, so there is limited number of >> >> >> stacks. Though, probably we will need to strip non-interrupt part for >> >> >> interrupt stacks, otherwise that can produce unbounded number of >> >> >> different stacks. >> >> >> There is no interface for user-space, it is used only inside of kernel >> >> >> to save stacks for memory blocks (rcu callbacks, thread pool items in >> >> >> the future). >> >> >> The design is based on what we successfully and extensively use in >> >> >> user-space sanitizers for years. Current code is here: >> >> >> https://github.com/ramosian-glider/kasan/commit/fb0eefd212366401ed5ad244233ef379a27bfb46 >> >> > >> >> > why did you pick approach to never free accumulated stacks? >> >> > That limits usability a lot, since once kasan starts using it only >> >> > reboot will free the memory. ouch. >> >> > what worked for user space doesn't work for kernel. >> >> >> >> >> >> Freeing and reusing will slow down and complicate code significantly. >> >> And it is not yet proved to be necessary. >> > >> > It's a joke, right? allocating kernel pages without ability to free?! >> >> >> The plan is to smash kernel much earlier than it will run out of memory. >> >> >> I think this scheme will work pretty well. >> I've counted 34403 calls to >> kmalloc/kfree/kmem_cache_alloc/kmem_cache_free in kernel. Multiply >> this by 2 to account for different stacks leading to the same >> malloc/free and assuming that we store 16-byte header and 20 4-byte >> frames, this gives us about 6MB. I can live with that. I can live with >> 60MB as well. > > so you're saying you want to add hundreds lines of code to the kernel only > to be used by kasan for this very specific and narrow use case > instead of designing generic 'stacktrace<->id' mechanism? > That's not how kernel operates. Every kernel developer must think about > code reuse. We cannot bloat kernel with unique hacks. We would happily share this code with other subsystems, or even better reuse an existing solutions. But to the best of my knowledge there is no such existing solution, and I still know basically nothing about what you were hacking, why and what are your requirements. Our requirements are: - map stack trace to 4-byte id - relatively memory efficient for storing of ~100K traces - the only performance-critical operation is mapping of an already existing stack (in particular no atomic RMW on this path) Non-requirements: - any user-space interface - removal of stack traces (they all will be reused in future) We plan to use in KASAN, KTSAN (already uses it), KMSAN. -- 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 v5 08/11] ARM: STi: Register CPUFreq device
On 09-12-15, 10:15, Arnd Bergmann wrote:
> On Tuesday 08 December 2015 14:32:01 Lee Jones wrote:
> > @@ -161,3 +166,11 @@ struct smp_operations __initdata sti_smp_ops = {
> > .smp_secondary_init = sti_secondary_init,
> > .smp_boot_secondary = sti_boot_secondary,
> > };
> > +
> > +/**
> > + * CPUFreq Registration
> > + */
> > +void init_cpufreq(void)
> > +{
> > + platform_device_register_simple("sti-cpufreq", -1, NULL, 0);
> > +}
> >
>
> Can you please do this under drivers/cpufreq somewhere?
>
> I really don't want to any more of these in platform code. Requiring a
> device to be created just to probe the driver is really silly.
He is actually creating two device right now..
- create sti-cpufreq device
- so that sti-cpufreq driver get probed
- And fix OPPs here first and then create cpufreq-dt device
- so that cpufreq-dt driver get probed
:)
I already recommended him that he can replace the first two points by
doing things from module_init() instead. And then create cpufreq-dt
device.
--
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 v5] clk: sunxi: Add CLK_OF_DECLARE support for sun8i-a23-apb0-clk driver
On Mon, Dec 07, 2015 at 09:46:24PM +0800, Chen-Yu Tsai wrote:
> On Mon, Dec 7, 2015 at 5:36 PM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Thu, Dec 03, 2015 at 03:05:30PM +0800, Chen-Yu Tsai wrote:
> >> The APBS clock on sun9i is the same as the APB0 clock on sun8i. With
> >> sun9i we are supporting the PRCM clocks by using CLK_OF_DECLARE,
> >> instead of through a PRCM mfd device and subdevices for each clock
> >> and reset control. As such we need a CLK_OF_DECLARE version of
> >> the sun8i-a23-apb0-clk driver.
> >>
> >> Also, build it for sun9i/A80, and not just for configurations with
> >> MFD_SUN6I_PRCM enabled.
> >>
> >> Signed-off-by: Chen-Yu Tsai
> >> ---
> >>
> >> Changes since v4:
> >>
> >> - Keep building clk-sun8i-apb0 for SUN6I_MFD_PRCM.
> >>
> >> - Add an error message and comment for when of_io_request_and_map()
> >> fails. of_io_request_and_map() merges a bunch of errors into -EINVAL,
> >> so this might not be the best approach. But I think having an error
> >> message when we know something is wrong (-EBUSY, -ENOMEM) is better.
> >>
> >> ---
> >> drivers/clk/sunxi/Makefile | 1 +
> >> drivers/clk/sunxi/clk-sun8i-apb0.c | 80
> >> --
> >> 2 files changed, 69 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> >> index 103efab05ca8..ccf21ba3b6b0 100644
> >> --- a/drivers/clk/sunxi/Makefile
> >> +++ b/drivers/clk/sunxi/Makefile
> >> @@ -15,6 +15,7 @@ obj-y += clk-sun9i-core.o
> >> obj-y += clk-sun9i-mmc.o
> >> obj-y += clk-usb.o
> >>
> >> +obj-$(CONFIG_MACH_SUN9I) += clk-sun8i-apb0.o
> >> obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
> >>
> >> obj-$(CONFIG_MFD_SUN6I_PRCM) += \
> >> diff --git a/drivers/clk/sunxi/clk-sun8i-apb0.c
> >> b/drivers/clk/sunxi/clk-sun8i-apb0.c
> >> index 7ae5d2c2cde1..7ba61103a6f5 100644
> >> --- a/drivers/clk/sunxi/clk-sun8i-apb0.c
> >> +++ b/drivers/clk/sunxi/clk-sun8i-apb0.c
> >> @@ -17,13 +17,77 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> +static struct clk *sun8i_a23_apb0_register(struct device_node *node,
> >> +void __iomem *reg)
> >> +{
> >> + const char *clk_name = node->name;
> >> + const char *clk_parent;
> >> + struct clk *clk;
> >> + int ret;
> >> +
> >> + clk_parent = of_clk_get_parent_name(node, 0);
> >> + if (!clk_parent)
> >> + return ERR_PTR(-EINVAL);
> >> +
> >> + of_property_read_string(node, "clock-output-names", &clk_name);
> >> +
> >> + /* The A23 APB0 clock is a standard 2 bit wide divider clock */
> >> + clk = clk_register_divider(NULL, clk_name, clk_parent, 0, reg,
> >> +0, 2, CLK_DIVIDER_POWER_OF_TWO, NULL);
> >> + if (IS_ERR(clk))
> >> + return clk;
> >> +
> >> + ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
> >> + if (ret)
> >> + goto err_unregister;
> >> +
> >> + return clk;
> >> +
> >> +err_unregister:
> >> + clk_unregister_divider(clk);
> >> +
> >> + return ERR_PTR(ret);
> >> +}
> >> +
> >> +static void sun8i_a23_apb0_setup(struct device_node *node)
> >> +{
> >> + void __iomem *reg;
> >> + struct resource res;
> >> + struct clk *clk;
> >> +
> >> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> >> + if (IS_ERR(reg)) {
> >> + /*
> >> + * This happens with clk nodes instantiated through mfd,
> >> + * as those do not have their resources assigned in the
> >> + * device tree. Do not print an error in this case.
> >> + */
> >> + if (PTR_ERR(reg) != -EINVAL)
> >> + pr_err("Could not get registers for a23-apb0-clk\n");
> >
> > This is not the only case you have to take into account.
> >
> > There's also the case when you have a regular clock (and by regular I
> > mean that is not in the PRCM) that will be probed by the
> > CLK_OF_DECLARE mechanism and then later by the device model.
> >
> > In such a case, the second of_io_request_and_map will fail, and you
> > will have an error returned that you do not ignore at the moment.
>
> Right. It will return -EBUSY. But ignoring it and returning 0 is telling
> the driver core that the device successfully binded. I think this is
> wrong.
Well, technically, it is already bound.
> Normal clocks should be in the "clocks" node, and wouldn't be probed a
> second time through the device model, would it? Am I missing something?
Hmmm, that's true.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH] regmap: fix the warning about unused variable
The variable 'u64 *u64' should be only visible on 64-BIT platform. Signed-off-by: Xiubo Li --- drivers/base/regmap/regmap.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index 1791180..a0d30a0 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -2581,7 +2581,9 @@ int regmap_bulk_read(struct regmap *map, unsigned int reg, void *val, * we assume that the values are native * endian. */ +#ifdef CONFIG_64BIT u64 *u64 = val; +#endif u32 *u32 = val; u16 *u16 = val; u8 *u8 = val; -- 1.8.3.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 v5] clk: sunxi: Add CLK_OF_DECLARE support for sun8i-a23-apb0-clk driver
On Thu, Dec 03, 2015 at 03:05:30PM +0800, Chen-Yu Tsai wrote: > The APBS clock on sun9i is the same as the APB0 clock on sun8i. With > sun9i we are supporting the PRCM clocks by using CLK_OF_DECLARE, > instead of through a PRCM mfd device and subdevices for each clock > and reset control. As such we need a CLK_OF_DECLARE version of > the sun8i-a23-apb0-clk driver. > > Also, build it for sun9i/A80, and not just for configurations with > MFD_SUN6I_PRCM enabled. > > Signed-off-by: Chen-Yu Tsai Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 5/8] mm: memcontrol: separate kmem code from legacy tcp accounting code
On Tue, Dec 08, 2015 at 01:34:22PM -0500, Johannes Weiner wrote: > The cgroup2 memory controller will include important in-kernel memory > consumers per default, including socket memory, but it will no longer > carry the historic tcp control interface. > > Separate the kmem state init from the tcp control interface init in > preparation for that. > > Signed-off-by: Johannes Weiner Acked-by: Vladimir Davydov -- 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: arRe: [PATCH net-next 2/2] net: hns: enet specisies a reference to dsaf (config and documents)
On 2015/12/7 17:40, Arnd Bergmann wrote:
> On Monday 07 December 2015 15:14:13 Yankejian wrote:
>> On 2015/12/6 6:19, Arnd Bergmann wrote:
>>> On Saturday 05 December 2015 14:10:56 yankejian wrote:
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
index 80411b2..ecacfa4 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
@@ -4,8 +4,6 @@ Required properties:
- compatible: should be "hisilicon,hns-dsaf-v1" or
"hisilicon,hns-dsaf-v2".
"hisilicon,hns-dsaf-v1" is for hip05.
"hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
-- dsa-name: dsa fabric name who provide this interface.
- should be "dsafX", X is the dsaf id.
- mode: dsa fabric mode string. only support one of dsaf modes like these:
"2port-64vf",
"6port-16rss",
@@ -26,9 +24,8 @@ Required properties:
Example:
-dsa: dsa@c700 {
+dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
- dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <&mbigen_dsa>;
reg = <0x0 0xC000 0x0 0x42
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
index 41d19be..e6a9d1c 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
@@ -4,8 +4,9 @@ Required properties:
- compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2".
"hisilicon,hns-nic-v1" is for hip05.
"hisilicon,hns-nic-v2" is for Hi1610 and Hi1612.
-- ae-name: accelerator name who provides this interface,
- is simply a name referring to the name of name in the accelerator node.
+- ae-handle: accelerator engine handle for hns,
+ specifies a reference to the associating hardware driver node.
+ see Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
- port-id: is the index of port provided by DSAF (the accelerator). DSAF
can
connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose.
They
are called debug ports.
@@ -41,7 +42,7 @@ Example:
>>> This looks like an incompatible change, as you add and remove
>>> required properties. Is there a way to support both the old and
>>> the new style?
>>>
>>> Arnd
>>>
>>> .
>> Hi Arnd,
>> Thanks for your suggestions. it must be set the same strings in dsaf node
>> and every enet node before.
>> it seems inappropriate. as Rob Herring 's suggestions,
>> that would solve associating
>> enet with a particular dsaf. so we discus the solution with Yisen Zhuang
>> .
>> we decide to use the new way instead of the old one.
> I agree the new form looks better than the original way, but I'm worried
> about the migration path. You don't explain in the patch description
> how you want to ensure that nothing breaks for existing systems.
>
> We generally try to avoid doing incompatible changes altogether and
> prefer to keep backwards compatibility, unless we can prove that no
> other systems exist that would get impacted by the change.
>
> Are you sure that nobody ships a DTB file for this hardware with their
> firmware that would now require an incompatible update which in turn
> breaks old kernels?
>
> Are you sure that there is no hardware using the same dsa hardware
> with out-of-tree dts files that need to make the same change but might
> not be aware of the change?
>
> Arnd
>
> .
hi Arnd.
thanks a lot for pointing it out.
It is great regret that this change breaks compatibility with old dtbs.
this is a new driver which is run on developing boards, and all the
clients' boards are developing boards. So we provide them a method to
update the firmware on the board, once we update the dtsi and kernel,
we require our clients to update the existed firmware and kernel.
Therefore, these changes is actually under control. Shall we treat this
by this way?
thanks very much.
--
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] IXGBE/VFIO: Add live migration support for SRIOV NIC
On 12/8/2015 1:12 AM, Alexander Duyck wrote: On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote: On 12/5/2015 1:07 AM, Alexander Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. That is a poor argument. I highly doubt Microsoft is interested in having to modify all of the drivers that will support direct assignment in order to support migration. They would likely request something similar to what I have in that they will want a way to do DMA tracking with minimal modification required to the drivers. This totally depends on the NIC or other devices' vendors and they should make decision to support migration or not. If yes, they would modify driver. Having to modify every driver that wants to support live migration is a bit much. In addition I don't see this being limited only to NIC devices. You can direct assign a number of different devices, your solution cannot be specific to NICs. We are also adding such migration support for QAT device and so our solution will not just be limit to NIC. Now just is the beginning. We can't limit user to only use Linux guest. So the migration feature should work for both Windows and Linux guest. If just target to call suspend/resume during migration, the feature will be meaningless. Most cases don't want to affect user during migration a lot and so the service down time is vital. Our target is to apply SRIOV NIC passthough to cloud service and NFV(network functions virtualization) projects which are sensitive to network performance and stability. From my opinion, We should give a change for device driver to implement itself migration job. Call suspend and resume callback in the driver if it doesn't care the performance during migration. The suspend/resume callback should be efficient in terms of time. After all we don't want the system to stall for a long period of time when it should be either running or asleep. Having it burn cycles in a power state limbo doesn't do anyone any good. If nothing else maybe it will help to push the vendors to speed up those functions which then benefit migration and the system sleep states. If we can benefit both migration and suspend, that would be wonderful. But migration and system pm is still different. Just for example, driver doesn't need to put device into deep D-status during migration and host can do this after migration while it's essential for system sleep. PCI configure space and interrupt config is emulated by Qemu and Qemu can migrate these configures to new machine. Driver doesn't need to deal with such thing. So I think migration still needs a different callback or different code path than device suspend/resume. Another concern is that we have to rework PM core ore PCI bus driver to call suspend/resume for passthrough devices during migration. This also blocks new feature works on the Windows. Also you keep assuming you can keep the device running while you do the migration and you can't. You are going to corrupt the memory if you do, and you have yet to provide any means to explain how you are going to solve that. The main problem is tracking DMA issue. I will repose my solution in the new thread for discussion. If not way to mark DMA page dirty when DMA is enabled, we have to stop DMA for a small time to do that at the last stage. Following is my idea to do DMA tracking. Inject event to VF driver after memory iterate stage and before stop VCPU and then VF driver marks dirty all using DMA memory. The new allocated pages also need to be marked dirty before stopping VCPU. All dirty memory in this time slot will be migrated until stop-and-copy stage. We also need to make sure to disable VF via clearing the bus master enable bit for VF before migrating these memory. The ordering of your explanation here doesn't quite work. What needs to happen is that you have to disable DMA and then mark the pages as dirty. What the disabling of the BME does is signal to the hypervisor that the device is now stopped. The ixgbevf_suspend call already supported by the driver is almost exactly what is needed to take care of something like this. This is why I hope to reserve a piece of space in the dma page to do dummy write. This can help to mark page dirty while not require to stop DMA and not race with DMA data. You can't and it will still race. What concerns me is that your patches and the document you referenced earlier show a considerable lack of understanding about how DMA and device drivers work. There is a reason why device drivers have so many memory barriers and the like in them. The fact is when you have CPU and a device both accessing memory things have to be done in a very specific order and you cannot violate that. If you have a contiguous block of memory you expect the device to write into you cannot just poke a hole in it. Such a situation
[PATCH 1/1] iio:adc128s052: add support for adc124s021
Signed-off-by: Oliver Stäbler
---
Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt | 4 ++--
drivers/iio/adc/Kconfig | 6 +++---
drivers/iio/adc/ti-adc128s052.c | 13 -
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt
b/Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt
index 15ca6b4..daa2b2c 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt
+++ b/Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt
@@ -1,7 +1,7 @@
-* Texas Instruments' ADC128S052 and ADC122S021 ADC chip
+* Texas Instruments' ADC128S052, ADC122S021 and ADC124S021 ADC chip
Required properties:
- - compatible: Should be "ti,adc128s052" or "ti,adc122s021"
+ - compatible: Should be "ti,adc128s052", "ti,adc122s021" or "ti,adc124s021"
- reg: spi chip select number for the device
- vref-supply: The regulator supply for ADC reference voltage
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7868c74..351bd11 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -324,11 +324,11 @@ config TI_ADC081C
called ti-adc081c.
config TI_ADC128S052
- tristate "Texas Instruments ADC128S052/ADC122S021"
+ tristate "Texas Instruments ADC128S052/ADC122S021/ADC124S021"
depends on SPI
help
- If you say yes here you get support for Texas Instruments ADC128S052
- and ADC122S021 chips.
+ If you say yes here you get support for Texas Instruments ADC128S052,
+ ADC122S021 and ADC124S021 chips.
This driver can also be built as a module. If so, the module will be
called ti-adc128s052.
diff --git a/drivers/iio/adc/ti-adc128s052.c b/drivers/iio/adc/ti-adc128s052.c
index ff6f7f6..bc58867 100644
--- a/drivers/iio/adc/ti-adc128s052.c
+++ b/drivers/iio/adc/ti-adc128s052.c
@@ -1,10 +1,11 @@
/*
* Copyright (C) 2014 Angelo Compagnucci
*
- * Driver for Texas Instruments' ADC128S052 and ADC122S021 ADC chip.
+ * Driver for Texas Instruments' ADC128S052, ADC122S021 and ADC124S021 ADC
chip.
* Datasheets can be found here:
* http://www.ti.com/lit/ds/symlink/adc128s052.pdf
* http://www.ti.com/lit/ds/symlink/adc122s021.pdf
+ * http://www.ti.com/lit/ds/symlink/adc124s021.pdf
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -114,9 +115,17 @@ static const struct iio_chan_spec adc122s021_channels[] = {
ADC128_VOLTAGE_CHANNEL(1),
};
+static const struct iio_chan_spec adc124s021_channels[] = {
+ ADC128_VOLTAGE_CHANNEL(0),
+ ADC128_VOLTAGE_CHANNEL(1),
+ ADC128_VOLTAGE_CHANNEL(2),
+ ADC128_VOLTAGE_CHANNEL(3),
+};
+
static const struct adc128_configuration adc128_config[] = {
{ adc128s052_channels, ARRAY_SIZE(adc128s052_channels) },
{ adc122s021_channels, ARRAY_SIZE(adc122s021_channels) },
+ { adc124s021_channels, ARRAY_SIZE(adc124s021_channels) },
};
static const struct iio_info adc128_info = {
@@ -177,6 +186,7 @@ static int adc128_remove(struct spi_device *spi)
static const struct of_device_id adc128_of_match[] = {
{ .compatible = "ti,adc128s052", },
{ .compatible = "ti,adc122s021", },
+ { .compatible = "ti,adc124s021", },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, adc128_of_match);
@@ -184,6 +194,7 @@ MODULE_DEVICE_TABLE(of, adc128_of_match);
static const struct spi_device_id adc128_id[] = {
{ "adc128s052", 0}, /* index into adc128_config */
{ "adc122s021", 1},
+ { "adc124s021", 2},
{ }
};
MODULE_DEVICE_TABLE(spi, adc128_id);
--
2.4.10
--
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/1] iio:adc128s052: add support for adc124s021
This trivial patch adds support for adc124s021, which is a 4-channel version of the already supported ADC chips. Built against v4.4-rc4 Oliver Stäbler (1): iio:adc128s052: add support for adc124s021 Documentation/devicetree/bindings/iio/adc/ti-adc128s052.txt | 4 ++-- drivers/iio/adc/Kconfig | 6 +++--- drivers/iio/adc/ti-adc128s052.c | 13 - 3 files changed, 17 insertions(+), 6 deletions(-) -- 2.4.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] mm: memcontrol: move kmem accounting code to CONFIG_MEMCG
On Tue, Dec 08, 2015 at 01:34:23PM -0500, Johannes Weiner wrote: > The cgroup2 memory controller will account important in-kernel memory > consumers per default. Move all necessary components to CONFIG_MEMCG. > > Signed-off-by: Johannes Weiner Acked-by: Vladimir Davydov -- 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: [Questions] perf c2c: What's the current status of perf c2c?
On Wed, Dec 09, 2015 at 09:04:40AM +0100, Jiri Olsa wrote:
> On Wed, Dec 09, 2015 at 12:06:44PM +0800, Yunlong Song wrote:
> > Hi, Don,
> > I am interested in the perf c2c tool, which is introduced in:
> > http://lwn.net/Articles/588866/
> > However, I found that this tool has not been applied to the mainline tree
> > of perf, Why? It was first
> > introduced in Feb. 2014. What's its current status now? Does it have a new
> > version or a repository
> > somewhere else? And does it support Haswell?
>
> hi,
> not sure Don made any progress on this field, but I'm having
> his c2c sources rebased current perf sources ATM.
>
> I changed the tool a little to run over new DATALA events
> added in Haswell (in addition to ldlat events) and it seems
> to work.
>
> the plan for me is to to use it some more to prove it's useful
> and kick it to be merged with perf at some point
So I never really liked the c2c tool because it was so narrowly
focussed, it only works on NUMA thingies IIRC.
I would much rather see a tool that uses PEBS events and does a dwarf
decode of the exact instruction's data reference -- without relying on
data address bits.
That is; suppose we measure LLC_MISS, even if we have a
data-address, as soon as its inside a dynamically allocated object,
you're lost.
However, since we have the exact instruction we can simply look at that.
Imagine something like:
struct foo {
int blah;
int val;
int array[];
};
struct bar {
struct foo *foo;
}
int foobar(struct bar *bar)
{
return bar->foo->val;
}
Which we can imagine could result in code like:
foobar:
mov (%rax), %rax# load bar::foo
mov (%rax,1,4), %rax# load foo::val
And DWARFs should know this, so by knowing the instruction we can know
which load missed the cache.
Once you have this information, you can use pahole like structure output
and heat colour them or whatnot. Bright red if you miss lots etc..
Now currently this is possible but a bit of work because the DWARF
annotations are not exactly following these data types, that is you
might need to decode previous instructions and infer some bits.
I think Stephane was working with GCC people to allow more/better DWARF
annotations and allow easier retrieval of this information.
Note: the proposed scheme still have some holes in, imagine trying to
load an array[] member like:
mov 8(%rax, %rcx, 4), %rcx
This would load the array element indexed by RCX into RCX, thereby
destroying the index. In this case knowing the data address you can
still compute the index if you also know RAX (which you get from the
PEBS register dump).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/9] Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings
Hi Rob, 2015-12-09 4:41 GMT+01:00 Rob Herring : > On Tue, Dec 08, 2015 at 01:45:04PM +0100, Maxime Coquelin wrote: >> Signed-off-by: Maxime Coquelin >> --- >> .../bindings/pinctrl/st,stm32-pinctrl.txt | 126 >> + >> 1 file changed, 126 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt >> >> diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt >> b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt >> new file mode 100644 >> index 000..7b4800c >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt >> @@ -0,0 +1,126 @@ >> +* STM32 GPIO and Pin Mux/Config controller >> + >> +STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config >> hardware >> +controller. It controls the input/output settings on the available pins and >> +also provides ability to multiplex and configure the output of various >> on-chip >> +controllers onto these pads. >> + >> +Pin controller node: >> +Required properies: >> + - compatible: value should be one of the following: >> + (a) "st,stm32f429-pinctrl" >> + - #address-cells: The value of this property must be 1 >> + - #size-cells : The value of this property must be 1 >> + - ranges: defines mapping between pin controller node (parent) to >> + gpio-bank node (children). >> + - pins-are-numbered: Specify the subnodes are using numbered pinmux to >> + specify pins. >> + >> +GPIO controller/bank node: >> +Required properties: >> + - gpio-controller : Indicates this device is a GPIO controller >> + - #gpio-cells : Should be two. >> + The first cell is the pin number >> + The second one is the polarity: >> + - 0 for active high >> + - 1 for active low >> + - reg : The gpio address range, relative to the pinctrl >> range >> + - clocks : clock that drives this bank >> + - st,bank-name: Should be a name string for this bank as specified >> in >> + the datasheet > > How do you intend to use this? We should come up with something generic > or drop it. Good point. It is used to have a meaningful name set in gpio_chip's label. I see two alternatives: 1. replace "st,bank-name" with label 2. use aliases, and construct label in driver with something like: kasprintf(GFP_KERNEL, "GPIO%c", 'A' + of_alias_get_id(np, "gpio")); What do you prefer? Do you have other ideas? Thanks, Maxime -- 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.16.y-ckt 001/126] irda: precedence bug in irlmp_seq_hb_idx()
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Dan Carpenter
commit 50010c20597d14667eff0fdb628309986f195230 upstream.
This is decrementing the pointer, instead of the value stored in the
pointer. KASan detects it as an out of bounds reference.
Reported-by: "Berry Cheng 程君(成淼)"
Signed-off-by: Dan Carpenter
Signed-off-by: David S. Miller
Signed-off-by: Luis Henriques
---
net/irda/irlmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/irda/irlmp.c b/net/irda/irlmp.c
index 98ad6ec4bd3c..8ad149478e19 100644
--- a/net/irda/irlmp.c
+++ b/net/irda/irlmp.c
@@ -1876,7 +1876,7 @@ static void *irlmp_seq_hb_idx(struct irlmp_iter_state
*iter, loff_t *off)
for (element = hashbin_get_first(iter->hashbin);
element != NULL;
element = hashbin_get_next(iter->hashbin)) {
- if (!off || *off-- == 0) {
+ if (!off || (*off)-- == 0) {
/* NB: hashbin left locked */
return element;
}
--
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.16.y-ckt 005/126] stmmac: Correctly report PTP capabilities.
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Phil Reid
commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 upstream.
priv->hwts_*_en indicate if timestamping is enabled/disabled at run
time. But priv->dma_cap.time_stamp and priv->dma_cap.atime_stamp
indicates HW is support for PTPv1/PTPv2.
Signed-off-by: Phil Reid
Acked-by: Richard Cochran
Signed-off-by: David S. Miller
Signed-off-by: Luis Henriques
---
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index c62e67f3c2f0..aa0480402c97 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -723,10 +723,13 @@ static int stmmac_get_ts_info(struct net_device *dev,
{
struct stmmac_priv *priv = netdev_priv(dev);
- if ((priv->hwts_tx_en) && (priv->hwts_rx_en)) {
+ if ((priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp)) {
- info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
+ info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE |
+ SOF_TIMESTAMPING_TX_HARDWARE |
+ SOF_TIMESTAMPING_RX_SOFTWARE |
SOF_TIMESTAMPING_RX_HARDWARE |
+ SOF_TIMESTAMPING_SOFTWARE |
SOF_TIMESTAMPING_RAW_HARDWARE;
if (priv->ptp_clock)
--
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.16.y-ckt 012/126] net: fix a race in dst_release()
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet
commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 upstream.
Only cpu seeing dst refcount going to 0 can safely
dereference dst->flags.
Otherwise an other cpu might already have freed the dst.
Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
Reported-by: Greg Thelen
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
---
net/core/dst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index a028409ee438..a80e92346b9b 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -285,7 +285,7 @@ void dst_release(struct dst_entry *dst)
newrefcnt = atomic_dec_return(&dst->__refcnt);
WARN_ON(newrefcnt < 0);
- if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt)
+ if (!newrefcnt && unlikely(dst->flags & DST_NOCACHE))
call_rcu(&dst->rcu_head, dst_destroy_rcu);
}
}
--
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.16.y-ckt 019/126] ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Marek Szyprowski
commit 371f0f085f629fc0f66695f572373ca4445a67ad upstream.
dma_mmap() function in IOMMU-based dma-mapping implementation lacked
a check for valid range of mmap parameters (offset and buffer size), what
might have caused access beyond the allocated buffer. This patch fixes
this issue.
Signed-off-by: Marek Szyprowski
Signed-off-by: Russell King
Signed-off-by: Luis Henriques
---
arch/arm/mm/dma-mapping.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0e09af35f69a..59336561d747 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1459,12 +1459,17 @@ static int arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma,
unsigned long uaddr = vma->vm_start;
unsigned long usize = vma->vm_end - vma->vm_start;
struct page **pages = __iommu_get_pages(cpu_addr, attrs);
+ unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ unsigned long off = vma->vm_pgoff;
vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
if (!pages)
return -ENXIO;
+ if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
+ return -ENXIO;
+
do {
int ret = vm_insert_page(vma, uaddr, *pages++);
if (ret) {
--
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.16.y-ckt 009/126] sit: fix sit0 percpu double allocations
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet
commit 4ece9009774596ee3df0acba65a324b7ea79387c upstream.
sit0 device allocates its percpu storage twice :
- One time in ipip6_tunnel_init()
- One time in ipip6_fb_tunnel_init()
Thus we leak 48 bytes per possible cpu per network namespace dismantle.
ipip6_fb_tunnel_init() can be much simpler and does not
return an error, and should be called after register_netdev()
Note that ipip6_tunnel_clone_6rd() also needs to be called
after register_netdev() (calling ipip6_tunnel_init())
Fixes: ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.")
Signed-off-by: Eric Dumazet
Reported-by: Dmitry Vyukov
Cc: Steffen Klassert
Signed-off-by: David S. Miller
Signed-off-by: Luis Henriques
---
net/ipv6/sit.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 051e9c508933..b5bdd2aeb2f8 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1374,34 +1374,20 @@ static int ipip6_tunnel_init(struct net_device *dev)
return 0;
}
-static int __net_init ipip6_fb_tunnel_init(struct net_device *dev)
+static void __net_init ipip6_fb_tunnel_init(struct net_device *dev)
{
struct ip_tunnel *tunnel = netdev_priv(dev);
struct iphdr *iph = &tunnel->parms.iph;
struct net *net = dev_net(dev);
struct sit_net *sitn = net_generic(net, sit_net_id);
- tunnel->dev = dev;
- tunnel->net = dev_net(dev);
-
iph->version= 4;
iph->protocol = IPPROTO_IPV6;
iph->ihl= 5;
iph->ttl= 64;
- dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
- if (!dev->tstats)
- return -ENOMEM;
-
- tunnel->dst_cache = alloc_percpu(struct ip_tunnel_dst);
- if (!tunnel->dst_cache) {
- free_percpu(dev->tstats);
- return -ENOMEM;
- }
-
dev_hold(dev);
rcu_assign_pointer(sitn->tunnels_wc[0], tunnel);
- return 0;
}
static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -1738,23 +1724,18 @@ static int __net_init sit_init_net(struct net *net)
*/
sitn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
- err = ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
- if (err)
- goto err_dev_free;
-
- ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
-
if ((err = register_netdev(sitn->fb_tunnel_dev)))
goto err_reg_dev;
+ ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
+ ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
+
t = netdev_priv(sitn->fb_tunnel_dev);
strcpy(t->parms.name, sitn->fb_tunnel_dev->name);
return 0;
err_reg_dev:
- dev_put(sitn->fb_tunnel_dev);
-err_dev_free:
ipip6_dev_free(sitn->fb_tunnel_dev);
err_alloc_dev:
return err;
--
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.16.y-ckt 013/126] Failing to send a CLOSE if file is opened WRONLY and server reboots on a 4.x mount
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me know. -- From: Olga Kornievskaia commit a41cbe86df3afbc82311a1640e20858c0cd7e065 upstream. A test case is as the description says: open(foobar, O_WRONLY); sleep() --> reboot the server close(foobar) The bug is because in nfs4state.c in nfs4_reclaim_open_state() a few line before going to restart, there is clear_bit(NFS4CLNT_RECLAIM_NOGRACE, &state->flags). NFS4CLNT_RECLAIM_NOGRACE is a flag for the client states not open owner states. Value of NFS4CLNT_RECLAIM_NOGRACE is 4 which is the value of NFS_O_WRONLY_STATE in nfs4_state->flags. So clearing it wipes out state and when we go to close it, “call_close” doesn’t get set as state flag is not set and CLOSE doesn’t go on the wire. Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Cc: Ben Hutchings Signed-off-by: Luis Henriques --- fs/nfs/nfs4state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index 46d876487795..577bb8d849f7 100644 --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1482,7 +1482,7 @@ restart: spin_unlock(&state->state_lock); } nfs4_put_open_state(state); - clear_bit(NFS4CLNT_RECLAIM_NOGRACE, + clear_bit(NFS_STATE_RECLAIM_NOGRACE, &state->flags); spin_lock(&sp->so_lock); goto restart; -- 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.16.y-ckt 045/126] KVM: s390: SCA must not cross page boundaries
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: David Hildenbrand
commit c5c2c393468576bad6d10b2b5fefff8cd25df3f4 upstream.
We seemed to have missed a few corner cases in commit f6c137ff00a4
("KVM: s390: randomize sca address").
The SCA has a maximum size of 2112 bytes. By setting the sca_offset to
some unlucky numbers, we exceed the page.
0x7c0 (1984) -> Fits exactly
0x7d0 (2000) -> 16 bytes out
0x7e0 (2016) -> 32 bytes out
0x7f0 (2032) -> 48 bytes out
One VCPU entry is 32 bytes long.
For the last two cases, we actually write data to the other page.
1. The address of the VCPU.
2. Injection/delivery/clearing of SIGP externall calls via SIGP IF.
Especially the 2. happens regularly. So this could produce two problems:
1. The guest losing/getting external calls.
2. Random memory overwrites in the host.
So this problem happens on every 127 + 128 created VM with 64 VCPUs.
Acked-by: Christian Borntraeger
Signed-off-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
Signed-off-by: Luis Henriques
---
arch/s390/kvm/kvm-s390.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 5e9217d96cfe..fd8a8373c275 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -429,7 +429,9 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
if (!kvm->arch.sca)
goto out_err;
spin_lock(&kvm_lock);
- sca_offset = (sca_offset + 16) & 0x7f0;
+ sca_offset += 16;
+ if (sca_offset + sizeof(struct sca_block) > PAGE_SIZE)
+ sca_offset = 0;
kvm->arch.sca = (struct sca_block *) ((char *) kvm->arch.sca +
sca_offset);
spin_unlock(&kvm_lock);
--
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.16.y-ckt 033/126] spi: dw: explicitly free IRQ handler in dw_spi_remove_host()
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Andy Shevchenko
commit 02f20387e1bca550639c37b1945f20cd32ddfcce upstream.
The following warning occurs when DW SPI is compiled as a module and it's a PCI
device. On the removal stage pcibios_free_irq() is called earlier than
free_irq() due to the latter is called at managed resources free strage.
[ cut here ]
WARNING: CPU: 1 PID: 1003 at /home/andy/prj/linux/fs/proc/generic.c:575
remove_proc_entry+0x118/0x150()
remove_proc_entry: removing non-empty directory 'irq/38', leaking at least
'dw_spi1'
Modules linked in: spi_dw_midpci(-) spi_dw [last unloaded: dw_dmac_core]
CPU: 1 PID: 1003 Comm: modprobe Not tainted 4.3.0-rc5-next-20151013+ #32
f5535d70 c12dc220 f5535db0 f5535da0 c104e912 c198a6bc
f5535dcc 03eb c198a638 023f c11b4098 c11b4098 f54f1ec8 f54f1ea0
f642ba20 f5535db8 c104e96e 0009 f5535db0 c198a6bc f5535dcc f5535df0
Call Trace:
[] dump_stack+0x41/0x61
[] warn_slowpath_common+0x82/0xb0
[] ? remove_proc_entry+0x118/0x150
[] ? remove_proc_entry+0x118/0x150
[] warn_slowpath_fmt+0x2e/0x30
[] remove_proc_entry+0x118/0x150
[] unregister_irq_proc+0xaa/0xc0
[] free_desc+0x1e/0x60
[] irq_free_descs+0x32/0x70
[] irq_domain_free_irqs+0x120/0x150
[] mp_unmap_irq+0x5c/0x60
[] intel_mid_pci_irq_disable+0x20/0x40
[] pcibios_free_irq+0xf/0x20
[] pci_device_remove+0x52/0xb0
[] __device_release_driver+0x77/0x100
[] driver_detach+0x87/0x90
[] bus_remove_driver+0x4a/0xc0
[] ? selinux_capable+0xd/0x10
[] driver_unregister+0x23/0x60
[] ? find_module_all+0x5a/0x80
[] pci_unregister_driver+0x13/0x60
[] dw_spi_driver_exit+0xd/0xf [spi_dw_midpci]
[] SyS_delete_module+0x17a/0x210
Explicitly call free_irq() at removal stage of the DW SPI driver.
Fixes: 04f421e7b0b1 (spi: dw: use managed resources)
Signed-off-by: Andy Shevchenko
Signed-off-by: Mark Brown
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
---
drivers/spi/spi-dw.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 4fc4c20893e1..66e9e5196c8c 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -652,8 +652,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
snprintf(dws->name, sizeof(dws->name), "dw_spi%d",
dws->bus_num);
- ret = devm_request_irq(dev, dws->irq, dw_spi_irq, IRQF_SHARED,
- dws->name, dws);
+ ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED, dws->name, dws);
if (ret < 0) {
dev_err(&master->dev, "can not get IRQ\n");
goto err_free_master;
@@ -695,6 +694,7 @@ err_dma_exit:
if (dws->dma_ops && dws->dma_ops->dma_exit)
dws->dma_ops->dma_exit(dws);
spi_enable_chip(dws, 0);
+ free_irq(dws->irq, master);
err_free_master:
spi_master_put(master);
return ret;
@@ -712,6 +712,8 @@ void dw_spi_remove_host(struct dw_spi *dws)
spi_enable_chip(dws, 0);
/* Disable clk */
spi_set_clk(dws, 0);
+
+ free_irq(dws->irq, dws->master);
}
EXPORT_SYMBOL_GPL(dw_spi_remove_host);
--
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.16.y-ckt 053/126] megaraid_sas : SMAP restriction--do not access user memory from IOCTL code
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: "sumit.sax...@avagotech.com"
commit 323c4a02c631d00851d8edc4213c4d184ef83647 upstream.
This is an issue on SMAP enabled CPUs and 32 bit apps running on 64 bit
OS. Do not access user memory from kernel code. The SMAP bit restricts
accessing user memory from kernel code.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
Reviewed-by: Tomas Henzl
Signed-off-by: Martin K. Petersen
Signed-off-by: Luis Henriques
---
drivers/scsi/megaraid/megaraid_sas_base.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 9f5f61c00b61..acecd7de4ea1 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5812,6 +5812,9 @@ static int megasas_mgmt_compat_ioctl_fw(struct file
*file, unsigned long arg)
int i;
int error = 0;
compat_uptr_t ptr;
+ unsigned long local_raw_ptr;
+ u32 local_sense_off;
+ u32 local_sense_len;
if (clear_user(ioc, sizeof(*ioc)))
return -EFAULT;
@@ -5829,9 +5832,15 @@ static int megasas_mgmt_compat_ioctl_fw(struct file
*file, unsigned long arg)
* sense_len is not null, so prepare the 64bit value under
* the same condition.
*/
- if (ioc->sense_len) {
+ if (get_user(local_raw_ptr, ioc->frame.raw) ||
+ get_user(local_sense_off, &ioc->sense_off) ||
+ get_user(local_sense_len, &ioc->sense_len))
+ return -EFAULT;
+
+
+ if (local_sense_len) {
void __user **sense_ioc_ptr =
- (void __user **)(ioc->frame.raw + ioc->sense_off);
+ (void __user **)((u8*)local_raw_ptr + local_sense_off);
compat_uptr_t *sense_cioc_ptr =
(compat_uptr_t *)(cioc->frame.raw + cioc->sense_off);
if (get_user(ptr, sense_cioc_ptr) ||
--
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.16.y-ckt 051/126] crypto: algif_hash - Only export and import on sockets with data
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Herbert Xu
commit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream.
The hash_accept call fails to work on sockets that have not received
any data. For some algorithm implementations it may cause crashes.
This patch fixes this by ensuring that we only export and import on
sockets that have received data.
Reported-by: Harsh Jain
Signed-off-by: Herbert Xu
Tested-by: Stephan Mueller
Signed-off-by: Luis Henriques
---
crypto/algif_hash.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 850246206b12..a68b56a368a8 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -192,9 +192,14 @@ static int hash_accept(struct socket *sock, struct socket
*newsock, int flags)
struct sock *sk2;
struct alg_sock *ask2;
struct hash_ctx *ctx2;
+ bool more;
int err;
- err = crypto_ahash_export(req, state);
+ lock_sock(sk);
+ more = ctx->more;
+ err = more ? crypto_ahash_export(req, state) : 0;
+ release_sock(sk);
+
if (err)
return err;
@@ -205,7 +210,10 @@ static int hash_accept(struct socket *sock, struct socket
*newsock, int flags)
sk2 = newsock->sk;
ask2 = alg_sk(sk2);
ctx2 = ask2->private;
- ctx2->more = 1;
+ ctx2->more = more;
+
+ if (!more)
+ return err;
err = crypto_ahash_import(&ctx2->req, state);
if (err) {
--
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.16.y-ckt 041/126] ACPI: Use correct IRQ when uninstalling ACPI interrupt handler
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Chen Yu
commit 49e4b84333f338d4f183f28f1f3c1131b9fb2b5a upstream.
Currently when the system is trying to uninstall the ACPI interrupt
handler, it uses acpi_gbl_FADT.sci_interrupt as the IRQ number.
However, the IRQ number that the ACPI interrupt handled is installed
for comes from acpi_gsi_to_irq() and that is the number that should
be used for the handler removal.
Fix this problem by using the mapped IRQ returned from acpi_gsi_to_irq()
as appropriate.
Acked-by: Lv Zheng
Signed-off-by: Chen Yu
Signed-off-by: Rafael J. Wysocki
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
---
drivers/acpi/osl.c | 9 ++---
include/linux/acpi.h | 6 ++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 5e240a479b71..9fb0e4fd6ac0 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -83,6 +83,7 @@ static void *acpi_irq_context;
static struct workqueue_struct *kacpid_wq;
static struct workqueue_struct *kacpi_notify_wq;
static struct workqueue_struct *kacpi_hotplug_wq;
+unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
/*
* This list of permanent mappings is for memory that may be accessed from
@@ -828,17 +829,19 @@ acpi_os_install_interrupt_handler(u32 gsi,
acpi_osd_handler handler,
acpi_irq_handler = NULL;
return AE_NOT_ACQUIRED;
}
+ acpi_sci_irq = irq;
return AE_OK;
}
-acpi_status acpi_os_remove_interrupt_handler(u32 irq, acpi_osd_handler handler)
+acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler)
{
- if (irq != acpi_gbl_FADT.sci_interrupt)
+ if (gsi != acpi_gbl_FADT.sci_interrupt || !acpi_sci_irq_valid())
return AE_BAD_PARAMETER;
- free_irq(irq, acpi_irq);
+ free_irq(acpi_sci_irq, acpi_irq);
acpi_irq_handler = NULL;
+ acpi_sci_irq = INVALID_ACPI_IRQ;
return AE_OK;
}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 3b18cb3d5307..7e52e670d6ad 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -151,6 +151,12 @@ int acpi_unregister_ioapic(acpi_handle handle, u32
gsi_base);
void acpi_irq_stats_init(void);
extern u32 acpi_irq_handled;
extern u32 acpi_irq_not_handled;
+extern unsigned int acpi_sci_irq;
+#define INVALID_ACPI_IRQ ((unsigned)-1)
+static inline bool acpi_sci_irq_valid(void)
+{
+ return acpi_sci_irq != INVALID_ACPI_IRQ;
+}
extern int sbf_port;
extern unsigned long acpi_realmode_flags;
--
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.16.y-ckt 075/126] ideapad-laptop: Add Lenovo Yoga 900 to no_hw_rfkill dmi list
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Hans de Goede
commit f71c882dd4cfe4aa88ea07b1402ddd43605d4aef upstream.
Like some of the other Yoga models the Lenovo Yoga 900 does not have a
hw rfkill switch, and trying to read the hw rfkill switch through the
ideapad module causes it to always reported blocking breaking wifi.
This commit adds the Lenovo Yoga 900 to the no_hw_rfkill dmi list, fixing
the wifi breakage.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1275490
Reported-and-tested-by: Kevin Fenzi
Signed-off-by: Hans de Goede
Signed-off-by: Darren Hart
Signed-off-by: Luis Henriques
---
drivers/platform/x86/ideapad-laptop.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index cfc93618ebf1..964f83cc00c6 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -859,6 +859,13 @@ static struct dmi_system_id no_hw_rfkill_list[] = {
DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 3
Pro-1370"),
},
},
+ {
+ .ident = "Lenovo Yoga 900",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 900"),
+ },
+ },
{}
};
--
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.16.y-ckt 064/126] mm: slab: only move management objects off-slab for sizes larger than KMALLOC_MIN_SIZE
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Catalin Marinas
commit d4322d88f5fdf92729dd40f923013414fbb2184d upstream.
On systems with a KMALLOC_MIN_SIZE of 128 (arm64, some mips and powerpc
configurations defining ARCH_DMA_MINALIGN to 128), the first
kmalloc_caches[] entry to be initialised after slab_early_init = 0 is
"kmalloc-128" with index 7. Depending on the debug kernel configuration,
sizeof(struct kmem_cache) can be larger than 128 resulting in an
INDEX_NODE of 8.
Commit 8fc9cf420b36 ("slab: make more slab management structure off the
slab") enables off-slab management objects for sizes starting with
PAGE_SIZE >> 5 (128 bytes for a 4KB page configuration) and the creation
of the "kmalloc-128" cache would try to place the management objects
off-slab. However, since KMALLOC_MIN_SIZE is already 128 and
freelist_size == 32 in __kmem_cache_create(), kmalloc_slab(freelist_size)
returns NULL (kmalloc_caches[7] not populated yet). This triggers the
following bug on arm64:
kernel BUG at /work/Linux/linux-2.6-aarch64/mm/slab.c:2283!
Internal error: Oops - BUG: 0 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.3.0-rc4+ #540
Hardware name: Juno (DT)
PC is at __kmem_cache_create+0x21c/0x280
LR is at __kmem_cache_create+0x210/0x280
[...]
Call trace:
__kmem_cache_create+0x21c/0x280
create_boot_cache+0x48/0x80
create_kmalloc_cache+0x50/0x88
create_kmalloc_caches+0x4c/0xf4
kmem_cache_init+0x100/0x118
start_kernel+0x214/0x33c
This patch introduces an OFF_SLAB_MIN_SIZE definition to avoid off-slab
management objects for sizes equal to or smaller than KMALLOC_MIN_SIZE.
Fixes: 8fc9cf420b36 ("slab: make more slab management structure off the slab")
Signed-off-by: Catalin Marinas
Reported-by: Geert Uytterhoeven
Acked-by: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Luis Henriques
---
mm/slab.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 9a8dc5470e5e..084985404fec 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -279,6 +279,7 @@ static void kmem_cache_node_init(struct kmem_cache_node
*parent)
#define CFLGS_OFF_SLAB (0x8000UL)
#defineOFF_SLAB(x) ((x)->flags & CFLGS_OFF_SLAB)
+#define OFF_SLAB_MIN_SIZE (max_t(size_t, PAGE_SIZE >> 5, KMALLOC_MIN_SIZE + 1))
#define BATCHREFILL_LIMIT 16
/*
@@ -2328,7 +2329,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned
long flags)
* it too early on. Always use on-slab management when
* SLAB_NOLEAKTRACE to avoid recursive calls into kmemleak)
*/
- if ((size >= (PAGE_SIZE >> 5)) && !slab_early_init &&
+ if (size >= OFF_SLAB_MIN_SIZE && !slab_early_init &&
!(flags & SLAB_NOLEAKTRACE))
/*
* Size is large, assume best to place the slab management obj
@@ -2392,7 +2393,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned
long flags)
/*
* This is a possibility for one of the kmalloc_{dma,}_caches.
* But since we go off slab only for object size greater than
-* PAGE_SIZE/8, and kmalloc_{dma,}_caches get created
+* OFF_SLAB_MIN_SIZE, and kmalloc_{dma,}_caches get created
* in ascending order,this should not happen at all.
* But leave a BUG_ON for some lucky dude.
*/
--
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.16.y-ckt 088/126] wm831x_power: Use IRQF_ONESHOT to request threaded IRQs
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Valentin Rothberg
commit 90adf98d9530054b8e665ba5a928de4307231d84 upstream.
Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.
scripts/coccinelle/misc/irqf_oneshot.cocci detected this issue.
Fixes: b5874f33bbaf ("wm831x_power: Use genirq")
Signed-off-by: Valentin Rothberg
Signed-off-by: Sebastian Reichel
Signed-off-by: Luis Henriques
---
drivers/power/wm831x_power.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 3bed2f55cf7d..3ccadf631d45 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -567,7 +567,7 @@ static int wm831x_power_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "SYSLO"));
ret = request_threaded_irq(irq, NULL, wm831x_syslo_irq,
- IRQF_TRIGGER_RISING, "System power low",
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "System
power low",
power);
if (ret != 0) {
dev_err(&pdev->dev, "Failed to request SYSLO IRQ %d: %d\n",
@@ -577,7 +577,7 @@ static int wm831x_power_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "PWR SRC"));
ret = request_threaded_irq(irq, NULL, wm831x_pwr_src_irq,
- IRQF_TRIGGER_RISING, "Power source",
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT, "Power
source",
power);
if (ret != 0) {
dev_err(&pdev->dev, "Failed to request PWR SRC IRQ %d: %d\n",
@@ -590,7 +590,7 @@ static int wm831x_power_probe(struct platform_device *pdev)
platform_get_irq_byname(pdev,
wm831x_bat_irqs[i]));
ret = request_threaded_irq(irq, NULL, wm831x_bat_irq,
- IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
wm831x_bat_irqs[i],
power);
if (ret != 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.16.y-ckt 081/126] drm/ast: Initialized data needed to map fbdev memory
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Egbert Eich
commit 28fb4cb7fa6f63dc2fbdb5f2564dcbead8e3eee0 upstream.
Due to a missing initialization there was no way to map fbdev memory.
Thus for example using the Xserver with the fbdev driver failed.
This fix adds initialization for fix.smem_start and fix.smem_len
in the fb_info structure, which fixes this problem.
Requested-by: Benjamin Herrenschmidt
Signed-off-by: Egbert Eich
[pulled from SuSE tree by me - airlied]
Signed-off-by: Dave Airlie
Signed-off-by: Luis Henriques
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_fb.c | 7 +++
drivers/gpu/drm/ast/ast_main.c | 1 +
drivers/gpu/drm/ast/ast_mode.c | 2 ++
4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 5d6a87573c33..7a49bd9fdacc 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -310,6 +310,7 @@ int ast_framebuffer_init(struct drm_device *dev,
int ast_fbdev_init(struct drm_device *dev);
void ast_fbdev_fini(struct drm_device *dev);
void ast_fbdev_set_suspend(struct drm_device *dev, int state);
+void ast_fbdev_set_base(struct ast_private *ast, unsigned long gpu_addr);
struct ast_bo {
struct ttm_buffer_object bo;
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index a28640f47c27..b55b6b1c9fe2 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -367,3 +367,10 @@ void ast_fbdev_set_suspend(struct drm_device *dev, int
state)
fb_set_suspend(ast->fbdev->helper.fbdev, state);
}
+
+void ast_fbdev_set_base(struct ast_private *ast, unsigned long gpu_addr)
+{
+ ast->fbdev->helper.fbdev->fix.smem_start =
+ ast->fbdev->helper.fbdev->apertures->ranges[0].base + gpu_addr;
+ ast->fbdev->helper.fbdev->fix.smem_len = ast->vram_size - gpu_addr;
+}
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index b792194e0d9c..0dfefbf929a3 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -385,6 +385,7 @@ int ast_driver_load(struct drm_device *dev, unsigned long
flags)
dev->mode_config.min_height = 0;
dev->mode_config.preferred_depth = 24;
dev->mode_config.prefer_shadow = 1;
+ dev->mode_config.fb_base = pci_resource_start(ast->dev->pdev, 0);
if (ast->chip == AST2100 ||
ast->chip == AST2200 ||
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 1550d80ea2bc..d7e615282d38 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -522,6 +522,8 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc,
ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
if (ret)
DRM_ERROR("failed to kmap fbcon\n");
+ else
+ ast_fbdev_set_base(ast, gpu_addr);
}
ast_bo_unreserve(bo);
--
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.16.y-ckt 063/126] scsi: restart list search after unlock in scsi_remove_target
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Christoph Hellwig
commit 40998193560dab6c3ce8d25f4fa58a23e252ef38 upstream.
When dropping a lock while iterating a list we must restart the search
as other threads could have manipulated the list under us. Without this
we can get stuck in an endless loop. This bug was introduced by
commit bc3f02a795d3b4faa99d37390174be2a75d091bd
Author: Dan Williams
Date: Tue Aug 28 22:12:10 2012 -0700
[SCSI] scsi_remove_target: fix softlockup regression on hot remove
Which was itself trying to fix a reported soft lockup issue
http://thread.gmane.org/gmane.linux.kernel/1348679
However, we believe even with this revert of the original patch, the soft
lockup problem has been fixed by
commit f2495e228fce9f9cec84367547813cbb0d6db15a
Author: James Bottomley
Date: Tue Jan 21 07:01:41 2014 -0800
[SCSI] dual scan thread bug fix
Thanks go to Dan Williams for tracking all this
prior history down.
Reported-by: Johannes Thumshirn
Signed-off-by: Christoph Hellwig
Tested-by: Johannes Thumshirn
Reviewed-by: Johannes Thumshirn
Fixes: bc3f02a795d3b4faa99d37390174be2a75d091bd
Signed-off-by: James Bottomley
Signed-off-by: Luis Henriques
---
drivers/scsi/scsi_sysfs.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 074e8cc30955..fee7d1aebc3e 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1148,31 +1148,23 @@ static void __scsi_remove_target(struct scsi_target
*starget)
void scsi_remove_target(struct device *dev)
{
struct Scsi_Host *shost = dev_to_shost(dev->parent);
- struct scsi_target *starget, *last = NULL;
+ struct scsi_target *starget;
unsigned long flags;
- /* remove targets being careful to lookup next entry before
-* deleting the last
-*/
+restart:
spin_lock_irqsave(shost->host_lock, flags);
list_for_each_entry(starget, &shost->__targets, siblings) {
if (starget->state == STARGET_DEL)
continue;
if (starget->dev.parent == dev || &starget->dev == dev) {
- /* assuming new targets arrive at the end */
kref_get(&starget->reap_ref);
spin_unlock_irqrestore(shost->host_lock, flags);
- if (last)
- scsi_target_reap(last);
- last = starget;
__scsi_remove_target(starget);
- spin_lock_irqsave(shost->host_lock, flags);
+ scsi_target_reap(starget);
+ goto restart;
}
}
spin_unlock_irqrestore(shost->host_lock, flags);
-
- if (last)
- scsi_target_reap(last);
}
EXPORT_SYMBOL(scsi_remove_target);
--
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.16.y-ckt 093/126] netfilter: remove dead code
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Flavio Leitner
commit 0647e708344f4bf8b9e3f1855361c597f93d084d upstream.
Remove __nf_conntrack_find() from headers.
Fixes: dcd93ed4cd1 ("netfilter: nf_conntrack: remove dead code")
Signed-off-by: Flavio Leitner
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Luis Henriques
---
include/net/netfilter/nf_conntrack.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack.h
b/include/net/netfilter/nf_conntrack.h
index 37252f71a380..5c53572b5f0d 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -181,10 +181,6 @@ void *nf_ct_alloc_hashtable(unsigned int *sizep, int
nulls);
void nf_ct_free_hashtable(void *hash, unsigned int size);
-struct nf_conntrack_tuple_hash *
-__nf_conntrack_find(struct net *net, u16 zone,
- const struct nf_conntrack_tuple *tuple);
-
int nf_conntrack_hash_check_insert(struct nf_conn *ct);
bool nf_ct_delete(struct nf_conn *ct, u32 pid, int report);
--
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.16.y-ckt 098/126] ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Arnd Bergmann
commit 54c09889bff6d99c8733eed4a26c9391b177c88b upstream.
The z2 machine calls pxa27x_set_pwrmode() in order to power off
the machine, but this function gets discarded early at boot because
it is marked __init, as pointed out by kbuild:
WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the
function z2_power_off() to the function .init.text:pxa27x_set_pwrmode()
The function z2_power_off() references
the function __init pxa27x_set_pwrmode().
This is often because z2_power_off lacks a __init
annotation or the annotation of pxa27x_set_pwrmode is wrong.
This removes the __init section modifier to fix rebooting and the
build error.
Signed-off-by: Arnd Bergmann
Fixes: ba4a90a6d86a ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend()
no longer available")
Signed-off-by: Robert Jarzmik
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
---
arch/arm/mach-pxa/include/mach/pxa27x.h | 2 +-
arch/arm/mach-pxa/pxa27x.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/pxa27x.h
b/arch/arm/mach-pxa/include/mach/pxa27x.h
index 7cff640582b8..66c4cbfc7f36 100644
--- a/arch/arm/mach-pxa/include/mach/pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/pxa27x.h
@@ -21,7 +21,7 @@
extern void __init pxa27x_map_io(void);
extern void __init pxa27x_init_irq(void);
-extern int __init pxa27x_set_pwrmode(unsigned int mode);
+extern int pxa27x_set_pwrmode(unsigned int mode);
extern void pxa27x_cpu_pm_enter(suspend_state_t state);
#define pxa27x_handle_irq ichp_handle_irq
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 301471a07a10..4fc7c57ec495 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -251,7 +251,7 @@ static struct clk_lookup pxa27x_clkregs[] = {
*/
static unsigned int pwrmode = PWRMODE_SLEEP;
-int __init pxa27x_set_pwrmode(unsigned int mode)
+int pxa27x_set_pwrmode(unsigned int mode)
{
switch (mode) {
case PWRMODE_SLEEP:
--
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.16.y-ckt 095/126] packet: fix match_fanout_group()
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Eric Dumazet
commit 161642e24fee40fba2c5bc2ceacc00d118a22d65 upstream.
Recent TCP listener patches exposed a prior af_packet bug :
match_fanout_group() blindly assumes it is always safe
to cast sk to a packet socket to compare fanout with af_packet_priv
But SYNACK packets can be sent while attached to request_sock, which
are smaller than a "struct sock".
We can read non existent memory and crash.
Fixes: c0de08d04215 ("af_packet: don't emit packet on orig fanout group")
Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of
listener")
Signed-off-by: Eric Dumazet
Cc: Willem de Bruijn
Cc: Eric Leblond
Signed-off-by: David S. Miller
Signed-off-by: Luis Henriques
---
net/packet/af_packet.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e6bd6df9e2a2..1f618bbce0ac 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1412,10 +1412,10 @@ static void __fanout_unlink(struct sock *sk, struct
packet_sock *po)
static bool match_fanout_group(struct packet_type *ptype, struct sock *sk)
{
- if (ptype->af_packet_priv == (void *)((struct packet_sock *)sk)->fanout)
- return true;
+ if (sk->sk_family != PF_PACKET)
+ return false;
- return false;
+ return ptype->af_packet_priv == pkt_sk(sk)->fanout;
}
static int fanout_add(struct sock *sk, u16 id, u16 type_flags)
--
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.16.y-ckt 116/126] xtensa: nommu: provide _PAGE_CHG_MASK definition
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me know. -- From: Max Filippov commit 972c55bf70c04b3deeecec022c8ca64136350655 upstream. Signed-off-by: Max Filippov Signed-off-by: Luis Henriques --- arch/xtensa/include/asm/pgtable.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/xtensa/include/asm/pgtable.h b/arch/xtensa/include/asm/pgtable.h index b2173e5da601..cd1c00fc744f 100644 --- a/arch/xtensa/include/asm/pgtable.h +++ b/arch/xtensa/include/asm/pgtable.h @@ -178,6 +178,7 @@ #else /* no mmu */ +# define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_DIRTY) # define PAGE_NONE __pgprot(0) # define PAGE_SHARED __pgprot(0) # define PAGE_COPY __pgprot(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.16.y-ckt 124/126] ALSA: hda - Disable 64bit address for Creative HDA controllers
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Takashi Iwai
commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream.
We've had many reports that some Creative sound cards with CA0132
don't work well. Some reported that it starts working after reloading
the module, while some reported it starts working when a 32bit kernel
is used. All these facts seem implying that the chip fails to
communicate when the buffer is located in 64bit address.
This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT
flag to the corresponding PCI entries. I casually had a chance to
test an SB Recon3D board, and indeed this seems helping.
Although this hasn't been tested on all Creative devices, it's safer
to assume that this restriction applies to the rest of them, too. So
the flag is applied to all Creative entries.
Signed-off-by: Takashi Iwai
[ kamal: backport to 3.13-stable: context ]
Signed-off-by: Kamal Mostafa
Signed-off-by: Luis Henriques
---
sound/pci/hda/hda_intel.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e91c93dc08c6..d4268a2bbca7 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -262,7 +262,8 @@ enum {
AZX_DCAPS_CORBRP_SELF_CLEAR)
#define AZX_DCAPS_PRESET_CTHDA \
- (AZX_DCAPS_NO_MSI | AZX_DCAPS_POSFIX_LPIB | AZX_DCAPS_4K_BDLE_BOUNDARY)
+ (AZX_DCAPS_NO_MSI | AZX_DCAPS_POSFIX_LPIB | AZX_DCAPS_4K_BDLE_BOUNDARY
|\
+AZX_DCAPS_NO_64BIT)
/*
* VGA-switcher support
@@ -1963,11 +1964,13 @@ static const struct pci_device_id azx_ids[] = {
.class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
.class_mask = 0xff,
.driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+ AZX_DCAPS_NO_64BIT |
AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
#else
/* this entry seems still valid -- i.e. without emu20kx chip */
{ PCI_DEVICE(0x1102, 0x0009),
.driver_data = AZX_DRIVER_CTX | AZX_DCAPS_CTX_WORKAROUND |
+ AZX_DCAPS_NO_64BIT |
AZX_DCAPS_RIRB_PRE_DELAY | AZX_DCAPS_POSFIX_LPIB },
#endif
/* Vortex86MX */
--
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.16.y-ckt 125/126] printk: prevent userland from spoofing kernel messages
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Mathias Krause
commit 3824657c522f19f85a76bd932821174a5557a382 upstream.
The following statement of ABI/testing/dev-kmsg is not quite right:
It is not possible to inject messages from userspace with the
facility number LOG_KERN (0), to make sure that the origin of the
messages can always be reliably determined.
Userland actually can inject messages with a facility of 0 by abusing the
fact that the facility is stored in a u8 data type. By using a facility
which is a multiple of 256 the assignment of msg->facility in log_store()
implicitly truncates it to 0, i.e. LOG_KERN, allowing users of /dev/kmsg
to spoof kernel messages as shown below:
The following call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg
...leads to the following log entry (dmesg -x | tail -n 1):
user :emerg : [ 66.137758] Kernel panic - not syncing: beer empty
However, this call...
# printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg
...leads to the slightly different log entry (note the kernel facility):
kern :emerg : [ 74.177343] Kernel panic - not syncing: beer empty
Fix that by limiting the user provided facility to 8 bit right from the
beginning and catch the truncation early.
Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...")
Signed-off-by: Mathias Krause
Cc: Greg Kroah-Hartman
Cc: Petr Mladek
Cc: Alex Elder
Cc: Joe Perches
Cc: Kay Sievers
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
[ kamal: backport to 3.13-stable: retain local 'int i' ]
Signed-off-by: Kamal Mostafa
Signed-off-by: Luis Henriques
---
kernel/printk/printk.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index f7f6f7e5ff8a..5fa3f3b3b338 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -259,6 +259,9 @@ static u32 clear_idx;
#define PREFIX_MAX 32
#define LOG_LINE_MAX 1024 - PREFIX_MAX
+#define LOG_LEVEL(v) ((v) & 0x07)
+#define LOG_FACILITY(v)((v) >> 3 & 0xff)
+
/* record buffer */
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
#define LOG_ALIGN 4
@@ -547,12 +550,13 @@ static ssize_t devkmsg_writev(struct kiocb *iocb, const
struct iovec *iv,
line = buf;
if (line[0] == '<') {
char *endp = NULL;
+ unsigned int u;
- i = simple_strtoul(line+1, &endp, 10);
+ u = simple_strtoul(line + 1, &endp, 10);
if (endp && endp[0] == '>') {
- level = i & 7;
- if (i >> 3)
- facility = i >> 3;
+ level = LOG_LEVEL(u);
+ if (LOG_FACILITY(u) != 0)
+ facility = LOG_FACILITY(u);
endp++;
len -= endp - line;
line = endp;
--
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.16.y-ckt 112/126] perf trace: Fix documentation for -i
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Peter Feiner
commit 956959f6b7a982b2e789a7a8fa1de437074a5eb9 upstream.
The -i flag was incorrectly listed as a short flag for --no-inherit. It
should have only been listed as a short flag for --input.
This documentation error has existed since the --input flag was
introduced in 6810fc915f7a89d8134edb3996dbbf8eac386c26 (perf trace: Add
option to analyze events in a file versus live).
Signed-off-by: Peter Feiner
Cc: David Ahern
Link:
http://lkml.kernel.org/r/1446657706-14518-1-git-send-email-pfei...@google.com
Fixes: 6810fc915f7a ("perf trace: Add option to analyze events in a file versus
live")
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Luis Henriques
---
tools/perf/Documentation/perf-trace.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-trace.txt
b/tools/perf/Documentation/perf-trace.txt
index fae38d9a44a4..65d6a7a88c53 100644
--- a/tools/perf/Documentation/perf-trace.txt
+++ b/tools/perf/Documentation/perf-trace.txt
@@ -59,7 +59,6 @@ OPTIONS
--verbose=::
Verbosity level.
--i::
--no-inherit::
Child tasks do not inherit counters.
--
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.16.y-ckt 103/126] tcp: apply Kern's check on RTTs used for congestion control
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Yuchung Cheng
commit 9e45a3e36b363cc4c79c70f2b4f994e66543a219 upstream.
Currently ca_seq_rtt_us does not use Kern's check. Fix that by
checking if any packet acked is a retransmit, for both RTT used
for RTT estimation and congestion control.
Fixes: 5b08e47ca ("tcp: prefer packet timing to TS-ECR for RTT")
Signed-off-by: Yuchung Cheng
Signed-off-by: Neal Cardwell
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques
---
net/ipv4/tcp_input.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 0cdaa633059b..e3d40a303b8f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2891,9 +2891,6 @@ static inline bool tcp_ack_update_rtt(struct sock *sk,
const int flag,
* Karn's algorithm forbids taking RTT if some retransmitted data
* is acked (RFC6298).
*/
- if (flag & FLAG_RETRANS_DATA_ACKED)
- seq_rtt_us = -1L;
-
if (seq_rtt_us < 0)
seq_rtt_us = sack_rtt_us;
@@ -3115,7 +3112,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, int
prior_fackets,
flag |= FLAG_SACK_RENEGING;
skb_mstamp_get(&now);
- if (first_ackt.v64) {
+ if (first_ackt.v64 && !(flag & FLAG_RETRANS_DATA_ACKED)) {
seq_rtt_us = skb_mstamp_us_delta(&now, &first_ackt);
ca_seq_rtt_us = skb_mstamp_us_delta(&now, &last_ackt);
}
--
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.16.y-ckt 126/126] FS-Cache: Handle a write to the page immediately beyond the EOF marker
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: David Howells
commit 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 upstream.
Handle a write being requested to the page immediately beyond the EOF
marker on a cache object. Currently this gets an assertion failure in
CacheFiles because the EOF marker is used there to encode information about
a partial page at the EOF - which could lead to an unknown blank spot in
the file if we extend the file over it.
The problem is actually in fscache where we check the index of the page
being written against store_limit. store_limit is set to the number of
pages that we're allowed to store by fscache_set_store_limit() - which
means it's one more than the index of the last page we're allowed to store.
The problem is that we permit writing to a page with an index _equal_ to
the store limit - when we should reject that case.
Whilst we're at it, change the triggered assertion in CacheFiles to just
return -ENOBUFS instead.
The assertion failure looks something like this:
CacheFiles: Assertion failed
1000 < 7b1 is false
[ cut here ]
kernel BUG at fs/cachefiles/rdwr.c:962!
...
RIP: 0010:[] []
cachefiles_write_page+0x273/0x2d0 [cachefiles]
Signed-off-by: David Howells
Signed-off-by: Al Viro
[ kamal: backport to 3.13-stable: no __kernel_write(); thanks Ben H. ]
Signed-off-by: Kamal Mostafa
Signed-off-by: Luis Henriques
---
fs/cachefiles/rdwr.c | 79 +++-
fs/fscache/page.c| 2 +-
2 files changed, 42 insertions(+), 39 deletions(-)
diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c
index 4b1fb5ca65b8..88483abe08d3 100644
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -912,6 +912,15 @@ int cachefiles_write_page(struct fscache_storage *op,
struct page *page)
cache = container_of(object->fscache.cache,
struct cachefiles_cache, cache);
+ pos = (loff_t)page->index << PAGE_SHIFT;
+
+ /* We mustn't write more data than we have, so we have to beware of a
+* partial page at EOF.
+*/
+ eof = object->fscache.store_limit_l;
+ if (pos >= eof)
+ goto error;
+
/* write the page to the backing filesystem and let it store it in its
* own time */
path.mnt = cache->mnt;
@@ -919,49 +928,43 @@ int cachefiles_write_page(struct fscache_storage *op,
struct page *page)
file = dentry_open(&path, O_RDWR | O_LARGEFILE, cache->cache_cred);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
- } else {
- ret = -EIO;
- if (file->f_op->write) {
- pos = (loff_t) page->index << PAGE_SHIFT;
-
- /* we mustn't write more data than we have, so we have
-* to beware of a partial page at EOF */
- eof = object->fscache.store_limit_l;
- len = PAGE_SIZE;
- if (eof & ~PAGE_MASK) {
- ASSERTCMP(pos, <, eof);
- if (eof - pos < PAGE_SIZE) {
- _debug("cut short %llx to %llx",
- pos, eof);
- len = eof - pos;
- ASSERTCMP(pos + len, ==, eof);
- }
- }
+ goto error_2;
+ }
- data = kmap(page);
- file_start_write(file);
- old_fs = get_fs();
- set_fs(KERNEL_DS);
- ret = file->f_op->write(
- file, (const void __user *) data, len, &pos);
- set_fs(old_fs);
- kunmap(page);
- file_end_write(file);
- if (ret != len)
- ret = -EIO;
+ len = PAGE_SIZE;
+ if (eof & ~PAGE_MASK) {
+ if (eof - pos < PAGE_SIZE) {
+ _debug("cut short %llx to %llx",
+ pos, eof);
+ len = eof - pos;
+ ASSERTCMP(pos + len, ==, eof);
}
- fput(file);
}
- if (ret < 0) {
- if (ret == -EIO)
- cachefiles_io_error_obj(
- object, "Write page to backing file failed");
- ret = -ENOBUFS;
- }
+ data = kmap(page);
+ file_start_write(file);
+ old_fs = get_fs();
+ set_fs(KERNEL_DS);
+ ret = file->f_op->write(
+ file, (const void __user *) data, len, &pos);
+ set_fs(old_fs);
+ kunmap(page);
+ fput(file);
+ if (ret != len)
+ goto error_eio;
+
+ _le
[PATCH 3.16.y-ckt 123/126] fs/proc, core/debug: Don't expose absolute kernel addresses via wchan
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Ingo Molnar
commit b2f73922d119686323f14fbbe46587f863852328 upstream.
So the /proc/PID/stat 'wchan' field (the 30th field, which contains
the absolute kernel address of the kernel function a task is blocked in)
leaks absolute kernel addresses to unprivileged user-space:
seq_put_decimal_ull(m, ' ', wchan);
The absolute address might also leak via /proc/PID/wchan as well, if
KALLSYMS is turned off or if the symbol lookup fails for some reason:
static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
unsigned long wchan;
char symname[KSYM_NAME_LEN];
wchan = get_wchan(task);
if (lookup_symbol_name(wchan, symname) < 0) {
if (!ptrace_may_access(task, PTRACE_MODE_READ))
return 0;
seq_printf(m, "%lu", wchan);
} else {
seq_printf(m, "%s", symname);
}
return 0;
}
This isn't ideal, because for example it trivially leaks the KASLR offset
to any local attacker:
fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35)
8123b380
Most real-life uses of wchan are symbolic:
ps -eo pid:10,tid:10,wchan:30,comm
and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat:
triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan
| tail -1
open("/proc/30833/wchan", O_RDONLY) = 6
There's one compatibility quirk here: procps relies on whether the
absolute value is non-zero - and we can provide that functionality
by outputing "0" or "1" depending on whether the task is blocked
(whether there's a wchan address).
These days there appears to be very little legitimate reason
user-space would be interested in the absolute address. The
absolute address is mostly historic: from the days when we
didn't have kallsyms and user-space procps had to do the
decoding itself via the System.map.
So this patch sets all numeric output to "0" or "1" and keeps only
symbolic output, in /proc/PID/wchan.
( The absolute sleep address can generally still be profiled via
perf, by tasks with sufficient privileges. )
Reviewed-by: Thomas Gleixner
Acked-by: Kees Cook
Acked-by: Linus Torvalds
Cc: Al Viro
Cc: Alexander Potapenko
Cc: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Denys Vlasenko
Cc: Dmitry Vyukov
Cc: Kostya Serebryany
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: kasan-dev
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/20150930135917.ga3...@gmail.com
Signed-off-by: Ingo Molnar
[ kamal: backport to 3.16-stable: proc_pid_wchan context ]
Signed-off-by: Kamal Mostafa
Signed-off-by: Luis Henriques
---
Documentation/filesystems/proc.txt | 5 +++--
fs/proc/array.c| 16 ++--
fs/proc/base.c | 9 +++--
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index ddc531a74d04..225ae3ba74b3 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -139,7 +139,8 @@ Table 1-1: Process specific entries in /proc
stat Process status
statm Process memory status information
statusProcess status in human readable form
- wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
+ wchan Present with CONFIG_KALLSYMS=y: it shows the kernel function
+ symbol the task is blocked in - or "0" if not blocked.
pagemap Page table
stack Report full stack trace, enable via CONFIG_STACKTRACE
smaps a extension based on maps, showing the memory consumption of
@@ -301,7 +302,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
blocked bitmap of blocked signals
sigignbitmap of ignored signals
sigcatch bitmap of caught signals
- wchan address where process went to sleep
+ 0(place holder, used to be the wchan address, use
/proc/PID/wchan instead)
0 (place holder)
0 (place holder)
exit_signal signal to send to parent thread on exit
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 3e1290b0492e..98f368b7c857 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -371,7 +371,7 @@ int proc_pid_status(struct seq_file *m, struct
pid_namespace *ns,
static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task, int whole)
{
- unsigned long vsize, eip, esp, wchan = ~0UL;
+ unsigned long vsize, eip, esp, wchan = 0;
int priority, nice;
int tty_pgrp = -1, tty_nr = 0;
sigset_t sigign, sigcatc
[PATCH 3.16.y-ckt 119/126] drm/radeon: add quirk for MSI R7 370
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Maxim Sheviakov
commit e78654799135a788a941bacad3452fbd7083e518 upstream.
Just adds the quirk for MSI R7 370 Armor 2X
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91294
Signed-off-by: Maxim Sheviakov
Signed-off-by: Alex Deucher
Signed-off-by: Luis Henriques
---
drivers/gpu/drm/radeon/si_dpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 46c945740b85..cdafcf0b633e 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2922,6 +2922,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
{ PCI_VENDOR_ID_ATI, 0x6810, 0x1462, 0x3036, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
+ { PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 12 },
{ 0, 0, 0, 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.16.y-ckt 122/126] tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Kosuke Tatsukawa
commit e81107d4c6bd098878af9796b24edc8d4a9524fd upstream.
My colleague ran into a program stall on a x86_64 server, where
n_tty_read() was waiting for data even if there was data in the buffer
in the pty. kernel stack for the stuck process looks like below.
#0 [88303d107b58] __schedule at 815c4b20
#1 [88303d107bd0] schedule at 815c513e
#2 [88303d107bf0] schedule_timeout at 815c7818
#3 [88303d107ca0] wait_woken at 81096bd2
#4 [88303d107ce0] n_tty_read at 8136fa23
#5 [88303d107dd0] tty_read at 81368013
#6 [88303d107e20] __vfs_read at 811a3704
#7 [88303d107ec0] vfs_read at 811a3a57
#8 [88303d107f00] sys_read at 811a4306
#9 [88303d107f50] entry_SYSCALL_64_fastpath at 815c86d7
There seems to be two problems causing this issue.
First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
updates ldata->commit_head using smp_store_release() and then checks
the wait queue using waitqueue_active(). However, since there is no
memory barrier, __receive_buf() could return without calling
wake_up_interactive_poll(), and at the same time, n_tty_read() could
start to wait in wait_woken() as in the following chart.
__receive_buf() n_tty_read()
if (waitqueue_active(&tty->read_wait))
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
add_wait_queue(&tty->read_wait, &wait);
...
if (!input_available_p(tty, 0)) {
smp_store_release(&ldata->commit_head,
ldata->read_head);
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
The second problem is that n_tty_read() also lacks a memory barrier
call and could also cause __receive_buf() to return without calling
wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
as in the chart below.
__receive_buf() n_tty_read()
spin_lock_irqsave(&q->lock, flags);
/* from add_wait_queue() */
...
if (!input_available_p(tty, 0)) {
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
smp_store_release(&ldata->commit_head,
ldata->read_head);
if (waitqueue_active(&tty->read_wait))
__add_wait_queue(q, wait);
spin_unlock_irqrestore(&q->lock,flags);
/* from add_wait_queue() */
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
There are also other places in drivers/tty/n_tty.c which have similar
calls to waitqueue_active(), so instead of adding many memory barrier
calls, this patch simply removes the call to waitqueue_active(),
leaving just wake_up*() behind.
This fixes both problems because, even though the memory access before
or after the spinlocks in both wake_up*() and add_wait_queue() can
sneak into the critical section, it cannot go past it and the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.
Latency measurement using a ping-pong test over a pty doesn't show any
visible performance drop.
Signed-off-by: Kosuke Tatsukawa
Signed-off-by: Greg Kroah-Hartman
[ luis: backported to 3.16:
- always use wake_up_interruptible() instead of wake_up_interruptible_poll()
- adjusted context ]
Signed-off-by: Luis Henriques
---
drivers/tty/n_tty.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 39ec99fbb135..29de4bfe5c70 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -364,8 +364,7 @@ static void n_tty_packet_mode_flush(struct tty_struct *tty)
spin_lock_irqsave(&tty->ct
[PATCH 3.16.y-ckt 120/126] drm/radeon: add quirk for ASUS R7 370
3.16.7-ckt21 -stable review patch. If anyone has any objections, please let me
know.
--
From: Alex Deucher
commit 2b02ec79004388a8c65e227bc289ed891b5ac8c6 upstream.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=92260
Signed-off-by: Alex Deucher
Signed-off-by: Luis Henriques
---
drivers/gpu/drm/radeon/si_dpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index cdafcf0b633e..1040c3638c26 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2923,6 +2923,7 @@ static struct si_dpm_quirk si_dpm_quirk_list[] = {
{ PCI_VENDOR_ID_ATI, 0x6811, 0x174b, 0xe271, 0, 12 },
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
{ PCI_VENDOR_ID_ATI, 0x6811, 0x1762, 0x2015, 0, 12 },
+ { PCI_VENDOR_ID_ATI, 0x6811, 0x1043, 0x2015, 0, 12 },
{ 0, 0, 0, 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/
