[PATCH] xen: Use module_pci_driver() in platform pci driver.
Eliminate the module_init function by using module_pci_driver()
Signed-off-by: Rajat Jain
Signed-off-by: Rajat Jain
---
drivers/xen/platform-pci.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index 3454973..3fb4d41 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -192,9 +192,4 @@ static struct pci_driver platform_driver = {
#endif
};
-static int __init platform_pci_module_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-module_init(platform_pci_module_init);
+module_pci_driver(platform_driver);
--
2.4.3.573.g4eafbef
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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] cpufreq: Initialize the governor again while restoring policy
When all CPUs of a policy are hot-unplugged, we EXIT the governor but
don't mark policy->governor as NULL. This was done in order to keep last
used governor's information intact in sysfs, while the CPUs are offline.
We also missed marking policy->governor as NULL while restoring the
policy. Because of that, we call __cpufreq_governor(CPUFREQ_GOV_LIMITS)
for an uninitialized policy. Which eventually returns -EBUSY.
Fix this by setting policy->governor to NULL while restoring the policy.
Reported-by: Pi-Cheng Chen
Reported-by: "Jon Medhurst (Tixy)"
Fixes: 18bf3a124ef8 ("cpufreq: Mark policy->governor = NULL for inactive
policies")
Signed-off-by: Viresh Kumar
---
For 4.2-rc
drivers/cpufreq/cpufreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b612411655f9..2c22e3902e72 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1132,6 +1132,7 @@ static struct cpufreq_policy
*cpufreq_policy_restore(unsigned int cpu)
down_write(>rwsem);
policy->cpu = cpu;
+ policy->governor = NULL;
up_write(>rwsem);
}
--
2.4.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] mtd: denali: Use module_pci_driver()
Use module_pci_driver, since init and exit functions only register
and unregister the pci driver, respectively.
Signed-off-by: Rajat Jain
Signed-off-by: Rajat Jain
---
drivers/mtd/nand/denali_pci.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index 6e2f387..29e5d0c 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -129,14 +129,4 @@ static struct pci_driver denali_pci_driver = {
.remove = denali_pci_remove,
};
-static int denali_init_pci(void)
-{
- return pci_register_driver(_pci_driver);
-}
-module_init(denali_init_pci);
-
-static void denali_exit_pci(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-module_exit(denali_exit_pci);
+module_pci_driver(denali_pci_driver);
--
2.4.3.573.g4eafbef
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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 4/4] ARM: dts: Extend exynos5420-pinctrl nodes using labels instead of paths
A previously defined Device Tree node, can be extended either by defining
a node using the same full path or by creating a label for the node and
referencing to it.
Using full paths is more error prone since if there was a typo error, a
new node will be created instead of extending the node as it was desired.
This will lead to run-time errors that could be hard to detect.
A misstyped label on the other hand, will cause a dtc compile error which
makes it easier to detect the mistake since happens at build-time instead.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 1411 ++---
1 file changed, 705 insertions(+), 706 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index 8b153166ebdb..130563b2ca95 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -12,711 +12,710 @@
* published by the Free Software Foundation.
*/
-/ {
- pinctrl@1340 {
- gpy7: gpy7 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpx0: gpx0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- interrupt-parent = <>;
- #interrupt-cells = <2>;
- interrupts = <23 0>, <24 0>, <25 0>, <25 1>,
-<26 0>, <26 1>, <27 0>, <27 1>;
- };
-
- gpx1: gpx1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- interrupt-parent = <>;
- #interrupt-cells = <2>;
- interrupts = <28 0>, <28 1>, <29 0>, <29 1>,
-<30 0>, <30 1>, <31 0>, <31 1>;
- };
-
- gpx2: gpx2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpx3: gpx3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- dp_hpd: dp_hpd {
- samsung,pins = "gpx0-7";
- samsung,pin-function = <3>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
- };
- };
-
- pinctrl@1341 {
- gpc0: gpc0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc1: gpc1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc2: gpc2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc3: gpc3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc4: gpc4 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpd1: gpd1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpy0: gpy0 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy1: gpy1 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy2: gpy2 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy3: gpy3 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy4: gpy4 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy5: gpy5 {
- gpio-controller;
-
Re: [PATCH] [SCSI] FlashPoint: optimize string comparison
Le 07/07/2015 19:04, Khalid Aziz a écrit :
On 07/07/2015 02:45 AM, Frans Klaver wrote:
On Tue, Jul 7, 2015 at 7:39 AM, Christophe JAILLET
wrote:
Stop comparing the strings as soon as we know that they don't match.
Signed-off-by: Christophe JAILLET
---
drivers/scsi/FlashPoint.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/FlashPoint.c b/drivers/scsi/FlashPoint.c
index 5c74e4c..24a4d1a 100644
--- a/drivers/scsi/FlashPoint.c
+++ b/drivers/scsi/FlashPoint.c
@@ -6280,8 +6280,10 @@ static unsigned char FPT_scmachid(unsigned
char p_card,
match = 1;
for (k = 0; k < ID_STRING_LENGTH; k++) {
- if (p_id_string[k] !=
FPT_scamInfo[i].id_string[k])
+ if (p_id_string[k] !=
FPT_scamInfo[i].id_string[k]) {
match = 0;
+ break;
+ }
}
if (match) {
Why doesn't this use strncmp?
Thanks,
Frans
I suspect that is how this code came from Mylex many years ago. Using
strncmp would indeed be a better way to clean this up. Also, further
down in the same routine:
if (FPT_scamInfo[match].state == ID_UNUSED) {
for (k = 0; k < ID_STRING_LENGTH; k++) {
FPT_scamInfo[match].id_string[k] =
p_id_string[k];
}
This should use strncpy instead. There is another similar spot further
down.
Christophe, if you can send a new patch with these clean-ups, that
would be great.
Thanks,
Khalid
Hi,
I'm sorry but I won't propose a new patch for that.
I had the same reaction at first (why not use strncmp?) but it seems to
be the way this driver is coded. Should we want to introduce strncmp
here, then, as you have noticed, strcpy should be used to. memset could
be also used in many places. Then looking elsewhere in the code, many
things should, IMHO, also be fixed. (use consistently empty lines
before/after code ; use consistently { }...)
Another concern to me is "the use of carriage return". In the following
examples, things could be much more readable if not limited to 50 chars
per line, or so.
1357
FPT_sccbMgrTbl
[thisCard][id
* 2 +
1358
i
].TarStatus |=
1359
SYNC_SUPPORTED
;
or
4850
FPT_sccbMgrTbl
[p_card]
4851
[currSCCB->TargID].
4852
TarLUNBusy[0] = 1;
4853
if (currSCCB->Sccb_tag) {
4854
if (FPT_BL_Card
[p_card].
4855
discQCount != 0)
4856
FPT_BL_Card
4857
[p_card].
4858
discQCount--;
4859
FPT_BL_Card
[p_card].
4860
discQ_Tbl[currSCCB->
4861
[PATCH v2 6/6] ARM: PRM: AM437x: Enable IO wakeup feature
Enable IO wakeup feature.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/prm_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 7add799..1730fc4 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -696,6 +696,7 @@ static struct omap_prcm_init_data am4_prm_data __initdata =
{
.index = TI_CLKM_PRM,
.init = omap44xx_prm_init,
.device_inst_offset = AM43XX_PRM_DEVICE_INST,
+ .flags = PRM_HAS_IO_WAKEUP,
};
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Wed, Jul 08, 2015 at 10:37:21AM +0800, Eddie Huang wrote:
> On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote:
> > On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer
> > wrote:
> > > On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> > >> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer
> > >> wrote:
> > >> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> > >> >> Add clk_null, which represents clocks that can not / need not
> > >> >> controlled by software.
> > >> >> There are many clocks' parent set to clk_null.
> > >> >>
> > >> >> Signed-off-by: James Liao
> > >> >> Signed-off-by: Eddie Huang
> > >> >> ---
> > >> >> Base on 4.1-rc1
> > >> >>
> > >> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> > >> >> ---
> > >> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
> > >> >> 1 file changed, 6 insertions(+)
> > >> >>
> > >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> index 924fdb6..4798f44 100644
> > >> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > >> >> @@ -81,6 +81,12 @@
> > >> >> cpu_on= <0x8403>;
> > >> >> };
> > >> >>
> > >> >> + clk_null: clk_null {
> > >> >> + compatible = "fixed-clock";
> > >> >> + clock-frequency = <0>;
> > >> >> + #clock-cells = <0>;
> > >> >> + };
> > >> >
> > >> > The discussion around this patch shows that we don't want to have this
> > >> > clock in the device tree as it is not a hardware description.
> > >> >
> > >> > Ok, fine. Eddie, you told us that the rate of the current clk_null
> > >> > children
> > >> > is not interesting. What's the motivation to send this patch anyway
> > >> > then? Why can't you keep its children on the orphan list where they are
> > >> > already now?
> > >> >
> > >> > Another possibility would be to instantiate the clk_null clock from C
> > >> > code rather than from the device tree. This way we wouldn't put any
> > >> > wrong descriptions into the device tree and still can implement the
> > >> > support for the real parent clocks when we actually need them.
> > >>
> > >> Some device nodes, like mmc, use a clk_null phandle as one of their
> > >> clocks:
> > >>
> > >> mmc1: mmc@1124 {
> > >> compatible = "mediatek,mt8173-mmc",
> > >> "mediatek,mt8135-mmc";
> > >> reg = <0 0x1124 0 0x1000>;
> > >> interrupts = ;
> > >> clocks = < CLK_PERI_MSDC30_1>,
> > >> <_null>;
> > >> clock-names = "source", "hclk";
> > >> status = "disabled";
> > >> };
> > >
> > > This is another case than the one we discussed about. In the case above
> > > I motivated using a dummy clock since the clock exists in the system,
> > > but is not software controllable. To abstract this from the driver
> > > (which needs this clock since it exists) we here have the dummy clock.
> > > However, of course I can't prove the clock is indeed not software
> > > controllable; that's only the information I have.
> >
> > I was trying to answer your question "What's the motivation to send
> > this patch anyway?".
> > The motivation is to send follow on patches that use the clk_null
> > phandle. We need to provide some clock as the mmc1's hclk. I do not
> > understand why this has to be "clk_null", though. It seems like this
> > should be a real clock coming from one of the real clock_controller
> > nodes. After all, the mmc driver is going to be enabling/disabling
> > this clock for power savings at runtime. What does that even mean for
> > clk_null ?
>
> The original purpose of this patch is to provide a common dummy clock
> for both software don't care clock and clock that is not software
> controllable.I got comments that device tree should describe hardware
> and should put exact clock in device tree. I think this is true. So we
> will remove this clock_null patch, and:
>
> 1. For Mediatek SoC CCF driver, James will clarify clock usage further.
> Actually, we still think it's not necessary to describe whole tree that
> software don't care, James will deal this in clock driver.
I think that aswell since the device tree is not affected in this case.
Should we realize later that we indeed need the missing clocks we can
still implement them without modifying the device tree.
>
> 2. For other module that use SW not controllable clock (mmc case
> mentioned by Dan), because this is a real clock, we will put a dummy
> clock in device tree, like
>
> clk_mmchclk: dummyhclk {
> compatible = "fixed-clock";
> clock-frequency = <0>;
> #clock-cells = <0>;
> };
>
> How about this modification ?
I wouldn't name it 'dummy', this will again raise some eyebrows.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/
[PATCH v2 1/6] ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register
PRM_IO_PMCTRL_OFFSET need not be same for all SOCs hence
remove hardcoding and use the value provided by the omap_prcm_irq_setup
structure.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/prcm-common.h | 1 +
arch/arm/mach-omap2/prm44xx.c | 11 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm-common.h
b/arch/arm/mach-omap2/prcm-common.h
index 6ae0b3a..2e60406 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -494,6 +494,7 @@ struct omap_prcm_irq {
struct omap_prcm_irq_setup {
u16 ack;
u16 mask;
+ u16 pm_ctrl;
u8 nr_regs;
u8 nr_irqs;
const struct omap_prcm_irq *irqs;
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 4541700..8149e5a 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -45,6 +45,7 @@ static const struct omap_prcm_irq omap4_prcm_irqs[] = {
static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
.ack= OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.mask = OMAP4_PRM_IRQENABLE_MPU_OFFSET,
+ .pm_ctrl= OMAP4_PRM_IO_PMCTRL_OFFSET,
.nr_regs= 2,
.irqs = omap4_prcm_irqs,
.nr_irqs= ARRAY_SIZE(omap4_prcm_irqs),
@@ -306,10 +307,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap4_prcm_irq_setup.pm_ctrl);
omap_test_timeout(
(((omap4_prm_read_inst_reg(inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET) &
+ omap4_prcm_irq_setup.pm_ctrl) &
OMAP4430_WUCLK_STATUS_MASK) >>
OMAP4430_WUCLK_STATUS_SHIFT) == 1),
MAX_IOPAD_LATCH_TIME, i);
@@ -319,10 +320,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
/* Trigger WUCLKIN disable */
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap4_prcm_irq_setup.pm_ctrl);
omap_test_timeout(
(((omap4_prm_read_inst_reg(inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET) &
+ omap4_prcm_irq_setup.pm_ctrl) &
OMAP4430_WUCLK_STATUS_MASK) >>
OMAP4430_WUCLK_STATUS_SHIFT) == 0),
MAX_IOPAD_LATCH_TIME, i);
@@ -350,7 +351,7 @@ static void __init omap44xx_prm_enable_io_wakeup(void)
omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
OMAP4430_GLOBAL_WUEN_MASK,
inst,
- OMAP4_PRM_IO_PMCTRL_OFFSET);
+ omap4_prcm_irq_setup.pm_ctrl);
}
/**
--
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 01/41] clocksource: asm9260: Migrate to new 'set-state' interface
On 08-07-15, 11:07, Vineet Gupta wrote: > Is this series (and other one touching arch/arm/*) specific to ARM event > timers. > Are you planning to fixup the drivers in arch/* or the respective maintainers > need > to follow suit. Hi Vineet, I am fixing all clockevent drivers available in Linux kernel, so you need not worry :) I stopped a bit because of a dependency patch, which just got included in tip tree yesterday. Once that gets into next rc release (hopefully -4.2-rc2), I will send all the patches I have. At that point, these changes wouldn't have any dependency on clockevents tree and maintainers like you can apply them directly. Changes are kept here for testing by auto-bots, in case you wanna have a look at arc patch :). git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git clkevt/clocksource/set-state -- 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/
[PATCH v2 0/6] ARM: AM437x: Add IO wake up support
The patch series adds IO wake up support for AM437x series making use of the existing OMAP4 support. Adds the AM437x specifics. The series is boot tested on OMAP4 panda, DAR7 evm and AM437x evms. Changes in v2: Removed inefficient way of using arrays for irq ack and masks. Keerthy (6): ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register ARM: AM43xx: Add the PRM IRQ register offsets ARM: dts: AM4372: Add PRCM IRQ entry ARM: OMAP: PRM: Remove hardcoding of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 register offsets ARM: OMAP4+: PRM: Add AM437x specific data ARM: PRM: AM437x: Enable IO wakeup feature arch/arm/boot/dts/am4372.dtsi | 1 + arch/arm/mach-omap2/prcm-common.h | 1 + arch/arm/mach-omap2/prcm43xx.h| 5 arch/arm/mach-omap2/prm44xx.c | 58 +++ arch/arm/mach-omap2/prm_common.c | 1 + 5 files changed, 42 insertions(+), 24 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] ARM: OMAP: PRM: Remove hardcoding of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 register offsets
The register offsets of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 are hardcoded.
This makes it difficult to reuse the code for SoCs like AM437x that have
a single instance of IRQENABLE_MPU and IRQSTATUS_MPU registers.
Hence handling the case using offset of 4 to accommodate single set of IRQ*
registers generically.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/prm44xx.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 8149e5a..f82d89a 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -217,11 +217,11 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs,
u16 irqst_offs)
*/
static void omap44xx_prm_read_pending_irqs(unsigned long *events)
{
- events[0] = _read_pending_irq_reg(OMAP4_PRM_IRQENABLE_MPU_OFFSET,
- OMAP4_PRM_IRQSTATUS_MPU_OFFSET);
+ int i;
- events[1] = _read_pending_irq_reg(OMAP4_PRM_IRQENABLE_MPU_2_OFFSET,
- OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET);
+ for (i = 0; i < omap4_prcm_irq_setup.nr_regs; i++)
+ events[i] = _read_pending_irq_reg(omap4_prcm_irq_setup.mask +
+ i * 4, omap4_prcm_irq_setup.ack + i * 4);
}
/**
@@ -251,17 +251,15 @@ static void omap44xx_prm_ocp_barrier(void)
*/
static void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
{
- saved_mask[0] =
- omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
- OMAP4_PRM_IRQENABLE_MPU_OFFSET);
- saved_mask[1] =
- omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
- OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
+ int i;
- omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
-OMAP4_PRM_IRQENABLE_MPU_OFFSET);
- omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
-OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
+ for (i = 0; i < omap4_prcm_irq_setup.nr_regs; i++) {
+ saved_mask[i] =
+ omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
+ omap4_prcm_irq_setup.mask + i * 4);
+ omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
+omap4_prcm_irq_setup.mask + i * 4);
+ }
/* OCP barrier */
omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
@@ -280,10 +278,12 @@ static void omap44xx_prm_save_and_clear_irqen(u32
*saved_mask)
*/
static void omap44xx_prm_restore_irqen(u32 *saved_mask)
{
- omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_OCP_SOCKET_INST,
-OMAP4_PRM_IRQENABLE_MPU_OFFSET);
- omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_OCP_SOCKET_INST,
-OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
+ int i;
+
+ for (i = 0; i < omap4_prcm_irq_setup.nr_regs; i++)
+ omap4_prm_write_inst_reg(saved_mask[i],
+ OMAP4430_PRM_OCP_SOCKET_INST,
+ omap4_prcm_irq_setup.mask + i * 4);
}
/**
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/6] ARM: AM43xx: Add the PRM IRQ register offsets
Add the PRM IRQ register offsets. Signed-off-by: Keerthy --- arch/arm/mach-omap2/prcm43xx.h | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h index 7eebc27..d716d2e 100644 --- a/arch/arm/mach-omap2/prcm43xx.h +++ b/arch/arm/mach-omap2/prcm43xx.h @@ -25,6 +25,10 @@ #define AM43XX_PRM_WKUP_INST 0x2000 #define AM43XX_PRM_DEVICE_INST 0x4000 +/* PRM_IRQ offsets */ +#define AM43XX_PRM_IRQSTATUS_MPU_OFFSET0x0004 +#define AM43XX_PRM_IRQENABLE_MPU_OFFSET0x0008 + /* RM RSTCTRL offsets */ #define AM43XX_RM_PER_RSTCTRL_OFFSET 0x0010 #define AM43XX_RM_GFX_RSTCTRL_OFFSET 0x0010 @@ -146,6 +150,7 @@ #define AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET 0x04a0 #define AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET 0x0068 #define AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET 0x0070 +#define AM43XX_PRM_IO_PMCTRL_OFFSET0x0024 #define AM43XX_CM_PER_EMIF_CLKCTRL_OFFSET 0x0720 #endif -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/6] ARM: OMAP4+: PRM: Add AM437x specific data
The register offsets for some of the PRM Registers are different
hence populating the differing fields.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/prm44xx.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index f82d89a..311d717 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -18,13 +18,14 @@
#include
#include
#include
-
+#include
#include "soc.h"
#include "iomap.h"
#include "common.h"
#include "vp.h"
#include "prm44xx.h"
+#include "prcm43xx.h"
#include "prm-regbits-44xx.h"
#include "prcm44xx.h"
#include "prminst44xx.h"
@@ -720,6 +721,14 @@ int __init omap44xx_prm_init(const struct
omap_prcm_init_data *data)
omap4_prminst_set_prm_dev_inst(data->device_inst_offset);
+ /* Add AM437X specific differences */
+ if (of_device_is_compatible(data->np, "ti,am4-prcm")) {
+ omap4_prcm_irq_setup.nr_irqs = 1;
+ omap4_prcm_irq_setup.pm_ctrl = AM43XX_PRM_IO_PMCTRL_OFFSET;
+ omap4_prcm_irq_setup.ack = AM43XX_PRM_IRQSTATUS_MPU_OFFSET;
+ omap4_prcm_irq_setup.mask = AM43XX_PRM_IRQENABLE_MPU_OFFSET;
+ }
+
return prm_register(_prm_ll_data);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/6] ARM: dts: AM4372: Add PRCM IRQ entry
Add PRCM IRQ entry.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/am4372.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c80a3e2..637133b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -86,6 +86,7 @@
prcm: prcm@1f {
compatible = "ti,am4-prcm";
reg = <0x1f 0x11000>;
+ interrupts = ;
prcm_clocks: clocks {
#address-cells = <1>;
--
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: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support
Hi Stefan,
On 15-07-07 14:49:06, Stefan Wahren wrote:
> Hi Sanchayan,
>
> > maitysancha...@gmail.com hat am 7. Juli 2015 um 07:19 geschrieben:
> >
> >
> > [...]
> > > > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > > > index 17f1a57..84c830d 100644
> > > > --- a/drivers/nvmem/Kconfig
> > > > +++ b/drivers/nvmem/Kconfig
> > > > @@ -33,4 +33,14 @@ config NVMEM_SUNXI_SID
> > > > This driver can also be built as a module. If so, the module
> > > > will be called eeprom-sunxi-sid.
> > > >
> > > > +config NVMEM_VF610_OCOTP
> > > > + tristate "VF610 SoCs OCOTP support"
> > > > + depends on SOC_VF610
> > > > + help
> > > > + This is a driver for the 'OCOTP' available on various Vybrid
> > > > + devices.
> > >
> > > I don't know much about Vybrid. But this driver is specific for VF610,
> > > isn't
> > > it?
> >
> > Sorry. I only checked on VF50 and VF61. Will check if is it available with
> > the
> > other Vybrid devices and change if it is not so.
>
> no problem. If you spend time in testing your driver with different devices,
> you
> could mention
> this in your patch description. The naming VF610 suggests that the driver is
> very specific.
> That confuses me a little bit.
Sorry about that. Will add the necessary information in the next respin for
sure.
>
> >
> > >
> > > > +
> > > > +
> > > > +static int vf610_ocotp_write(void *context, const void *data, size_t
> > > > count)
> > > > +{
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int vf610_ocotp_read(void *context,
> > > > + const void *offset, size_t reg_size,
> > > > + void *val, size_t val_size)
> > > > +{
> > > > + void __iomem *ocotp_base = context;
> > > > + u32 *buf = val;
> > > > + u32 reg;
> > > > + int ret;
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(valid_fuse_addr); i++) {
> > > > + vf610_ocotp_set_timing(ocotp_base, ocotp_timing);
> > > > + ret = vf610_ocotp_wait_busy(ocotp_base + OCOTP_CTRL_REG);
> > > > + if (ret)
> > > > + return ret;
> > >
> > > Is it really necessary to set the timing in the loop, instead before?
> >
> > I will test it once. From my understanding of 35.3.1.5 I thought the timing
> > needs to explicitly programmed on every read. Perhaps I took it too
> > literally.
>
> It was only a question. If barebox does the same, it should be okay.
>
Yes, the code logic is completely similar to barebox except for changes like
how timeout is handled here in the wait busy function.
> >
> > >
> > > > +
> > > > + reg = readl(ocotp_base + OCOTP_CTRL_REG);
> > > > + reg &= ~OCOTP_CTRL_ADDR_MASK;
> > > > + reg &= ~OCOTP_CTRL_WR_UNLOCK_MASK;
> > > > + reg |= BF(valid_fuse_addr[i], OCOTP_CTRL_ADDR);
> > > > + writel(reg, ocotp_base + OCOTP_CTRL_REG);
> > > > +
> > > > + writel(OCOTP_READ_CTRL_READ_FUSE,
> > > > + ocotp_base + OCOTP_READ_CTRL_REG);
> > > > + ret = vf610_ocotp_wait_busy(ocotp_base + OCOTP_CTRL_REG);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + if (readl(ocotp_base) & OCOTP_CTRL_ERROR) {
> > > > + pr_err("Error reading from fuse address %d\n",
> > > > + valid_fuse_addr[i]);
> > >
> > > You could use dev_err() when storing vf610_ocotp_dev in the context.
> >
> > Ok.
> >
> > >
> > > > + writel(OCOTP_CTRL_ERROR, ocotp_base + OCOTP_CTRL_CLR);
> > >
> > > Shouldn't the function abort here?
> >
> > I am not sure about what usage I should follow here. I went for an
> > explicit error message and since 0xBADABADA is expected to be returned
> > on a read locked shadow register, the user would get the above for this
> > particular fuse address and the rest can still be valid since the TRM
> > mentions "subsequent reads to unlocked shadow locations will still work
> > successfully." So I did not abort on the error. Should I?
>
> In case you don't want to abort, a comment about the 0xBADABADA behavior would
> be helpful.
Ok. Will add the same.
>
> >
> > >
> > > > +
> > > > +
> > > > +static int vf610_ocotp_probe(struct platform_device *pdev)
> > > > +{
> > > > + struct vf610_ocotp_dev *ocotp_dev;
> > > > +
> > > > + ocotp_dev = devm_kzalloc(>dev,
> > > > + sizeof(struct vf610_ocotp_dev), GFP_KERNEL);
> > > > + if (!ocotp_dev)
> > > > + return -ENOMEM;
> > > > +
> > > > + ocotp_dev->dev = >dev;
> > > > +
> > > > + ocotp_dev->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > + ocotp_dev->base = devm_ioremap_resource(ocotp_dev->dev,
> > > > ocotp_dev->res);
> > > > + if (IS_ERR(ocotp_dev->base))
> > > > + return PTR_ERR(ocotp_dev->base);
> > > > +
> > > > + ocotp_dev->clk = devm_clk_get(ocotp_dev->dev, "ocotp");
> > > > + if (IS_ERR(ocotp_dev->clk)) {
> > > > + dev_err(ocotp_dev->dev, "failed getting clock, err = %ld\n",
> > > > + PTR_ERR(ocotp_dev->clk));
> > > > + return PTR_ERR(ocotp_dev->clk);
> > > > + }
> > > > +
> > > > + ocotp_regmap_config.max_register = resource_size(ocotp_dev->res) - 1;
> > >
> > > Looking at valid_fuse_addr shows me 0x3F as last valid register. So the
> > > rest
> > > of the buffer ( 0xD00 - sizeof(valid_fuse_addr) ) in case
[PATCH 3/4] ARM: dts: Include exynos5420-pinctrl after the nodes were defined
The dtc compiler combines all the defined nodes that have the same path so a device node definition can be in one file and later be extended in another one. That's the case of the Exynos5420 pinctrl device nodes that are defined in the exynos5420.dtsi file and extended in exynos5420-pinctrl.dtsi. But since the exynos5420.dtsi file includes the exynos5420-pinctrl.dtsi before the pinctrl device nodes are actually defined, the definition of the pinctrl device nodes happens in exynos5420-pinctrl.dtsi and are extended in exynos5420.dtsi. That is the opposite of the original intention so even when there is no difference in practice, the exynos5420-pinctrl.dtsi include should be moved at the end of the exynos5420.dtsi file after the pinctrl device nodes have been already defined. This will also allow to later change the exynos5420-pinctrl.dtsi file to use labels instead of full paths to extend the pinctrl nodes. Since keeping the include at the top, would cause a dtc build error due the pinctrl labels not being defined yet. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos5420.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index 534f27ceb10b..df9aee92ecf4 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -15,7 +15,6 @@ #include #include "exynos5.dtsi" -#include "exynos5420-pinctrl.dtsi" #include @@ -1166,3 +1165,5 @@ clocks = < CLK_UART3>, < CLK_SCLK_UART3>; clock-names = "uart", "clk_uart_baud0"; }; + +#include "exynos5420-pinctrl.dtsi" -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] ARM: dts: Include exynos5250-pinctrl after the nodes were defined
The dtc compiler combines all the defined nodes that have the same path so a device node definition can be in one file and later be extended in another one. That's the case of the Exynos5250 pinctrl device nodes that are defined in the exynos5250.dtsi file and extended in exynos5250-pinctrl.dtsi. But since the exynos5250.dtsi file includes the exynos5250-pinctrl.dtsi before the pinctrl device nodes are actually defined, the definition of the pinctrl device nodes happens in exynos5250-pinctrl.dtsi and are extended in exynos5250.dtsi. That is the opposite of the original intention so even when there is no difference in practice, the exynos5250-pinctrl.dtsi include should be moved at the end of the exynos5250.dtsi file after the pinctrl device nodes have been already defined. This will also allow to later change the exynos5250-pinctrl.dtsi file to use labels instead of full paths to extend the pinctrl nodes. Since keeping the include at the top, would cause a dtc build error due the pinctrl labels not being defined yet. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos5250.dtsi | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi index bf9bee67c416..4a1f88300a28 100644 --- a/arch/arm/boot/dts/exynos5250.dtsi +++ b/arch/arm/boot/dts/exynos5250.dtsi @@ -19,7 +19,6 @@ #include #include "exynos5.dtsi" -#include "exynos5250-pinctrl.dtsi" #include "exynos4-cpu-thermal.dtsi" #include @@ -1062,3 +1061,5 @@ clocks = < CLK_UART3>, < CLK_SCLK_UART3>; clock-names = "uart", "clk_uart_baud0"; }; + +#include "exynos5250-pinctrl.dtsi" -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] ARM: dts: Use labels instead of full paths for Exynos5 pinctrl nodes
Hello Kukjin and Krzysztof, This is a trivial series that changes Exynos5 pinctrl dtsi files to extend the pinctrl nodes using labels instead of full paths. Using labels is less error prone since a misstyped label leads to a build error while full paths can lead to the creation of a new node instead of overriding the original which makes the mistake harder to detect. I tested the changes by decompiling the Exynos5* dtbs and comparing before and after. The resulting dts were identical modulo some node ordering due the pinctrl include change. The series is composed of the following trivial patches: Javier Martinez Canillas (4): ARM: dts: Include exynos5250-pinctrl after the nodes were defined ARM: dts: Extend exynos5250-pinctrl nodes using labels instead of paths ARM: dts: Include exynos5420-pinctrl after the nodes were defined ARM: dts: Extend exynos5420-pinctrl nodes using labels instead of paths arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 1600 ++--- arch/arm/boot/dts/exynos5250.dtsi |3 +- arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 1411 + arch/arm/boot/dts/exynos5420.dtsi |3 +- 4 files changed, 1508 insertions(+), 1509 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ARM: dts: Extend exynos5250-pinctrl nodes using labels instead of paths
A previously defined Device Tree node, can be extended either by defining
a node using the same full path or by creating a label for the node and
referencing to it.
Using full paths is more error prone since if there was a typo error, a
new node will be created instead of extending the node as it was desired.
This will lead to run-time errors that could be hard to detect.
A misstyped label on the other hand, will cause a dtc compile error which
makes it easier to detect the mistake since happens at build-time instead.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 1600 ++---
1 file changed, 799 insertions(+), 801 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 886cfca044ac..880917e508b2 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -12,807 +12,805 @@
* published by the Free Software Foundation.
*/
-/ {
- pinctrl@1140 {
- gpa0: gpa0 {
- gpio-controller;
- #gpio-cells = <2>;
+_0 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpa1: gpa1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpa2: gpa2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb0: gpb0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb1: gpb1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb2: gpb2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpb3: gpb3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc0: gpc0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc1: gpc1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc2: gpc2 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpc3: gpc3 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpd0: gpd0 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpd1: gpd1 {
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- gpy0: gpy0 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy1: gpy1 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy2: gpy2 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy3: gpy3 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy4: gpy4 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy5: gpy5 {
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- gpy6: gpy6 {
-
Re: [PATCH 01/41] clocksource: asm9260: Migrate to new 'set-state' interface
On Thursday 18 June 2015 04:24 PM, Viresh Kumar wrote: > Migrate asm9260 driver to the new 'set-state' interface provided by > clockevents core, the earlier 'set-mode' interface is marked obsolete > now. > > This also enables us to implement callbacks for new states of clockevent > devices, for example: ONESHOT_STOPPED. Hi Viresh, Is this series (and other one touching arch/arm/*) specific to ARM event timers. Are you planning to fixup the drivers in arch/* or the respective maintainers need to follow suit. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
> -Original Message- > From: Olaf Hering > Sent: Tuesday, July 7, 2015 18:59 > Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature > > On Tue, Jul 07, Dexuan Cui wrote: > > > OK, removing the line seems better than 'default n', though both reproduce > > the same "# CONFIG_HYPERV_SOCK is not set". > > Perhaps "default VMBUS" (or whatever syntax is needed) may be the way to > enable it conditionally. > > Olaf Thanks, Olaf! I think we can use "default m if HYPERV". Paul, I'll remove the sentence "If unsure, say N." Thanks, -- Dexuan
[PATCH] net: systemport: Use eth_hw_addr_random
Use eth_hw_addr_random() instead of calling random_ether_addr().
Here, this change is setting addr_assign_type to NET_ADDR_RANDOM.
The Coccinelle semantic patch that performs this transformation
is as follows:
@@
identifier a,b;
@@
-random_ether_addr(a->b);
+eth_hw_addr_random(a);
Signed-off-by: Vaishali Thakkar
---
Note that this patch is compile tested only and I have used file
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c as a reference.
Also, original call didn't make assignment to NET_ADDR_RANDOM. So,
it would be good if someone can test this change.
---
drivers/net/ethernet/broadcom/bcmsysport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index 909ad7a..4566cdf 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -1793,7 +1793,7 @@ static int bcm_sysport_probe(struct platform_device *pdev)
macaddr = of_get_mac_address(dn);
if (!macaddr || !is_valid_ether_addr(macaddr)) {
dev_warn(>dev, "using random Ethernet MAC\n");
- random_ether_addr(dev->dev_addr);
+ eth_hw_addr_random(dev);
} else {
ether_addr_copy(dev->dev_addr, macaddr);
}
--
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 1/7] pinctrl: UniPhier: add UniPhier pinctrl core support
Hi Paul,
2015-07-07 18:14 GMT+09:00 Paul Bolle :
> (I only comment on 1/7, because it's not useful to repeat one remark
> seven times.)
>
> On ma, 2015-07-06 at 21:29 +0900, Masahiro Yamada wrote:
>> --- /dev/null
>> +++ b/drivers/pinctrl/uniphier/Kconfig
>
>> +config PINCTRL_UNIPHIER_CORE
>> + bool
>> + select PINMUX
>> + select GENERIC_PINCONF
>
>> --- /dev/null
>> +++ b/drivers/pinctrl/uniphier/Makefile
>
>> +obj-$(CONFIG_PINCTRL_UNIPHIER_CORE) += pinctrl-uniphier-core.o
>
>> --- /dev/null
>> +++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
>
>> +#include
>
>> +int uniphier_pinctrl_probe(struct platform_device *pdev,
>> +struct pinctrl_desc *desc,
>> +struct uniphier_pinctrl_socdata *socdata)
>> +{
>> + [...]
>
>> + desc->owner = THIS_MODULE;
>
>> + [...]
>> +}
>
> This series adds a number of bool Kconfig symbols. So, as far as I can
> see, the code it adds can only be built-in.
>
> This series also uses a number of module specific constructs (ie,
> THIS_MODULE, MODULE_DEVICE_TABLE, module_exit, MODULE_AUTHOR,
> MODULE_DESCRIPTION, and MODULE_LICENSE). So I wonder whether it was
> intended to make these new Kconfig symbols tristate instead?
>
I think it could be tristate if
- all the "pinctrl-names" properties are ripped off from the
mandatory devices in the device tree
- all the necessary pinmux settings have been done in the
boot-loader or somewhere.
But, such a use-case is really limited, so either boolean or tristate
makes sense for pinctrl drivers, I think.
Actually, most of pinctrl drivers are boolean, but most of them
conventionally have MODULE_AUTHOR, THIS_MODULE, etc.
I do not think it looks so weird. Thought?
$ git grep MODULE_AUTHOR -- drivers/pinctrl/
drivers/pinctrl/bcm/pinctrl-bcm281xx.c:MODULE_AUTHOR("Broadcom
Corporation ");
drivers/pinctrl/bcm/pinctrl-bcm281xx.c:MODULE_AUTHOR("Sherman Yin
");
drivers/pinctrl/bcm/pinctrl-bcm2835.c:MODULE_AUTHOR("Chris Boot, Simon
Arlott, Stephen Warren");
drivers/pinctrl/bcm/pinctrl-cygnus-mux.c:MODULE_AUTHOR("Ray Jui
");
drivers/pinctrl/berlin/berlin-bg2.c:MODULE_AUTHOR("Antoine Ténart
");
drivers/pinctrl/berlin/berlin-bg2cd.c:MODULE_AUTHOR("Antoine Ténart
");
drivers/pinctrl/berlin/berlin-bg2q.c:MODULE_AUTHOR("Antoine Ténart
");
drivers/pinctrl/freescale/pinctrl-imx1.c:MODULE_AUTHOR("Alexander
Shiyan ");
drivers/pinctrl/freescale/pinctrl-imx21.c:MODULE_AUTHOR("Alexander
Shiyan ");
drivers/pinctrl/freescale/pinctrl-imx23.c:MODULE_AUTHOR("Shawn Guo
");
drivers/pinctrl/freescale/pinctrl-imx25.c:MODULE_AUTHOR("Denis Carikli
");
drivers/pinctrl/freescale/pinctrl-imx27.c:MODULE_AUTHOR("Markus
Pargmann ");
drivers/pinctrl/freescale/pinctrl-imx28.c:MODULE_AUTHOR("Shawn Guo
");
drivers/pinctrl/freescale/pinctrl-imx35.c:MODULE_AUTHOR("Dong Aisheng
");
drivers/pinctrl/freescale/pinctrl-imx51.c:MODULE_AUTHOR("Dong Aisheng
");
drivers/pinctrl/freescale/pinctrl-imx53.c:MODULE_AUTHOR("Dong Aisheng
");
drivers/pinctrl/freescale/pinctrl-imx6dl.c:MODULE_AUTHOR("Shawn Guo
");
drivers/pinctrl/freescale/pinctrl-imx6q.c:MODULE_AUTHOR("Dong Aisheng
");
drivers/pinctrl/freescale/pinctrl-imx6sl.c:MODULE_AUTHOR("Shawn Guo
");
drivers/pinctrl/freescale/pinctrl-imx6sx.c:MODULE_AUTHOR("Anson Huang
");
drivers/pinctrl/freescale/pinctrl-imx7d.c:MODULE_AUTHOR("Anson Huang
");
drivers/pinctrl/intel/pinctrl-cherryview.c:MODULE_AUTHOR("Mika
Westerberg ");
drivers/pinctrl/intel/pinctrl-intel.c:MODULE_AUTHOR("Mathias Nyman
");
drivers/pinctrl/intel/pinctrl-intel.c:MODULE_AUTHOR("Mika Westerberg
");
drivers/pinctrl/intel/pinctrl-sunrisepoint.c:MODULE_AUTHOR("Mathias
Nyman ");
drivers/pinctrl/intel/pinctrl-sunrisepoint.c:MODULE_AUTHOR("Mika
Westerberg ");
drivers/pinctrl/mediatek/pinctrl-mt6397.c:MODULE_AUTHOR("Hongzhou Yang
");
drivers/pinctrl/mediatek/pinctrl-mt8127.c:MODULE_AUTHOR("Yingjoe Chen
");
drivers/pinctrl/mediatek/pinctrl-mt8135.c:MODULE_AUTHOR("Hongzhou Yang
");
drivers/pinctrl/mediatek/pinctrl-mt8173.c:MODULE_AUTHOR("Hongzhou Yang
");
drivers/pinctrl/mediatek/pinctrl-mtk-common.c:MODULE_AUTHOR("Hongzhou
Yang ");
drivers/pinctrl/meson/pinctrl-meson.c:MODULE_AUTHOR("Beniamino Galvani
");
drivers/pinctrl/mvebu/pinctrl-armada-370.c:MODULE_AUTHOR("Thomas
Petazzoni ");
drivers/pinctrl/mvebu/pinctrl-armada-375.c:MODULE_AUTHOR("Thomas
Petazzoni ");
drivers/pinctrl/mvebu/pinctrl-armada-38x.c:MODULE_AUTHOR("Thomas
Petazzoni ");
drivers/pinctrl/mvebu/pinctrl-armada-39x.c:MODULE_AUTHOR("Thomas
Petazzoni ");
drivers/pinctrl/mvebu/pinctrl-armada-xp.c:MODULE_AUTHOR("Thomas
Petazzoni ");
drivers/pinctrl/mvebu/pinctrl-dove.c:MODULE_AUTHOR("Sebastian
Hesselbarth ");
drivers/pinctrl/mvebu/pinctrl-kirkwood.c:MODULE_AUTHOR("Sebastian
Hesselbarth ");
drivers/pinctrl/mvebu/pinctrl-orion.c:MODULE_AUTHOR("Thomas Petazzoni
");
drivers/pinctrl/nomadik/pinctrl-abx500.c:MODULE_AUTHOR("Patrice
Chotard ");
drivers/pinctrl/nomadik/pinctrl-nomadik.c:MODULE_AUTHOR("Prafulla
WADASKAR and
[PATCH] uio: uio_fsl_elbc_gpcm: Use module_platform_driver
Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/uio/uio_fsl_elbc_gpcm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/uio/uio_fsl_elbc_gpcm.c b/drivers/uio/uio_fsl_elbc_gpcm.c
index b6cac91..2bcf80c 100644
--- a/drivers/uio/uio_fsl_elbc_gpcm.c
+++ b/drivers/uio/uio_fsl_elbc_gpcm.c
@@ -480,19 +480,7 @@ static struct platform_driver uio_fsl_elbc_gpcm_driver = {
.probe = uio_fsl_elbc_gpcm_probe,
.remove = uio_fsl_elbc_gpcm_remove,
};
-
-static int __init uio_fsl_elbc_gpcm_init(void)
-{
- return platform_driver_register(_fsl_elbc_gpcm_driver);
-}
-
-static void __exit uio_fsl_elbc_gpcm_exit(void)
-{
- platform_driver_unregister(_fsl_elbc_gpcm_driver);
-}
-
-module_init(uio_fsl_elbc_gpcm_init);
-module_exit(uio_fsl_elbc_gpcm_exit);
+module_platform_driver(uio_fsl_elbc_gpcm_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("John Ogness ");
--
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 V2] acpi-cpufreq: replace per_cpu with driver_data of policy
Hi Dmitry, On 07-07-15, 10:11, Dmitry Torokhov wrote: > > + data = policy->driver_data; > > + cpufreq_cpu_put(policy); > > If we put policy here can we guarantee that memory pointed to by data > stays valid? Shoudln't we issue cpufreq_cpu_put(policy) after we done > assessing the pointer? Ideally yes, you are right. But this was a special case as a callback of the cpufreq-driver is being called and any such issues must be handled at the core level, it at all they are relevant. So probably we can do cpufreq_cpu_put() as soon as we have used it. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: UniPhier: add USB EHCI device nodes
Hi Rob,
2015-07-07 23:53 GMT+09:00 Rob Herring :
> On Sun, Jul 5, 2015 at 10:47 PM, Masahiro Yamada
> wrote:
>> Get USB 2.0 host controllers available with generic-ehci bindings.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>
>> diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> index 1261e6d..b042711 100644
>> --- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> +++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
>> @@ -127,6 +127,27 @@
>> reg = <0x5980 0x2000>;
>> };
>>
>> + usb0: usb@5a800100 {
>> + compatible = "generic-ehci";
>
> You should also have a chip specific compatible string in addition to
> generic-ehci.
OK, will do.
I will wait a bit more before sending v2
in case someone might have some comments on this series.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: Use module_platform_driver
Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/scsi/jazz_esp.c | 14 +-
drivers/scsi/mac_esp.c| 14 +-
drivers/scsi/qlogicpti.c | 14 +-
drivers/scsi/sni_53c710.c | 14 +-
drivers/scsi/sun3x_esp.c | 14 +-
drivers/scsi/sun_esp.c| 14 +-
6 files changed, 6 insertions(+), 78 deletions(-)
diff --git a/drivers/scsi/jazz_esp.c b/drivers/scsi/jazz_esp.c
index 9aaa74e..003c455 100644
--- a/drivers/scsi/jazz_esp.c
+++ b/drivers/scsi/jazz_esp.c
@@ -229,20 +229,8 @@ static struct platform_driver esp_jazz_driver = {
},
};
-static int __init jazz_esp_init(void)
-{
- return platform_driver_register(_jazz_driver);
-}
-
-static void __exit jazz_esp_exit(void)
-{
- platform_driver_unregister(_jazz_driver);
-}
-
MODULE_DESCRIPTION("JAZZ ESP SCSI driver");
MODULE_AUTHOR("Thomas Bogendoerfer (tsbog...@alpha.franken.de)");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
-
-module_init(jazz_esp_init);
-module_exit(jazz_esp_exit);
+module_platform_driver(esp_jazz_driver);
diff --git a/drivers/scsi/mac_esp.c b/drivers/scsi/mac_esp.c
index 14c0334..30906ae 100644
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -620,21 +620,9 @@ static struct platform_driver esp_mac_driver = {
},
};
-static int __init mac_esp_init(void)
-{
- return platform_driver_register(_mac_driver);
-}
-
-static void __exit mac_esp_exit(void)
-{
- platform_driver_unregister(_mac_driver);
-}
-
MODULE_DESCRIPTION("Mac ESP SCSI driver");
MODULE_AUTHOR("Finn Thain ");
MODULE_LICENSE("GPL v2");
MODULE_VERSION(DRV_VERSION);
MODULE_ALIAS("platform:" DRV_MODULE_NAME);
-
-module_init(mac_esp_init);
-module_exit(mac_esp_exit);
+module_platform_driver(esp_mac_driver);
diff --git a/drivers/scsi/qlogicpti.c b/drivers/scsi/qlogicpti.c
index 676385f..a63c6ea 100644
--- a/drivers/scsi/qlogicpti.c
+++ b/drivers/scsi/qlogicpti.c
@@ -1460,21 +1460,9 @@ static struct platform_driver qpti_sbus_driver = {
.remove = qpti_sbus_remove,
};
-static int __init qpti_init(void)
-{
- return platform_driver_register(_sbus_driver);
-}
-
-static void __exit qpti_exit(void)
-{
- platform_driver_unregister(_sbus_driver);
-}
-
MODULE_DESCRIPTION("QlogicISP SBUS driver");
MODULE_AUTHOR("David S. Miller (da...@davemloft.net)");
MODULE_LICENSE("GPL");
MODULE_VERSION("2.1");
MODULE_FIRMWARE("qlogic/isp1000.bin");
-
-module_init(qpti_init);
-module_exit(qpti_exit);
+module_platform_driver(qpti_sbus_driver);
diff --git a/drivers/scsi/sni_53c710.c b/drivers/scsi/sni_53c710.c
index 7627807..eb74dbb 100644
--- a/drivers/scsi/sni_53c710.c
+++ b/drivers/scsi/sni_53c710.c
@@ -139,16 +139,4 @@ static struct platform_driver snirm710_driver = {
.name = "snirm_53c710",
},
};
-
-static int __init snirm710_init(void)
-{
- return platform_driver_register(_driver);
-}
-
-static void __exit snirm710_exit(void)
-{
- platform_driver_unregister(_driver);
-}
-
-module_init(snirm710_init);
-module_exit(snirm710_exit);
+module_platform_driver(snirm710_driver);
diff --git a/drivers/scsi/sun3x_esp.c b/drivers/scsi/sun3x_esp.c
index e26e81d..c1214bf 100644
--- a/drivers/scsi/sun3x_esp.c
+++ b/drivers/scsi/sun3x_esp.c
@@ -298,21 +298,9 @@ static struct platform_driver esp_sun3x_driver = {
},
};
-static int __init sun3x_esp_init(void)
-{
- return platform_driver_register(_sun3x_driver);
-}
-
-static void __exit sun3x_esp_exit(void)
-{
- platform_driver_unregister(_sun3x_driver);
-}
-
MODULE_DESCRIPTION("Sun3x ESP SCSI driver");
MODULE_AUTHOR("Thomas Bogendoerfer (tsbog...@alpha.franken.de)");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
-
-module_init(sun3x_esp_init);
-module_exit(sun3x_esp_exit);
+module_platform_driver(esp_sun3x_driver);
MODULE_ALIAS("platform:sun3x_esp");
diff --git a/drivers/scsi/sun_esp.c b/drivers/scsi/sun_esp.c
index 7b6d4c2..ecbe4c2 100644
--- a/drivers/scsi/sun_esp.c
+++ b/drivers/scsi/sun_esp.c
@@ -639,20 +639,8 @@ static struct platform_driver esp_sbus_driver = {
.remove = esp_sbus_remove,
};
-static int __init sunesp_init(void)
-{
- return platform_driver_register(_sbus_driver);
-}
-
-static void __exit sunesp_exit(void)
-{
- platform_driver_unregister(_sbus_driver);
-}
-
Re: [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id
On 2015. 7. 7., at PM 10:00, Krzysztof Kozlowski
wrote:
>
> The platform_device_id is not modified by the driver and core uses it as
> const.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/fbdev/s3c-fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
> index 7e3a05fc47aa..f72dd12456f9 100644
> --- a/drivers/video/fbdev/s3c-fb.c
> +++ b/drivers/video/fbdev/s3c-fb.c
> @@ -1938,7 +1938,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
>},
> };
>
> -static struct platform_device_id s3c_fb_driver_ids[] = {
> +static const struct platform_device_id s3c_fb_driver_ids[] = {
>{
>.name= "s3c-fb",
>.driver_data= (unsigned long)_fb_data_64xx,
> --
> 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] scsi: Use module_pci_driver
Use module_pci_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return pci_register_driver(); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { pci_unregister_driver(); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_pci_driver;
@@
-module_exit(e);
+module_pci_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/scsi/a100u2w.c | 14 +-
drivers/scsi/am53c974.c | 14 +-
drivers/scsi/dc395x.c | 25 +
drivers/scsi/dmx3191d.c | 14 +-
drivers/scsi/hpsa.c | 18 +-
drivers/scsi/initio.c | 14 +-
drivers/scsi/mvumi.c| 21 +
drivers/scsi/wd719x.c | 14 +-
8 files changed, 8 insertions(+), 126 deletions(-)
diff --git a/drivers/scsi/a100u2w.c b/drivers/scsi/a100u2w.c
index cac6b37..927c1a4 100644
--- a/drivers/scsi/a100u2w.c
+++ b/drivers/scsi/a100u2w.c
@@ -1222,19 +1222,7 @@ static struct pci_driver inia100_pci_driver = {
.remove = inia100_remove_one,
};
-static int __init inia100_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit inia100_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
MODULE_DESCRIPTION("Initio A100U2W SCSI driver");
MODULE_AUTHOR("Initio Corporation");
MODULE_LICENSE("Dual BSD/GPL");
-
-module_init(inia100_init);
-module_exit(inia100_exit);
+module_pci_driver(inia100_pci_driver);
diff --git a/drivers/scsi/am53c974.c b/drivers/scsi/am53c974.c
index beea30e..0234b38 100644
--- a/drivers/scsi/am53c974.c
+++ b/drivers/scsi/am53c974.c
@@ -556,16 +556,6 @@ static struct pci_driver am53c974_driver = {
.remove = pci_esp_remove_one,
};
-static int __init am53c974_module_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-static void __exit am53c974_module_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
MODULE_DESCRIPTION("AM53C974 SCSI driver");
MODULE_AUTHOR("Hannes Reinecke ");
MODULE_LICENSE("GPL");
@@ -577,6 +567,4 @@ MODULE_PARM_DESC(am53c974_debug, "Enable debugging");
module_param(am53c974_fenab, bool, 0444);
MODULE_PARM_DESC(am53c974_fenab, "Enable 24-bit DMA transfer sizes");
-
-module_init(am53c974_module_init);
-module_exit(am53c974_module_exit);
+module_pci_driver(am53c974_driver);
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index 5ee7f44..a0a6eaf 100644
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -4870,30 +4870,7 @@ static struct pci_driver dc395x_driver = {
.probe = dc395x_init_one,
.remove = dc395x_remove_one,
};
-
-
-/**
- * dc395x_module_init - Module initialization function
- *
- * Used by both module and built-in driver to initialise this driver.
- **/
-static int __init dc395x_module_init(void)
-{
- return pci_register_driver(_driver);
-}
-
-
-/**
- * dc395x_module_exit - Module cleanup function.
- **/
-static void __exit dc395x_module_exit(void)
-{
- pci_unregister_driver(_driver);
-}
-
-
-module_init(dc395x_module_init);
-module_exit(dc395x_module_exit);
+module_pci_driver(dc395x_driver);
MODULE_AUTHOR("C.L. Huang / Erich Chen / Kurt Garloff");
MODULE_DESCRIPTION("SCSI host adapter driver for Tekram TRM-S1040 based
adapters: Tekram DC395 and DC315 series");
diff --git a/drivers/scsi/dmx3191d.c b/drivers/scsi/dmx3191d.c
index 3e08812..2913fc7 100644
--- a/drivers/scsi/dmx3191d.c
+++ b/drivers/scsi/dmx3191d.c
@@ -143,19 +143,7 @@ static struct pci_driver dmx3191d_pci_driver = {
.probe = dmx3191d_probe_one,
.remove = dmx3191d_remove_one,
};
-
-static int __init dmx3191d_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit dmx3191d_exit(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
-module_init(dmx3191d_init);
-module_exit(dmx3191d_exit);
+module_pci_driver(dmx3191d_pci_driver);
MODULE_AUTHOR("Massimo Piccioni ");
MODULE_DESCRIPTION("Domex DMX3191D SCSI driver");
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 1dafeb4..3f04f42 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -8697,20 +8697,6 @@ static void hpsa_drain_accel_commands(struct ctlr_info
*h)
} while (1);
}
-/*
- * This is it. Register the PCI driver information for the cards we control
- * the OS will call our registered routines when it finds one of our cards.
- */
-static int __init hpsa_init(void)
-{
- return pci_register_driver(_pci_driver);
-}
-
-static void __exit hpsa_cleanup(void)
-{
- pci_unregister_driver(_pci_driver);
-}
-
static void __attribute__((unused)) verify_offsets(void)
{
#define
Re: [PATCH v3 1/3] IRQ/Gic-V3: Add mbigen driver to support mbigen interrupt controller
Hi Thomas:
在 2015/7/6 20:33, Thomas Gleixner 写道:
> On Mon, 6 Jul 2015, Ma Jun wrote:
>
>> +/**
>> + * get_mbigen_node_type: get the mbigen node type
>> + * @nid: the mbigen node value
>> + * return 0: evnent id of interrupt connected to this node can be changed.
>> + * return 1: evnent id of interrupt connected to this node cant be changed.
>> + */
>> +static int get_mbigen_node_type(int nid)
>> +{
>> +if (nid > MG_NR) {
>> +pr_warn("MBIGEN: Device ID exceeds max number!\n");
>> +return 1;
>> +}
>> +if ((nid == 0) || (nid == 5) || (nid > 7))
>> +return 0;
>> +else
>> +return 1;
>
> Oh no. We do not hardcode such properties into a driver. That wants to
> be in the device tree and set as a property in the node data structure.
>
Ok,I will move this to device tree
>> +static int mbigen_write_msg(struct irq_data *d, struct msi_msg *msg)
>> +{
>> +struct mbigen_chip *chip = d->domain->host_data;
>> +void __iomem *addr;
>> +u32 nid, val, offset;
>> +int ret = 0;
>> +
>> +nid = GET_NODE_NUM(d->hwirq);
>> +ret = get_mbigen_node_type(nid);
>> +if (ret)
>> +return 0;
>
> Care to explain what this does? It seems for some nodes you cannot
> write the msi message. So how is that supposed to work? How is that
> interrupt controlled (mask/unmask ...) ?
>
This function is used to write irq event id into vector register.Depends on
hardware design, write operation is permitted in some mbigen node(nid=0,5,and
>7),
For other mbigen node, this register is read only.
But only vector register has this problem. Other registers are ok for
read/write.
>> +
>> +ofst = hwirq / 32 * 4;
>> +mask = 1 << (hwirq % 32);
>> +
>> +addr = chip->base + MBIGEN_TYPE_REG_ADDR(nid, ofst);
>> +raw_spin_lock(>lock);
>> +val = readl_relaxed(addr);
>> +
>> +if (type == IRQ_TYPE_LEVEL_HIGH)
>> +val |= mask;
>> +else if (type == IRQ_TYPE_EDGE_RISING)
>> +val &= ~mask;
>> +
>> +writel_relaxed(val, addr);
>> +raw_spin_unlock(>lock);
>
> What is the lock protecting here? The read/write access to a per
> interrupt register? Why is the per interrupt descriptor lock not
> sufficient and why does the above write_msg not requited locking?
>
yes,lock protecting is not necessary here.
>> +return 0;
[...]
>> +static int mbigen_domain_alloc(struct irq_domain *domain, unsigned int virq,
>> + unsigned int nr_irqs, void *arg)
>> +{
>> +struct mbigen_chip *chip = domain->host_data;
>> +struct of_phandle_args *irq_data = arg;
>> +irq_hw_number_t hwirq;
>> +u32 nid, dev_id, mbi_lines;
>> +struct mbigen_node *mgn_node;
>> +struct mbigen_device *mgn_dev;
>> +msi_alloc_info_t out_arg;
>> +int ret = 0, i;
>> +
>> +/* OF style allocation, one interrupt at a time */
>
> -ENOPARSE
>
what's this mean? I didn't find this definition in kernel code
>> +WARN_ON(nr_irqs != 1);
>> +
>> +dev_id = irq_data->args[0];
>> +nid = irq_data->args[3];
>> +hwirq = COMPOSE_HWIRQ(nid, irq_data->args[2]);
>> +
>> +mgn_node = get_mbigen_node(chip, nid);
>> +if (!mgn_node)
>> +return -ENODEV;
>> +
>> +mgn_dev = mbigen_create_device(mgn_node, irq_data->np, virq, nr_irqs);
>> +if (!mgn_dev)
>> +return -ENOMEM;
>
> Leaks the node allocation.
>
>> +
>> +mbi_lines = irq_data->args[1];
>> +
>> +ret = its_msi_prepare(domain, dev_id, mbi_lines, _arg);
>
> This looks wrong. Why do you have an explicit call for this in the
> allocation function?
>
> msi_domain_ops.msi_prepare is called from the core code and you should
> provide a msi_prepare callback which does the necessary initialization
> and invokes the parent domains msi_prepare callback.
>
According to Marc suggestion, I changed the ITS code so I can use
its_msi_prepare
function in my code.
So,do you mean i should not call this function directly ?
How about make this code likes below in mbigen driver:
static struct msi_domain_ops mbigen_domain_ops = {
.msi_prepare= mbigen_domain_ops_prepare,
};
static int mbigen_domain_ops_prepare(struct irq_domain *domain, struct device
*dev,
int nvec, msi_alloc_info_t *info)
{
return its_msi_prepare(domain, dev_id, count, info);
}
>> +if (ret)
>> +return ret;
>
> Leaks the node allocation and the device.
>
>> +
>> +ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, _arg);
>> +if (ret < 0)
>> +return ret;
>> +
>> +for (i = 0; i < nr_irqs; i++) {
>
> This loop is required because?
>
Although we know this value is 1, I think use loop seems better
>> +irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
>> +_irq_chip, mgn_dev);
>> +}
>> +
>> +return ret;
>
>> +/*
>> + * Early initialization as an interrupt controller
>> + */
>>
Re: [PATCH 1/1] infiniband: Remove redundant NULL check before kfree
Hello, >> +for (i = 0; i < dev->caps.num_ports; i++) >> +kfree(dm[i]); >> goto out; >> } >> } >> -- >> 1.7.9.5 >> > >If you are going to change this, you might as well make it 100% correct: > >i—-; >while (i >= 0) > kfree(dm[i]); > >Then you don’t have to worry about whether kfree works on NULL, every item you >free will be guaranteed to be non-NULL. Thanks for suggestion :) Sent new patch with described changes, I was thinking one more thing. In below code :- if (!ibdev->sriov.is_going_down) queue_work(ibdev->sriov.demux[i].ud_wq, [i]->work); spin_unlock_irqrestore(>sriov.going_down_lock, flags); } out: kfree(dm); return; dm is freed after queue_work, is it correct to free dm when other dm[i] are allocated ? i did not get it. Thanks Maninder
Re: [PATCH v2 6/7] crypto: omap-aes: Add support for GCM mode
On Tue, Jul 07, 2015 at 09:01:48PM +0530, Lokesh Vutla wrote:
>
> +static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
> + struct aead_request *req)
> +{
> + void *buf_in;
> + int pages, alen, clen, cryptlen, nsg;
> + struct crypto_aead *aead = crypto_aead_reqtfm(req);
> + unsigned int authlen = crypto_aead_authsize(aead);
> + u32 dec = !(dd->flags & FLAGS_ENCRYPT);
> + struct scatterlist *input, *assoc, tmp[2];
> +
> + alen = ALIGN(req->assoclen, AES_BLOCK_SIZE);
> + cryptlen = req->cryptlen - (dec * authlen);
> + clen = ALIGN(cryptlen, AES_BLOCK_SIZE);
> +
> + dd->sgs_copied = 0;
> +
> + nsg = !!(req->assoclen && req->cryptlen);
> +
> + assoc = >src[0];
> + sg_init_table(dd->in_sgl, nsg + 1);
> + if (req->assoclen) {
> + if (omap_aes_check_aligned(assoc, req->assoclen)) {
> + dd->sgs_copied |= AES_ASSOC_DATA_COPIED;
> + pages = get_order(alen);
> + buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
> + if (!buf_in) {
> + pr_err("Couldn't allocate for unaligncases.\n");
> + return -1;
> + }
> +
> + scatterwalk_map_and_copy(buf_in, assoc, 0,
> + req->assoclen, 0);
> + memset(buf_in + req->assoclen, 0, alen - req->assoclen);
> + } else {
> + buf_in = sg_virt(req->assoc);
req->assoc is now obsolete. Did you test this code?
> +static int do_encrypt_iv(struct aead_request *req, u32 *tag)
> +{
> + struct scatterlist iv_sg;
> + struct ablkcipher_request *ablk_req;
> + struct crypto_ablkcipher *tfm;
> + struct tcrypt_result result;
> + struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
> + int ret = 0;
> +
> + tfm = crypto_alloc_ablkcipher("ctr(aes)", 0, 0);
Ugh, you cannot allocate crypto transforms in the data path. You
should allocate it in init instead. Also using ctr(aes) is overkill.
Just use aes and do the xor by hand.
> +static int omap_aes_gcm_crypt(struct aead_request *req, unsigned long mode)
> +{
> + struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
> + struct omap_aes_reqctx *rctx = aead_request_ctx(req);
> + struct crypto_aead *aead = crypto_aead_reqtfm(req);
> + unsigned int authlen = crypto_aead_authsize(aead);
> + struct omap_aes_dev *dd;
> + __be32 counter = cpu_to_be32(1);
> + int err;
> +
> + memset(ctx->auth_tag, 0, sizeof(ctx->auth_tag));
The ctx is shared memory and you must not write to it as multiple
requests can be called on the same tfm. Use rctx instead.
> + memcpy(req->iv + 12, , 4);
The IV is only 12 bytes long so you're corrupting memory here.
You should use rctx here too.
> + if (req->assoclen + req->cryptlen == 0) {
> + scatterwalk_map_and_copy(ctx->auth_tag, req->dst, 0, authlen,
> + 1);
> + return 0;
> + }
How can this be right? Did you enable the selftest?
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] mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used
Hi, Alexey.
On 06/25/2015 05:25 PM, Alexey Brodkin wrote:
> As per DW MobileStorage databook "each descriptor can transfer up to 4kB
> of data in chained mode", moreover buffer size that is put in "des1" is
> limited to 13 bits, i.e. for example on attempt to
> IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written
> will be 0.
>
> On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in
> SG-list of 8kB size and that leads to unpredictable behavior of the
> SD/MMC controller.
I didn't see your problem, since i didn't test with 8K PAGE_SIZE.
But I think your patch is reasonable.
As possible, I want to know in more detail what unpredictable behavior.
(Just stuck behavior?)
>
> In particular on write to FAT partition of SD-card the controller will
> stuck in the middle of DMA transaction.
>
> Solution to the problem is simple - we need to pass large (> 4kB) data
> buffers to the controller via multiple descriptors. And that's what
> that change does.
>
> What's interesting I did try original driver on same platform but
> configured with 4kB PAGE_SIZE and may confirm that data blocks passed
> in SG-list to dw_mmc never exeed 4kB limit - that explains why nobody
> ever faced a problem I did.
>
> Signed-off-by: Alexey Brodkin
> Cc: Seungwon Jeon
> Cc: Jaehoon Chung
> Cc: Ulf Hansson
> Cc: arc-linux-...@synopsys.com
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/mmc/host/dw_mmc.c | 109
> ++
> 1 file changed, 71 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 40e9d8e..e41fb74 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -99,6 +99,9 @@ struct idmac_desc {
>
> __le32 des3; /* buffer 2 physical address */
> };
> +
> +/* Each descriptor can transfer up to 4KB of data in chained mode */
> +#define DW_MCI_DESC_DATA_LENGTH 0x1000
> #endif /* CONFIG_MMC_DW_IDMAC */
>
> static bool dw_mci_reset(struct dw_mci *host);
> @@ -462,66 +465,96 @@ static void dw_mci_idmac_complete_dma(struct dw_mci
> *host)
> static void dw_mci_translate_sglist(struct dw_mci *host, struct mmc_data
> *data,
> unsigned int sg_len)
> {
> + unsigned int desc_len;
> int i;
> if (host->dma_64bit_address == 1) {
> - struct idmac_desc_64addr *desc = host->sg_cpu;
> + struct idmac_desc_64addr *desc_first, *desc_last, *desc;
Why it needs desc_first?
> +
> + desc_first = desc_last = desc = host->sg_cpu;
>
> - for (i = 0; i < sg_len; i++, desc++) {
> + for (i = 0; i < sg_len; i++) {
> unsigned int length = sg_dma_len(>sg[i]);
> u64 mem_addr = sg_dma_address(>sg[i]);
>
> - /*
> - * Set the OWN bit and disable interrupts for this
> - * descriptor
> - */
> - desc->des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
> - IDMAC_DES0_CH;
> - /* Buffer length */
> - IDMAC_64ADDR_SET_BUFFER1_SIZE(desc, length);
> -
> - /* Physical address to DMA to/from */
> - desc->des4 = mem_addr & 0x;
> - desc->des5 = mem_addr >> 32;
> + for ( ; length ; desc++) {
Is there no infinite loop case?
Best Regards,
Jaehoon Chung
> + desc_len = (length <= DW_MCI_DESC_DATA_LENGTH) ?
> +length : DW_MCI_DESC_DATA_LENGTH;
> +
> + length -= desc_len;
> +
> + /*
> + * Set the OWN bit and disable interrupts
> + * for this descriptor
> + */
> + desc->des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
> + IDMAC_DES0_CH;
> +
> + /* Buffer length */
> + IDMAC_64ADDR_SET_BUFFER1_SIZE(desc, desc_len);
> +
> + /* Physical address to DMA to/from */
> + desc->des4 = mem_addr & 0x;
> + desc->des5 = mem_addr >> 32;
> +
> + /* Update physical address for the next desc */
> + mem_addr += desc_len;
> +
> + /* Save pointer to the last descriptor */
> + desc_last = desc;
> + }
> }
>
> /* Set first descriptor */
> - desc = host->sg_cpu;
> - desc->des0 |= IDMAC_DES0_FD;
> + desc_first->des0 |= IDMAC_DES0_FD;
>
> /* Set last descriptor */
> -
[PATCH v2] infiniband: free only allocated items
o If allocation of dm fails, no need to free it.
o Free only allocated items.
Signed-off-by: Maninder Singh
---
drivers/infiniband/hw/mlx4/main.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 067a691..253498f 100644
--- a/drivers/infiniband/hw/mlx4/main.c
+++ b/drivers/infiniband/hw/mlx4/main.c
@@ -2669,17 +2669,15 @@ static void do_slave_init(struct mlx4_ib_dev *ibdev,
int slave, int do_init)
dm = kcalloc(ports, sizeof(*dm), GFP_ATOMIC);
if (!dm) {
pr_err("failed to allocate memory for tunneling qp update\n");
- goto out;
+ return;
}
for (i = 0; i < ports; i++) {
dm[i] = kmalloc(sizeof (struct mlx4_ib_demux_work), GFP_ATOMIC);
if (!dm[i]) {
pr_err("failed to allocate memory for tunneling qp
update work struct\n");
- for (i = 0; i < dev->caps.num_ports; i++) {
- if (dm[i])
- kfree(dm[i]);
- }
+ while (--i >= 0)
+ kfree(dm[i]);
goto out;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,1/2] powerpc/numa: fix cpu_to_node() usage during boot
On Thu, 2015-02-07 at 23:02:02 UTC, Nishanth Aravamudan wrote: > Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we > have an ordering issue during boot with early calls to cpu_to_node(). "now that .." implies we changed something and broke this. What commit was it that changed the behaviour? > The value returned by those calls now depend on the per-cpu area being > setup, but that is not guaranteed to be the case during boot. Instead, > we need to add an early_cpu_to_node() which doesn't use the per-CPU area > and call that from certain spots that are known to invoke cpu_to_node() > before the per-CPU areas are not configured. > > On an example 2-node NUMA system with the following topology: > > available: 2 nodes (0-1) > node 0 cpus: 0 1 2 3 > node 0 size: 2029 MB > node 0 free: 1753 MB > node 1 cpus: 4 5 6 7 > node 1 size: 2045 MB > node 1 free: 1945 MB > node distances: > node 0 1 > 0: 10 40 > 1: 40 10 > > we currently emit at boot: > > [0.00] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7 > > After this commit, we correctly emit: > > [0.00] pcpu-alloc: [0] 0 1 2 3 [1] 4 5 6 7 So it looks fairly sane, and I guess it's a bug fix. But I'm a bit reluctant to put it in straight away without some time in next. It looks like the symptom is that the per-cpu areas are all allocated on node 0, is that all that goes wrong? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [trace] kernel BUG at kernel/sched/core.c:2881!
On Tue, Jul 07, 2015 at 06:37:11PM -0400, Steven Rostedt wrote:
> On Tue, 7 Jul 2015 15:03:31 -0400
> Steven Rostedt wrote:
>
> > On Tue, 7 Jul 2015 11:06:27 -0400
> > Steven Rostedt wrote:
> >
> > > On Tue, 30 Jun 2015 22:18:03 +0800
> > > Fengguang Wu wrote:
> > >
> > > > Hi Rostedt,
> > > >
> > > > FYI, this merge changes kernel crash to some more obvious kernel BUG
> > > > message. If it's still not helpful, I can try bisect the old crash
> > > > or split up the merge and bisect into them.
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > >
> > >
> > > This has been a bug for some time. Does this fix it?
> > >
> >
> > Test this patch instead, this is the one I'm testing and will be
> > pushing to Linus.
> >
>
> Um, third time's a charm. Found yet another area that can recurse.
Steven, it works!
Tested-by: Fengguang Wu
Thanks,
Fengguang
> -- Steve
>
> >From efd39d5241abf5bde995b1d324d619cca0a23b71 Mon Sep 17 00:00:00 2001
> From: "Steven Rostedt (Red Hat)"
> Date: Tue, 7 Jul 2015 15:05:03 -0400
> Subject: [PATCH] tracing: Have branch tracer use recursive field of task
> struct
>
> Fengguang Wu's tests triggered a bug in the branch tracer's start up
> test when CONFIG_DEBUG_PREEMPT set. This was because that config
> adds some debug logic in the per cpu field, which calls back into
> the branch tracer.
>
> The branch tracer has its own recursive checks, but uses a per cpu
> variable to implement it. If retrieving the per cpu variable calls
> back into the branch tracer, you can see how things will break.
>
> Instead of using a per cpu variable, use the trace_recursion field
> of the current task struct. Simply set a bit when entering the
> branch tracing and clear it when leaving. If the bit is set on
> entry, just don't do the tracing.
>
> There's also the case with lockdep, as the local_irq_save() called
> before the recursion can also trigger code that can call back into
> the function. Changing that to a raw_local_irq_save() will protect
> that as well.
>
> This prevents the recursion and the inevitable crash that follows.
>
> Link: http://lkml.kernel.org/r/20150630141803.ga28...@wfg-t540p.sh.intel.com
>
> Cc: sta...@vger.kernel.org # 3.10+
> Reported-by: Fengguang Wu
> Signed-off-by: Steven Rostedt
> ---
> kernel/trace/trace.h| 1 +
> kernel/trace/trace_branch.c | 17 ++---
> 2 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index f060716b02ae..74bde81601a9 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -444,6 +444,7 @@ enum {
>
> TRACE_CONTROL_BIT,
>
> + TRACE_BRANCH_BIT,
> /*
> * Abuse of the trace_recursion.
> * As we need a way to maintain state if we are tracing the function
> diff --git a/kernel/trace/trace_branch.c b/kernel/trace/trace_branch.c
> index a87b43f49eb4..e2e12ad3186f 100644
> --- a/kernel/trace/trace_branch.c
> +++ b/kernel/trace/trace_branch.c
> @@ -36,9 +36,12 @@ probe_likely_condition(struct ftrace_branch_data *f, int
> val, int expect)
> struct trace_branch *entry;
> struct ring_buffer *buffer;
> unsigned long flags;
> - int cpu, pc;
> + int pc;
> const char *p;
>
> + if (current->trace_recursion & TRACE_BRANCH_BIT)
> + return;
> +
> /*
>* I would love to save just the ftrace_likely_data pointer, but
>* this code can also be used by modules. Ugly things can happen
> @@ -49,10 +52,10 @@ probe_likely_condition(struct ftrace_branch_data *f, int
> val, int expect)
> if (unlikely(!tr))
> return;
>
> - local_irq_save(flags);
> - cpu = raw_smp_processor_id();
> - data = per_cpu_ptr(tr->trace_buffer.data, cpu);
> - if (atomic_inc_return(>disabled) != 1)
> + raw_local_irq_save(flags);
> + current->trace_recursion |= TRACE_BRANCH_BIT;
> + data = this_cpu_ptr(tr->trace_buffer.data);
> + if (atomic_read(>disabled))
> goto out;
>
> pc = preempt_count();
> @@ -81,8 +84,8 @@ probe_likely_condition(struct ftrace_branch_data *f, int
> val, int expect)
> __buffer_unlock_commit(buffer, event);
>
> out:
> - atomic_dec(>disabled);
> - local_irq_restore(flags);
> + current->trace_recursion &= ~TRACE_BRANCH_BIT;
> + raw_local_irq_restore(flags);
> }
>
> static inline
> --
> 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 v2 5/7] crypto: aead: Add aead_request_cast() api
On Tue, Jul 07, 2015 at 09:01:47PM +0530, Lokesh Vutla wrote:
> Add aead_request_cast() api to get pointer to aead_request
> from cryto_async_request.
>
> Signed-off-by: Lokesh Vutla
> ---
> include/crypto/internal/aead.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/crypto/internal/aead.h b/include/crypto/internal/aead.h
> index 4b25471..0423fa5 100644
> --- a/include/crypto/internal/aead.h
> +++ b/include/crypto/internal/aead.h
> @@ -157,6 +157,12 @@ static inline unsigned int
> crypto_aead_maxauthsize(struct crypto_aead *aead)
> return crypto_aead_alg_maxauthsize(crypto_aead_alg(aead));
> }
>
> +static inline struct aead_request *aead_request_cast(
> + struct crypto_async_request *req)
> +{
> + return container_of(req, struct aead_request, base);
> +}
Please drop this and use the aead_queue interface I just posted.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
> -Original Message- > From: Stephen Hemminger > Sent: Wednesday, July 8, 2015 2:31 > Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature > > On Mon, 6 Jul 2015 07:47:29 -0700 > Dexuan Cui wrote: > > > Hyper-V VM sockets (hvsock) supplies a byte-stream based communication > > mechanism between the host and a guest. It's kind of TCP over VMBus, but > > the transportation layer (VMBus) is much simpler than IP. With Hyper-V VM > > Sockets, applications between the host and a guest can talk with each > > other directly by the traditional BSD-style socket APIs. > > > > Hyper-V VM Sockets is only available on Windows 10 host and later. The > > patch implements the necessary support in the guest side by introducing > > a new socket address family AF_HYPERV. > > > > Signed-off-by: Dexuan Cui > > Is there any chance that AF_VSOCK could be used with different transport > for VMware and Hyper-V. Better to make guest applications host independent. Hi Stephen, Thanks for the question. I tried to do that (since AF_HYPERV and AF_VSOCK are conceptually similar), but I found it would be impractical: I listed the reasons in my cover letter of the patchset: https://lkml.org/lkml/2015/7/6/431 IMO the biggest difference is the size of the endpoint (u128 vs. u32): in AF_VOSCK vs. in AF_HYPERV. In the current code of AF_VSOCK and the related transport layer (the wrapper ops of VMware's VMCI), the size is widely used by "struct sockaddr_vm" (this struct is also exported to the user space). So, anyway, the user space application has to explicitly handle the different endpoint size. And in the driver side, I'm afraid there is no way to directly reuse the code of AF_VSOCK with trivial change :-( , because we would have to make the AF_VSOCK code be able to know the real sockaddr type (sockaddr_vm or sockaddr_hv? The two structs have different layout and different field names) at runtime and behave differently. This would make the code a mess, IMO. That's why I think it would be better to introduce a new address family. Thanks, -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 7/7] zsmalloc: use shrinker to trigger auto-compaction
On (07/08/15 12:04), Minchan Kim wrote: > Hi Sergey, > Hi Minchan, [..] > > (a) we need something to signify that zs_unregister_shrinker() was > > successful > > I think a) is simple way to handle it now. > I don't want to stuck with this issue. > > Please comment out why we need such boolean so after someone who has interest > on shrinker clean-up is able to grab a chance. OK, sure. Do you think that (c) deserves a separate discussion (I can fork a new discussion thread and Cc more people). It does look like we can do a bit better and make shrinker less fragile (and probably cleanup/fix several places in the kernel). -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
Darlehen anbieten 1.5%
Guten Tag, Dies ist Lloyds TSB Bank plc Kredite anbieten. Lloyds TSB bietet flexible und erschwingliche Kredite für jeden Zweck zu helfen, Ihre Ziele zu erreichen. wir Darlehen zu niedrigen Zinssatz von 1,5%. Hier sind einige wichtige Merkmale der persönlichen Kredit von Lloyds TSB angeboten. Hier sind die Loan Factors arbeiten wir mit den führenden britischen Broker, die den Zugang zu Top-Kreditgeber haben und in der Lage, die beste finanzielle Lösung zu einem erschwinglichen price.Please finden, wenn Sie interessiert sind kontaktieren Sie uns bitte über diese E-Mail: lloyds25_...@hotmail.com Nach der Reaktion, werden Sie einen Antrag auf Kredit fill erhalten. Keine soziale Sicherheit und keine Bonitätsprüfung, 100% garantiert. Es wird uns eine Ehre, wenn Sie uns erlauben, zu Ihren Diensten. Mehr Informationen benötigt Ihre Namen: Adresse: ... Telefon: ... Benötigte Menge: Dauer: ... Beruf: ... Monatliches Einkommen Level: Geschlecht: ... Geburtsdatum: Status: .. Land: .. Zweck: . Treffen Sie Ihre finanziellen Bedürfnisse ist unser Stolz. Dr. John Mahama -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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 6/9] irqchip / gic: Add stacked irqdomain support for ACPI based GICv2 init
Hi Marc,
On 06/30/2015 08:17 PM, Marc Zyngier wrote:
On 30/06/15 12:50, Hanjun Guo wrote:
Hi Marc,
On 06/29/2015 04:39 PM, Marc Zyngier wrote:
On 27/06/15 04:52, Hanjun Guo wrote:
On 06/24/2015 01:38 AM, Lorenzo Pieralisi wrote:
On Tue, Jun 23, 2015 at 04:11:38PM +0100, Hanjun Guo wrote:
[...]
for (i = 0; i < nr_irqs; i++)
gic_irq_domain_map(domain, virq + i, hwirq + i);
@@ -945,11 +952,11 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
gic_irqs = 1020;
gic->gic_irqs = gic_irqs;
- if (node) { /* DT case */
+ if (node || !acpi_disabled) { /* DT or ACPI case */
gic->domain = irq_domain_add_linear(node, gic_irqs,
_irq_domain_hierarchy_ops,
gic);
I think this is a bit more worrying, I mean passing a NULL node pointer to
the irqdomain layer which basically means you are booting out of ACPI
I'm little confused here, would you mind explaining more for your
worrying? To me, node pointer is optional and it's ok for ACPI
case.
(for you, if that's true for the irq_domain_add_linear implementation
that's another story), the node pointer should be optional but you
need feedback from IRQ layer maintainers here.
Sure.
Frankly, I'd really like to see ACPI using the "node" parameter for
something useful. This would save having to cache pointers all over the
place, will make find_irq_host() work as expected... etc.
See the comment at the top of linux/irqdomain.h :
"... This code could thus be used on other architectures by replacing
those two by some sort of arch-specific void * "token" used to identify
interrupt controllers."
I'm stuck here, I think the token for now is tied to device tree as
the device node pointer for now in the code if the pointer is not NULL,
just see the of_node_get(of_node) in __irq_domain_add(), if dynamic
dt is enabled:
struct device_node *of_node_get(struct device_node *node)
{
if (node)
kobject_get(>kobj);
return node;
}
EXPORT_SYMBOL(of_node_get);
so if the node is not NULL, it will be used to get the node's
kobject, that will be a problem for acpi case if we pass a token
as a parameter.
I rethink for quite a while and have a discussion with Graeme,
I come out another idea and we don't need the token at all
for ACPI case.
To init GIC in ACPI, we can only use the table entry pointer as
the token, but the ACPI static tables are early mem/io remapped
memory at boot stage, and it will be not available after boot,
also we need muti types of MADT enties to init GIC (GICC and GICD
for GICv2, GICC or GICR and GICD for GICv3), not as DT, just
one single node to include all the information needed to init
the GIC.
A single pointer would be enough, you don't need all of them.
We use ACPI handle for devices as node for DT when the namespace
is available, but that's pretty late in the boot stage which GIC,
SMP and timers were already initialized, so ACPI handle can not
use as the token too.
I see multi places just pass NULL as the pointer directly for
irq_domain_add_linear() which works fine, and for ACPI, we tested
this patch and also it works.
Yes it works. But you're reinventing the wheel by keeping references
outside of the normal framework, which is simply going to make the code
That's the framework for DT not suitable for ACPI, just see the comments
below.
more difficult to maintain in the long run.
Putting NULL as the device_node parameter really means "this is a domain
I don't need to look up later". In your case, you will have to lookup
I agree that we need to look up the domain not just using the
global acpi_irq_domain pointer everywhere, which make the code not
scalable, but I don't think it's not OK to put NULL as the device_node
parameter in ACPI case.
The reason is that we use different model of mapping interrupt with
device in ACPI, for ACPI device in DSDT, it's using another mapping of
device and hwirq number than DT, in DT, we using the interrupt parent
property to get the device node of irqchip, that's why we need the
matching function that match the device node with the one associated
with the irqdomain. But for ACPI, we only can get the gsi which the
device is using, no interrupt parent will be used, that because gsi is
a flat hwirq number which is unique in the system, then we can get its
associated irq domain by matching the gsi supported by this irqchip
(see drawings below), then we can be without the token pointer
matching the interrupt controller.
---> gsi_base0
||
||
irqdomain <| irqchip 0 |
||
||
|| ---> gsi_end0
---> gsi_base1 (probably gsi_end0+1)
linux-next: Tree for Jul 8
Hi all, Changes since 20150707: Renamed trees: powerpc-merge to powerpc-merge-benh powerpc to powerpc-benh New trees: powerpc-fixes and powerpc The tip tree gained a build failure so I used the version from next-20150707. The vhost tree gaiend a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 808 907 files changed, 56701 insertions(+), 13727 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 223 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4f273959b850 mei: nfc: fix deadlock on shutdown/suspend path) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off warning) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (b32aadc1a8ed powerpc/powernv: Fix race in updating core_idle_state) Merging powerpc-merge-mpe/fixes (a8956a7b7232 powerpc/powernv: Fix opal-elog interrupt handler) Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (fda8b18c515a cxgb4: Fix incorrect sequence numbers shown in devlog) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (e828b23734bf ALSA: hda - add codec ID for Broxton display audio codec) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d770e558e219 Linux 4.2-rc1) Merging tty.current/tty-linus (d770e558e219 Linux 4.2-rc1) Merging usb.current/usb-linus (d4669bb1427c Merge tag 'fixes-for-v4.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (b2e2c94b878b usb: gadget: f_midi: fix error recovery path) Merging usb-serial-fixes/usb-linus (f98a7aa81eee USB: cp210x: add ID for Aruba Networks controllers) Merging staging.current/staging-linus (cbe4f4434ded staging:lustre: remove irq.h from socklnd.h) Merging char-misc.current/char-misc-linus (d770e558e219 Linux 4.2-rc1) Merging input-current/for-linus (539c4b88146c Input: elan_i2c - change the hover event from MT to ST) Merging crypto-current/master (acb33cc541d7 crypto: omap-des - Fix unmapping of dma channels) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => cpumask_local_spread, lament) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes
[PATCH] dsa: mv88e6352/mv88e6xxx: Add support for Marvell 88E6320 and 88E6321
From: "Aleksey S. Kazantsev"
MV88E6320 and MV88E6321 are largely compatible to MV886352,
but are members of a different chip family.
Signed-off-by: Aleksey S. Kazantsev
Signed-off-by: Guenter Roeck
---
drivers/net/dsa/Kconfig | 6 +++---
drivers/net/dsa/mv88e6352.c | 31 +--
drivers/net/dsa/mv88e6xxx.c | 42 ++
drivers/net/dsa/mv88e6xxx.h | 8 +++-
4 files changed, 65 insertions(+), 22 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 7ad0a4d8e475..4c483d937481 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -46,13 +46,13 @@ config NET_DSA_MV88E6171
ethernet switches chips.
config NET_DSA_MV88E6352
- tristate "Marvell 88E6172/88E6176/88E6352 ethernet switch chip support"
+ tristate "Marvell 88E6172/6176/6320/6321/6352 ethernet switch chip
support"
depends on NET_DSA
select NET_DSA_MV88E6XXX
select NET_DSA_TAG_EDSA
---help---
- This enables support for the Marvell 88E6172, 88E6176 and 88E6352
- ethernet switch chips.
+ This enables support for the Marvell 88E6172, 88E6176, 88E6320,
+ 88E6321 and 88E6352 ethernet switch chips.
config NET_DSA_BCM_SF2
tristate "Broadcom Starfighter 2 Ethernet switch support"
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 632815c10a40..cfece5ae9d5f 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -36,6 +36,18 @@ static char *mv88e6352_probe(struct device *host_dev, int
sw_addr)
return "Marvell 88E6172";
if ((ret & 0xfff0) == PORT_SWITCH_ID_6176)
return "Marvell 88E6176";
+ if (ret == PORT_SWITCH_ID_6320_A1)
+ return "Marvell 88E6320 (A1)";
+ if (ret == PORT_SWITCH_ID_6320_A2)
+ return "Marvell 88e6320 (A2)";
+ if ((ret & 0xfff0) == PORT_SWITCH_ID_6320)
+ return "Marvell 88E6320";
+ if (ret == PORT_SWITCH_ID_6321_A1)
+ return "Marvell 88E6321 (A1)";
+ if (ret == PORT_SWITCH_ID_6321_A2)
+ return "Marvell 88e6321 (A2)";
+ if ((ret & 0xfff0) == PORT_SWITCH_ID_6321)
+ return "Marvell 88E6321";
if (ret == PORT_SWITCH_ID_6352_A0)
return "Marvell 88E6352 (A0)";
if (ret == PORT_SWITCH_ID_6352_A1)
@@ -84,11 +96,12 @@ static int mv88e6352_setup_global(struct dsa_switch *ds)
static int mv88e6352_get_temp(struct dsa_switch *ds, int *temp)
{
+ int phy = mv88e6xxx_6320_family(ds) ? 3 : 0;
int ret;
*temp = 0;
- ret = mv88e6xxx_phy_page_read(ds, 0, 6, 27);
+ ret = mv88e6xxx_phy_page_read(ds, phy, 6, 27);
if (ret < 0)
return ret;
@@ -99,11 +112,12 @@ static int mv88e6352_get_temp(struct dsa_switch *ds, int
*temp)
static int mv88e6352_get_temp_limit(struct dsa_switch *ds, int *temp)
{
+ int phy = mv88e6xxx_6320_family(ds) ? 3 : 0;
int ret;
*temp = 0;
- ret = mv88e6xxx_phy_page_read(ds, 0, 6, 26);
+ ret = mv88e6xxx_phy_page_read(ds, phy, 6, 26);
if (ret < 0)
return ret;
@@ -114,23 +128,25 @@ static int mv88e6352_get_temp_limit(struct dsa_switch
*ds, int *temp)
static int mv88e6352_set_temp_limit(struct dsa_switch *ds, int temp)
{
+ int phy = mv88e6xxx_6320_family(ds) ? 3 : 0;
int ret;
- ret = mv88e6xxx_phy_page_read(ds, 0, 6, 26);
+ ret = mv88e6xxx_phy_page_read(ds, phy, 6, 26);
if (ret < 0)
return ret;
temp = clamp_val(DIV_ROUND_CLOSEST(temp, 5) + 5, 0, 0x1f);
- return mv88e6xxx_phy_page_write(ds, 0, 6, 26,
+ return mv88e6xxx_phy_page_write(ds, phy, 6, 26,
(ret & 0xe0ff) | (temp << 8));
}
static int mv88e6352_get_temp_alarm(struct dsa_switch *ds, bool *alarm)
{
+ int phy = mv88e6xxx_6320_family(ds) ? 3 : 0;
int ret;
*alarm = false;
- ret = mv88e6xxx_phy_page_read(ds, 0, 6, 26);
+ ret = mv88e6xxx_phy_page_read(ds, phy, 6, 26);
if (ret < 0)
return ret;
@@ -394,5 +410,8 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.fdb_getnext= mv88e6xxx_port_fdb_getnext,
};
-MODULE_ALIAS("platform:mv88e6352");
MODULE_ALIAS("platform:mv88e6172");
+MODULE_ALIAS("platform:mv88e6176");
+MODULE_ALIAS("platform:mv88e6320");
+MODULE_ALIAS("platform:mv88e6321");
+MODULE_ALIAS("platform:mv88e6352");
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index fd8547c2b79d..f394e4d4d9e0 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -517,6 +517,18 @@ static bool mv88e6xxx_6185_family(struct dsa_switch
Re: [PATCH] regmap: Use different lockdep class for each regmap init call
On Tue, Jul 7, 2015 at 8:13 PM, Mark Brown wrote: > On Wed, Jul 01, 2015 at 12:43:59PM +0800, Nicolas Boichat wrote: > >> (this also applies to all other regmap_init functions...). We do not want to >> document the lock_key/name parameters, so we could either leave it like that, >> or move all the documentation to regmap.h, in front of the respective macros. > > That seems reasonable. Which one? Leave as-is? Or move the documentation to regmap.h? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf, kprobes: fuzzer generates huge number of WARNings
Hi Vince,
On 2015/07/08 3:06, Vince Weaver wrote:
> On Tue, 7 Jul 2015, Steven Rostedt wrote:
>
>> On Tue, 7 Jul 2015 11:06:55 -0400 (EDT)
>> Probably. If you recompiled the kernel, you need to find the new
>> address points.
>
> should these messages really be spamming the syslog?
>
> I updated the kprobe to point to the right location again
> (this is
>
> and the fuzzer just generates infinite of these warnings. Maybe they
> should be WARN_ONCE rather than plain WARN?
>
> [ 5447.623713] [ cut here ]
> [ 5447.629160] WARNING: CPU: 1 PID: 4158 at kernel/kprobes.c:939
> arm_kprobe+0xe3/0xf0()
> [ 5447.637944] Failed to arm kprobe-ftrace at 81196670 (-19)
The corresponding code is
ret = ftrace_set_filter_ip(_ftrace_ops,
(unsigned long)p->addr, 0, 0);
WARN(ret < 0, "Failed to arm kprobe-ftrace at %p (%d)\n", p->addr, ret);
-19 is -ENODEV, and it may be returned from ftrace_set_hash
(ftrace_set_filter_ip -> ftrace_set_addr -> ftrace_set_hash)
static int
ftrace_set_hash(struct ftrace_ops *ops, unsigned char *buf, int len,
unsigned long ip, int remove, int reset, int enable)
{
struct ftrace_hash **orig_hash;
struct ftrace_ops_hash old_hash_ops;
struct ftrace_hash *old_hash;
struct ftrace_hash *hash;
int ret;
if (unlikely(ftrace_disabled))
return -ENODEV;
the ftrace_disabled (I think it would better be renamed to ftrace_died...) is
set only if an unrecoverable error happened. So before this message you'll
see some other error messages.
Thank you,
> [ 5447.723237] CPU: 1 PID: 4158 Comm: perf_fuzzer Tainted: GW
> 4.2.0-rc1+ #169
> [ 5447.732454] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS
> 01/26/2014
> [ 5447.740897] 81a2894e 8801161b3bf8 816a0fd3
>
> [ 5447.749426] 8801161b3c48 8801161b3c38 8106ec8a
> aed0
> [ 5447.757931] 88011847b810 8800cd8b8000
> 81d25640
> [ 5447.766463] Call Trace:
> [ 5447.769567] [] dump_stack+0x45/0x57
> [ 5447.775569] [] warn_slowpath_common+0x8a/0xc0
> [ 5447.782504] [] warn_slowpath_fmt+0x46/0x50
> [ 5447.789111] [] ? pcpu_alloc+0x36a/0x630
> [ 5447.795466] [] ? vm_insert_mixed+0x40/0x40
> [ 5447.802098] [] arm_kprobe+0xe3/0xf0
> [ 5447.808095] [] enable_kprobe+0x78/0x80
> [ 5447.814353] [] kprobe_register+0x59/0xe0
> [ 5447.820805] [] perf_trace_init+0x1b5/0x2c0
> [ 5447.827471] [] perf_tp_event_init+0x2a/0x50
> [ 5447.834197] [] perf_try_init_event+0x8b/0xa0
> [ 5447.841012] [] perf_init_event+0x133/0x160
> [ 5447.847658] [] ? perf_bp_event+0x90/0x90
> [ 5447.854101] [] perf_event_alloc+0x42a/0x680
> [ 5447.860840] [] SYSC_perf_event_open+0x3c7/0xd20
> [ 5447.867949] [] SyS_perf_event_open+0x9/0x10
> [ 5447.874702] [] entry_SYSCALL_64_fastpath+0x16/0x7a
> [ 5447.882093] ---[ end trace 5d38212a775ec3f3 ]---
> [ 5447.887538] [ cut here ]
> [ 5447.892984] WARNING: CPU: 1 PID: 4158 at kernel/kprobes.c:943
> arm_kprobe+0xae/0xf0()
> [ 5447.901755] Failed to init kprobe-ftrace (-19)
> [ 5447.985337] CPU: 1 PID: 4158 Comm: perf_fuzzer Tainted: GW
> 4.2.0-rc1+ #169
> [ 5447.994611] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS
> 01/26/2014
> [ 5448.003174] 81a2894e 8801161b3bf8 816a0fd3
>
> [ 5448.011805] 8801161b3c48 8801161b3c38 8106ec8a
> 81125c1a
> [ 5448.020424] 88011847b810 8800cd8b8000
> 81d25640
> [ 5448.029074] Call Trace:
> [ 5448.032265] [] dump_stack+0x45/0x57
> [ 5448.038342] [] warn_slowpath_common+0x8a/0xc0
> [ 5448.045376] [] ? register_ftrace_function+0x4a/0x70
> [ 5448.052930] [] warn_slowpath_fmt+0x46/0x50
> [ 5448.059617] [] ? mutex_unlock+0xe/0x10
> [ 5448.065951] [] arm_kprobe+0xae/0xf0
> [ 5448.072003] [] enable_kprobe+0x78/0x80
> [ 5448.078341] [] kprobe_register+0x59/0xe0
> [ 5448.084823] [] perf_trace_init+0x1b5/0x2c0
> [ 5448.091484] [] perf_tp_event_init+0x2a/0x50
> [ 5448.098212] [] perf_try_init_event+0x8b/0xa0
> [ 5448.105068] [] perf_init_event+0x133/0x160
> [ 5448.111689] [] ? perf_bp_event+0x90/0x90
> [ 5448.118116] [] perf_event_alloc+0x42a/0x680
> [ 5448.124825] [] SYSC_perf_event_open+0x3c7/0xd20
> [ 5448.131946] [] SyS_perf_event_open+0x9/0x10
> [ 5448.138640] [] entry_SYSCALL_64_fastpath+0x16/0x7a
> [ 5448.146065] ---[ end trace 5d38212a775ec3f4 ]---
> [ 5448.228748] [ cut here ]
> [ 5448.234201] WARNING: CPU: 2 PID: 4247 at kernel/kprobes.c:955
> disarm_kprobe+0xf8/0x100()
> [ 5448.243366] Failed to init kprobe-ftrace (-19)
> [ 5448.327114] CPU: 2 PID: 4247 Comm: perf_fuzzer Tainted: GW
> 4.2.0-rc1+ #169
> [ 5448.336416] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS
> 01/26/2014
>
Re: [PATCH v6 7/7] zsmalloc: use shrinker to trigger auto-compaction
Hi Sergey,
On Wed, Jul 08, 2015 at 11:18:36AM +0900, Sergey Senozhatsky wrote:
> On (07/08/15 00:12), Sergey Senozhatsky wrote:
> > > I don't think it would fail in *real practice*.
> > > Althout it might happen, what does zram could help in that cases?
> > >
> >
> > This argument depends on the current register_shrinker() implementation,
> > should some one add additional return branch there and it's done.
> >
> > > If it were failed, it means there is already little memory on the system
> > > so zram could not be helpful for those environment.
> > > IOW, zram should be enabled earlier.
> > >
> > > If you want it strongly, please reproduce such failing and prove that
> > > zram was helpful for the system.
> >
> > No, thanks. I'll just remove it.
> >
>
> hm... This makes error path a bit ugly. What we have now is
> pretty straight forward
>
> ... zs_create_pool(char *name, gfp_t flags)
> {
> ..
> if (zs_register_shrinker(pool) == 0)
> pool->shrinker_enabled = true;
> ..
> err:
> zs_destroy_pool(pool);
> return NULL;
> }
>
> zs_destroy_pool() does a destruction. It performs unconditional
> zs_unregister_shrinker(), which does unregister_shrinker() _if needed_.
>
> Shrinker API does not handle nicely unregister_shrinker() on a not-registered
> ->shrinker. And error path can be triggered even before we do
> register_shrinker(),
> so we can't 'fix' unregister_shrinker() in a common way, doing something like
>
> void unregister_shrinker(struct shrinker *shrinker)
> {
> + if (!unlikely(shrinker->nr_deferred))
> + return;
> +
> down_write(_rwsem);
> list_del(>list);
> up_write(_rwsem);
>
>
> (just for example), because someone can accidentally pass a dirty (not zeroed
> out) `struct shrinker'. e.g.
>
> struct foo {
> const char *b;
> ...
> struct shrinker s;
> };
>
> void bar(void)
> {
> struct foo *f = kmalloc(...);
>
> if (!f)
> return;
>
> f->a = kmalloc(...);
> if (!f->a)
> goto err;
>
> err:
> unregister_shrinker(f->s);
> ^^ boom
> ...
> }
>
>
Yes, it's ugly.
>
> So... options:
>
> (a) we need something to signify that zs_unregister_shrinker() was successful
I think a) is simple way to handle it now.
I don't want to stuck with this issue.
Please comment out why we need such boolean so after someone who has interest
on shrinker clean-up is able to grab a chance.
Thanks!
>
> or
>
> (b) factor out 'core' part of zs_destroy_pool() and do a full destruction when
> called from the outside (from zram for example), or a partial destruction when
> called from zs_create_pool() error path.
>
>
>
> or
>
> (c) introduce INIT_SHRINKER macro to init `struct shrinker' internal
> members
>
> (!!! composed in email client, not tested !!!)
>
> include/linux/shrinker.h
>
> #define INIT_SHRINKER(s) \
> do {\
> (s)->nr_deferred = NULL;\
> INIT_LIST_HEAD(&(s)->list); \
> } while (0)
>
>
> and do
>
> struct zs_pool *zs_create_pool(char *name, gfp_t flags)
> {
> ..
> INIT_SHRINKER(>shrinker);
>
> pool->name = kstrdup(name, GFP_KERNEL);
> ..
> }
>
>
>
> Looking at shrinker users, they all have to carry on some sort of
> a flag telling that "unregister_shrinker()" will not blow up... or
> just be fishy... like
>
> int ldlm_pools_init(void)
> {
> int rc;
>
> rc = ldlm_pools_thread_start();
> if (rc == 0) {
> register_shrinker(_pools_srv_shrinker);
> register_shrinker(_pools_cli_shrinker);
> }
> return rc;
> }
> EXPORT_SYMBOL(ldlm_pools_init);
>
> void ldlm_pools_fini(void)
> {
> unregister_shrinker(_pools_srv_shrinker);
> unregister_shrinker(_pools_cli_shrinker);
> ldlm_pools_thread_stop();
> }
> EXPORT_SYMBOL(ldlm_pools_fini);
>
>
>
> or access private members of the `struct shrinker', like
>
>
> struct cache_set {
> ...
> struct shrinker shrink;
> ...
> };
>
> void bch_btree_cache_free(struct cache_set *c)
> {
> struct btree *b;
> struct closure cl;
> closure_init_stack();
>
> if (c->shrink.list.next)
> unregister_shrinker(>shrink);
>
>
> Note that `shrink.list.next' check.
>
> -ss
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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] Warnings : Fixed 80 character length warning in rtw_ap.c
On Tue, 2015-07-07 at 22:08 -0400, valdis.kletni...@vt.edu wrote: > On Tue, 07 Jul 2015 13:38:47 -0700, Joe Perches said: > > > The longest line in this file is 158 chars, that's > > probably excessive, awk shows 35 lines > 80 chars. > > That doesn't count tabs. Checkpatch throws 98 warnings. Yup, forgot the expand. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
[Announce] sg3_utils-1.41 available
sg3_utils is a package of command line utilities for sending SCSI and some ATA commands to devices. This package targets the Linux 4, 3, 2.6 and 2.4 kernel series. It has ports to FreeBSD, Tru64, Solaris, and Windows (cygwin and MinGW). There is one new utility (sg_zone) and additions to many others, see the ChangeLog below. This version tracks various changes made by www.t10.org since November 2014 until May 2015. For an overview of sg3_utils and downloads see this page: http://sg.danny.cz/sg/sg3_utils.html The sg_ses utility (for enclosure devices) is discussed at: http://sg.danny.cz/sg/sg_ses.html A full changelog can be found at: http://sg.danny.cz/sg/p/sg3_utils.ChangeLog Changelog for sg3_utils-1.41 [20150511] [svn: r644] - sg_zone: new utility for open, close and finish zone commands introduced in zbc-r02 - sg_rep_zones and sg_reset_wp: change opcodes as indicated in zbc-r02 - sg_read_buffer: add READ BUFFER(16) support (spc5r02) - sg_logs: add --enumerate and acronyms - allow decode from hex or binary in file - decode environmental reporting + limits lpages - sg_write_buffer: add --timeout=TO option - sg_lib interface: add sg_lib_pdt_decay(), TPROTO_PCIE plus support for zoning service actions - sg_lib: in Linux blocked devices yield ENXIO from ioctl(SG_IO), map to SG_LIB_CAT_NOT_READY - clean up sg_warnings_stream handling - sg_inq+sg_vpd: fix SCSI name string decoding in device identification VPD page (0x83) - increase sanity on Unit Serial number VPD page - improve rdac vpd page reporting (vendor) - sg_inq: improve NAA handling in dev_id VPD page - update version descriptor list to 20150126 - sg_vpd: add atomic boundary values (sbc4r04) - block limits VPD page: fix unmap granularity alignment value; spc5r02 additions - sg_readcap: add support for ZBC's rc_basis field - sg_senddiag: fix bug with --raw option - add support for -HHH for output suitable for --raw - sg_ses: enclosure element: add failure and warning acronyms, fix warning indication output - additional element status dpage: add PCIe/NVMe - handle element descriptor names that count multiple trailing NULLs - rescan-scsi-bus.sh: add --issue-lip-wait option and improve error handling - improve dm-multipath handling - sg_modes: make '-HHH' output suitable as input to 'sdparm --inhex=' - sg_rdac: add '-6' option for mode sense/select(6) - add support for reporting more SCSI transports and accessing rdac extended mode page 0x2c - sg_write_same: cleanup, mainly man page - scsi_logging_level: replace use of tr command - examples/sg_tst_async: cleanup - examples/sg-simple_aio.c: remove - sg_lib_data: sync asc/ascq codes with T10 20150423 - Makefile cleanup - autogen.sh: upgrade to buildconf 20091223 version Changelog for sg3_utils-1.40 [20141110] [svn: r620] ... Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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] freeing unliked file indefinitely delayed
On Wed, Jul 08, 2015 at 02:42:38AM +0100, Al Viro wrote:
> Normally opening a file, unlinking it and then closing will have
> the inode freed upon close() (provided that it's not otherwise busy and
> has no remaining links, of course). However, there's one case where that
> does *not* happen. Namely, if you open it by fhandle with cold dcache,
> then unlink() and close().
>
> In normal case you get d_delete() in unlink(2) notice that dentry
> is busy and unhash it; on the final dput() it will be forcibly evicted from
> dcache, triggering iput() and inode removal. In this case, though, we end
> up with *two* dentries - disconnected (created by open-by-fhandle) and
> regular one (used by unlink()). The latter will have its reference to inode
> dropped just fine, but the former will not - it's considered hashed (it
> is on the ->s_anon list), so it will stay around until the memory pressure
> will finally do it in. As the result, we have the final iput() delayed
> indefinitely. It's trivial to reproduce -
>
> #define _GNU_SOURCE
> #include
> #include
> #include
>
> void flush_dcache(void)
> {
> system("mount -o remount,rw /");
> }
>
> static char buf[20 * 1024 * 1024];
>
> main()
> {
> int fd;
> union {
> struct file_handle f;
> char buf[MAX_HANDLE_SZ];
> } x;
> int m;
>
> x.f.handle_bytes = sizeof(x);
> chdir("/root");
> mkdir("foo", 0700);
> fd = open("foo/bar", O_CREAT | O_RDWR, 0600);
> close(fd);
> name_to_handle_at(AT_FDCWD, "foo/bar", , , 0);
> flush_dcache();
> fd = open_by_handle_at(AT_FDCWD, , O_RDWR);
> unlink("foo/bar");
> write(fd, buf, sizeof(buf));
> system("df ."); /* 20Mb eaten */
> close(fd);
> system("df ."); /* should've freed those 20Mb */
> flush_dcache();
> system("df ."); /* should be the same as #2 */
> }
>
> will spit out something like
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/root 322023 303843 1131 100% /
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/root 322023 303843 1131 100% /
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/root 322023 283282 21692 93% /
> - inode gets freed only when dentry is finally evicted (here we trigger
> than by remount; normally it would've happened in response to memory
> pressure hell knows when).
>
> IMO it's a bug.
Definitely agreed.
> Between the close() and final flush_dcache() the file has
> no surviving links, is *not* busy, won't show up in fuser/lsof/whatnot
> output, and yet it's still not freed. I'm not saying that it's realistically
> exploitable (albeit with nfsd it might be)
I'd be surprised if it doesn't happen. This, for example, is a "space
on nfs export not freed when I expected it after an unlink" report that
could easily have the same cause:
https://www.redhat.com/archives/linux-cluster/2015-May/msg0.html
(Not sure, I'll get back to them and see if they can confirm.)
> but it's a very unpleasant self-LART.
> FWIW, my prefered fix would be simply to have the final dput() treat
> disconnected dentries as "kill on sight"; checking for i_nlink of the
> inode, as Bruce suggested several years ago, will *not* work, simply
> because having another link to that file and unlinking it after close
> will reproduce the situation - disconnected dentry sticks around in
> dcache past its final dput() and past the last unlink() of our file.
> Theoretically it might cause an overhead for nfsd (no_subtree_check v3
> export might see more d_alloc()/d_free(); icache retention will still
> prevent constant rereading the inode from disk). _IF_ that proves to
> be noticable, we might need to come up with something more elaborate
> (e.g. have unlink() and rename() kick disconnected aliases out if the link
> count has reached 0), but it's more complex and needs careful ananlysis
> of correctness - we need to prove that there's no way to miss the link
> count reaching 0. I would prefer to treat all disconnected as unhashed
> for dcache retention purposes - it's simpler and less brittle. Comments?
> I mean something like this:
ACK from me.
--b.
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 7a3f3e5..5c8ea15 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -642,7 +642,7 @@ static inline bool fast_dput(struct dentry *dentry)
>
> /*
>* If we have a d_op->d_delete() operation, we sould not
> - * let the dentry count go to zero, so use "put__or_lock".
> + * let the dentry count go to zero, so use "put_or_lock".
>*/
> if (unlikely(dentry->d_flags & DCACHE_OP_DELETE))
> return lockref_put_or_lock(>d_lockref);
> @@ -697,7 +697,7 @@ static inline bool fast_dput(struct dentry *dentry)
>
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote:
> On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer wrote:
> > On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> >> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer
> >> wrote:
> >> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> >> >> Add clk_null, which represents clocks that can not / need not
> >> >> controlled by software.
> >> >> There are many clocks' parent set to clk_null.
> >> >>
> >> >> Signed-off-by: James Liao
> >> >> Signed-off-by: Eddie Huang
> >> >> ---
> >> >> Base on 4.1-rc1
> >> >>
> >> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> >> >> ---
> >> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
> >> >> 1 file changed, 6 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> index 924fdb6..4798f44 100644
> >> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> >> @@ -81,6 +81,12 @@
> >> >> cpu_on= <0x8403>;
> >> >> };
> >> >>
> >> >> + clk_null: clk_null {
> >> >> + compatible = "fixed-clock";
> >> >> + clock-frequency = <0>;
> >> >> + #clock-cells = <0>;
> >> >> + };
> >> >
> >> > The discussion around this patch shows that we don't want to have this
> >> > clock in the device tree as it is not a hardware description.
> >> >
> >> > Ok, fine. Eddie, you told us that the rate of the current clk_null
> >> > children
> >> > is not interesting. What's the motivation to send this patch anyway
> >> > then? Why can't you keep its children on the orphan list where they are
> >> > already now?
> >> >
> >> > Another possibility would be to instantiate the clk_null clock from C
> >> > code rather than from the device tree. This way we wouldn't put any
> >> > wrong descriptions into the device tree and still can implement the
> >> > support for the real parent clocks when we actually need them.
> >>
> >> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
> >>
> >> mmc1: mmc@1124 {
> >> compatible = "mediatek,mt8173-mmc",
> >> "mediatek,mt8135-mmc";
> >> reg = <0 0x1124 0 0x1000>;
> >> interrupts = ;
> >> clocks = < CLK_PERI_MSDC30_1>,
> >> <_null>;
> >> clock-names = "source", "hclk";
> >> status = "disabled";
> >> };
> >
> > This is another case than the one we discussed about. In the case above
> > I motivated using a dummy clock since the clock exists in the system,
> > but is not software controllable. To abstract this from the driver
> > (which needs this clock since it exists) we here have the dummy clock.
> > However, of course I can't prove the clock is indeed not software
> > controllable; that's only the information I have.
>
> I was trying to answer your question "What's the motivation to send
> this patch anyway?".
> The motivation is to send follow on patches that use the clk_null
> phandle. We need to provide some clock as the mmc1's hclk. I do not
> understand why this has to be "clk_null", though. It seems like this
> should be a real clock coming from one of the real clock_controller
> nodes. After all, the mmc driver is going to be enabling/disabling
> this clock for power savings at runtime. What does that even mean for
> clk_null ?
The original purpose of this patch is to provide a common dummy clock
for both software don't care clock and clock that is not software
controllable.I got comments that device tree should describe hardware
and should put exact clock in device tree. I think this is true. So we
will remove this clock_null patch, and:
1. For Mediatek SoC CCF driver, James will clarify clock usage further.
Actually, we still think it's not necessary to describe whole tree that
software don't care, James will deal this in clock driver.
2. For other module that use SW not controllable clock (mmc case
mentioned by Dan), because this is a real clock, we will put a dummy
clock in device tree, like
clk_mmchclk: dummyhclk {
compatible = "fixed-clock";
clock-frequency = <0>;
#clock-cells = <0>;
};
How about this modification ?
Thanks
Eddie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN
On 7/7/2015 6:25 PM, Andy Lutomirski wrote: VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is in use. The code is a big undocumented mess, it's a real PITA to test, and it looks like a big chunk of vm86_32.c is dead code. It also plays awful games with the entry asm. No one should be using it anyway. Use DOSBOX or KVM instead. Mark it BROKEN. I want to remove some (obviously incorrect) exit asm that it depends on, and I don't want to figure out how to run severely obsolete programs just to test something that no one uses for anything other than exploits anyway. while it is never great to deprecate features, in this case I am not sure there is another choice unless someone steps up to seriously revamp this code. (and look at it from a PREEMPT, NO_HZ etc etc angle) if this patch would not be acceptable, at minimum we need some sort of "off by default unless the sysadmin flips a sysfs thing", which is really just a huge hack. so for me this is Acked-by: Arjan van de Ven -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
LOAN OFFER
We offer private, commercial and any type of loans with very minimal annual Interest Rate of 3%. If you are interested contact us -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 7/7] zsmalloc: use shrinker to trigger auto-compaction
On (07/08/15 00:12), Sergey Senozhatsky wrote:
> > I don't think it would fail in *real practice*.
> > Althout it might happen, what does zram could help in that cases?
> >
>
> This argument depends on the current register_shrinker() implementation,
> should some one add additional return branch there and it's done.
>
> > If it were failed, it means there is already little memory on the system
> > so zram could not be helpful for those environment.
> > IOW, zram should be enabled earlier.
> >
> > If you want it strongly, please reproduce such failing and prove that
> > zram was helpful for the system.
>
> No, thanks. I'll just remove it.
>
hm... This makes error path a bit ugly. What we have now is
pretty straight forward
... zs_create_pool(char *name, gfp_t flags)
{
..
if (zs_register_shrinker(pool) == 0)
pool->shrinker_enabled = true;
..
err:
zs_destroy_pool(pool);
return NULL;
}
zs_destroy_pool() does a destruction. It performs unconditional
zs_unregister_shrinker(), which does unregister_shrinker() _if needed_.
Shrinker API does not handle nicely unregister_shrinker() on a not-registered
->shrinker. And error path can be triggered even before we do
register_shrinker(),
so we can't 'fix' unregister_shrinker() in a common way, doing something like
void unregister_shrinker(struct shrinker *shrinker)
{
+ if (!unlikely(shrinker->nr_deferred))
+ return;
+
down_write(_rwsem);
list_del(>list);
up_write(_rwsem);
(just for example), because someone can accidentally pass a dirty (not zeroed
out) `struct shrinker'. e.g.
struct foo {
const char *b;
...
struct shrinker s;
};
void bar(void)
{
struct foo *f = kmalloc(...);
if (!f)
return;
f->a = kmalloc(...);
if (!f->a)
goto err;
err:
unregister_shrinker(f->s);
^^ boom
...
}
So... options:
(a) we need something to signify that zs_unregister_shrinker() was successful
or
(b) factor out 'core' part of zs_destroy_pool() and do a full destruction when
called from the outside (from zram for example), or a partial destruction when
called from zs_create_pool() error path.
or
(c) introduce INIT_SHRINKER macro to init `struct shrinker' internal
members
(!!! composed in email client, not tested !!!)
include/linux/shrinker.h
#define INIT_SHRINKER(s)\
do {\
(s)->nr_deferred = NULL;\
INIT_LIST_HEAD(&(s)->list); \
} while (0)
and do
struct zs_pool *zs_create_pool(char *name, gfp_t flags)
{
..
INIT_SHRINKER(>shrinker);
pool->name = kstrdup(name, GFP_KERNEL);
..
}
Looking at shrinker users, they all have to carry on some sort of
a flag telling that "unregister_shrinker()" will not blow up... or
just be fishy... like
int ldlm_pools_init(void)
{
int rc;
rc = ldlm_pools_thread_start();
if (rc == 0) {
register_shrinker(_pools_srv_shrinker);
register_shrinker(_pools_cli_shrinker);
}
return rc;
}
EXPORT_SYMBOL(ldlm_pools_init);
void ldlm_pools_fini(void)
{
unregister_shrinker(_pools_srv_shrinker);
unregister_shrinker(_pools_cli_shrinker);
ldlm_pools_thread_stop();
}
EXPORT_SYMBOL(ldlm_pools_fini);
or access private members of the `struct shrinker', like
struct cache_set {
...
struct shrinker shrink;
...
};
void bch_btree_cache_free(struct cache_set *c)
{
struct btree *b;
struct closure cl;
closure_init_stack();
if (c->shrink.list.next)
unregister_shrinker(>shrink);
Note that `shrink.list.next' check.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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/
[lkp] [Btrfs] c9dc4c65785: +9.8% fsmark.files_per_sec
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit c9dc4c6578502c2085705347375b82089aad18d0 ("Btrfs: two stage dirty block
group writeout")
testcase/path_params/tbox_group:
fsmark/performance-1x-1t-1HDD-btrfs-4M-60G-NoSync/ivb44
4c6d1d85ad89fd8e c9dc4c6578502c208570534737
--
462211 ± 1% +16.8% 539707 ± 0% fsmark.app_overhead
35.27 ± 0% +9.8% 38.74 ± 1% fsmark.files_per_sec
9 ± 0% +17.8% 10 ± 4%
fsmark.time.percent_of_cpu_this_job_got
9864 ± 2%+156.9% 25345 ± 4%
fsmark.time.voluntary_context_switches
435 ± 0% -9.0%396 ± 1% fsmark.time.elapsed_time
435 ± 0% -9.0%396 ± 1% fsmark.time.elapsed_time.max
21057 ± 0% -9.0% 19165 ± 1% uptime.idle
68983 ± 2% +19.1% 82190 ± 4% softirqs.RCU
129619 ± 0% +3.2% 133743 ± 0% vmstat.io.bo
1 ± 0%+100.0% 2 ± 0% vmstat.procs.b
18873 ± 0% +14.9% 21692 ± 1% vmstat.system.cs
1787510 ± 1%+117.0%3878984 ± 2% meminfo.Dirty
5585235 ± 0% +25.5%7011242 ± 0% meminfo.Writeback
8276795 ± 10% +15.9%9592682 ± 0% numa-numastat.node0.local_node
8287205 ± 10% +16.0%9611684 ± 0% numa-numastat.node0.numa_hit
2447873 ± 42% -67.9% 785086 ± 33% numa-numastat.node1.numa_hit
2413662 ± 43% -68.1% 771115 ± 31% numa-numastat.node1.local_node
435 ± 0% -9.0%396 ± 1% time.elapsed_time
435 ± 0% -9.0%396 ± 1% time.elapsed_time.max
9 ± 0% +17.8% 10 ± 4% time.percent_of_cpu_this_job_got
0.41 ± 1% +17.1% 0.48 ± 4% time.user_time
9864 ± 2%+156.9% 25345 ± 4% time.voluntary_context_switches
5.189e+08 ± 0% +72.6% 8.956e+08 ± 1% cpuidle.C1-IVT.time
4626942 ± 19% +49.6%6924087 ± 22% cpuidle.C1E-IVT.time
2646692 ± 7% +75.0%4630890 ± 23% cpuidle.C3-IVT.time
2.028e+10 ± 0% -11.1% 1.803e+10 ± 1% cpuidle.C6-IVT.time
268137 ± 0% +12.2% 300911 ± 2% cpuidle.C6-IVT.usage
222 ± 11% +47.0%326 ± 25% cpuidle.POLL.usage
0.69 ± 2% +7.2% 0.74 ± 3% turbostat.%Busy
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Ying Huang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c
On Tue, 07 Jul 2015 13:38:47 -0700, Joe Perches said: > The longest line in this file is 158 chars, that's > probably excessive, awk shows 35 lines > 80 chars. That doesn't count tabs. Checkpatch throws 98 warnings. pgpRav2SIlbke.pgp Description: PGP signature
Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c
On Tue, 07 Jul 2015 21:08:10 -0400, Sreenath Madasu said: > The kernelnewbies.org guide said "For your first patch, only pick one > warning". That is the reason why I fixed one warning. They mean "don't fix lines over 80 characters *and* missing-blank warnings in the same patch". pgpMmWKYBIEA7.pgp Description: PGP signature
Re: [RFC PATCH v10 23/50] perf tools: Make perf depend on libbpf
On 7/7/15 1:16 PM, Arnaldo Carvalho de Melo wrote: So, please move this to just before we can use it, wiring it up should mean, hey, try this "hello, world" eBPF program right now! btw, since bpf is now stable llvm backend, one can just get the latest clang/llvm 3.7 from pre-built llvm packages for debian/ubuntu: http://llvm.org/apt/ and bpf backend will be there by default. No need to build clang/llvm from sources. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/5] arc:irqchip: prepare for drivers/irqchip/irqchip.h removal
On Wednesday 08 July 2015 02:45 AM, Joël Porquet wrote:
The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h'.
See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d
("irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h").
This patch removes the inclusions of private header 'drivers/irqchip/irqchip.h'
and if necessary replaces them with inclusions of 'include/linux/irqchip.h'.
Signed-off-by: Joel Porquet
Acked-by: Vineet Gupta mailto:vgu...@synopsys.com>>
Joel, Thomas : Do you want me to pick this one up ?
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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/
[lkp] [thp] 79553da293d: +1.8% fileio.time.file_system_inputs
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 79553da293d38d63097278de13e28a3b371f43c1 ("thp: cleanup khugepaged
startup")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/disk/iosched/fs/nr_threads:
bay/dd-write/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/1HDD/cfq/xfs/10dd
commit:
e39155ea11eac6da056b04669d7c9fc612e2065a
79553da293d38d63097278de13e28a3b371f43c1
e39155ea11eac6da 79553da293d38d63097278de13
--
%stddev %change %stddev
\ |\
30460 ± 0% +34.3% 40920 ± 0% softirqs.BLOCK
231.27 ± 4% -17.3% 191.30 ± 3% uptime.idle
765.75 ± 7% +19.7% 916.50 ± 4% slabinfo.kmalloc-512.active_objs
972.25 ± 8% +17.4% 1141 ± 5% slabinfo.kmalloc-512.num_objs
74.00 ± 0% +15.9% 85.75 ± 10% vmstat.memory.buff
91092 ± 0% -62.3% 34370 ± 1% vmstat.memory.free
22460 ± 1% +29.2% 29026 ± 1% ftrace.global_dirty_state.dirty
35516 ± 1% -11.0% 31615 ± 0%
ftrace.global_dirty_state.writeback
2.00 ± 0% +50.0% 3.00 ± 0%
ftrace.writeback_single_inode.sda.age
4913 ± 1% +35.7% ± 1%
ftrace.writeback_single_inode.sda.wrote
36958 ± 4% -67.3% 12083 ± 28% meminfo.AnonHugePages
89634 ± 0% +29.2% 115815 ± 1% meminfo.Dirty
1315242 ± 0% +10.4%1451507 ± 0% meminfo.MemAvailable
87870 ± 0% -63.5% 32046 ± 2% meminfo.MemFree
142291 ± 1% -11.2% 126331 ± 0% meminfo.Writeback
2.76 ± 14% +22.8% 3.39 ± 8%
perf-profile.cpu-cycles.__clear_user.iov_iter_zero.read_iter_zero.new_sync_read.__vfs_read
4.94 ± 16% +31.2% 6.48 ± 6%
perf-profile.cpu-cycles.__memset.xfs_vm_write_begin.generic_perform_write.xfs_file_buffered_aio_write.xfs_file_write_iter
1.31 ± 34% -50.4% 0.65 ± 36%
perf-profile.cpu-cycles.end_page_writeback.end_buffer_async_write.xfs_destroy_ioend.xfs_end_io.process_one_work
0.86 ± 24% -44.1% 0.48 ± 42%
perf-profile.cpu-cycles.handle_pte_fault.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
1.15 ± 27% -50.4% 0.57 ± 39%
perf-profile.cpu-cycles.test_clear_page_writeback.end_page_writeback.end_buffer_async_write.xfs_destroy_ioend.xfs_end_io
0.76 ± 39% +65.6% 1.26 ± 23%
perf-profile.cpu-cycles.try_to_free_buffers.xfs_vm_releasepage.try_to_release_page.shrink_page_list.shrink_inactive_list
0.00 ± -1% +Inf% 9581 ± 43%
latency_stats.avg.do_truncate.do_sys_ftruncate.SyS_ftruncate.system_call_fastpath
0.00 ± -1% +Inf% 500330 ± 58%
latency_stats.avg.xfs_file_buffered_aio_write.xfs_file_write_iter.new_sync_write.vfs_write.SyS_write.system_call_fastpath
163371 ± 3% +26.6% 206775 ± 1%
latency_stats.hits.ring_buffer_wait.wait_on_pipe.tracing_wait_pipe.tracing_read_pipe.__vfs_read.vfs_read.SyS_read.system_call_fastpath
0.00 ± -1% +Inf% 32695 ± 10%
latency_stats.max.do_truncate.do_sys_ftruncate.SyS_ftruncate.system_call_fastpath
0.00 ± -1% +Inf% 669208 ± 18%
latency_stats.max.xfs_file_buffered_aio_write.xfs_file_write_iter.new_sync_write.vfs_write.SyS_write.system_call_fastpath
0.00 ± -1% +Inf% 53331 ± 28%
latency_stats.sum.do_truncate.do_sys_ftruncate.SyS_ftruncate.system_call_fastpath
0.00 ± -1% +Inf% 706140 ± 12%
latency_stats.sum.xfs_file_buffered_aio_write.xfs_file_write_iter.new_sync_write.vfs_write.SyS_write.system_call_fastpath
394.50 ± 24% -53.2% 184.50 ± 37% sched_debug.cfs_rq[3]:/.load
37.00 ± 34% +51.4% 56.00 ± 17% sched_debug.cpu#1.cpu_load[1]
84.75 ± 19% -52.8% 40.00 ± 68% sched_debug.cpu#3.cpu_load[0]
69.25 ± 20% -50.5% 34.25 ± 34% sched_debug.cpu#3.cpu_load[1]
50.25 ± 11% -45.8% 27.25 ± 23% sched_debug.cpu#3.cpu_load[2]
36.25 ± 5% -37.9% 22.50 ± 22% sched_debug.cpu#3.cpu_load[3]
394.50 ± 24% -53.2% 184.50 ± 37% sched_debug.cpu#3.load
2.138e+11 ± 0% -1.4% 2.108e+11 ± 0% perf-stat.L1-dcache-loads
2.483e+08 ± 0% -4.3% 2.376e+08 ± 0% perf-stat.L1-dcache-prefetches
4.605e+09 ± 0% +7.8% 4.962e+09 ± 0% perf-stat.L1-icache-load-misses
5.684e+11 ± 0% +2.0% 5.797e+11 ± 0% perf-stat.L1-icache-loads
1.637e+08 ± 0% +15.8% 1.895e+08 ± 1% perf-stat.LLC-load-misses
1.089e+11 ± 0% +1.3% 1.103e+11 ± 0% perf-stat.branch-loads
8.163e+10 ± 0% +2.9% 8.396e+10 ± 1% perf-stat.bus-cycles
3.116e+08 ± 1% +9.6% 3.415e+08 ± 0% perf-stat.cache-misses
9306030 ± 1% -1.4%9171655 ± 0%
Re: [PATCH] thermal: cpu_cooling: Iterate over all CPUs in clip_cpu mask to get frequency table
Hi Viresh,
On Tue, Jul 7, 2015 at 6:27 PM, Viresh Kumar wrote:
> On 01-07-15, 12:13, Pi-Cheng Chen wrote:
>> Sorry for the mistake I made when cherry-picking the patch. Fix and resend
>> again.
>
> You really want above to show up in git logs ?
>
> Any comments like this should be present:
> - in cover-letter
> - OR after the three dashes below ---
> - OR must be followed with a scissors line, like this:
> --8<
Thanks for the lesson. :)
>
>> __cpufreq_cooling_register() might fail if some CPU other than first one in
>> clip_cpu mask is present earlier e.g. CPU hotplug. Iterate all CPUs in the
>> mask
>> to handle this case.
>>
>> Signed-off-by: Pi-Cheng Chen
>> ---
>> drivers/thermal/cpu_cooling.c | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index 6509c61..5e90eb6 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -776,9 +776,14 @@ __cpufreq_cooling_register(struct device_node *np,
>> char dev_name[THERMAL_NAME_LENGTH];
>> struct cpufreq_frequency_table *pos, *table;
>> unsigned int freq, i, num_cpus;
>> - int ret;
>> + int ret, cpu;
>> +
>> + for_each_cpu(cpu, clip_cpus) {
>> + table = cpufreq_frequency_get_table(cpu);
>> + if (table)
>> + break;
>> + }
>>
>> - table = cpufreq_frequency_get_table(cpumask_first(clip_cpus));
>
> Nah, that's wrong. I hope that's a hypothetical problem and not a real
> one. Would have been better if cpufreq maintainers were cc'd as they
> can provide more insight into this :)
>
> cpufreq_frequency_get_table() does: policy->freq_table and so it
> doesn't matter if the cpu is online or not.
>
> cpufreq_cpu_data was getting unset earlier on hotplug, but that's not
> the case anymore. So nothing to worry about :)
Yes. This is based on the case before 4.2-rc1 which policy of cpu will
be destroy after all cpus in a cluster are unplugged (right?). Since it
is not the case anymore now, this patch is not needed at all.
Thanks.
Best Regards,
Pi-Cheng
>
> --
> 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/
[PATCH] clk: st: Fix error paths and allocation style
The error paths in this file leak memory and mappings and test
for pointers being valid after dereferencing them. Fix these
problems and properly free resources on errors. Fix some
stylistic things too like using sizeof(*ptr) and fitting more
code on a single line. Note that we don't unregister clocks here.
That needs a clk_composite_unregister() API that we don't have
right now.
Cc: Gabriel Fernandez
Cc: Pankaj Dev
Signed-off-by: Stephen Boyd
---
drivers/clk/st/clkgen-mux.c | 83 -
1 file changed, 45 insertions(+), 38 deletions(-)
diff --git a/drivers/clk/st/clkgen-mux.c b/drivers/clk/st/clkgen-mux.c
index 717c4a91a17b..ab9298395264 100644
--- a/drivers/clk/st/clkgen-mux.c
+++ b/drivers/clk/st/clkgen-mux.c
@@ -30,7 +30,7 @@ static const char ** __init clkgen_mux_get_parents(struct
device_node *np,
if (WARN_ON(nparents <= 0))
return ERR_PTR(-EINVAL);
- parents = kzalloc(nparents * sizeof(const char *), GFP_KERNEL);
+ parents = kcalloc(nparents, sizeof(const char *), GFP_KERNEL);
if (!parents)
return ERR_PTR(-ENOMEM);
@@ -215,7 +215,7 @@ static const struct clk_ops clkgena_divmux_ops = {
/**
* clk_register_genamux - register a genamux clock with the clock framework
*/
-static struct clk *clk_register_genamux(const char *name,
+static struct clk * __init clk_register_genamux(const char *name,
const char **parent_names, u8 num_parents,
void __iomem *reg,
const struct clkgena_divmux_data *muxdata,
@@ -369,11 +369,10 @@ static const struct of_device_id
clkgena_divmux_of_match[] = {
{}
};
-static void __iomem * __init clkgen_get_register_base(
- struct device_node *np)
+static void __iomem * __init clkgen_get_register_base(struct device_node *np)
{
struct device_node *pnode;
- void __iomem *reg = NULL;
+ void __iomem *reg;
pnode = of_get_parent(np);
if (!pnode)
@@ -398,7 +397,7 @@ static void __init st_of_clkgena_divmux_setup(struct
device_node *np)
if (WARN_ON(!match))
return;
- data = (struct clkgena_divmux_data *)match->data;
+ data = match->data;
reg = clkgen_get_register_base(np);
if (!reg)
@@ -406,18 +405,18 @@ static void __init st_of_clkgena_divmux_setup(struct
device_node *np)
parents = clkgen_mux_get_parents(np, _parents);
if (IS_ERR(parents))
- return;
+ goto err_parents;
clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
if (!clk_data)
- goto err;
+ goto err_alloc;
clk_data->clk_num = data->num_outputs;
- clk_data->clks = kzalloc(clk_data->clk_num * sizeof(struct clk *),
+ clk_data->clks = kcalloc(clk_data->clk_num, sizeof(struct clk *),
GFP_KERNEL);
if (!clk_data->clks)
- goto err;
+ goto err_alloc_clks;
for (i = 0; i < clk_data->clk_num; i++) {
struct clk *clk;
@@ -447,11 +446,13 @@ static void __init st_of_clkgena_divmux_setup(struct
device_node *np)
of_clk_add_provider(np, of_clk_src_onecell_get, clk_data);
return;
err:
- if (clk_data)
- kfree(clk_data->clks);
-
+ kfree(clk_data->clks);
+err_alloc_clks:
kfree(clk_data);
+err_alloc:
kfree(parents);
+err_parents:
+ iounmap(reg);
}
CLK_OF_DECLARE(clkgenadivmux, "st,clkgena-divmux", st_of_clkgena_divmux_setup);
@@ -491,7 +492,7 @@ static void __init st_of_clkgena_prediv_setup(struct
device_node *np)
void __iomem *reg;
const char *parent_name, *clk_name;
struct clk *clk;
- struct clkgena_prediv_data *data;
+ const struct clkgena_prediv_data *data;
match = of_match_node(clkgena_prediv_of_match, np);
if (!match) {
@@ -499,7 +500,7 @@ static void __init st_of_clkgena_prediv_setup(struct
device_node *np)
return;
}
- data = (struct clkgena_prediv_data *)match->data;
+ data = match->data;
reg = clkgen_get_register_base(np);
if (!reg)
@@ -507,18 +508,18 @@ static void __init st_of_clkgena_prediv_setup(struct
device_node *np)
parent_name = of_clk_get_parent_name(np, 0);
if (!parent_name)
- return;
+ goto err;
if (of_property_read_string_index(np, "clock-output-names",
0, _name))
- return;
+ goto err;
clk = clk_register_divider_table(NULL, clk_name, parent_name,
CLK_GET_RATE_NOCACHE,
reg + data->offset, data->shift, 1,
0, data->table, NULL);
if (IS_ERR(clk))
-
Re: [PATCH v4 3/8] clk: add support for clocks provided by SCP(System Control Processor)
On 07/07, Sudeep Holla wrote:
>
>
> On 06/07/15 20:52, Stephen Boyd wrote:
> >>
> >
> >If I have time I may try to start doing the clk_register() conversion,
> >but it will take a while so I doubt it will be in v4.3. I'm asking if
> >you can add a clk_hw based API that does something like
> >clk_set_rate_range() without requiring a struct clk pointer. i.e.
> >clk_hw_set_rate_range(struct clk_hw *hw, min, max) that constraints the
> >min/max rate of the clock. This way, the driver is only using clk
> >provider APIs and not clk consumer APIs.
> >
>
> I understand the intention of separating clk provider helpers/APIs
> and clk consumer APIs. Since {min,max}_rate are part of struct clk
> itself, I was thinking that you would have moved it to struct clk_core
> as part of the rework you mentioned and hence asked about the patches.
>
> IIUC, if {min,max}_rate remain part of struct clk, then how are we
> restricting that operation to just the clk providers ? clk consumer
> can still directly modify or use clk_set_rate_range.
>
> Do we continue to provide that feature for both provider and consumer ?
> If so I assume {min,max}_rate range requested by consumer should be
> within the limits set by provider and do we maintain both the limits ?
>
> Sorry if I am missing something fundamental since I don't have much
> knowledge of clk layer internals.
>
Yes struct clk would have min/max, and struct clk_core would have
min/max. Then some sort of provider API (or possibly even
clk_init_data) would take the min/max fields and copy them over
to struct clk_core. Then during set_rate operations we would
aggregate the constraints from struct clk like we already do and
add in the constrains in struct clk_core.
One downside to adding new fields to clk_init_data is that there
are drivers out there that aren't initializing that structure to
0, and they're putting it on the stack, so stack junk can come
through. Furthermore, min/max would mean that every driver needs
to specify some large number for max or we have to special case
min == max == 0 and ignore it. Somehow it needs to be opt-in. If
we want to go down the clk_init_data route then perhaps we need
some sort of rate_constraint struct pointer in there that drivers
can optionally setup.
struct clk_rate_constraint {
unsigned long min;
unsigned long max;
};
struct clk_init_data {
...
struct clk_rate_constraint *rate_constraint;
};
I haven't thought it through completely, but I can probably write
up some patch tomorrow after I sleep on it.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/2] bpf: Introduce function for outputing data to perf event
On 7/7/15 4:43 AM, He Kuang wrote:
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -210,6 +210,9 @@ enum bpf_func_id {
* Return: 0 on success
*/
BPF_FUNC_l4_csum_replace,
+
+ /* int bpf_output_data(void *src, int size, void *regs) */
bpf_output_trace_data(struct pt_regs *ctx, void *data, int data_size)
+ BPF_FUNC_output_data,
__BPF_FUNC_MAX_ID,
};
+static u64 bpf_output_data(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ void *src = (void *) (long) r1;
+ int dsize = (int) r2, __size, size;
+ void *regs = (void *) (long) r3;
please cast to 'struct pt_regs *', since that's what it is.
+ __size = sizeof(*entry) + dsize;
+ size = ALIGN(__size + sizeof(u32), sizeof(u64));
+ size -= sizeof(u32);
+
+ entry = perf_trace_buf_prepare(size, TRACE_BPF, NULL, );
+ if (!entry)
+ return -ENOMEM;
+
+ entry->size = dsize;
something wrong here. Either 'size' from bpf_trace_entry_head
should be used or from trace_bpf.
(void *) BPF_FUNC_l4_csum_replace;
+static int (*bpf_output_data)(void *src, int size, void *regs) =
+ (void *) BPF_FUNC_output_data;
'struct pt_regs *ctx' here as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the vhost tree with Linus' tree
Hi Michael,
Today's linux-next merge of the vhost tree got a conflict in:
MAINTAINERS
between commit:
4ad6ee91aa9f ("Add MAINTAINERS entry for virtio-gpu")
from Linus' tree and commit:
f2dbda3b4fc2 ("MAINTAINERS: separate section for s390 virtio drivers")
from the vhost tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc MAINTAINERS
index d558d280fdc1,fbef7d0a4dd5..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -10895,15 -10570,15 +10894,24 @@@ F:drivers/block/virtio_blk.
F:include/linux/virtio_*.h
F:include/uapi/linux/virtio_*.h
+ VIRTIO DRIVERS FOR S390
+ M:Christian Borntraeger
+ M:Cornelia Huck
+ L:linux-s...@vger.kernel.org
+ L:virtualizat...@lists.linux-foundation.org
+ L:k...@vger.kernel.org
+ S:Supported
+ F:drivers/s390/virtio/
+
+VIRTIO GPU DRIVER
+M:David Airlie
+M:Gerd Hoffmann
+L:dri-de...@lists.freedesktop.org
+L:virtualizat...@lists.linux-foundation.org
+S:Maintained
+F:drivers/gpu/drm/virtio/
+F:include/uapi/linux/virtio_gpu.h
+
VIRTIO HOST (VHOST)
M:"Michael S. Tsirkin"
L:k...@vger.kernel.org
pgpKILSDDbBt9.pgp
Description: OpenPGP digital signature
[RFC] freeing unliked file indefinitely delayed
Normally opening a file, unlinking it and then closing will have
the inode freed upon close() (provided that it's not otherwise busy and
has no remaining links, of course). However, there's one case where that
does *not* happen. Namely, if you open it by fhandle with cold dcache,
then unlink() and close().
In normal case you get d_delete() in unlink(2) notice that dentry
is busy and unhash it; on the final dput() it will be forcibly evicted from
dcache, triggering iput() and inode removal. In this case, though, we end
up with *two* dentries - disconnected (created by open-by-fhandle) and
regular one (used by unlink()). The latter will have its reference to inode
dropped just fine, but the former will not - it's considered hashed (it
is on the ->s_anon list), so it will stay around until the memory pressure
will finally do it in. As the result, we have the final iput() delayed
indefinitely. It's trivial to reproduce -
#define _GNU_SOURCE
#include
#include
#include
void flush_dcache(void)
{
system("mount -o remount,rw /");
}
static char buf[20 * 1024 * 1024];
main()
{
int fd;
union {
struct file_handle f;
char buf[MAX_HANDLE_SZ];
} x;
int m;
x.f.handle_bytes = sizeof(x);
chdir("/root");
mkdir("foo", 0700);
fd = open("foo/bar", O_CREAT | O_RDWR, 0600);
close(fd);
name_to_handle_at(AT_FDCWD, "foo/bar", , , 0);
flush_dcache();
fd = open_by_handle_at(AT_FDCWD, , O_RDWR);
unlink("foo/bar");
write(fd, buf, sizeof(buf));
system("df ."); /* 20Mb eaten */
close(fd);
system("df ."); /* should've freed those 20Mb */
flush_dcache();
system("df ."); /* should be the same as #2 */
}
will spit out something like
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 322023 303843 1131 100% /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 322023 303843 1131 100% /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 322023 283282 21692 93% /
- inode gets freed only when dentry is finally evicted (here we trigger
than by remount; normally it would've happened in response to memory
pressure hell knows when).
IMO it's a bug. Between the close() and final flush_dcache() the file has
no surviving links, is *not* busy, won't show up in fuser/lsof/whatnot
output, and yet it's still not freed. I'm not saying that it's realistically
exploitable (albeit with nfsd it might be), but it's a very unpleasant
self-LART.
FWIW, my prefered fix would be simply to have the final dput() treat
disconnected dentries as "kill on sight"; checking for i_nlink of the
inode, as Bruce suggested several years ago, will *not* work, simply
because having another link to that file and unlinking it after close
will reproduce the situation - disconnected dentry sticks around in
dcache past its final dput() and past the last unlink() of our file.
Theoretically it might cause an overhead for nfsd (no_subtree_check v3
export might see more d_alloc()/d_free(); icache retention will still
prevent constant rereading the inode from disk). _IF_ that proves to
be noticable, we might need to come up with something more elaborate
(e.g. have unlink() and rename() kick disconnected aliases out if the link
count has reached 0), but it's more complex and needs careful ananlysis
of correctness - we need to prove that there's no way to miss the link
count reaching 0. I would prefer to treat all disconnected as unhashed
for dcache retention purposes - it's simpler and less brittle. Comments?
I mean something like this:
diff --git a/fs/dcache.c b/fs/dcache.c
index 7a3f3e5..5c8ea15 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -642,7 +642,7 @@ static inline bool fast_dput(struct dentry *dentry)
/*
* If we have a d_op->d_delete() operation, we sould not
-* let the dentry count go to zero, so use "put__or_lock".
+* let the dentry count go to zero, so use "put_or_lock".
*/
if (unlikely(dentry->d_flags & DCACHE_OP_DELETE))
return lockref_put_or_lock(>d_lockref);
@@ -697,7 +697,7 @@ static inline bool fast_dput(struct dentry *dentry)
*/
smp_rmb();
d_flags = ACCESS_ONCE(dentry->d_flags);
- d_flags &= DCACHE_REFERENCED | DCACHE_LRU_LIST;
+ d_flags &= DCACHE_REFERENCED | DCACHE_LRU_LIST | DCACHE_DISCONNECTED;
/* Nothing to do? Dropping the reference was all we needed? */
if (d_flags == (DCACHE_REFERENCED | DCACHE_LRU_LIST) &&
!d_unhashed(dentry))
@@ -776,6 +776,9 @@ repeat:
if (unlikely(d_unhashed(dentry)))
goto kill_it;
+ if (unlikely(dentry->d_flags & DCACHE_DISCONNECTED))
+ goto kill_it;
+
if (unlikely(dentry->d_flags & DCACHE_OP_DELETE)) {
Re: [RFC PATCH v3 1/2] tracing: Add new trace type for bpf data output
On 7/7/15 4:43 AM, He Kuang wrote:
+ F_STRUCT(
+ __field(long, size)
as Peter said please use u32 to avoid 32 vs 64-bit issues.
+ __array(u64,raw_data, TRACE_BPF_MAX_ENTRY)
+ ),
+
+ F_printk("%ld: (%016llx, ...)", __entry->size, __entry->raw_data[0]),
can we conditionally print raw_data[0], raw_data[1], ..[3] when
values are non-zero? '...' as part of print is kinda useless.
Also I would drop '()' and ',' they don't add much value.
Remember we won't be able to change this format once it goes in.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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 v3 0/2] Make eBPF programs output data to perf event
On 7/7/15 4:43 AM, He Kuang wrote: Hi, The two previous versions tried to combine bpf output data with the sample event of the attached kprobe point, which leads to problems about perf_trace_buf. After discussion we found it's not necessary to combine those two parts of information, even we do not need the orignial kprobe output event at all. Based on this idea, the implementation becomes simple, just like what perf do with ftrace:functions, we set up a bpf ftrace entry for perf tools to poll and collect data on it, eBpf program use a helper function to submit data to ring-buffer, that's all. This implementation also leaves all issues such as sample-types to perf commandline. Currently, we just use raw data in the format fields to not interfere perf sample parser, because the raw-data can be parsed by perf script plugin easily. Looks much better! In general I think splitting it into two patches is confusing, since 1st patch is meaningless without 2nd. I would squash it. Other comments inline. bpf_output_sample(_time, sizeof(del_time)); typo? You meant bpf_output_data(_time, sizeof(del_time), ctx) ? To match the rest of helpers, please make ctx to be first argument. Also I think bpf_output_trace_data() name is better. bpf_output_data name doesn't indicate that it's tracing only helper and might be confusing with networking helpers. Record bpf events: $ perf record -e ftrace:bpf -e sample.o -- dd if=/dev/zero of=test bs=4k count=3 The results showed in perf-script: $ perf script dd 994 [000] 166.686779: ftrace:bpf: 8: (0542b426, ...) dd 994 [000] 166.686779: ftrace:bpf: 8: (001011ef, ...) dd 994 [000] 166.686779: ftrace:bpf: 8: (0007a2b6, ...) nice! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] STAGING SUBSYSTEM rtl8188eu driver : Fixed 80 character length warning in rtw_ap.c
When the checkpatch.pl script was run, it showed lines with length
more than 80 characters in rtw_ap.c file. Fixed line number 382 by
breaking it up into two lines within 80 characters.
Signed-off-by: Sreenath Madasu
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 581af88..293510e 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -379,7 +379,8 @@ voidexpire_timeout_chk(struct adapter *padapter)
if (pmlmeext->active_keep_alive_check) {
int stainfo_offset;
- stainfo_offset = rtw_stainfo_offset(pstapriv,
psta);
+ stainfo_offset =
+ rtw_stainfo_offset(pstapriv, psta);
if (stainfo_offset_valid(stainfo_offset))
chk_alive_list[chk_alive_num++] =
stainfo_offset;
continue;
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN
VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is in use. The code is a big undocumented mess, it's a real PITA to test, and it looks like a big chunk of vm86_32.c is dead code. It also plays awful games with the entry asm. No one should be using it anyway. Use DOSBOX or KVM instead. Mark it BROKEN. I want to remove some (obviously incorrect) exit asm that it depends on, and I don't want to figure out how to run severely obsolete programs just to test something that no one uses for anything other than exploits anyway. Signed-off-by: Andy Lutomirski --- I find it implausible that vm86_32.c isn't full or root holes. It's also full of hilariously ugly code, it does terrible things to the kernel stack, and its interaction with the syscall slowpath is blatantly incorrect. It really shouldn't have any users, anyway. It doesn't (and can't!) work on 64-bit kernels, and the only program that even knows how it works appears to be DOSEMU. DOSEMU doesn't even need it for most programs (it uses modify_ldt instead if possible), and DOSBOX and KVM are better choices anyway. I think that even DOSEMU might be able to emulate vm86 (by emulating instruction-by-instruction) if the vm86 syscall isn't there. Want to be terrified? Read copy_vm86_regs_from_user. Or mark_screen_rdonly. Or return_to_32bit. Or VM86_REQUEST_IRQ. What do you all think? This code is a maintenance disaster, and I'd love to see it go. This would be a nice first step. This patch is intended for tip/x86/asm. The 32-bit part of my big cleanup will interfere with vm86, and, while I think I fixed it up right, I'd rather not expose everyone to the high probability of crazy security bugs in this mess. arch/x86/Kconfig | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index aa94fd014fa2..080228bdbcda 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -997,8 +997,8 @@ config X86_THERMAL_VECTOR depends on X86_MCE_INTEL config VM86 - bool "Enable VM86 support" if EXPERT - default y + bool "Enable VM86 support" if BROKEN + default n depends on X86_32 ---help--- This option is required by programs like DOSEMU to run @@ -1006,6 +1006,12 @@ config VM86 be needed by software like XFree86 to initialize some video cards via BIOS. Disabling this option saves about 6K. + Linux's vm86 support is poorly maintained, essentially never + tested by upstream kernel developers, has quite a few known + bugs, and is probably full of security holes. The only thing + that appears to use it is DOSEMU, and DOSBOX and KVM are + better options these days. Don't enable it. + config X86_16BIT bool "Enable support for 16-bit segments" if EXPERT default y -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] power_supply: rt9455_charger: Properly notify userspace about charging events
2015-07-07 21:25 GMT+09:00 Anda-Maria Nicolae : > Charging events this patch refers to are: > - charger is connected to/disconnected from the power source > - battery is reconnected to the charger, after it was absent. > > When the charger is connected to/disconnected from the power source, CHRVPI > interrupt occurs and PWR_RDY bit is either set or cleared. PWR_RDY bit is > updated after 1-2 seconds CHRVPI interrupt has occurred. > power_supply_changed() should be called after PWR_RDY bit is updated. > /sys/class/power_supply/rt9455-charger/online file displays the value of > PWR_RDY bit. > This way, if the userspace is notified that a charging event has occurred > and the userspace reads /sys/class/power_supply/rt9455-charger/online file, > this file is properly updated when the userspace reads it. > This is the reason why power_supply_changed() is called in > rt9455_pwr_rdy_work_callback(), instead of being called in interrupt > handler. > > Since no interrupt is triggered when the battery is reconnected to the > charger, the userspace is never notified that the battery is reconnected. > This is why power_supply_changed() is called in > rt9455_max_charging_time_work_callback(), so that the userspace is notified > that the battery is reconnected. > > Signed-off-by: Anda-Maria Nicolae > --- > > Updates from v1 version: > - I have followed Kzrysztof's suggestion and I have added explanations in > the commit message so that the change is more clear > - Code is the same as in v1 Thanks, FWIW: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hwmon: (f71882fg): Add support for f81768d
Add f81768d (id 0x1210) currently found on Jetway motherboards.
It has 11 voltages but otherwise needed no special handling
in this driver.
Signed-off-by: George Joseph
---
drivers/hwmon/f71882fg.c | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/hwmon/f71882fg.c b/drivers/hwmon/f71882fg.c
index e4ff21f..4c9ec5c 100644
--- a/drivers/hwmon/f71882fg.c
+++ b/drivers/hwmon/f71882fg.c
@@ -59,6 +59,7 @@
#define SIO_F71889E_ID 0x0909 /* Chipset ID */
#define SIO_F71889A_ID 0x1005 /* Chipset ID */
#define SIO_F8000_ID 0x0581 /* Chipset ID */
+#define SIO_F81768D_ID 0x1210 /* Chipset ID */
#define SIO_F81865_ID 0x0704 /* Chipset ID */
#define SIO_F81866_ID 0x1010 /* Chipset ID */
@@ -107,7 +108,7 @@
#defineF71882FG_REG_START 0x01
-#define F71882FG_MAX_INS 10
+#define F71882FG_MAX_INS 11
#define FAN_MIN_DETECT 366 /* Lowest detectable fanspeed */
@@ -116,7 +117,7 @@ module_param(force_id, ushort, 0);
MODULE_PARM_DESC(force_id, "Override the detected device ID");
enum chips { f71808e, f71808a, f71858fg, f71862fg, f71868a, f71869, f71869a,
- f71882fg, f71889fg, f71889ed, f71889a, f8000, f81865f, f81866a};
+ f71882fg, f71889fg, f71889ed, f71889a, f8000, f81768d, f81865f,
f81866a};
static const char *const f71882fg_names[] = {
"f71808e",
@@ -131,25 +132,27 @@ static const char *const f71882fg_names[] = {
"f71889ed",
"f71889a",
"f8000",
+ "f81768d",
"f81865f",
"f81866a",
};
static const char f71882fg_has_in[][F71882FG_MAX_INS] = {
- [f71808e] = { 1, 1, 1, 1, 1, 1, 0, 1, 1, 0 },
- [f71808a] = { 1, 1, 1, 1, 0, 0, 0, 1, 1, 0 },
- [f71858fg] = { 1, 1, 1, 0, 0, 0, 0, 0, 0, 0 },
- [f71862fg] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
- [f71868a] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
- [f71869]= { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
- [f71869a] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
- [f71882fg] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
- [f71889fg] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
- [f71889ed] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
- [f71889a] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
- [f8000] = { 1, 1, 1, 0, 0, 0, 0, 0, 0, 0 },
- [f81865f] = { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
- [f81866a] = { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f71808e] = { 1, 1, 1, 1, 1, 1, 0, 1, 1, 0, 0 },
+ [f71808a] = { 1, 1, 1, 1, 0, 0, 0, 1, 1, 0, 0 },
+ [f71858fg] = { 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
+ [f71862fg] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f71868a] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
+ [f71869]= { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f71869a] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f71882fg] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f71889fg] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f71889ed] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f71889a] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ [f8000] = { 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
+ [f81768d] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
+ [f81865f] = { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
+ [f81866a] = { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
};
static const char f71882fg_has_in1_alarm[] = {
@@ -165,6 +168,7 @@ static const char f71882fg_has_in1_alarm[] = {
[f71889ed] = 1,
[f71889a] = 1,
[f8000] = 0,
+ [f81768d] = 1,
[f81865f] = 1,
[f81866a] = 1,
};
@@ -182,6 +186,7 @@ static const char f71882fg_fan_has_beep[] = {
[f71889ed] = 1,
[f71889a] = 1,
[f8000] = 0,
+ [f81768d] = 1,
[f81865f] = 1,
[f81866a] = 1,
};
@@ -199,6 +204,7 @@ static const char f71882fg_nr_fans[] = {
[f71889ed] = 3,
[f71889a] = 3,
[f8000] = 3, /* +1 fan which is monitor only */
+ [f81768d] = 3,
[f81865f] = 2,
[f81866a] = 3,
};
@@ -216,6 +222,7 @@ static const char f71882fg_temp_has_beep[] = {
[f71889ed] = 1,
[f71889a] = 1,
[f8000] = 0,
+ [f81768d] = 1,
[f81865f] = 1,
[f81866a] = 1,
};
@@ -233,6 +240,7 @@ static const char f71882fg_nr_temps[] = {
[f71889ed] = 3,
[f71889a] = 3,
[f8000] = 3,
+ [f81768d] = 3,
[f81865f] = 2,
[f81866a] = 3,
};
@@ -569,6 +577,7 @@ static struct sensor_device_attribute_2 f_in_attr[] = {
SENSOR_ATTR_2(in7_input, S_IRUGO, show_in, NULL, 0, 7),
SENSOR_ATTR_2(in8_input,
Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c
The kernelnewbies.org guide said "For your first patch, only pick one warning". That is the reason why I fixed one warning. Thanks Sreenath On Tue, Jul 07, 2015 at 03:32:50PM -0400, valdis.kletni...@vt.edu wrote: > On Mon, 06 Jul 2015 21:53:26 -0400, Sreenath Madasu said: > > When the checkpatch.pl script was run, it showed lines with length > > more than 80 characters in rtw_ap.c file. Fixed line number 382 by > > breaking it up into two lines within 80 characters. > > > > - stainfo_offset = rtw_stainfo_offset(pstapriv, > > psta); > > + stainfo_offset = > > + rtw_stainfo_offset(pstapriv, psta); > > if (stainfo_offset_valid(stainfo_offset)) > > chk_alive_list[chk_alive_num++] = > > stainfo_offset; > > Umm... Sreenath? > > There's 97 more occurrences of the same problem in that file. > > All: Is it time to kill that checkpatch test, or hide it behind a non-default > flag, to prevent code churn? > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/15] SH: kill off set_irq_flags usage
On Tue, Jul 07, 2015 at 09:38:53AM -0500, Rob Herring wrote:
> On Mon, Jul 6, 2015 at 8:55 PM, Simon Horman wrote:
> > On Tue, Jul 07, 2015 at 09:53:39AM +0900, Simon Horman wrote:
> >> On Tue, Jun 09, 2015 at 01:26:38PM -0500, Rob Herring wrote:
> >> > set_irq_flags is ARM specific with custom flags which have genirq
> >> > equivalents. Convert drivers to use the genirq interfaces directly, so we
> >> > can kill off set_irq_flags. The translation of flags is as follows:
> >> >
> >> > IRQF_VALID -> !IRQ_NOREQUEST
> >> > IRQF_PROBE -> !IRQ_NOPROBE
> >> > IRQF_NOAUTOEN -> IRQ_NOAUTOEN
> >> >
> >> > For IRQs managed by an irqdomain, the irqdomain core code handles
> >> > clearing
> >> > and setting IRQ_NOREQUEST already, so there is no need to do this in
> >> > .map() functions and we can simply remove the set_irq_flags calls. Some
> >> > users also set IRQ_NOPROBE and this has been maintained although it is
> >> > not
> >> > clear that is really needed. There appears to be a great deal of blind
> >> > copy and paste of this code.
> >> >
> >> > Signed-off-by: Rob Herring
> >> > Cc: Simon Horman
> >> > Cc: Magnus Damm
> >> > Cc: linux...@vger.kernel.org
> >>
> >> I am trusting the description above coupled with the comments in
> >> the original code (that this patch removes). Assuming those ducks are
> >> aligned:
> >>
> >> Acked-by: Simon Horman
> >
> > As I usually take patches for drivers/sh/ (there have not been many of late)
> > please let me know if you would like me to pick up this change.
>
> This is a dependency for removing set_irq_flags from ARM, so I plan to
> send the whole series to arm-soc.
Thanks, that is fine by me.
> > Also, a very minor nit, the prefix for patches to this file is usually
> > 'sh:' rather than 'SH:'.
>
> Okay, will fix-up.
>
> Rob
>
> >
> >>
> >> > ---
> >> > drivers/sh/intc/internals.h | 10 +-
> >> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >> >
> >> > diff --git a/drivers/sh/intc/internals.h b/drivers/sh/intc/internals.h
> >> > index 7dff08e..897ffb1 100644
> >> > --- a/drivers/sh/intc/internals.h
> >> > +++ b/drivers/sh/intc/internals.h
> >> > @@ -99,15 +99,7 @@ static inline struct intc_desc_int
> >> > *get_intc_desc(unsigned int irq)
> >> > */
> >> > static inline void activate_irq(int irq)
> >> > {
> >> > -#ifdef CONFIG_ARM
> >> > - /* ARM requires an extra step to clear IRQ_NOREQUEST, which it
> >> > -* sets on behalf of every irq_chip. Also sets IRQ_NOPROBE.
> >> > -*/
> >> > - set_irq_flags(irq, IRQF_VALID);
> >> > -#else
> >> > - /* same effect on other architectures */
> >> > - irq_set_noprobe(irq);
> >> > -#endif
> >> > + irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
> >> > }
> >> >
> >> > static inline int intc_handle_int_cmp(const void *a, const void *b)
> >> > --
> >> > 2.1.0
> >> >
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-sh" 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: [RESEND] mfd: rtsx: add support for rts522A
On 07/07/2015 07:46 PM, Lee Jones wrote:
> On Mon, 29 Jun 2015, micky_ch...@realsil.com.cn wrote:
>
>> From: Micky Ching
>>
>> rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
>> Add it to file mfd/rts5227.c to support this chip.
>>
>> Signed-off-by: Micky Ching
>> ---
>> drivers/mfd/Kconfig | 7 ++--
>> drivers/mfd/rts5227.c| 77
>> ++--
>> drivers/mfd/rtsx_pcr.c | 5 +++
>> drivers/mfd/rtsx_pcr.h | 3 ++
>> include/linux/mfd/rtsx_pci.h | 6
>> 5 files changed, 93 insertions(+), 5 deletions(-)
> I Acked this once already.
>
> What's changed since then?
It's not changed, but I don't have time to fix magic numbers these days,
so, I prefer you apply this patch not waiting next patch.
Thanks.
>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 6538159..614c146 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -686,9 +686,10 @@ config MFD_RTSX_PCI
>> select MFD_CORE
>> help
>>This supports for Realtek PCI-Express card reader including rts5209,
>> - rts5229, rtl8411, etc. Realtek card reader supports access to many
>> - types of memory cards, such as Memory Stick, Memory Stick Pro,
>> - Secure Digital and MultiMediaCard.
>> + rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
>> + Realtek card reader supports access to many types of memory cards,
>> + such as Memory Stick, Memory Stick Pro, Secure Digital and
>> + MultiMediaCard.
>>
>> config MFD_RT5033
>> tristate "Richtek RT5033 Power Management IC"
>> diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
>> index ce012d7..cf13e66 100644
>> --- a/drivers/mfd/rts5227.c
>> +++ b/drivers/mfd/rts5227.c
>> @@ -26,6 +26,14 @@
>>
>> #include "rtsx_pcr.h"
>>
>> +static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
>> +{
>> +u8 val;
>> +
>> +rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, );
>> +return val & 0x0F;
>> +}
>> +
>> static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
>> {
>> u8 driving_3v3[4][3] = {
>> @@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr,
>> u8 pm_state)
>> rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
>>
>> if (pm_state == HOST_ENTER_S3)
>> -rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
>> +rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x10);
>>
>> rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
>> }
>> @@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
>> rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
>> else
>> rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
>> -rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
>> +rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr->reg_pm_ctrl3, 0x10, 0x00);
>>
>> return rtsx_pci_send_cmd(pcr, 100);
>> }
>> @@ -298,8 +306,73 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
>> pcr->tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
>> pcr->rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
>>
>> +pcr->ic_version = rts5227_get_ic_version(pcr);
>> pcr->sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
>> pcr->sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
>> pcr->ms_pull_ctl_enable_tbl = rts5227_ms_pull_ctl_enable_tbl;
>> pcr->ms_pull_ctl_disable_tbl = rts5227_ms_pull_ctl_disable_tbl;
>> +
>> +pcr->reg_pm_ctrl3 = PM_CTRL3;
>> +}
>> +
>> +static int rts522a_optimize_phy(struct rtsx_pcr *pcr)
>> +{
>> +int err;
>> +
>> +err = rtsx_pci_write_register(pcr, RTS522A_PM_CTRL3, D3_DELINK_MODE_EN,
>> +0x00);
>> +if (err < 0)
>> +return err;
>> +
>> +if (is_version(pcr, 0x522A, IC_VER_A)) {
>> +err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
>> +PHY_RCR2_INIT_27S);
>> +if (err)
>> +return err;
>> +
>> +rtsx_pci_write_phy_register(pcr, PHY_RCR1, PHY_RCR1_INIT_27S);
>> +rtsx_pci_write_phy_register(pcr, PHY_FLD0, PHY_FLD0_INIT_27S);
>> +rtsx_pci_write_phy_register(pcr, PHY_FLD3, PHY_FLD3_INIT_27S);
>> +rtsx_pci_write_phy_register(pcr, PHY_FLD4, PHY_FLD4_INIT_27S);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int rts522a_extra_init_hw(struct rtsx_pcr *pcr)
>> +{
>> +rts5227_extra_init_hw(pcr);
>> +
>> +rtsx_pci_write_register(pcr, FUNC_FORCE_CTL, FUNC_FORCE_UPME_XMT_DBG,
>> +FUNC_FORCE_UPME_XMT_DBG);
>> +rtsx_pci_write_register(pcr, PCLK_CTL, 0x04, 0x04);
>> +rtsx_pci_write_register(pcr, PM_EVENT_DEBUG, PME_DEBUG_0, PME_DEBUG_0);
>> +rtsx_pci_write_register(pcr, PM_CLK_FORCE_CTL, 0xFF, 0x11);
>> +
>> +return 0;
>> +}
>> +
>> +/* rts522a operations mainly derived from rts5227, except phy/hw init
>>
RE: [RFC PATCH] irq: IRQ bypass manager
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Wednesday, July 08, 2015 5:40 AM
> To: linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Cc: eric.au...@st.com; eric.au...@linaro.org; j...@8bytes.org;
> avi.kiv...@gmail.com; pbonz...@redhat.com; Wu, Feng
> Subject: [RFC PATCH] irq: IRQ bypass manager
>
> When a physical I/O device is assigned to a virtual machine through
> facilities like VFIO and KVM, the interrupt for the device generally
> bounces through the host system before being injected into the VM.
> However, hardware technologies exist that often allow the host to be
> bypassed for some of these scenarios. Intel Posted Interrupts allow
> the specified physical edge interrupts to be directly injected into a
> guest when delivered to a physical processor while the vCPU is
> running. ARM IRQ Forwarding allows the hypervisor to handle level
> triggered device interrupts as edge interrupts, by giving the guest
> control of de-asserting and unmasking the interrupt line.
>
> The IRQ bypass manager here is meant to provide the shim to connect
> interrupt producers, generally the host physical device driver, with
> interrupt consumers, generally the hypervisor, in order to configure
> these bypass mechanism. To do this, we base the connection on a
> shared, opaque token. For KVM-VFIO this is expected to be an
> eventfd_ctx since this is the connection we already use to connect an
> eventfd to an irqfd on the in-kernel path. When a producer and
> consumer with matching tokens is found, callbacks via both registered
> participants allow the bypass facilities to be automatically enabled.
>
> Signed-off-by: Alex Williamson
> Cc: Eric Auger
> ---
>
> This is the current draft of the IRQ bypass manager, I've made the
> following changes:
>
> - Incorporated Eric's extensions (I would welcome Sign-offs from all
>involved in the development, especially Eric - I've gone ahead and
>added Linaro copyright for the contributions so far)
> - Module support with module reference tracking
> - might_sleep() as suggested by Paolo
> - kerneldoc as suggested by Paolo
> - Renamed file s/bypass/irqbypass/ because a module named "bypass"
>is strange
>
> Issues:
> - The update() callback is defined but not used
Yeah, the update() callback is added by me, I need it to update IRTE
in irqfd_update().
> - We can't have *all* the callbacks be optional. I assume add/del
>are required
> - Naming consistency, stop is to start as suspend is to resume, not
>stop/resume
> - Callback descriptions including why we need separate stop/start
>hooks when it seems like the callee could reasonably assume such
>around the add/del callbacks
> - Need functional prototypes for both PI and forwarding
>
> include/linux/irqbypass.h | 75
> kernel/irq/Kconfig|3 +
> kernel/irq/Makefile |1
> kernel/irq/irqbypass.c| 206
> +
> 4 files changed, 285 insertions(+)
> create mode 100644 include/linux/irqbypass.h
> create mode 100644 kernel/irq/irqbypass.c
>
> diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
> new file mode 100644
> index 000..cc7ce45
> --- /dev/null
> +++ b/include/linux/irqbypass.h
> @@ -0,0 +1,75 @@
> +/*
> + * IRQ offload/bypass manager
> + *
> + * Copyright (C) 2015 Red Hat, Inc.
> + * Copyright (c) 2015 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef IRQBYPASS_H
> +#define IRQBYPASS_H
> +
> +#include
> +
> +struct irq_bypass_consumer;
> +
> +/**
> + * struct irq_bypass_producer - IRQ bypass producer definition
> + * @node: IRQ bypass manager private list management
> + * @token: opaque token to match between producer and consumer
> + * @irq: Linux IRQ number for the producer device
> + * @stop:
> + * @resume:
> + * @add_consumer:
> + * @del_consumer:
> + *
> + * The IRQ bypass producer structure represents an interrupt source for
> + * participation in possible host bypass, for instance an interrupt vector
> + * for a physical device assigned to a VM.
> + */
> +struct irq_bypass_producer {
> + struct list_head node;
> + void *token;
> + int irq; /* linux irq */
> + void (*stop)(struct irq_bypass_producer *);
> + void (*resume)(struct irq_bypass_producer *);
> + void (*add_consumer)(struct irq_bypass_producer *,
> + struct irq_bypass_consumer *);
> + void (*del_consumer)(struct irq_bypass_producer *,
> + struct irq_bypass_consumer *);
> +};
> +
> +/**
> + * struct irq_bypass_consumer - IRQ bypass consumer definition
> + * @node: IRQ bypass manager private list management
> + * @token: opaque token to match between producer and consumer
> + * @stop:
> + *
Re: [PATCH v5] clk: change clk_ops' ->determine_rate() prototype
On 07/07, Boris Brezillon wrote:
> Clock rates are stored in an unsigned long field, but ->determine_rate()
> (which returns a rounded rate from a requested one) returns a long
> value (errors are reported using negative error codes), which can lead
> to long overflow if the clock rate exceed 2Ghz.
>
> Change ->determine_rate() prototype to return 0 or an error code, and pass
> a pointer to a clk_rate_request structure containing the expected target
> rate and the rate constraints imposed by clk users.
>
> The clk_rate_request structure might be extended in the future to contain
> other kind of constraints like the rounding policy, the maximum clock
> inaccuracy or other things that are not yet supported by the CCF
> (power consumption constraints ?).
>
> Signed-off-by: Boris Brezillon
>
> CC: Jonathan Corbet
> CC: Tony Lindgren
> CC: Ralf Baechle
> CC: "Emilio López"
> CC: Maxime Ripard
> CC: Tero Kristo
> CC: Peter De Schrijver
> CC: Prashant Gaikwad
> CC: Stephen Warren
> CC: Thierry Reding
> CC: Alexandre Courbot
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-o...@vger.kernel.org
> CC: linux-m...@linux-mips.org
> CC: linux-te...@vger.kernel.org
>
> ---
I'll throw this patch into -next now to see if any other problems
shake out. I'm hoping we get some more acks though, so it'll be
on it's own branch and become immutable in a week or so. One
question below.
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index 616f5ae..9e69f34 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -99,33 +99,33 @@ static long clk_composite_determine_rate(struct clk_hw
> *hw, unsigned long rate,
>
> parent_rate = __clk_get_rate(parent);
>
> - tmp_rate = rate_ops->round_rate(rate_hw, rate,
> + tmp_rate = rate_ops->round_rate(rate_hw, req->rate,
> _rate);
> if (tmp_rate < 0)
> continue;
>
> - rate_diff = abs(rate - tmp_rate);
> + rate_diff = abs(req->rate - tmp_rate);
>
> - if (!rate_diff || !*best_parent_p
> + if (!rate_diff || !req->best_parent_hw
> || best_rate_diff > rate_diff) {
> - *best_parent_p = __clk_get_hw(parent);
> - *best_parent_rate = parent_rate;
> + req->best_parent_hw = __clk_get_hw(parent);
> + req->best_parent_rate = parent_rate;
> best_rate_diff = rate_diff;
> best_rate = tmp_rate;
> }
>
> if (!rate_diff)
> - return rate;
> + return 0;
> }
>
> - return best_rate;
> + req->rate = best_rate;
> + return 0;
> } else if (mux_hw && mux_ops && mux_ops->determine_rate) {
> __clk_hw_set_clk(mux_hw, hw);
> - return mux_ops->determine_rate(mux_hw, rate, min_rate,
> -max_rate, best_parent_rate,
> -best_parent_p);
> + return mux_ops->determine_rate(mux_hw, req);
> } else {
> pr_err("clk: clk_composite_determine_rate function called, but
> no mux or rate callback set!\n");
> + req->rate = 0;
> return 0;
Shouldn't this return an error now? And then assigning req->rate
wouldn't be necessary. Sorry I must have missed this last round.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
kernel/cpu.c: In function '_cpu_down':
kernel/cpu.c:398:2: error: implicit declaration of function 'irq_lock_sparse'
[-Werror=implicit-function-declaration]
irq_lock_sparse();
^
kernel/cpu.c:407:3: error: implicit declaration of function 'irq_unlock_sparse'
[-Werror=implicit-function-declaration]
irq_unlock_sparse();
^
Caused by commit
fc862aa8288b ("hotplug: Prevent alloc/free of irq descriptors during cpu
up/down")
Forgot to include linux/irqdesc.h.
I have used the tip tree from next-20150707 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpM29tfFp18n.pgp
Description: OpenPGP digital signature
Re: lock-up with module: Optimize __module_address() using a latched RB-tree
Peter Zijlstra writes: > On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote: >> On Wed, Jul 08, 2015 at 05:45:45AM +0930, Arthur Marsh wrote: >> > I'm not aware of any modules being loaded with --force . >> > >> > I've applied the patch, thanks! >> > >> > The resultant kernel locked up as follows: >> > >> > http://www.users.on.net/~arthur.marsh/20150708469.jpg >> >> This has "Not tainted" which would indeed rule out forced loading. So >> much for that idea :/ >> >> > http://www.users.on.net/~arthur.marsh/20150708470.jpg >> >> And that one has a bunch of NMI prints, curious those. But given Mathieu >> made them return NULL, that completely rules out the most interesting >> races. > > Could you try the below? It appears there was a spot freeing modules > that forgot to take them out of the tree. Ouch! Good catch. I'm testing that here Yep, "modprobe lp reset=7" (which fails to parse) three times and then oops in __mod_tree_insert. If you want to wrap that with a SOB and Reported-by/Tested-by if my compatriot acks... Thanks! Rusty. > --- > kernel/module.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/module.c b/kernel/module.c > index 3e0e19763d24..4d2b82e610e2 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3557,6 +3557,7 @@ static int load_module(struct load_info *info, const > char __user *uargs, > mutex_lock(_mutex); > /* Unlink carefully: kallsyms could be walking list. */ > list_del_rcu(>list); > + mod_tree_remove(mod); > wake_up_all(_wq); > /* Wait for RCU-sched synchronizing before releasing mod->list. */ > synchronize_sched(); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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 0/4][RFC] regmap: add force write option
Hi Mark > > Can I have some feedback about these patches ? > > Please do allow some time for review, especially during the merge > window. Thank you for your feedback, and sorry for my reminder. I will re-send these to ML after -rc1 or -rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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: [RFCv3 0/5] enable migration of driver pages
On Wed, Jul 08, 2015 at 09:19:50AM +0900, Gioh Kim wrote: > > > 2015-07-08 오전 9:07에 Andrew Morton 이(가) 쓴 글: > >On Wed, 08 Jul 2015 09:02:59 +0900 Gioh Kim wrote: > > > >> > >> > >>2015-07-08 __ 7:37___ Andrew Morton ___(___) ___ ___: > >>>On Tue, 7 Jul 2015 13:36:20 +0900 Gioh Kim wrote: > >>> > From: Gioh Kim > > Hello, > > This series try to enable migration of non-LRU pages, such as driver's > page. > > My ARM-based platform occured severe fragmentation problem after long-term > (several days) test. Sometimes even order-3 page allocation failed. It has > memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic > processing > and 20~30 memory is reserved for zram. > > I found that many pages of GPU driver and zram are non-movable pages. So I > reported Minchan Kim, the maintainer of zram, and he made the internal > compaction logic of zram. And I made the internal compaction of GPU > driver. > > They reduced some fragmentation but they are not enough effective. > They are activated by its own interface, /sys, so they are not cooperative > with kernel compaction. If there is too much fragmentation and kernel > starts > to compaction, zram and GPU driver cannot work with the kernel compaction. > > ... > > This patch set is tested: > - turn on Ubuntu 14.04 with 1G memory on qemu. > - do kernel building > - after several seconds check more than 512MB is used with free command > - command "balloon 512" in qemu monitor > - check hundreds MB of pages are migrated > >>> > >>>OK, but what happens if the balloon driver is not used to force > >>>compaction? Does your test machine successfully compact pages on > >>>demand, so those order-3 allocations now succeed? > >> > >>If any driver that has many pages like the balloon driver is forced to > >>compact, > >>the system can get free high-order pages. > >> > >>I have to show how this patch work with a driver existing in the kernel > >>source, > >>for kernel developers' undestanding. So I selected the balloon driver > >>because it has already compaction and working with kernel compaction. > >>I can show how driver pages is compacted with lru-pages together. > >> > >>Actually balloon driver is not best example to show how this patch compacts > >>pages. > >>The balloon driver compaction is decreasing page consumtion, for instance > >>1024MB -> 512MB. > >>I think it is not compaction precisely. It frees pages. > >>Of course there will be many high-order pages after 512MB is freed. > > > >Can the various in-kernel GPU drivers benefit from this? If so, wiring > >up one or more of those would be helpful? > > I'm sure that other in-kernel GPU drivers can have benefit. > It must be helpful. > > If I was familiar with other in-kernel GPU drivers code, I tried to patch > them. > It's too bad. > > Minchan Kim said he had a plan to apply this patch into zram compaction. > Many embedded machines use several hundreds MB for zram. > The zram can also have benefit with this patch as much as GPU drivers. > Hello Gioh, It would be helpful for fork-latency and zra+CMA in small memory system. I will implement zsmalloc.migratepages after I finish current going works. Thanks for the nice work! -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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 1/3] video: fbdev: atyfb: clarify ioremap() base and length used
On Thu, Jul 2, 2015 at 4:23 PM, Luis R. Rodriguez wrote: > On Fri, Jun 26, 2015 at 12:30 AM, Borislav Petkov wrote: >> On Fri, Jun 26, 2015 at 03:09:27AM +0200, Luis R. Rodriguez wrote: >>> Sure, mind this as a follow up patch if its too late? >> >> No need, you can send me an updated one - I'll replace it. > > Will do! OK the commend I'm adding: @@ -3489,6 +3489,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, /* Map in frame buffer */ info->fix.smem_start = addr; + + /* +* The framebuffer is not always 8 MiB that's just the size of the +* PCI BAR, this is later corrected for use with write-combining +* helpers with aty_fudge_framebuffer_len() which will adjust the +* framebuffer accordingly depending on the device. We do this +* to match semantics over ioremap calls on framebuffer devices +* with with other drivers with the info->fix.smem_len. +*/ info->fix.smem_len = 0x80; info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len); Will respin. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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] sched: make decaying sched_avg's variables happen on period boundary
On Wed, Jul 08, 2015 at 12:54:30AM +0200, Peter Zijlstra wrote: > On Tue, Jul 07, 2015 at 02:42:56PM +0900, byungchul.p...@lge.com wrote: > > From: Byungchul Park > > > > decaying time happens on every period boundary. if it does not reach > > the period boundary yet, the partial time needs to be kept so that > > the time can be decayed on exactly period boundary at next update. > > > > sa->avg_period is not appropriate for getting partial delta_w because > > the value is a decayed average value, with which we cannnot get partial > > delta at all which does not reach the period boundary yet. > > lkml.kernel.org/r/1435018085-7004-1-git-send-email-yuyang...@intel.com > > There is a comprehensive rewrite of all this under consideration. thank you, peter :) i will check it. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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] clk: at91: Silence warnings and cleanup __init usage
On 07/07, Boris Brezillon wrote: > Hi Stephen, > > On Mon, 6 Jul 2015 14:37:59 -0700 > Stephen Boyd wrote: > > > On 07/06, Alexandre Belloni wrote: > > > Hi, > > > > > > On 06/07/2015 at 12:31:45 -0700, Stephen Boyd wrote : > > > > Remove useless ifdefs around function prototypes to silence the > > > > following sparse warnings when the configs aren't enabled. > > > > > > > > drivers/clk/at91/clk-h32mx.c:95:13: warning: symbol > > > > 'of_sama5d4_clk_h32mx_setup' was not declared. Should it be > > > > static? > > > > drivers/clk/at91/clk-utmi.c:159:13: warning: symbol > > > > 'of_at91sam9x5_clk_utmi_setup' was not declared. Should it be > > > > static? > > > > > > > > Plus, using __init in function prototypes doesn't do anything, so > > > > just drop it throughout this file. > > > > > > > > > > The main drawback of that removal is that it destroys the alignment > > > throughout the header file :) > > > > > > > Ok I can fix the alignment at the same time. > > > > ---8<--- > > From: Stephen Boyd > > Subject: [PATCH] clk: at91: Silence warnings and cleanup __init usage > > > > Remove useless ifdefs around function prototypes to silence the > > following sparse warnings when the configs aren't enabled. > > > > drivers/clk/at91/clk-h32mx.c:95:13: warning: symbol > > 'of_sama5d4_clk_h32mx_setup' was not declared. Should it be > > static? > > drivers/clk/at91/clk-utmi.c:159:13: warning: symbol > > 'of_at91sam9x5_clk_utmi_setup' was not declared. Should it be > > static? > > > > Plus, using __init in function prototypes doesn't do anything, so > > just drop it throughout this file. > > I think we should also drop the useless extern keywords. > Otherwise, > > Acked-by: Boris Brezillon > Ok, I think we got a color match ;-) -8<- From: Stephen Boyd Subject: [PATCH] clk: at91: Silence warnings and cleanup __init/extern usage Remove useless ifdefs around function prototypes to silence the following sparse warnings when the configs aren't enabled. drivers/clk/at91/clk-h32mx.c:95:13: warning: symbol 'of_sama5d4_clk_h32mx_setup' was not declared. Should it be static? drivers/clk/at91/clk-utmi.c:159:13: warning: symbol 'of_at91sam9x5_clk_utmi_setup' was not declared. Should it be static? Plus, using __init and extern in function prototypes doesn't do anything, so just drop it throughout this file. Acked-by: Boris BREZILLON Acked-by: Alexandre Belloni Signed-off-by: Stephen Boyd --- drivers/clk/at91/pmc.h | 124 +++-- 1 file changed, 58 insertions(+), 66 deletions(-) diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h index eb8e5dc9076d..8b87771c69b2 100644 --- a/drivers/clk/at91/pmc.h +++ b/drivers/clk/at91/pmc.h @@ -59,71 +59,63 @@ static inline void pmc_write(struct at91_pmc *pmc, int offset, u32 value) int of_at91_get_clk_range(struct device_node *np, const char *propname, struct clk_range *range); -extern void __init of_at91sam9260_clk_slow_setup(struct device_node *np, -struct at91_pmc *pmc); - -extern void __init of_at91rm9200_clk_main_osc_setup(struct device_node *np, - struct at91_pmc *pmc); -extern void __init of_at91sam9x5_clk_main_rc_osc_setup(struct device_node *np, - struct at91_pmc *pmc); -extern void __init of_at91rm9200_clk_main_setup(struct device_node *np, - struct at91_pmc *pmc); -extern void __init of_at91sam9x5_clk_main_setup(struct device_node *np, - struct at91_pmc *pmc); - -extern void __init of_at91rm9200_clk_pll_setup(struct device_node *np, - struct at91_pmc *pmc); -extern void __init of_at91sam9g45_clk_pll_setup(struct device_node *np, - struct at91_pmc *pmc); -extern void __init of_at91sam9g20_clk_pllb_setup(struct device_node *np, -struct at91_pmc *pmc); -extern void __init of_sama5d3_clk_pll_setup(struct device_node *np, - struct at91_pmc *pmc); -extern void __init of_at91sam9x5_clk_plldiv_setup(struct device_node *np, - struct at91_pmc *pmc); - -extern void __init of_at91rm9200_clk_master_setup(struct device_node *np, - struct at91_pmc *pmc); -extern void __init of_at91sam9x5_clk_master_setup(struct device_node *np, - struct at91_pmc *pmc); - -extern void __init of_at91rm9200_clk_sys_setup(struct device_node *np, - struct at91_pmc *pmc); - -extern void __init of_at91rm9200_clk_periph_setup(struct device_node *np, - struct
Re: [PATCH] sched: let __sched_period() use rq cfs's nr_running
On Tue, Jul 07, 2015 at 01:28:18PM -0700, Cong Wang wrote: > On Mon, Jul 6, 2015 at 9:40 PM, wrote: > > From: Byungchul Park > > > > __sched_period() returns a period which a rq can have. the period has to be > > stretched by the number of task *the rq has*, when nr_running > nr_latency. > > otherwise, task slice can be very smaller than sysctl_sched_min_granularity > > depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED. > > > Hmm, rq_of(cfs_rq)->cfs should point to the root cfs_rq whose > ->nr_running is number of running entities at root level? This > doesn't look right. hello, cong wang, __sched_period() returns a root level period now. stretching the period with a local task group's nr_running is meaningless for getting this period. is there something i missed? :) thank you, byungchul > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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: [RFCv3 0/5] enable migration of driver pages
2015-07-08 오전 9:07에 Andrew Morton 이(가) 쓴 글: On Wed, 08 Jul 2015 09:02:59 +0900 Gioh Kim wrote: 2015-07-08 __ 7:37___ Andrew Morton ___(___) ___ ___: On Tue, 7 Jul 2015 13:36:20 +0900 Gioh Kim wrote: From: Gioh Kim Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver and zram are non-movable pages. So I reported Minchan Kim, the maintainer of zram, and he made the internal compaction logic of zram. And I made the internal compaction of GPU driver. They reduced some fragmentation but they are not enough effective. They are activated by its own interface, /sys, so they are not cooperative with kernel compaction. If there is too much fragmentation and kernel starts to compaction, zram and GPU driver cannot work with the kernel compaction. ... This patch set is tested: - turn on Ubuntu 14.04 with 1G memory on qemu. - do kernel building - after several seconds check more than 512MB is used with free command - command "balloon 512" in qemu monitor - check hundreds MB of pages are migrated OK, but what happens if the balloon driver is not used to force compaction? Does your test machine successfully compact pages on demand, so those order-3 allocations now succeed? If any driver that has many pages like the balloon driver is forced to compact, the system can get free high-order pages. I have to show how this patch work with a driver existing in the kernel source, for kernel developers' undestanding. So I selected the balloon driver because it has already compaction and working with kernel compaction. I can show how driver pages is compacted with lru-pages together. Actually balloon driver is not best example to show how this patch compacts pages. The balloon driver compaction is decreasing page consumtion, for instance 1024MB -> 512MB. I think it is not compaction precisely. It frees pages. Of course there will be many high-order pages after 512MB is freed. Can the various in-kernel GPU drivers benefit from this? If so, wiring up one or more of those would be helpful? I'm sure that other in-kernel GPU drivers can have benefit. It must be helpful. If I was familiar with other in-kernel GPU drivers code, I tried to patch them. It's too bad. Minchan Kim said he had a plan to apply this patch into zram compaction. Many embedded machines use several hundreds MB for zram. The zram can also have benefit with this patch as much as GPU drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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] bio integrity: do not assume bio_integrity_pool exists if bioset exists
> "Mike" == Mike Snitzer writes: Sorry I'm a bit late to the game here. Just got back from vacation. But I agree with the patch. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] tcp: v1 always send a quick ack when quickacks are enabled
V1 of this patch contains Eric Dumazet's suggestion to move the per
dst RTAX_QUICKACK check into tcp_in_quickack_mode(). Thanks Eric.
I ran some tests and after setting the "ip route change quickack 1"
knob there were still many delayed ACKs sent. This occured
because when icsk_ack.quick=0 the !icsk_ack.pingpong value is
subsequently ignored as tcp_in_quickack_mode() checks both these
values. The condition for a quick ack to trigger requires
that both icsk_ack.quick != 0 and icsk_ack.pingpong=0. Currently
only icsk_ack.pingpong is controlled by the knob. But the
icsk_ack.quick value changes dynamically depending on heuristics.
The crux of the matter is that delayed acks still cannot be entirely
disabled even with the RTAX_QUICKACK per dst knob enabled. This
patch ensures that a quick ack is always sent when the RTAX_QUICKACK
per dst knob is turned on.
The "ip route change quickack 1" knob was recently added to enable
quickacks. It was modeled around the TCP_QUICKACK setsockopt() option.
This issue is that even with "ip route change quickack 1" enabled
we still see delayed ACKs under some conditions. It would be nice
to be able to completely disable delayed ACKs.
Here is an example:
# netstat -s|grep dela
3 delayed acks sent
For all routes enable the knob
# ip route change quickack 1
Generate some traffic across a slow link and we still see the delayed
acks.
# netstat -s|grep dela
106 delayed acks sent
1 delayed acks further delayed because of locked socket
The issue is that both the "ip route change quickack 1" knob and
the TCP_QUICKACK option set the icsk_ack.pingpong variable to 0.
However at the business end in the __tcp_ack_snd_check() routine,
tcp_in_quickack_mode() checks that both icsk_ack.quick != 0
and icsk_ack.pingpong=0 in order to trigger a quickack. As
icsk_ack.quick is determined by heuristics it can be 0. When
that occurs the icsk_ack.pingpong value is ignored and a delayed
ACK is sent regardless.
This patch moves the RTAX_QUICKACK per dst check into the
tcp_in_quickack_mode() routine which ensures that a quickack is
always sent when the quickack knob is enabled for that dst.
Signed-off-by: Jon Maxwell
---
net/ipv4/tcp_input.c | 11 +--
net/ipv4/tcp_output.c | 6 ++
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 684f095..b9da527 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -196,11 +196,13 @@ static void tcp_enter_quickack_mode(struct sock *sk)
* and the session is not interactive.
*/
-static inline bool tcp_in_quickack_mode(const struct sock *sk)
+static bool tcp_in_quickack_mode(struct sock *sk)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
+ const struct dst_entry *dst = __sk_dst_get(sk);
- return icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong;
+ return (dst && dst_metric(dst, RTAX_QUICKACK)) ||
+ (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);
}
static void tcp_ecn_queue_cwr(struct tcp_sock *tp)
@@ -3948,7 +3950,6 @@ void tcp_reset(struct sock *sk)
static void tcp_fin(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- const struct dst_entry *dst;
inet_csk_schedule_ack(sk);
@@ -3960,9 +3961,7 @@ static void tcp_fin(struct sock *sk)
case TCP_ESTABLISHED:
/* Move to CLOSE_WAIT */
tcp_set_state(sk, TCP_CLOSE_WAIT);
- dst = __sk_dst_get(sk);
- if (!dst || !dst_metric(dst, RTAX_QUICKACK))
- inet_csk(sk)->icsk_ack.pingpong = 1;
+ inet_csk(sk)->icsk_ack.pingpong = 1;
break;
case TCP_CLOSE_WAIT:
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index b1c218d..7105784 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -163,7 +163,6 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
{
struct inet_connection_sock *icsk = inet_csk(sk);
const u32 now = tcp_time_stamp;
- const struct dst_entry *dst = __sk_dst_get(sk);
if (sysctl_tcp_slow_start_after_idle &&
(!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto))
@@ -174,9 +173,8 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
/* If it is a reply for ato after last received
* packet, enter pingpong mode.
*/
- if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato &&
- (!dst || !dst_metric(dst, RTAX_QUICKACK)))
- icsk->icsk_ack.pingpong = 1;
+ if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato)
+ icsk->icsk_ack.pingpong = 1;
}
/* Account for an ACK we sent. */
--
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
Re: [RFCv3 0/5] enable migration of driver pages
On Wed, 08 Jul 2015 09:02:59 +0900 Gioh Kim wrote: > > > 2015-07-08 __ 7:37___ Andrew Morton ___(___) ___ ___: > > On Tue, 7 Jul 2015 13:36:20 +0900 Gioh Kim wrote: > > > >> From: Gioh Kim > >> > >> Hello, > >> > >> This series try to enable migration of non-LRU pages, such as driver's > >> page. > >> > >> My ARM-based platform occured severe fragmentation problem after long-term > >> (several days) test. Sometimes even order-3 page allocation failed. It has > >> memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic > >> processing > >> and 20~30 memory is reserved for zram. > >> > >> I found that many pages of GPU driver and zram are non-movable pages. So I > >> reported Minchan Kim, the maintainer of zram, and he made the internal > >> compaction logic of zram. And I made the internal compaction of GPU driver. > >> > >> They reduced some fragmentation but they are not enough effective. > >> They are activated by its own interface, /sys, so they are not cooperative > >> with kernel compaction. If there is too much fragmentation and kernel > >> starts > >> to compaction, zram and GPU driver cannot work with the kernel compaction. > >> > >> ... > >> > >> This patch set is tested: > >> - turn on Ubuntu 14.04 with 1G memory on qemu. > >> - do kernel building > >> - after several seconds check more than 512MB is used with free command > >> - command "balloon 512" in qemu monitor > >> - check hundreds MB of pages are migrated > > > > OK, but what happens if the balloon driver is not used to force > > compaction? Does your test machine successfully compact pages on > > demand, so those order-3 allocations now succeed? > > If any driver that has many pages like the balloon driver is forced to > compact, > the system can get free high-order pages. > > I have to show how this patch work with a driver existing in the kernel > source, > for kernel developers' undestanding. So I selected the balloon driver > because it has already compaction and working with kernel compaction. > I can show how driver pages is compacted with lru-pages together. > > Actually balloon driver is not best example to show how this patch compacts > pages. > The balloon driver compaction is decreasing page consumtion, for instance > 1024MB -> 512MB. > I think it is not compaction precisely. It frees pages. > Of course there will be many high-order pages after 512MB is freed. Can the various in-kernel GPU drivers benefit from this? If so, wiring up one or more of those would be helpful? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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: [REPOST PATCH 3/3] USB: dwc2: Don't turn off the usbphy in suspend if wakeup is enabled
> Doug, how would you feel about reworking the patch that exports > usb_wakeup_enabled_descendants()? Instead of doing it that way, create > and export a new subroutine in hcd.c called > usb_hcd_wakeup_not_needed(), or something similar. We have a use case with another host controller (Tegra, which I think is still in the process of being upstreamed) where we are able to power down PHYs (and thus reduce power consumption) per port. I think we should prefer the more flexible 'number of wake devices in subtree' interface to be able to support cases like that. (And for the simple case, 'if (usb_hcd_wakeup_not_needed(hcd))' and 'if (!usb_wakeup_enabled_descendants(hcd->self.root_hub))' look pretty similar anyway.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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: [RFCv3 0/5] enable migration of driver pages
2015-07-08 오전 7:37에 Andrew Morton 이(가) 쓴 글: On Tue, 7 Jul 2015 13:36:20 +0900 Gioh Kim wrote: From: Gioh Kim Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver and zram are non-movable pages. So I reported Minchan Kim, the maintainer of zram, and he made the internal compaction logic of zram. And I made the internal compaction of GPU driver. They reduced some fragmentation but they are not enough effective. They are activated by its own interface, /sys, so they are not cooperative with kernel compaction. If there is too much fragmentation and kernel starts to compaction, zram and GPU driver cannot work with the kernel compaction. ... This patch set is tested: - turn on Ubuntu 14.04 with 1G memory on qemu. - do kernel building - after several seconds check more than 512MB is used with free command - command "balloon 512" in qemu monitor - check hundreds MB of pages are migrated OK, but what happens if the balloon driver is not used to force compaction? Does your test machine successfully compact pages on demand, so those order-3 allocations now succeed? If any driver that has many pages like the balloon driver is forced to compact, the system can get free high-order pages. I have to show how this patch work with a driver existing in the kernel source, for kernel developers' undestanding. So I selected the balloon driver because it has already compaction and working with kernel compaction. I can show how driver pages is compacted with lru-pages together. Actually balloon driver is not best example to show how this patch compacts pages. The balloon driver compaction is decreasing page consumtion, for instance 1024MB -> 512MB. I think it is not compaction precisely. It frees pages. Of course there will be many high-order pages after 512MB is freed. Why are your changes to the GPU driver not included in this patch series? My platform is ARM-based and GPU is ARM-Mali. The driver is not open source. It's too bad that I cannot show effect of this patch with the GPU driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation
On Tue, Jul 07, 2015 at 04:35:17PM -0700, Andy Lutomirski wrote: > On Tue, Jul 7, 2015 at 4:29 PM, Josh Poimboeuf wrote: > > On Tue, Jul 07, 2015 at 03:57:14PM -0700, Andy Lutomirski wrote: > >> On Tue, Jul 7, 2015 at 7:54 AM, Josh Poimboeuf wrote: > >> > > >> > It currently only supports x86_64. I tried to make the code generic so > >> > that support for other architectures can hopefully be plugged in > >> > relatively easily. > >> > > >> > Currently with my Fedora config it's reporting over 1400 warnings, but > >> > most of them are duplicates. The warnings affect 37 .c files and 18 .S > >> > files. The C file warnings are generally due to inline assembly, which > >> > doesn't seem to play nice with frame pointers. > >> > >> This issue might be worth bringing up on the gcc and binutils lists. > >> If we need better toolchain support, let's ask for it. > > > > I think we found a good solution for this. See my update at: > > > > https://lkml.kernel.org/r/20150707223519.ga31...@treble.redhat.com > > Does that force frame pointer generation? If so, then once we have a > real kernel unwinder, we might want a non-frame-pointer-forcing > version for better code generation. (That can wait, of course.) I strongly doubt it would force frame pointer generation if -fomit-frame-pointer is set. But I'll verify :-) > >> > + > >> > + This is a context switch instruction like sysenter or sysret. Such > >> > + instructions aren't allowed in a callable function, and are most > >> > + likely part of kernel entry code. > >> > + > >> > + If the instruction isn't actually in a callable function, change > >> > + ENDPROC to END. > >> > + > >> > + > >> > +6. stackvalidate: asm_file.o: func()+0x26: jump to outside file from > >> > callable function > >> > + or > >> > + stackvalidate: asm_file.o: func()+0xd9: jump to dynamic address from > >> > callable function > >> > + > >> > + These are constraints imposed by stackvalidate so that it can > >> > + properly analyze all jump targets. Dynamic jump targets and jumps to > >> > + code in other object files aren't allowed. > >> > >> Does this not trigger due to optimized sibling calls to different files? > > > > This is a great point. With CONFIG_FRAME_POINTER it's not a problem, > > because it adds -fno-optimize-sibling-calls. > > > > Without it, I think stackvalidate would spit out a ton of "jump to > > outside file" warnings. > > > > I haven't yet looked at the details of how exactly sibling calls work. > > I'd assume they're disabled because they break frame pointers somehow. > > Any idea if they'd also break DWARF CFI stack traces? > > They'll certainly prevent unwinding from finding the pre-optimization > caller, but the rest of unwinding should work. I don't know why we > turn it off, though. > > You might want special-case jump-out-of-translation-unit to be okay if > the stack frame is in its initial state. That is: > > func: > jmp elsewhere > > could be considered okay, as could: > > func: > push %rax > pop %rax > jmp elsewhere > > and similar. Ah, nice idea. That might cover all the cases. I'll try it. > > > > > I probably need to do some digging there. If sibling calls don't break > > CFI stack traces and we end up needing them, stackvalidate might need to > > analyze the entire kernel image at once instead of its current per-.o > > checking. > > > > Anyway, thanks a bunch for all your insightful feedback Andy! > > > > I'm just pretending to be insightful :) Insightful or not, your comments have been very helpful! -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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:irqchip: IRQCHIP_DECLARE macro is now accessible
On 08.07.2015 05:02, Joel Porquet wrote:
> The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h', making it
> globally accessible.
>
> See commit 91e20b5040c67c51aad88cf87db4305c5bd7f79d
> ("irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h").
>
> This patch adds inclusions of 'include/linux/irqchip.h' and replaces uses of
> macro OF_DECLARE_2 with IRQCHIP_DECLARE.
>
> Signed-off-by: Joel Porquet
> ---
> arch/arm/mach-exynos/suspend.c | 3 ++-
> arch/arm/mach-imx/gpc.c | 7 ++-
> arch/arm/mach-omap2/omap-wakeupgen.c | 7 ++-
> 3 files changed, 6 insertions(+), 11 deletions(-)
>
For Exynos:
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Clarification for the use of additional fields in the message body
Hi Markus, On Wed, Jul 8, 2015 at 2:15 AM, SF Markus Elfring wrote: >> I can't remember ever changing or explicitly preserving the commit date. >> I don't think I care enough. > > Would any more software developers and maintainers like to share > their experiences around such details? > > When do commit timestamps become relevant as a documentation item > for contribution authorship? They are never relevant. "When" a commit happened is never relevant except in relation to other things, at which point the actual date and time is almost completely irrelevant. Just submit your patches using git-format-patch or git-send-email and friends. There's a file in the documentation directory of the kernel tree describing submitting patches and email client setup. Read them both, do what they say without anything extra. >> Remembering the author separately from the committer is something >> git does by design anyway. > > Do you usually just reuse a procedure from a well-known command > for which a description is provided like the following? > http://git-scm.com/docs/git-am > '… > "From: " and "Subject: " lines starting the body override > the respective commit author name and title values > taken from the headers. > …' > > Will further fields be eventually mentioned there? Why? Just do what is described in SubmittingPatches. Your attempts to "improve" on the system are unnecessary and annoying people. The instructions there are the recommended way to do things for a reason. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/4] stackvalidate: Add ignore macros
On Tue, Jul 07, 2015 at 04:00:54PM -0700, Andy Lutomirski wrote:
> On Tue, Jul 7, 2015 at 3:59 PM, Josh Poimboeuf wrote:
> > On Tue, Jul 07, 2015 at 03:00:38PM -0700, Andy Lutomirski wrote:
> >> On Tue, Jul 7, 2015 at 7:54 AM, Josh Poimboeuf wrote:
> >> > Add new stackvalidate ignore macros: STACKVALIDATE_IGNORE_INSN and
> >> > STACKVALIDATE_IGNORE_FUNC. These can be used to tell stackvalidate to
> >> > skip validation of an instruction or a function, respectively.
> >> >
> >> > Signed-off-by: Josh Poimboeuf
> >> > ---
> >> > include/linux/stackvalidate.h | 38
> >> > ++
> >> > 1 file changed, 38 insertions(+)
> >> > create mode 100644 include/linux/stackvalidate.h
> >> >
> >> > diff --git a/include/linux/stackvalidate.h
> >> > b/include/linux/stackvalidate.h
> >> > new file mode 100644
> >> > index 000..30d4a60
> >> > --- /dev/null
> >> > +++ b/include/linux/stackvalidate.h
> >> > @@ -0,0 +1,38 @@
> >> > +#ifndef _LINUX_STACKVALIDATE_H
> >> > +#define _LINUX_STACKVALIDATE_H
> >> > +
> >> > +#ifndef __ASSEMBLY__
> >> > +
> >> > +/*
> >> > + * This C macro tells the stack validation script to ignore the
> >> > function. It
> >> > + * should only be used in special cases where you're 100% sure it won't
> >> > affect
> >> > + * the reliability of frame pointers and kernel stack traces.
> >> > + *
> >> > + * For more information, see Documentation/stack-validation.txt.
> >> > + */
> >> > +#define STACKVALIDATE_IGNORE_FUNC(_func) \
> >> > + void
> >> > __attribute__((section("__stackvalidate_ignore_func,\"ae\"#"))) \
> >> > + *__stackvalidate_ignore_func_##_func = _func
> >> > +
> >>
> >> static? Otherwise there's some risk that ignoring a static function
> >> will cause a duplicate symbol. Alternatively you could generate a
> >> more unique name.
> >>
> >> Also, should the linker script be updated to discard this section?
> >
> > It validates per individual object file, so there shouldn't be a risk of
> > duplicate symbols. The 'e' flag in ,\"ae\"#" tells the linker to
> > discard the section.
> >
> > (The ,\"ae\"# stuff is a horrible hack, but it's the only way I could
> > figure out how to set the section flags from C code. The '#' is used to
> > comment out gcc's default arguments to the .section directive in favor
> > of the "ae" flags.)
>
> Oh, egads. FWIW, doing it in the linker script would probably be less
> hackish.
Yeah. I'll try that.
> Does the linker discard before noticing duplicate symbols in that section?
I think it does, but I'll verify. I deliberately made it global so the
compiler doesn't discard the symbol for being unused. But I can use the
unused attribute to avoid that.
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push
On Tue, Jul 07, 2015 at 05:29:43PM +0800, Gavin Guo wrote: > Hi all, > > Recently, we observed that there is the error message in > Ubuntu-3.13.0-48.80: > > "XFS: possible memory allocation deadlock in kmem_alloc (mode:0x8250)" > > repeatedly shows in the dmesg. Temporarily, our workaround is to tune the > parameters, such as, vfs_cache_pressure, min_free_kbytes, and dirty_ratio. > > And we also found that there are different error messages regarding the > hung tasks which happened in xfs_log_commit_cil and xlog_cil_push. > > The log is available at: http://paste.ubuntu.com/11835007/ > > The following link seems the same problem we suffered: > > XFS hangs with XFS: possible memory allocation deadlock in kmem_alloc > http://oss.sgi.com/archives/xfs/2015-03/msg00172.html > > I read the mail and found that there might be some modification regarding > to move the memory allocation outside the ctx lock. And I also read the > latest patch from February of 2015 to see if there is any new change > about that. Unfortunately, I didn't find anything regarding the change (may > be I'm not familiar with the XFS, so didn't find the commit). If it's > possible for someone who is familiar with the code to point out the commits > related to the bug if already exist or any status about the plan. No commits - the approach I thought we might be able to take to avoid the problem didn't work out. I have another idea of how we might solve the problem, but I haven't ad a chance to prototype it yet. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation
On Tue, Jul 7, 2015 at 4:29 PM, Josh Poimboeuf wrote: > On Tue, Jul 07, 2015 at 03:57:14PM -0700, Andy Lutomirski wrote: >> On Tue, Jul 7, 2015 at 7:54 AM, Josh Poimboeuf wrote: >> > >> > It currently only supports x86_64. I tried to make the code generic so >> > that support for other architectures can hopefully be plugged in >> > relatively easily. >> > >> > Currently with my Fedora config it's reporting over 1400 warnings, but >> > most of them are duplicates. The warnings affect 37 .c files and 18 .S >> > files. The C file warnings are generally due to inline assembly, which >> > doesn't seem to play nice with frame pointers. >> >> This issue might be worth bringing up on the gcc and binutils lists. >> If we need better toolchain support, let's ask for it. > > I think we found a good solution for this. See my update at: > > https://lkml.kernel.org/r/20150707223519.ga31...@treble.redhat.com Does that force frame pointer generation? If so, then once we have a real kernel unwinder, we might want a non-frame-pointer-forcing version for better code generation. (That can wait, of course.) >> > + >> > + This is a context switch instruction like sysenter or sysret. Such >> > + instructions aren't allowed in a callable function, and are most >> > + likely part of kernel entry code. >> > + >> > + If the instruction isn't actually in a callable function, change >> > + ENDPROC to END. >> > + >> > + >> > +6. stackvalidate: asm_file.o: func()+0x26: jump to outside file from >> > callable function >> > + or >> > + stackvalidate: asm_file.o: func()+0xd9: jump to dynamic address from >> > callable function >> > + >> > + These are constraints imposed by stackvalidate so that it can >> > + properly analyze all jump targets. Dynamic jump targets and jumps to >> > + code in other object files aren't allowed. >> >> Does this not trigger due to optimized sibling calls to different files? > > This is a great point. With CONFIG_FRAME_POINTER it's not a problem, > because it adds -fno-optimize-sibling-calls. > > Without it, I think stackvalidate would spit out a ton of "jump to > outside file" warnings. > > I haven't yet looked at the details of how exactly sibling calls work. > I'd assume they're disabled because they break frame pointers somehow. > Any idea if they'd also break DWARF CFI stack traces? They'll certainly prevent unwinding from finding the pre-optimization caller, but the rest of unwinding should work. I don't know why we turn it off, though. You might want special-case jump-out-of-translation-unit to be okay if the stack frame is in its initial state. That is: func: jmp elsewhere could be considered okay, as could: func: push %rax pop %rax jmp elsewhere and similar. > > I probably need to do some digging there. If sibling calls don't break > CFI stack traces and we end up needing them, stackvalidate might need to > analyze the entire kernel image at once instead of its current per-.o > checking. > > Anyway, thanks a bunch for all your insightful feedback Andy! > I'm just pretending to be insightful :) --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + kmod-remove-unecessary-explicit-wide-cpu-affinity-setting.patch added to -mm tree
Well, sorry for noise. Let me repeat that I agree with this change, but... On 07/07, Andrew Morton wrote: > > From: Frederic Weisbecker > Subject: kmod: remove unecessary explicit wide CPU affinity setting > > Not only useless it even breaks nohz full. The housekeeping work (general > kernel internal code that user doesn't care much about) is handled by a > reduced set of CPUs in nohz full, precisely those that are not included by > nohz_full= kernel parameters. For example unbound workqueues are handled > by housekeeping CPUs. I still think this part of the changelog looks confusing and just wrong. It is not that it breaks nohz full, unbound workqueues have nothing to do with housekeeping_mask from the kernel pov. But yes, people can change ->cpumask and this can connect to housekeeping_mask. Frederic, may I ask you to update the changelog? Although perhaps it was just me who was confused... Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation
On Tue, Jul 07, 2015 at 03:57:14PM -0700, Andy Lutomirski wrote: > On Tue, Jul 7, 2015 at 7:54 AM, Josh Poimboeuf wrote: > > 5. A callable function may not jump to a dynamically determined address. > >Such jumps can't be validated since the jump destination is unknown > >at compile time. > > Hmm. Are there no switch statements that get optimized into jump > tables for which this breaks? Yeah. I discovered this the hard way and had to add support for reading the switch jump tables. I should probably make that clearer here in the changelog and in the documentation. > > 6. A callable function may not execute a context switching instruction. > >The only code which needs to do context switches is kernel entry > >code, which shouldn't be annotated to be in callable functions > >anyway. > > > > It currently only supports x86_64. I tried to make the code generic so > > that support for other architectures can hopefully be plugged in > > relatively easily. > > > > Currently with my Fedora config it's reporting over 1400 warnings, but > > most of them are duplicates. The warnings affect 37 .c files and 18 .S > > files. The C file warnings are generally due to inline assembly, which > > doesn't seem to play nice with frame pointers. > > This issue might be worth bringing up on the gcc and binutils lists. > If we need better toolchain support, let's ask for it. I think we found a good solution for this. See my update at: https://lkml.kernel.org/r/20150707223519.ga31...@treble.redhat.com > > +2. stackvalidate: asm_file.o: .text+0x53: return instruction outside of a > > callable function > > + > > + A return instruction was detected, but stackvalidate couldn't find a > > + way for a callable function to reach the instruction. > > + > > + If the return instruction is inside (or reachable from) a callable > > + function, the function needs to be annotated with the PROC/ENDPROC > > + macros. > > + > > + If you _really_ need a return instruction outside of a function, and > > + are 100% sure that it won't affect stack traces, you can tell > > + stackvalidate to ignore it. See the "Adding exceptions" section > > + below. > > This will happen as soon as someone implements > iretless-return-to-kernel for real. We can add an exception :) > > > + > > +5. stackvalidate: asm_file.o: func()+0x6: context switch from callable > > function > > This description threw me off for a bit. When I read "context > switch", I thought of __switch_to. Would something like "kernel > entry/exit instruction" instead of "context switch" be clearer? Yeah, I'll rename it. > > + > > + This is a context switch instruction like sysenter or sysret. Such > > + instructions aren't allowed in a callable function, and are most > > + likely part of kernel entry code. > > + > > + If the instruction isn't actually in a callable function, change > > + ENDPROC to END. > > + > > + > > +6. stackvalidate: asm_file.o: func()+0x26: jump to outside file from > > callable function > > + or > > + stackvalidate: asm_file.o: func()+0xd9: jump to dynamic address from > > callable function > > + > > + These are constraints imposed by stackvalidate so that it can > > + properly analyze all jump targets. Dynamic jump targets and jumps to > > + code in other object files aren't allowed. > > Does this not trigger due to optimized sibling calls to different files? This is a great point. With CONFIG_FRAME_POINTER it's not a problem, because it adds -fno-optimize-sibling-calls. Without it, I think stackvalidate would spit out a ton of "jump to outside file" warnings. I haven't yet looked at the details of how exactly sibling calls work. I'd assume they're disabled because they break frame pointers somehow. Any idea if they'd also break DWARF CFI stack traces? I probably need to do some digging there. If sibling calls don't break CFI stack traces and we end up needing them, stackvalidate might need to analyze the entire kernel image at once instead of its current per-.o checking. Anyway, thanks a bunch for all your insightful feedback Andy! -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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 1/7] clk: introduce clk_div_mask() helper
On 07/07, Andy Shevchenko wrote:
> On Thu, 2015-06-18 at 12:48 -0700, Stephen Boyd wrote:
> > On 03/31, Andy Shevchenko wrote:
> > > diff --git a/include/linux/clk-provider.h b/include/linux/clk
> > > -provider.h
> > > index 5591ea7..20b0b67 100644
> > > --- a/include/linux/clk-provider.h
> > > +++ b/include/linux/clk-provider.h
> > > @@ -353,6 +353,11 @@ struct clk_divider {
> > > spinlock_t *lock;
> > > };
> > >
> > > +static inline unsigned long clk_div_mask(u8 width)
> > > +{
> > > + return (1 << width) - 1;
> > > +}
> > > +
> >
> > Why not just change drivers to use GENMASK? It's a proven and
> > tested way to generate a bitmask.
>
> Too many unneeded calculations I suppose.
That's what compiler optimizations are for.
>
> Compare:
> mask = clk_div_mask(mm) << ms;
> which is simple ((1 << mm) - 1) << ms
> and
> mask = GENMASK(mm + ms - 1, ms);
> which is (~0 << ms) & (~0 >> (BITS_PER_LONG - 1 - (mm + ms -
> 1)))
And if mm is 32 then we hit undefined behavior.
>
> >
> > So I'd rather see drivers converted to use that macro directly
> > especially because the mask may need to start at some bit that
> > isn't 0.
>
> If you think the above is not a burden, I can do the conversion to
> GENMASK.
>
> Though it might make sense when ms = 0 explicitly.
>
Yes let's use GENMASK. I imagine the extra few instructions are
negligible.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mm: Increase SWAP_CLUSTER_MAX to batch TLB flushes
On Mon, 6 Jul 2015 14:39:56 +0100 Mel Gorman wrote: > Pages that are unmapped for reclaim must be flushed before being freed to > avoid corruption due to a page being freed and reallocated while a stale > TLB entry exists. When reclaiming mapped pages, the requires one IPI per > SWAP_CLUSTER_MAX. This patch increases SWAP_CLUSTER_MAX to 256 so more > pages can be flushed with a single IPI. This number was selected because > it reduced IPIs for TLB shootdowns by 40% on a workload that is dominated > by mapped pages. > > Note that it is expected that doubling SWAP_CLUSTER_MAX would not always > halve the IPIs as it is workload dependent. Reclaim efficiency was not 100% > on this workload which was picked for being IPI-intensive and was closer to > 35%. More importantly, reclaim does not always isolate in SWAP_CLUSTER_MAX > pages. The LRU lists for a zone may be small, the priority can be low > and even when reclaiming a lot of pages, the last isolation may not be > exactly SWAP_CLUSTER_MAX. > > There are a few potential issues with increasing SWAP_CLUSTER_MAX. > > 1. LRU lock hold times increase slightly because more pages are being >isolated. > 2. There are slight timing changes due to more pages having to be >processed before they are freed. There is a slight risk that more >pages than are necessary get reclaimed. > 3. There is a risk that too_many_isolated checks will be easier to >trigger resulting in a HZ/10 stall. > 4. The rotation rate of active->inactive is slightly faster but there >should be fewer rotations before the lists get balanced so it >shouldn't matter. > 5. More pages are reclaimed in a single pass if zone_reclaim_mode is >active but that thing sucks hard when it's enabled no matter what > 6. More pages are isolated for compaction so page hold times there >are longer while they are being copied > > It's unlikely any of these will be problems but worth keeping in mind if > there are any reclaim-related bug reports in the near future. Yes, this may well cause small changes which will take some time to be noticed. What is the overall effect on the performance improvement if this patch is omitted? I wonder if we should leave small systems or !SMP systems or CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=n systems with SWAP_CLUSTER_MAX=32. If not, why didn't we change this years ago ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
