Re: [PATCH] clk: at91: fix pmc_clk_ids data type attriubte
Quoting Nicolas Ferre (2013-12-17 01:33:04)
> On 16/12/2013 22:25, Boris BREZILLON :
> > Fix pmc_clk_ids data type attribute (__initdata -> __initconst).
> >
> > Signed-off-by: Boris BREZILLON
> > Reported-by: Fengguang Wu
>
> Acked-by: Nicolas Ferre
>
> I take it in at91-3.14-cleanup2 branch and send it upstream through
> arm-soc like any other CCF material for AT91 for the 3.14 release.
>
> I guess that even without Mike Acked-by, this little fix can follow this
> path.
I can take it into the clk tree if you prefer.
Regards,
Mike
>
> Bye,
>
> > ---
> > drivers/clk/at91/pmc.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
> > index 7b9db60..4c03eda 100644
> > --- a/drivers/clk/at91/pmc.c
> > +++ b/drivers/clk/at91/pmc.c
> > @@ -228,7 +228,7 @@ out_free_pmc:
> > return NULL;
> > }
> >
> > -static const struct of_device_id pmc_clk_ids[] __initdata = {
> > +static const struct of_device_id pmc_clk_ids[] __initconst = {
> > /* Main clock */
> > {
> > .compatible = "atmel,at91rm9200-clk-main",
> >
>
>
> --
> Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 13/14] Documentation/RTC: add document of ACPI TAD and EFI TIME driver
This patch add rtc-tz.txt document to explain the RTC driver of ACPI TAD, EFI TIME. It focus on the timezone field and CMOS RTC Not Present bit of ACPI 5.0. Signed-off-by: Lee, Chun-Yi --- Documentation/rtc-tz.txt | 510 ++ 1 files changed, 510 insertions(+), 0 deletions(-) create mode 100644 Documentation/rtc-tz.txt diff --git a/Documentation/rtc-tz.txt b/Documentation/rtc-tz.txt new file mode 100644 index 000..7dfe523 --- /dev/null +++ b/Documentation/rtc-tz.txt @@ -0,0 +1,510 @@ + + ACPI TAD and EFI TIME Drivers for Timezone and Daylight + === + +In ACPI 5.0 ACPI TAD (Time and Alram Device) and EFI, they defined +Timezone and Daylight field in time struct: + +* ACPI TAD ... INT16 TimeZone +-1440 to 1440 or 2047 (unspecified) +Time zone field is the number of minutes that +the local time lags behind the UTC time. +Follow this equation: Localtime = UTC - TimeZone +UINT8 Daylight + Daylight is a bitmask containing the daylight + savings time information for the time: + Bit0: 1 = the time is affected by daylight savings time, + 0= time is not affected by daylight savings. + Bit1: 1= the time has been adjusted for daylight savings time, + 0= the time hasn't been adjusted for daylight savings. + +* EFI TIME ... INT16 TimeZone + -1440 to 1440 or 2047 (unspecified) + Time zone field is the number of minutes that + the local time lags behind the UTC time. + Follow this equation: Localtime = UTC - TimeZone +UINT8 Daylight + EFI_TIME_ADJUST_DAYLIGHT 0x01 + indicates if the time is affected by daylight + savings time or not. + EFI_TIME_IN_DAYLIGHT 0x02 + is set, the time has been adjusted for daylight + savings time. + +Then, the Timzone and daylight definition in GNU struct tm: + +* GNU struct tm ... long int __tm_gmtoff; /* Seconds east of UTC. */ + int tm_isdst; /* DST. [-1/0/1]*/ + +For Timzone, the definition match between ACPI TAD and EFI TIME. But it +different with GNU time struct. GNU's tm_gmtoff is "Seconds east of UTC". +Simply say, the timzone of ACPI/EFI and GNU are sign difference. + +Example 1: + 'Asia/Taipei'UTC +8 + GNU:tm_gmtoff = 28800 seconds. + Taiwan is east of UTC, so it's positive number. + ACPI or EFI:TimeZone = -480 hours + Timezone = UTC - Localtime = UTC - Taipei time + So, it's negative number. +Example 2: + 'Americ/Los_Angeles' UTC -8 + GNU:tm_gmtoff = -28800 seconds. + Los Angeles is west of UTC, so it's negative number. + ACPI or EFI:TimeZone = 480 hours + Timezone = UTC - Localtime = UTC - Taipei time + So, it's positive number. + +For Daylight, due to GNU's tm_isdst is only define: '1' means current +time is in daylight savings. '0' means not. '-1' means non-available. +So, 1b is the only value from ACPI/EFI will transfer to '1' in GNU. +When ACPI or EFI value is: + +* 11b: Time is affected by daylight and has been adjusted for daylight + tm->tm_isdst = 1 +* 01b: Time is affected by daylight but hasn't been adjusted for daylight + tm->tm_isdst = 0 +* 00b(or 10b): Time is affected by daylight + tm->tm_isdst = -1 + +The above data tranfer work of Timezone and Daylight will handled by RTC driver +to ACPI TAD and EFI TIME: rtc-acpitad and rtc-efi. + +SYSFS INTERFACE +--- + +The sysfs interface under /sys/class/rtc/rtcN provides access to various +rtc attributes without requiring the use of ioctls. Here only have one new +sysfs interface for grab the capabilities: + +caps: This interface will return a bitmap of capabilitites to the RTC + interface. Currently it indicates the RTC has capability for + handle Timezone or Daylight: + Bit0: Timezone. Set this bit means this interface has + capability to store Timezone + Bit1: Daylight: Set this bit means this interface has + capability to store Daylight savings time. + There already have the following definition in linux/rtc.h: + #defineRTC_TZ_CAP (1 << 0) + #defineRTC_DST_CAP (1 << 1) + +IOCTL
Re: [PATCH] clk: exynos: File scope reg_save array should depend on PM_SLEEP
Quoting Krzysztof Kozlowski (2013-12-17 01:56:39)
> Move reg_save[] into CONFIG_PM_SLEEP dependency block as it is used only
> by suspend and resume functions.
>
> This fixes the warning on CONFIG_PM_SLEEP=n:
> drivers/clk/samsung/clk-exynos-audss.c:29:22: warning: ‘reg_save’ defined but
> not used [-Wunused-variable]
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Mike Turquette
> ---
> drivers/clk/samsung/clk-exynos-audss.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c
> b/drivers/clk/samsung/clk-exynos-audss.c
> index 39b40aaede2b..68e515d093d8 100644
> --- a/drivers/clk/samsung/clk-exynos-audss.c
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -26,17 +26,17 @@ static struct clk_onecell_data clk_data;
> #define ASS_CLK_DIV 0x4
> #define ASS_CLK_GATE 0x8
>
> +/* list of all parent clock list */
> +static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
> +static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
> +
> +#ifdef CONFIG_PM_SLEEP
> static unsigned long reg_save[][2] = {
> {ASS_CLK_SRC, 0},
> {ASS_CLK_DIV, 0},
> {ASS_CLK_GATE, 0},
> };
>
> -/* list of all parent clock list */
> -static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
> -static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
> -
> -#ifdef CONFIG_PM_SLEEP
> static int exynos_audss_clk_suspend(void)
> {
> int i;
> --
> 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/
[TEST PATCH 14/14] acpi: add early parameter to set CMOS RTC Not Present bit for testing
This is a patch for testing that will not go to any git tree.
Add a early kernel parameter to set CMOS RTC Not Present bit in
acpi_gbl_FADT variable for testing. Use acpi_no_cmos_rtc=1 to enable
this bit to block rtc cmos interface.
Signed-off-by: Lee, Chun-Yi
---
arch/x86/kernel/acpi/boot.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 6c0b43b..64925dd 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -83,6 +83,8 @@ static u64 acpi_lapic_addr __initdata =
APIC_DEFAULT_PHYS_BASE;
#warning ACPI uses CMPXCHG, i486 and later hardware
#endif
+static bool acpi_no_cmos_rtc;
+
/* --
Boot-time Configuration
--
*/
@@ -1531,6 +1533,13 @@ int __init acpi_boot_init(void)
*/
acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
+ /* Dummy NO_CMOS_RTC enable option to fake out RTC CMOS */
+ if (acpi_no_cmos_rtc) {
+ acpi_gbl_FADT.header.revision = 5;
+ acpi_gbl_FADT.boot_flags |= ACPI_FADT_NO_CMOS_RTC;
+ pr_info("acpi: Set NO_CMOS_RTC bit in FADT for testing\n");
+ }
+
/*
* Process the Multiple APIC Description Table (MADT), if present
*/
@@ -1673,3 +1682,11 @@ void __init arch_reserve_mem_area(acpi_physical_address
addr, size_t size)
e820_add_region(addr, size, E820_ACPI);
update_e820();
}
+
+/* Dummy NO_CMOS_RTC enable option to fake out RTC CMOS */
+static int __init setup_acpi_no_cmos_rtc(char *arg)
+{
+ acpi_no_cmos_rtc = true;
+ return 0;
+}
+early_param("acpi_no_cmos_rtc", setup_acpi_no_cmos_rtc);
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 12/14] efi: adjust system time base on timezone from EFI time services
EFI time services provide the interface to store timezone to BIOS. The
timezone value from EFI indicates the offset of RTC time in minutes from
UTC.
The formula is: Localtime = UTC - TimeZone.
This patch add a efI_warp_clock() function to initial process for adjust
system time base on timezone value from EFI time services. It will also
set persistent_clock_is_local global variable to avoid user space
adjust timezone again.
This efi warp clock mechanism will triggered on x86_64 EFI machine when
timezone value is neither 0 nor 2047(UNSPECIFIED), kernel assume the
value of RTC is local time. On the other hand, system just follow
the old logic when timezone value from EFI is 0 or 2047, kernel assume
the value of RTC is UTC time.
About the 2047(EFI_UNSPECIFIED_TIMEZONE) value, it's the default value
of UEFI BIOS if there didn't have software set it through EFI interface.
We can _NOT_ follow EFI spec to interpret the RTC time as a local time
if timezone value is EFI_UNSPECIFIED_TIMEZONE, that's because Linux stored
UTC to BIOS on shipped UEFI machines.
Signed-off-by: Lee, Chun-Yi
---
arch/x86/platform/efi/efi.c | 37 +
include/linux/efi.h |2 ++
init/main.c |5 +
kernel/time.c |2 +-
4 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 42d6052..848160e 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -306,6 +306,43 @@ static void efi_get_time(struct timespec *now)
now->tv_nsec = 0;
}
+static int efi_read_timezone(s16 *timezone)
+{
+ efi_status_t status;
+ efi_time_t eft;
+ efi_time_cap_t cap;
+
+ status = efi.get_time(, );
+
+ if (status != EFI_SUCCESS) {
+ /* should never happen */
+ pr_err("efitime: can't read timezone.\n");
+ return -EINVAL;
+ }
+
+ *timezone = (s16)le16_to_cpu(eft.timezone);
+ return 0;
+}
+
+void __init efi_warp_clock(void)
+{
+ s16 timezone;
+
+ if (!efi_read_timezone()) {
+ /* TimeZone value, 2047 or 0 means UTC */
+ if (timezone != 0 && timezone != 2047) {
+ struct timespec adjust;
+
+ persistent_clock_is_local = 1;
+ adjust.tv_sec = timezone * 60;
+ adjust.tv_nsec = 0;
+ timekeeping_inject_offset();
+ pr_info("RTC timezone is %d mins behind of UTC.\n",
timezone);
+ pr_info("Adjusted system time to UTC.\n");
+ }
+ }
+}
+
/*
* Tell the kernel about the EFI memory map. This might include
* more than the max 128 entries that can fit in the e820 legacy
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 1c78ae7..a8d4f5c 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -715,10 +715,12 @@ extern void efi_memmap_walk (efi_freemem_callback_t
callback, void *arg);
extern void efi_gettimeofday (struct timespec *ts);
extern void efi_enter_virtual_mode (void); /* switch EFI to virtual mode,
if possible */
#ifdef CONFIG_X86
+extern void efi_warp_clock(void);
extern void efi_late_init(void);
extern void efi_free_boot_services(void);
extern efi_status_t efi_query_variable_store(u32 attributes, unsigned long
size);
#else
+static inline void efi_warp_clock(void) {}
static inline void efi_late_init(void) {}
static inline void efi_free_boot_services(void) {}
diff --git a/init/main.c b/init/main.c
index 61164ce..9effb1c 100644
--- a/init/main.c
+++ b/init/main.c
@@ -570,6 +570,11 @@ asmlinkage void __init start_kernel(void)
hrtimers_init();
softirq_init();
timekeeping_init();
+#ifdef CONFIG_X86_64
+ /* adjust system time by timezone */
+ if (efi_enabled(EFI_RUNTIME_SERVICES))
+ efi_warp_clock();
+#endif
time_init();
sched_clock_postinit();
perf_event_init();
diff --git a/kernel/time.c b/kernel/time.c
index 7c7964c..ce18bac 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -176,7 +176,7 @@ int do_sys_settimeofday(const struct timespec *tv, const
struct timezone *tz)
update_vsyscall_tz();
if (firsttime) {
firsttime = 0;
- if (!tv)
+ if (!tv && !persistent_clock_is_local)
warp_clock();
}
}
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: simple-card: Use devm_snd_soc_register_card()
Hi > Makes the code slightly shorter. > > Signed-off-by: Xiubo Li > --- Nice catch Acked-by: Kuninori Morimoto Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 09/14] efi: move functions of access efi time to header file for sharing
There have some functions, e.g. compute_yday, compute_wday, convert efi
time... are duplicated in efirtc, rtc-efi and will also used in rtc.c.
So this patch moved those functions of access efi time to efi.h header
file for sharing.
Signed-off-by: Lee, Chun-Yi
---
drivers/char/efirtc.c | 98
drivers/rtc/rtc-efi.c | 133 ++--
include/linux/efi.h | 134 +
3 files changed, 140 insertions(+), 225 deletions(-)
diff --git a/drivers/char/efirtc.c b/drivers/char/efirtc.c
index e39e740..8a30a02 100644
--- a/drivers/char/efirtc.c
+++ b/drivers/char/efirtc.c
@@ -41,109 +41,11 @@
#define EFI_RTC_VERSION"0.4"
-#define EFI_ISDST (EFI_TIME_ADJUST_DAYLIGHT|EFI_TIME_IN_DAYLIGHT)
-/*
- * EFI Epoch is 1/1/1998
- */
-#define EFI_RTC_EPOCH 1998
-
static DEFINE_SPINLOCK(efi_rtc_lock);
static long efi_rtc_ioctl(struct file *file, unsigned int cmd,
unsigned long arg);
-#define is_leap(year) \
- ((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0))
-
-static const unsigned short int __mon_yday[2][13] =
-{
- /* Normal years. */
- { 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 },
- /* Leap years. */
- { 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
-};
-
-/*
- * returns day of the year [0-365]
- */
-static inline int
-compute_yday(efi_time_t *eft)
-{
- /* efi_time_t.month is in the [1-12] so, we need -1 */
- return __mon_yday[is_leap(eft->year)][eft->month-1]+ eft->day -1;
-}
-/*
- * returns day of the week [0-6] 0=Sunday
- *
- * Don't try to provide a year that's before 1998, please !
- */
-static int
-compute_wday(efi_time_t *eft)
-{
- int y;
- int ndays = 0;
-
- if ( eft->year < 1998 ) {
- printk(KERN_ERR "efirtc: EFI year < 1998, invalid date\n");
- return -1;
- }
-
- for(y=EFI_RTC_EPOCH; y < eft->year; y++ ) {
- ndays += 365 + (is_leap(y) ? 1 : 0);
- }
- ndays += compute_yday(eft);
-
- /*
-* 4=1/1/1998 was a Thursday
-*/
- return (ndays + 4) % 7;
-}
-
-static void
-convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
-{
-
- eft->year = wtime->tm_year + 1900;
- eft->month = wtime->tm_mon + 1;
- eft->day= wtime->tm_mday;
- eft->hour = wtime->tm_hour;
- eft->minute = wtime->tm_min;
- eft->second = wtime->tm_sec;
- eft->nanosecond = 0;
- eft->daylight = wtime->tm_isdst ? EFI_ISDST: 0;
- eft->timezone = EFI_UNSPECIFIED_TIMEZONE;
-}
-
-static void
-convert_from_efi_time(efi_time_t *eft, struct rtc_time *wtime)
-{
- memset(wtime, 0, sizeof(*wtime));
- wtime->tm_sec = eft->second;
- wtime->tm_min = eft->minute;
- wtime->tm_hour = eft->hour;
- wtime->tm_mday = eft->day;
- wtime->tm_mon = eft->month - 1;
- wtime->tm_year = eft->year - 1900;
-
- /* day of the week [0-6], Sunday=0 */
- wtime->tm_wday = compute_wday(eft);
-
- /* day in the year [1-365]*/
- wtime->tm_yday = compute_yday(eft);
-
-
- switch (eft->daylight & EFI_ISDST) {
- case EFI_ISDST:
- wtime->tm_isdst = 1;
- break;
- case EFI_TIME_ADJUST_DAYLIGHT:
- wtime->tm_isdst = 0;
- break;
- default:
- wtime->tm_isdst = -1;
- }
-}
-
static long efi_rtc_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index 693ea47..4687022 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -22,95 +22,6 @@
#include
#include
-#define EFI_ISDST (EFI_TIME_ADJUST_DAYLIGHT|EFI_TIME_IN_DAYLIGHT)
-/*
- * EFI Epoch is 1/1/1998
- */
-#define EFI_RTC_EPOCH 1998
-
-/*
- * returns day of the year [0-365]
- */
-static inline int
-compute_yday(efi_time_t *eft)
-{
- /* efi_time_t.month is in the [1-12] so, we need -1 */
- return rtc_year_days(eft->day, eft->month - 1, eft->year);
-}
-/*
- * returns day of the week [0-6] 0=Sunday
- *
- * Don't try to provide a year that's before 1998, please !
- */
-static int
-compute_wday(efi_time_t *eft)
-{
- int y;
- int ndays = 0;
-
- if (eft->year < 1998) {
- pr_err("EFI year < 1998, invalid date\n");
- return -1;
- }
-
- for (y = EFI_RTC_EPOCH; y < eft->year; y++)
- ndays += 365 + (is_leap_year(y) ? 1 : 0);
-
- ndays += compute_yday(eft);
-
- /*
-* 4=1/1/1998 was a Thursday
-*/
- return (ndays + 4) % 7;
-}
-
-static void
-convert_to_efi_time(struct
[RFC PATCH 08/14] rtc-efi: set uie_unsupported for indicate rtc-efi doesn't support UIE mode
This patch set uie_unsupported flag when driver probed because current rtc-efi driver doesn't support UIE mode. Otherwise RTC_UIE_ON ioctl doesn't return EINVAL and it causes userspace think the RTC_UIE supported by rtc-efi. Set uie_unsupported then We can enable CONFIG_RTC_INTF_DEV_UIE_EMUL to emulate RTC_UIE on rtc-efi. Signed-off-by: Lee, Chun-Yi --- drivers/rtc/rtc-efi.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c index e0e3c7e..693ea47 100644 --- a/drivers/rtc/rtc-efi.c +++ b/drivers/rtc/rtc-efi.c @@ -293,6 +293,8 @@ static int efi_rtc_probe(struct platform_device *dev) rtc->caps = (RTC_TZ_CAP | RTC_DST_CAP); + rtc->uie_unsupported = 1; + platform_set_drvdata(dev, rtc); return 0; -- 1.6.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 11/14] rtc: switch to get/set rtc time to efi functions if CMOS RTC Not Present git set.
When CMOS RTC Not Present git set in FADT, system should not access CMOS
interface for time. This patch move get/set rtc time function from CMOS
to EFI runtime on x86_64 machine. And, it also set the BUG_ON check in
rtc_cmos_read/write function to avoid access it.
Signed-off-by: Lee, Chun-Yi
---
arch/x86/kernel/rtc.c |8
include/asm-generic/rtc.h | 22 ++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 9b6c568..a54cd09 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -117,6 +117,10 @@ unsigned char rtc_cmos_read(unsigned char addr)
{
unsigned char val;
+ BUG_ON(acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC &&
+ addr <= RTC_YEAR);
+
lock_cmos_prefix(addr);
outb(addr, RTC_PORT(0));
val = inb(RTC_PORT(1));
@@ -128,6 +132,10 @@ EXPORT_SYMBOL(rtc_cmos_read);
void rtc_cmos_write(unsigned char val, unsigned char addr)
{
+ BUG_ON(acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC &&
+ addr <= RTC_YEAR);
+
lock_cmos_prefix(addr);
outb(addr, RTC_PORT(0));
outb(val, RTC_PORT(1));
diff --git a/include/asm-generic/rtc.h b/include/asm-generic/rtc.h
index fa86f24..4ba8aa6 100644
--- a/include/asm-generic/rtc.h
+++ b/include/asm-generic/rtc.h
@@ -16,6 +16,8 @@
#include
#include
#include
+#include
+#include
#define RTC_PIE 0x40 /* periodic interrupt enable */
#define RTC_AIE 0x20 /* alarm interrupt enable */
@@ -51,6 +53,16 @@ static inline unsigned int __get_rtc_time(struct rtc_time
*time)
unsigned int real_year;
#endif
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+#if defined(CONFIG_EFI) && defined(CONFIG_X86_64)
+ printk_once(KERN_INFO "efi: get rtc time by EFI\n");
+ return efi_read_time(time);
+#else
+ BUG();
+#endif
+ }
+
/*
* read RTC once any update in progress is done. The update
* can take just over 2ms. We wait 20ms. There is no need to
@@ -123,6 +135,16 @@ static inline int __set_rtc_time(struct rtc_time *time)
unsigned int real_yrs, leap_yr;
#endif
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+#if defined(CONFIG_EFI) && defined(CONFIG_X86_64)
+ printk_once(KERN_INFO "efi: set rtc time by EFI\n");
+ return efi_set_time(time);
+#else
+ BUG();
+#endif
+ }
+
yrs = time->tm_year;
mon = time->tm_mon + 1; /* tm_mon starts at zero */
day = time->tm_mday;
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 07/14] rtc-efi: add GMTOFF support to rtc_efi
Per UEFI 2.3.1 spec, we can use SetTime() to store the timezone value to
BIOS and get it back by GetTime(). It's good for installation system to
gain the default timezone setting from BIOS that was set by
manufacturer.
This patch adds 2 new iotrl: RTC_RD_GMTOFF and RTC_SET_GMTOFF to rtc_efi
support get/set gmt offset that mapping to the GUN's tm_gmtoff extension
(Seconds east of UTC).
Due the timezone definition of UEFI is "Localtime = UTC - TimeZone",
rtc_efi driver will transfer the format between GNU and EFI.
The logic of timezone only affect on x86 architecture and keep the
original EFI_UNSPECIFIED_TIMEZONE value on IA64.
Signed-off-by: Lee, Chun-Yi
---
drivers/rtc/rtc-efi.c | 100 -
1 files changed, 99 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index c4c3843..e0e3c7e 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -75,7 +75,10 @@ convert_to_efi_time(struct rtc_time *wtime, efi_time_t *eft)
eft->second = wtime->tm_sec;
eft->nanosecond = 0;
eft->daylight = wtime->tm_isdst ? EFI_ISDST : 0;
+#ifdef CONFIG_IA64
+ /* avoid overwrite timezone on non-IA64 platform. e.g. x86_64 */
eft->timezone = EFI_UNSPECIFIED_TIMEZONE;
+#endif
}
static void
@@ -108,6 +111,84 @@ convert_from_efi_time(efi_time_t *eft, struct rtc_time
*wtime)
}
}
+static int efi_read_gmtoff(struct device *dev, long int *arg)
+{
+ efi_status_t status;
+ efi_time_t eft;
+ efi_time_cap_t cap;
+ s16 timezone;
+
+ status = efi.get_time(, );
+
+ if (status != EFI_SUCCESS) {
+ /* should never happen */
+ pr_err("efitime: can't read time\n");
+ return -EINVAL;
+ }
+
+ timezone = (s16)le16_to_cpu(eft.timezone);
+ *arg = EFI_UNSPECIFIED_TIMEZONE * 60;
+ if (abs(timezone) != EFI_UNSPECIFIED_TIMEZONE &&
+ abs(timezone) <= 1440)
+ *arg = timezone * 60 * -1;
+
+ return 0;
+}
+
+static int efi_set_gmtoff(struct device *dev, long int arg)
+{
+ efi_status_t status;
+ efi_time_t eft;
+ efi_time_cap_t cap;
+ s16 timezone;
+
+ /* transfer seconds east of UTC to minutes for ACPI */
+ timezone = arg / 60 * -1;
+ if (abs(timezone) > 1440 &&
+ abs(timezone) != EFI_UNSPECIFIED_TIMEZONE)
+ return -EINVAL;
+
+ /* can not use -2047 */
+ if (timezone == EFI_UNSPECIFIED_TIMEZONE * -1)
+ timezone = EFI_UNSPECIFIED_TIMEZONE;
+
+ status = efi.get_time(, );
+
+ if (status != EFI_SUCCESS) {
+ pr_err("efitime: can't read time\n");
+ return -EINVAL;
+ }
+
+ eft.timezone = (s16)cpu_to_le16(timezone);
+ status = efi.set_time();
+ if (status != EFI_SUCCESS) {
+ pr_err("efitime: can't set timezone\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int efi_rtc_ioctl(struct device *dev, unsigned int cmd, unsigned long
arg)
+{
+ long int gmtoff;
+ int err;
+
+ switch (cmd) {
+ case RTC_RD_GMTOFF:
+ err = efi_read_gmtoff(dev, );
+ if (err)
+ return err;
+ return put_user(gmtoff, (unsigned long __user *)arg);
+ case RTC_SET_GMTOFF:
+ return efi_set_gmtoff(dev, arg);
+ default:
+ return -ENOIOCTLCMD;
+ }
+
+ return 0;
+}
+
static int efi_read_alarm(struct device *dev, struct rtc_wkalrm *wkalrm)
{
efi_time_t eft;
@@ -172,6 +253,17 @@ static int efi_set_time(struct device *dev, struct
rtc_time *tm)
{
efi_status_t status;
efi_time_t eft;
+#ifdef CONFIG_X86
+ efi_time_cap_t cap;
+
+ /* read time for grab timezone to avoid overwrite it */
+ status = efi.get_time(, );
+
+ if (status != EFI_SUCCESS) {
+ pr_err("efitime: can't read time\n");
+ return -EINVAL;
+ }
+#endif
convert_to_efi_time(tm, );
@@ -181,13 +273,16 @@ static int efi_set_time(struct device *dev, struct
rtc_time *tm)
}
static const struct rtc_class_ops efi_rtc_ops = {
+#ifdef CONFIG_X86
+ .ioctl = efi_rtc_ioctl,
+#endif
.read_time = efi_read_time,
.set_time = efi_set_time,
.read_alarm = efi_read_alarm,
.set_alarm = efi_set_alarm,
};
-static int __init efi_rtc_probe(struct platform_device *dev)
+static int efi_rtc_probe(struct platform_device *dev)
{
struct rtc_device *rtc;
@@ -196,6 +291,8 @@ static int __init efi_rtc_probe(struct platform_device *dev)
if (IS_ERR(rtc))
return PTR_ERR(rtc);
+ rtc->caps = (RTC_TZ_CAP | RTC_DST_CAP);
+
platform_set_drvdata(dev, rtc);
return 0;
@@ -213,3 +310,4 @@ module_platform_driver_probe(efi_rtc_driver, efi_rtc_probe);
MODULE_AUTHOR("dann frazier ");
[RFC PATCH 10/14] rtc: improve and move week day computing function to rtc header
Due to rtc-acpid and efi time used the same logic for computing
week day, so this patch moves code to rtc.h header file.
Additionally using a leap year algorithm to replace the for-loop
block in compute_wday for improve the performance. The first
version of algorithm is from Oliver Neukum.
---
drivers/rtc/rtc-acpitad.c | 13 +
include/linux/efi.h | 13 +
include/linux/rtc.h | 38 ++
3 files changed, 40 insertions(+), 24 deletions(-)
diff --git a/drivers/rtc/rtc-acpitad.c b/drivers/rtc/rtc-acpitad.c
index 065a033..bdf7ae1 100644
--- a/drivers/rtc/rtc-acpitad.c
+++ b/drivers/rtc/rtc-acpitad.c
@@ -32,23 +32,12 @@ compute_yday(struct acpi_time *acpit)
static int
compute_wday(struct acpi_time *acpit)
{
- int y;
- int ndays = 0;
-
if (acpit->year < 1900) {
pr_err("ACPI year < 1900, invalid date\n");
return -1;
}
- for (y = 1900; y < acpit->year; y++)
- ndays += 365 + (is_leap_year(y) ? 1 : 0);
-
- ndays += compute_yday(acpit);
-
- /*
-* 1=1/1/1900 was a Monday
-*/
- return (ndays + 1) % 7;
+ return rtc_wday(acpit->day, acpit->month - 1, acpit->year);
}
static void
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 3859f3e..1c78ae7 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -177,23 +177,12 @@ compute_yday(efi_time_t *eft)
static inline int
compute_wday(efi_time_t *eft)
{
- int y;
- int ndays = 0;
-
if (eft->year < 1998) {
pr_err("EFI year < 1998, invalid date\n");
return -1;
}
- for (y = EFI_RTC_EPOCH; y < eft->year; y++)
- ndays += 365 + (is_leap_year(y) ? 1 : 0);
-
- ndays += compute_yday(eft);
-
- /*
-* 4=1/1/1998 was a Thursday
-*/
- return (ndays + 4) % 7;
+ return rtc_wday(eft->day, eft->month - 1, eft->year);
}
static inline void
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index e6380ec..511884f 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -196,6 +196,44 @@ static inline bool is_leap_year(unsigned int year)
return (!(year % 4) && (year % 100)) || !(year % 400);
}
+#define SINCE1900 25/* valid from 2000 */
+
+static inline int rtc_wday(unsigned int day, unsigned int month, unsigned int
year)
+{
+ int ndays, correction;
+ int base;
+
+ if (year < 1900) {
+ pr_err("rtc: year < 1900, invalid date\n");
+ return -1;
+ }
+
+ if (year >= 2000)
+ base = year - 2000;
+ else
+ base = year - 1900;
+
+ correction = 0;
+ if (base >= 0) {
+ correction += base / 4;
+ correction -= base / 100;
+ correction += base / 400;
+ if (year >= 2000)
+ correction += SINCE1900;
+
+ /* later rtc_year_days will add the leap day of current year */
+ correction -= ((is_leap_year(year)) ? 1 : 0);
+ }
+
+ ndays = (year - 1900) * 365 + correction;
+ ndays += rtc_year_days(day, month, year);
+
+ /*
+* 1=1/1/1900 was a Monday
+*/
+ return (ndays + 1) % 7;
+}
+
#ifdef CONFIG_RTC_HCTOSYS_DEVICE
extern int rtc_hctosys_ret;
#else
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 06/14] rtc-efi: register rtc-efi device when EFI enabled
UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are
also
supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86.
This patch changed RTC_DRV_EFI configuration to depend on EFI but not just
IA64. It
checks efi_enabled flag and efi-rtc driver should enabled.
Cc: Matt Fleming
Cc: H. Peter Anvin
Cc: Matthew Garrett
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Jan Beulich
Signed-off-by: Lee, Chun-Yi
---
arch/x86/platform/efi/efi.c | 17 +
drivers/rtc/Kconfig |2 +-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 7a7a692..42d6052 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -876,6 +877,22 @@ void __init efi_enter_virtual_mode(void)
0, NULL);
}
+static struct platform_device rtc_efi_dev = {
+ .name = "rtc-efi",
+ .id = -1,
+};
+
+static int __init rtc_init(void)
+{
+ if (efi_enabled(EFI_RUNTIME_SERVICES) &&
+ platform_device_register(_efi_dev) < 0)
+ pr_err("unable to register rtc-efi device...\n");
+
+ /* not necessarily an error */
+ return 0;
+}
+arch_initcall(rtc_init);
+
/*
* Convenience functions to obtain memory types and attributes
*/
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 349dbc4..bee13de 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -726,7 +726,7 @@ config RTC_DRV_DA9055
config RTC_DRV_EFI
tristate "EFI RTC"
- depends on IA64
+ depends on EFI
help
If you say yes here you will get support for the EFI
Real Time Clock.
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver
This patch add the driver of Time and Alarm Device in ACPI 5.0.
Currently it only implemented get/set time functions and grab
the capabilities of device when driver initial.
This driver also register rtc-acpitad platform device for RTC ACPITAD
stub driver using.
Signed-off-by: Lee, Chun-Yi
---
drivers/acpi/Makefile |3 +
drivers/acpi/acpi_tad.c | 176 +++
drivers/acpi/bus.c |3 +
drivers/acpi/internal.h |5 ++
include/linux/acpi.h| 31
5 files changed, 218 insertions(+), 0 deletions(-)
create mode 100644 drivers/acpi/acpi_tad.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..d250b15 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -50,6 +50,9 @@ acpi-$(CONFIG_ACPI_NUMA) += numa.o
ifdef CONFIG_ACPI_VIDEO
acpi-y += video_detect.o
endif
+ifdef CONFIG_X86
+acpi-y += acpi_tad.o
+endif
# These are (potentially) separate modules
diff --git a/drivers/acpi/acpi_tad.c b/drivers/acpi/acpi_tad.c
new file mode 100644
index 000..c2200f3
--- /dev/null
+++ b/drivers/acpi/acpi_tad.c
@@ -0,0 +1,176 @@
+/* rtc.c - ACPI 5.0 Time and Alarm Driver
+ *
+ * Copyright (C) 2013 SUSE Linux Products GmbH. All rights reserved.
+ * Written by Lee, Chun-Yi (j...@suse.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+#include
+#include
+#include
+
+#include
+
+#define ACPI_TIME_ALARM_NAME "Time and Alarm"
+ACPI_MODULE_NAME(ACPI_TIME_ALARM_NAME);
+#define ACPI_TIME_ALARM_CLASS "time_alarm"
+
+static const struct acpi_device_id time_alarm_ids[] = {
+ {"ACPI000E", 0},
+ {"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, time_alarm_ids);
+
+static struct platform_device rtc_acpitad_dev = {
+ .name = "rtc-acpitad",
+ .id = -1,
+};
+
+static struct acpi_device *acpi_tad_dev;
+static unsigned long long cap;
+
+int acpi_read_time(struct acpi_time *output)
+{
+ unsigned long flags;
+ struct acpi_buffer result = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_object *obj;
+ struct acpi_time *acpit;
+ acpi_status status;
+
+ if (!acpi_tad_dev)
+ return -ENODEV;
+
+ if (!(cap & TAD_CAP_GETSETTIME))
+ return -EINVAL;
+
+ if (!output)
+ return -EINVAL;
+
+ spin_lock_irqsave(_lock, flags);
+ status = acpi_evaluate_object(acpi_tad_dev->handle, "_GRT", NULL,
);
+ spin_unlock_irqrestore(_lock, flags);
+ if (ACPI_FAILURE(status)) {
+ ACPI_EXCEPTION((AE_INFO, status, "Evaluating _GRT"));
+ return -ENODEV;
+ }
+
+ obj = result.pointer;
+ if (!obj ||
+ obj->type != ACPI_TYPE_BUFFER ||
+ obj->buffer.length > sizeof(struct acpi_time) ||
+ obj->buffer.length < offsetof(struct acpi_time, pad2)) {
+ dev_err(_tad_dev->dev, ACPI_TIME_ALARM_NAME
+ " Invalid _GRT data\n");
+ return -EINVAL;
+ }
+
+ acpit = (struct acpi_time *) obj->buffer.pointer;
+ if (acpit) {
+ output->year = acpit->year;
+ output->month = acpit->month;
+ output->day = acpit->day;
+ output->hour = acpit->hour;
+ output->minute = acpit->minute;
+ output->second = acpit->second;
+ output->milliseconds = acpit->milliseconds;
+ output->timezone = acpit->timezone;
+ output->daylight = acpit->daylight;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(acpi_read_time);
+
+int acpi_set_time(struct acpi_time *acpit)
+{
+ unsigned long flags;
+ struct acpi_object_list input;
+ union acpi_object params[1];
+ unsigned long long output;
+ acpi_status status;
+
+ if (!acpi_tad_dev)
+ return -ENODEV;
+
+ if (!(cap & TAD_CAP_GETSETTIME))
+ return -EINVAL;
+
+ if (!acpit)
+ return -EINVAL;
+
+ input.count = 1;
+ input.pointer = params;
+ params[0].type = ACPI_TYPE_BUFFER;
+ params[0].buffer.length = sizeof(struct acpi_time);
+ params[0].buffer.pointer = (void *) acpit;
+
+ spin_lock_irqsave(_lock, flags);
+ status = acpi_evaluate_integer(acpi_tad_dev->handle, "_SRT", ,
);
+ spin_unlock_irqrestore(_lock, flags);
+ if (ACPI_FAILURE(status)) {
+ ACPI_EXCEPTION((AE_INFO, status, "Evaluating _SRT"));
+ return -ENODEV;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(acpi_set_time);
+
+int acpi_tad_get_capability(unsigned long *output)
+{
+ if (!acpi_tad_dev)
+ return -ENODEV;
+
+ *output = cap;
+
+ return
[PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present
We should not acess CMOS address when CMOS RTC Not Present bit set in
FADT. The ee5872be patch didn't avoid rtc-cmos driver loaded when system support
ACPI PNP PNP0B0* devices.
So this patch block the registion of rtc-cmos driver to avoid
user space access RTC through CMOS interface.
Signed-off-by: Lee, Chun-Yi
---
arch/x86/kernel/rtc.c | 20
drivers/rtc/rtc-cmos.c |9 +
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index ca9622a..9b6c568 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -174,16 +174,27 @@ static __init int add_rtc_cmos(void)
{ "PNP0b00", "PNP0b01", "PNP0b02", };
struct pnp_dev *dev;
struct pnp_id *id;
- int i;
+ int i = 0;
+ bool found_pnp;
pnp_for_each_dev(dev) {
for (id = dev->id; id; id = id->next) {
for (i = 0; i < ARRAY_SIZE(ids); i++) {
- if (compare_pnp_id(id, ids[i]) != 0)
- return 0;
+ if (compare_pnp_id(id, ids[i]) != 0) {
+ found_pnp = true;
+ goto found_pnp;
+ }
}
}
}
+
+found_pnp:
+ if (found_pnp) {
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
+ pr_err(FW_BUG "Found %s device but CMOS RTC Not Present
flag set\n", ids[i]);
+ return 0;
+ }
#endif
if (of_have_populated_dt())
return 0;
@@ -193,7 +204,8 @@ static __init int add_rtc_cmos(void)
return -ENODEV;
#ifdef CONFIG_ACPI
- if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
/* This warning can likely go away again in a year or two. */
pr_info("ACPI: not registering RTC platform device\n");
return -ENODEV;
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index f148762..3a84ca9 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -28,6 +28,9 @@
* interrupts disabled, holding the global rtc_lock, to exclude those
* other drivers and utilities on correctly configured systems.
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -1144,6 +1147,12 @@ static int __init cmos_init(void)
{
int retval = 0;
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+ pr_info("ACPI CMOS RTC Not Present detected - not loading\n");
+ return 0;
+ }
+
#ifdef CONFIG_PNP
retval = pnp_register_driver(_pnp_driver);
if (retval == 0)
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/14] rtc-efi: fix decrease day twice when computing year days
Compared with the logic in rtc_year_days of efirtc.c, the code in
rtc-efi decreases value of day twice when it computing year days.
That's becase rtc_year_days in rtc-lib.c already decrease day for
return the year days from 0 to 365.
---
drivers/rtc/rtc-efi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index 797aa02..c4c3843 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -35,7 +35,7 @@ static inline int
compute_yday(efi_time_t *eft)
{
/* efi_time_t.month is in the [1-12] so, we need -1 */
- return rtc_year_days(eft->day - 1, eft->month - 1, eft->year);
+ return rtc_year_days(eft->day, eft->month - 1, eft->year);
}
/*
* returns day of the week [0-6] 0=Sunday
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 05/14] rtc: Add RTC driver of ACPI Time and Alarm Device
This patch add the RTC driver of ACPI TAD to provide userspace access
ACPI time through RTC interface.
Signed-off-by: Lee, Chun-Yi
---
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile |1 +
drivers/rtc/rtc-acpitad.c | 294 +
drivers/rtc/rtc-dev.c |4 +
drivers/rtc/rtc-sysfs.c |8 ++
include/linux/rtc.h |5 +
include/uapi/linux/rtc.h |5 +
7 files changed, 327 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/rtc-acpitad.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 0077302..349dbc4 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -878,6 +878,16 @@ config RTC_DRV_NUC900
If you say yes here you get support for the RTC subsystem of the
NUC910/NUC920 used in embedded systems.
+config RTC_ACPI_TAD
+ tristate "RTC ACPI Time and Alarm Device driver"
+ help
+ This driver exposes ACPI 5.0 Time and Alarm Device as RTC device.
+ Say Y (or M) if you have a computer with ACPI 5.0 firmware that
+ implemented Time and Alarm Device.
+
+ To compile this driver as a module, choose M here:
+ the module will be called rtc_acpitad.
+
comment "on-CPU RTC drivers"
config RTC_DRV_DAVINCI
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 27b4bd8..bca5ab3 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_RTC_DRV_88PM860X) += rtc-88pm860x.o
obj-$(CONFIG_RTC_DRV_88PM80X) += rtc-88pm80x.o
obj-$(CONFIG_RTC_DRV_AB3100) += rtc-ab3100.o
obj-$(CONFIG_RTC_DRV_AB8500) += rtc-ab8500.o
+obj-$(CONFIG_RTC_ACPI_TAD) += rtc-acpitad.o
obj-$(CONFIG_RTC_DRV_AS3722) += rtc-as3722.o
obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
diff --git a/drivers/rtc/rtc-acpitad.c b/drivers/rtc/rtc-acpitad.c
new file mode 100644
index 000..065a033
--- /dev/null
+++ b/drivers/rtc/rtc-acpitad.c
@@ -0,0 +1,294 @@
+/* A RTC driver for ACPI 5.0 Time and Alarm Device
+ *
+ * Copyright (C) 2013 SUSE Linux Products GmbH. All rights reserved.
+ * Written by Lee, Chun-Yi (j...@suse.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+
+/*
+ * returns day of the year [0-365]
+ */
+static inline int
+compute_yday(struct acpi_time *acpit)
+{
+ /* acpi_time.month is in the [1-12] so, we need -1 */
+ return rtc_year_days(acpit->day, acpit->month - 1, acpit->year);
+}
+
+/*
+ * returns day of the week [0-6] 0=Sunday
+ */
+static int
+compute_wday(struct acpi_time *acpit)
+{
+ int y;
+ int ndays = 0;
+
+ if (acpit->year < 1900) {
+ pr_err("ACPI year < 1900, invalid date\n");
+ return -1;
+ }
+
+ for (y = 1900; y < acpit->year; y++)
+ ndays += 365 + (is_leap_year(y) ? 1 : 0);
+
+ ndays += compute_yday(acpit);
+
+ /*
+* 1=1/1/1900 was a Monday
+*/
+ return (ndays + 1) % 7;
+}
+
+static void
+convert_to_acpi_time(struct rtc_time *tm, struct acpi_time *acpit)
+{
+ acpit->year = tm->tm_year + 1900;
+ acpit->month= tm->tm_mon + 1;
+ acpit->day = tm->tm_mday;
+ acpit->hour = tm->tm_hour;
+ acpit->minute = tm->tm_min;
+ acpit->second = tm->tm_sec;
+ acpit->milliseconds = 0;
+ acpit->daylight = tm->tm_isdst ? ACPI_ISDST : 0;
+}
+
+static void
+convert_from_acpi_time(struct acpi_time *acpit, struct rtc_time *tm)
+{
+ memset(tm, 0, sizeof(*tm));
+ tm->tm_sec = acpit->second;
+ tm->tm_min = acpit->minute;
+ tm->tm_hour = acpit->hour;
+ tm->tm_mday = acpit->day;
+ tm->tm_mon = acpit->month - 1;
+ tm->tm_year = acpit->year - 1900;
+
+ /* day of the week [0-6], Sunday=0 */
+ tm->tm_wday = compute_wday(acpit);
+
+ /* day in the year [1-365]*/
+ tm->tm_yday = compute_yday(acpit);
+
+ switch (acpit->daylight & ACPI_ISDST) {
+ case ACPI_ISDST:
+ tm->tm_isdst = 1;
+ break;
+ case ACPI_TIME_AFFECTED_BY_DAYLIGHT:
+ tm->tm_isdst = 0;
+ break;
+ default:
+ tm->tm_isdst = -1;
+ }
+}
+
+static int acpitad_read_gmtoff(struct device *dev, long int *arg)
+{
+ struct acpi_time *acpit;
+ s16 timezone;
+ int ret;
+
+ acpit = kzalloc(sizeof(struct acpi_time), GFP_KERNEL);
+ if (!acpit)
+ return -ENOMEM;
+
+ ret = acpi_read_time(acpit);
+ if (ret)
+ goto error_read;
+
+ /* transfer minutes to
Re: [PATCH v0 04/71] itrace: Infrastructure for instruction flow tracing units
Peter Zijlstra writes: > On Wed, Dec 18, 2013 at 04:22:36PM +0200, Alexander Shishkin wrote: >> > Still confused, if you cannot copy it into one buffer, then why can you >> > copy it into a second buffer? >> >> It's not copied, hardware writes directly into that second buffer. > > Where's the PT documentation? I can't find it in the SDM and your ISA > extensions link is a generic Intel website which is friggin useless > (like all corporate websites strive to be). [1] > Your actual PT patch doesn't describe how the things works either, and > while I could go read the code, I'm too lazy. > > The thing is; why can't you zero-copy whatever buffer the hardware > writes into, into the normal buffer? I'm not sure I understand. You mean, have the buffer split between perf data and trace data? > Machinery like that would also be useful to zero-copy bits out of the > buffer right into the page-cache. Please elaborate. >> I've done the same with BTS now (as Ingo suggested) and it also benefits >> from this approach. > > The problem with DS is that it needs physically contiguous pages is it > not? So you cannot really allocate a large buffer, and you end up > needing to copy or swizzle stuff. Yes and some implementations of PT have the same issue, but you can do a sufficiently large high order allocation and map it to userspace and still no copying (or parsing/decoding) in kernel space required. [1] http://download-software.intel.com/sites/default/files/managed/71/2e/319433-017.pdf Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME
This patchset add the timezone support of ACPI TAD and EFI TIME, it also add codes for adjusting system time base on the timezone value from EFI TIME services when system boot. Those patches bring the following changes: + Add ACPI driver against ACPI000E ACPI Time and Alarm Device. + Add RTC driver of ACPI TAD. + Add rtc ioctl functions, RTC_RD_GMTOFF and RTC_SET_GMTOFF, provide interface to user space for maintain timezone value in BIOS. The GMTOFF names of ioctl functions match with the tm_gmtoff field in rtc_time and tm structure in GNU C library. + Add rtc ioctl function, RTC_CAPS_READ, provide to user space for grab the capabilities value to timezone and daylight of interface. + Moved duplicate functions to efi.h header for convert EFI Time. + When "CMOS RTC not Present" flag set in FADT, block CMOS RTC interface and switch to EFI time services. + Adjusting system time base on timezone from EFI time when system boot. + Add rtc-tz.txt document. Please set CONFIG_RTC_DRV_EFI=m and CONFIG_RTC_ACPI_TAD=m to build RTC ACPI TAD and EFI TIME drivers.For testing, please use "acpi_no_cmos_rtc=1" to set CMOST RTC not Present flag in FADT to trigger the mechanism for adjust system time and block CMOS interface. About the definition of timezone and the format transformation between ACPI, EFI and tm_gmtoff of GNU. Please check the rtc-tz.txt document in patch. Jan Beulich (1): x86-64/efi: Use EFI to deal with platform wall clock (again) Lee, Chun-Yi (13): rtc-efi: fix decrease day twice when computing year days rtc: block registration of rtc-cmos when CMOS RTC Not Present ACPI: Add ACPI 5.0 Time and Alarm Device driver rtc: Add RTC driver of ACPI Time and Alarm Device rtc-efi: register rtc-efi device when EFI enabled rtc-efi: add GMTOFF support to rtc_efi rtc-efi: set uie_unsupported for indicate rtc-efi doesn't support UIE efi: move functions of access efi time to header file for sharing rtc: improve and move week day computing function to rtc header rtc: switch to get/set rtc time to efi functions if CMOS RTC Not efi: adjust system time base on timezone from EFI time services Documentation/RTC: add document of ACPI TAD and EFI TIME driver acpi: add early parameter to set CMOS RTC Not Present bit for testing Documentation/rtc-tz.txt| 510 +++ arch/x86/kernel/acpi/boot.c | 17 ++ arch/x86/kernel/rtc.c | 28 ++- arch/x86/mm/pageattr.c | 10 +- arch/x86/platform/efi/efi.c | 89 ++-- drivers/acpi/Makefile |3 + drivers/acpi/acpi_tad.c | 176 +++ drivers/acpi/bus.c |3 + drivers/acpi/internal.h |5 + drivers/char/efirtc.c | 98 - drivers/rtc/Kconfig | 12 +- drivers/rtc/Makefile|1 + drivers/rtc/rtc-acpitad.c | 283 drivers/rtc/rtc-cmos.c |9 + drivers/rtc/rtc-dev.c |4 + drivers/rtc/rtc-efi.c | 177 +++- drivers/rtc/rtc-sysfs.c |8 + include/asm-generic/rtc.h | 22 ++ include/linux/acpi.h| 31 +++ include/linux/efi.h | 127 +++- include/linux/rtc.h | 43 include/uapi/linux/rtc.h|5 + init/main.c | 13 +- kernel/time.c |2 +- 24 files changed, 1439 insertions(+), 237 deletions(-) create mode 100644 Documentation/rtc-tz.txt create mode 100644 drivers/acpi/acpi_tad.c create mode 100644 drivers/rtc/rtc-acpitad.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
Hi Dan,
Am 18.12.2013 um 18:49 schrieb Dan Williams:
> On Wed, 2013-12-18 at 14:16 +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi Dan,
>>
>> Am 17.12.2013 um 23:27 schrieb Dan Williams:
>>
>>> On Tue, 2013-12-17 at 20:56 +0100, Dr. H. Nikolaus Schaller wrote:
Hi Dan,
Am 16.12.2013 um 20:40 schrieb Dan Williams:
> On Fri, 2013-12-13 at 15:43 +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi,
>>
>> Am 02.10.2013 um 09:00 schrieb Dr. H. Nikolaus Schaller:
>>
>>> Hi Jan,
>>>
>>> we are using a GTM601 modem (Firmware 1.7) for a while and have spotted
>>> an
>>> issue that under some conditions the modem sends a packed wIndex over
>>> USB
>>> that is rejected by the hso driver making troubles afterwards. Not
>>> rejecting makes
>>> it work fine.
>>>
>>> BR,
>>> Nikolaus Schaller
>>>
>>> ---
>>>
>>> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
>>> From: "H. Nikolaus Schaller"
>>> Date: Thu, 15 Nov 2012 14:40:57 +0100
>>> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by
>>> OPTION
>>> GTM601 during RING indication
>>>
>>> It has been observed that the GTM601 with 1.7 firmware sometimes sends
>>> a value
>>> wIndex that has bit 0x04 set instead of being reset as the code
>>> expects. So we
>>> mask it for the error check.
>>>
>>> See
>>> http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
>>>
>>> Signed-off-by: NeilBrown
>>> Signed-off-by: H. Nikolaus Schaller
>>> ---
>>> drivers/net/usb/hso.c |3 ++-
>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
>>> index cba1d46..d146e26 100644
>>> --- a/drivers/net/usb/hso.c
>>> +++ b/drivers/net/usb/hso.c
>>> @@ -1503,7 +1503,8 @@ static void tiocmget_intr_callback(struct urb
>>> *urb)
>>> if (serial_state_notification->bmRequestType != BM_REQUEST_TYPE
>>> ||
>>> serial_state_notification->bNotification != B_NOTIFICATION
>>> ||
>>> le16_to_cpu(serial_state_notification->wValue) != W_VALUE ||
>>> - le16_to_cpu(serial_state_notification->wIndex) != W_INDEX ||
>>> + (le16_to_cpu(serial_state_notification->wIndex) & ~0x4) !=
>>> + W_INDEX ||
>>> le16_to_cpu(serial_state_notification->wLength) !=
>>> W_LENGTH) {
>>> dev_warn(>dev,
>>> "hso received invalid serial state
>>> notification\n");
>>> --
>>> 1.7.7.4
>>>
>>>
>>
>> I have found this (better) proposal by OPTION, but wonder what did
>> happen to it.
>> It neither shows in mainline 3.13-rc nor linux-next:
>>
>> https://lkml.org/lkml/2013/10/9/263
>
> Likely because nobody formally submitted the patch with a signed-off-by,
> which indicates their intent that the patch is tested, correct, and can
> be merged to the kernel.
Ok, I see. I just wasn't aware of the proposal at all since I missed the
discussion
and wasn't on CC.
Therefore I have added Eric to the CC.
>
> I looked at this today, and I'm left wondering how any port other than
> HSO_PORT_MODEM can get the notification via tiocmget_intr_callback().
> "serial->tiocmget" is only created for HSO_PORT_MODEM serial ports (see
> hso_create_bulk_serial_device()):
>
> if ((port & HSO_PORT_MASK) == HSO_PORT_MODEM) {
> num_urbs = 2;
> serial->tiocmget = kzalloc(sizeof(struct hso_tiocmget),
> GFP_KERNEL);
>
> and the code in tiocmget_intr_callback() does this:
>
> tiocmget = serial->tiocmget;
> if (!tiocmget)
> return;
>
> which should mean that only a HSO_PORT_MODEM will ever process the
> notification. Further, the tiocmget interrupt URB is only created and
> submitted if serial->tiocmget != NULL, so only HSO_PORT_MODEM should
> ever be calling into tiocmget_intr_callback().
Ok, that looks plausible.
>
> So I think Eric's patch is actually wrong because it will *always* pass
> the new check.
>
> The original code had the correct intention, but the original code was
> obviously wrong for newer devices where the port layout is read from
> firmware and not from static tables, and thus for recent devices where
> the modem interface is not USB interface #2.
This explains why we did run into the problem with the GTM601.
>
> Can you confirm/deny that the 'modem' interface for your GTM601 is USB
> interface #6? For example, my Icon 452 has the following USB interface
> layout:
>
> 0: Diag
[PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present
We should not acess CMOS address when CMOS RTC Not Present bit set in
FADT. The ee5872be patch didn't avoid rtc-cmos driver loaded when system support
ACPI PNP PNP0B0* devices.
So this patch block the registion of rtc-cmos driver to avoid
user space access RTC through CMOS interface.
Signed-off-by: Lee, Chun-Yi
---
arch/x86/kernel/rtc.c | 20
drivers/rtc/rtc-cmos.c |9 +
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index ca9622a..9b6c568 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -174,16 +174,27 @@ static __init int add_rtc_cmos(void)
{ "PNP0b00", "PNP0b01", "PNP0b02", };
struct pnp_dev *dev;
struct pnp_id *id;
- int i;
+ int i = 0;
+ bool found_pnp;
pnp_for_each_dev(dev) {
for (id = dev->id; id; id = id->next) {
for (i = 0; i < ARRAY_SIZE(ids); i++) {
- if (compare_pnp_id(id, ids[i]) != 0)
- return 0;
+ if (compare_pnp_id(id, ids[i]) != 0) {
+ found_pnp = true;
+ goto found_pnp;
+ }
}
}
}
+
+found_pnp:
+ if (found_pnp) {
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
+ pr_err(FW_BUG "Found %s device but CMOS RTC Not Present
flag set\n", ids[i]);
+ return 0;
+ }
#endif
if (of_have_populated_dt())
return 0;
@@ -193,7 +204,8 @@ static __init int add_rtc_cmos(void)
return -ENODEV;
#ifdef CONFIG_ACPI
- if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
/* This warning can likely go away again in a year or two. */
pr_info("ACPI: not registering RTC platform device\n");
return -ENODEV;
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index f148762..3a84ca9 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -28,6 +28,9 @@
* interrupts disabled, holding the global rtc_lock, to exclude those
* other drivers and utilities on correctly configured systems.
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -1144,6 +1147,12 @@ static int __init cmos_init(void)
{
int retval = 0;
+ if (acpi_gbl_FADT.header.revision >= 5 &&
+ acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) {
+ pr_info("ACPI CMOS RTC Not Present detected - not loading\n");
+ return 0;
+ }
+
#ifdef CONFIG_PNP
retval = pnp_register_driver(_pnp_driver);
if (retval == 0)
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 00/14] Support timezone of ACPI TAD and EFI TIME
This patchset add the timezone support of ACPI TAD and EFI TIME, it also add codes for adjusting system time base on the timezone value from EFI TIME services when system boot. Those patches bring the following changes: + Add ACPI driver against ACPI000E ACPI Time and Alarm Device. + Add RTC driver of ACPI TAD. + Add rtc ioctl functions, RTC_RD_GMTOFF and RTC_SET_GMTOFF, provide interface to user space for maintain timezone value in BIOS. The GMTOFF names of ioctl functions match with the tm_gmtoff field in rtc_time and tm structure in GNU C library. + Add rtc ioctl function, RTC_CAPS_READ, provide to user space for grab the capabilities value to timezone and daylight of interface. + Moved duplicate functions to efi.h header for convert EFI Time. + When "CMOS RTC not Present" flag set in FADT, block CMOS RTC interface and switch to EFI time services. + Adjusting system time base on timezone from EFI time when system boot. + Add rtc-tz.txt document. Please set CONFIG_RTC_DRV_EFI=m and CONFIG_RTC_ACPI_TAD=m to build RTC ACPI TAD and EFI TIME drivers.For testing, please use "acpi_no_cmos_rtc=1" to set CMOST RTC not Present flag in FADT to trigger the mechanism for adjust system time and block CMOS interface. About the definition of timezone and the format transformation between ACPI, EFI and tm_gmtoff of GNU. Please check the rtc-tz.txt document in patch. Jan Beulich (1): x86-64/efi: Use EFI to deal with platform wall clock (again) Lee, Chun-Yi (13): rtc-efi: fix decrease day twice when computing year days rtc: block registration of rtc-cmos when CMOS RTC Not Present ACPI: Add ACPI 5.0 Time and Alarm Device driver rtc: Add RTC driver of ACPI Time and Alarm Device rtc-efi: register rtc-efi device when EFI enabled rtc-efi: add GMTOFF support to rtc_efi rtc-efi: set uie_unsupported for indicate rtc-efi doesn't support UIE efi: move functions of access efi time to header file for sharing rtc: improve and move week day computing function to rtc header rtc: switch to get/set rtc time to efi functions if CMOS RTC Not efi: adjust system time base on timezone from EFI time services Documentation/RTC: add document of ACPI TAD and EFI TIME driver acpi: add early parameter to set CMOS RTC Not Present bit for testing Documentation/rtc-tz.txt| 510 +++ arch/x86/kernel/acpi/boot.c | 17 ++ arch/x86/kernel/rtc.c | 28 ++- arch/x86/mm/pageattr.c | 10 +- arch/x86/platform/efi/efi.c | 89 ++-- drivers/acpi/Makefile |3 + drivers/acpi/acpi_tad.c | 176 +++ drivers/acpi/bus.c |3 + drivers/acpi/internal.h |5 + drivers/char/efirtc.c | 98 - drivers/rtc/Kconfig | 12 +- drivers/rtc/Makefile|1 + drivers/rtc/rtc-acpitad.c | 283 drivers/rtc/rtc-cmos.c |9 + drivers/rtc/rtc-dev.c |4 + drivers/rtc/rtc-efi.c | 177 +++- drivers/rtc/rtc-sysfs.c |8 + include/asm-generic/rtc.h | 22 ++ include/linux/acpi.h| 31 +++ include/linux/efi.h | 127 +++- include/linux/rtc.h | 43 include/uapi/linux/rtc.h|5 + init/main.c | 13 +- kernel/time.c |2 +- 24 files changed, 1439 insertions(+), 237 deletions(-) create mode 100644 Documentation/rtc-tz.txt create mode 100644 drivers/acpi/acpi_tad.c create mode 100644 drivers/rtc/rtc-acpitad.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/14] rtc-efi: fix decrease day twice when computing year days
Compared with the logic in rtc_year_days of efirtc.c, the code in
rtc-efi decreases value of day twice when it computing year days.
That's becase rtc_year_days in rtc-lib.c already decrease day for
return the year days from 0 to 365.
---
drivers/rtc/rtc-efi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-efi.c b/drivers/rtc/rtc-efi.c
index 797aa02..c4c3843 100644
--- a/drivers/rtc/rtc-efi.c
+++ b/drivers/rtc/rtc-efi.c
@@ -35,7 +35,7 @@ static inline int
compute_yday(efi_time_t *eft)
{
/* efi_time_t.month is in the [1-12] so, we need -1 */
- return rtc_year_days(eft->day - 1, eft->month - 1, eft->year);
+ return rtc_year_days(eft->day, eft->month - 1, eft->year);
}
/*
* returns day of the week [0-6] 0=Sunday
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] mm: add overcommit_kbytes sysctl variable
Hi,
On Tue, Dec 3, 2013 at 5:33 AM, Jerome Marchand wrote:
[...]
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 34a6047..7877929 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -97,6 +97,7 @@
> /* External variables not in a header file. */
> extern int sysctl_overcommit_memory;
> extern int sysctl_overcommit_ratio;
> +extern unsigned long sysctl_overcommit_kbytes;
> extern int max_threads;
> extern int suid_dumpable;
> #ifdef CONFIG_COREDUMP
> @@ -1128,7 +1129,14 @@ static struct ctl_table vm_table[] = {
> .data = _overcommit_ratio,
> .maxlen = sizeof(sysctl_overcommit_ratio),
> .mode = 0644,
> - .proc_handler = proc_dointvec,
> + .proc_handler = overcommit_ratio_handler,
> + },
> + {
> + .procname = "overcommit_kbytes",
> + .data = _overcommit_kbytes,
> + .maxlen = sizeof(sysctl_overcommit_kbytes),
> + .mode = 0644,
> + .proc_handler = overcommit_kbytes_handler,
> },
> {
> .procname = "page-cluster",
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 834b2d7..b25167d 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -86,6 +86,7 @@ EXPORT_SYMBOL(vm_get_page_prot);
>
> int sysctl_overcommit_memory __read_mostly = OVERCOMMIT_GUESS; /* heuristic
> overcommit */
> int sysctl_overcommit_ratio __read_mostly = 50;/* default is 50% */
> +unsigned long sysctl_overcommit_kbytes __read_mostly = 0;
> int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
> unsigned long sysctl_user_reserve_kbytes __read_mostly = 1UL << 17; /* 128MB
> */
> unsigned long sysctl_admin_reserve_kbytes __read_mostly = 1UL << 13; /* 8MB
> */
> @@ -95,6 +96,30 @@ unsigned long sysctl_admin_reserve_kbytes __read_mostly =
> 1UL << 13; /* 8MB */
> */
> struct percpu_counter vm_committed_as cacheline_aligned_in_smp;
>
> +int overcommit_ratio_handler(struct ctl_table *table, int write,
> +void __user *buffer, size_t *lenp,
> +loff_t *ppos)
> +{
> + int ret;
> +
> + ret = proc_dointvec(table, write, buffer, lenp, ppos);
> + if (ret == 0 && write)
> + sysctl_overcommit_kbytes = 0;
> + return ret;
> +}
> +
> +int overcommit_kbytes_handler(struct ctl_table *table, int write,
> +void __user *buffer, size_t *lenp,
> +loff_t *ppos)
> +{
> + int ret;
> +
> + ret = proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
> + if (ret == 0 && write)
> + sysctl_overcommit_ratio = 0;
> + return ret;
> +}
> +
> /*
> * The global memory commitment made in the system can be a metric
> * that can be used to drive ballooning decisions when Linux is hosted
> diff --git a/mm/nommu.c b/mm/nommu.c
> index fec093a..319ab8f 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -60,6 +60,7 @@ unsigned long highest_memmap_pfn;
> struct percpu_counter vm_committed_as;
> int sysctl_overcommit_memory = OVERCOMMIT_GUESS; /* heuristic overcommit */
> int sysctl_overcommit_ratio = 50; /* default is 50% */
> +unsigned long sysctl_overcommit_kbytes __read_mostly = 0;
> int sysctl_max_map_count = DEFAULT_MAX_MAP_COUNT;
> int sysctl_nr_trim_pages = CONFIG_NOMMU_INITIAL_TRIM_EXCESS;
> unsigned long sysctl_user_reserve_kbytes __read_mostly = 1UL << 17; /* 128MB
> */
You add the variable on the nommu side, but not the functions to
handle the sysctl. So things fail to compile on !MMU builds with:
kernel/built-in.o:(.data+0x4e0): undefined reference to
`overcommit_ratio_handler'
kernel/built-in.o:(.data+0x504): undefined reference to
`overcommit_kbytes_handler'
I don't know mm well enough to tell if copying and pasting the code
over verbatim is the right thing to do, or if there's a preferred
other location (that is shared) to move it to?
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ipvs: Remove unused variable ret from sync_thread_master()
Hello,
On Wed, 13 Nov 2013, Julian Anastasov wrote:
> On Tue, 12 Nov 2013, Geert Uytterhoeven wrote:
>
> > net/netfilter/ipvs/ip_vs_sync.c: In function 'sync_thread_master':
> > net/netfilter/ipvs/ip_vs_sync.c:1640:8: warning: unused variable 'ret'
> > [-Wunused-variable]
> >
> > Commit 35a2af94c7ce7130ca292c68b1d27fcfdb648f6b ("sched/wait: Make the
> > __wait_event*() interface more friendly") changed how the interruption
> > state is returned. However, sync_thread_master() ignores this state,
> > now causing a compile warning.
> >
> > According to Julian Anastasov , this behavior is OK:
> >
> > "Yes, your patch looks ok to me. In the past we used ssleep() but IPVS
> > users were confused why IPVS threads increase the load average. So, we
> > switched to _interruptible calls and later the socket polling was
> > added."
> >
> > Document this, as requested by Peter Zijlstra, to avoid precious developers
> > disappearing in this pitfall in the future.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > v2: Document that sync_thread_master() ignores the interruption state,
> >
> > net/netfilter/ipvs/ip_vs_sync.c |5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_sync.c
> > b/net/netfilter/ipvs/ip_vs_sync.c
> > index f63c2388f38d..db801263ee9f 100644
> > --- a/net/netfilter/ipvs/ip_vs_sync.c
> > +++ b/net/netfilter/ipvs/ip_vs_sync.c
> > @@ -1637,7 +1637,10 @@ static int sync_thread_master(void *data)
> > continue;
> > }
> > while (ip_vs_send_sync_msg(tinfo->sock, sb->mesg) < 0) {
> > - int ret = __wait_event_interruptible(*sk_sleep(sk),
> > + /* (Ab)use interruptible sleep to avoid increasing
> > +* the load avg.
> > +*/
> > + __wait_event_interruptible(*sk_sleep(sk),
> >sock_writeable(sk) ||
> >kthread_should_stop());
> > if (unlikely(kthread_should_stop()))
>
> Fabio Estevam posted similar change too early but
> we are better with such comment.
>
> Acked-by: Julian Anastasov
>
> Also, the TASK_UNINTERRUPTIBLE | TASK_IDLE idea looks good
> to me. If such change is planned may be the above patch
> better not to go via the ipvs-next tree to avoid conflicts?
> As we don't have any changes in this area let us know if
> someone takes the above patch for another tree.
Simon, lets apply this patch to ipvs-next tree...
Regards
--
Julian Anastasov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/17] tracing/probes: Move 'symbol' fetch method to kprobes
Hi Steve, On Wed, 18 Dec 2013 15:23:38 -0500, Steven Rostedt wrote: > On Mon, 16 Dec 2013 13:32:09 +0900 > Namhyung Kim wrote: > >> index 5395d37e5e72..adc9ac70fd3c 100644 >> --- a/kernel/trace/trace_uprobe.c >> +++ b/kernel/trace/trace_uprobe.c >> @@ -115,6 +115,14 @@ DEFINE_BASIC_FETCH_FUNCS(stack) >> #define fetch_stack_string_size NULL >> >> >> +/* uprobes don't support symbol fetch methods */ > > "uprobes does not support symbol fetch methods" I was confused since the "uprobes" looks like a plural.. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/2] ARM: tegra: add ams AS3722 device to Venice2 DT
On Thursday 19 December 2013 02:25 AM, Stephen Warren wrote: On 12/18/2013 05:52 AM, Laxman Dewangan wrote: Add ams AS3722 entry for gpio/pincontrol and regulators to venice2 DT. This patch still causes: [0.726545] as3722-pinctrl as3722-pinctrl: pin gpio0 already requested by as3722-pinctrl; cannot claim for as3722-regulator [0.737681] as3722-pinctrl as3722-pinctrl: pin-0 (as3722-regulator) status -22 [0.744895] as3722-pinctrl as3722-pinctrl: could not request pin 0 (gpio0) from group gpio0 on device as3722-pinctrl [0.755500] as3722-regulator as3722-regulator: Error applying setting, reverse things back This error is nothing related to the ams dt or driver. This came from the framework from the driver/base for adding pinmux call before calling any diver's probe. Here is my finding: Frameworks calls the pinctrl_bind_pins() before calls the driver's probe (drivers/base/dd.c) and pinctrl_bind_pins() calls the pinmux mapping and try to set the default (drvers/base/pinctrl.c). AMS AS3722 DT is flat type on which all sub devices of AS3722 have the property on parent node only, there is no subnode for each sub driver like palmas. In this case all sub drivers of_node is initialized as parent->of_node in mfd-core.c (mfd_add_devices). mfd-core.c: mfd_add_device() if (!pdev->dev.of_node) pdev->dev.of_node = parent->of_node; So all sub devices of AS3722 has the parent node. This node has the default pinmux configuration and so it tries to set the default pinmux before sud-driver's probe get called. The first one (for pinmux driver) it is success but for regulator and rtc, it is failed as pins are owned by the pinmux drivers. This does not have any side impact as currently, pinctrl_bind_pins() only return the success or ERPOBE_DEFER I was testing the patch with linux-next-common of your branch and chrome-os/kernel-next with linux-next's pinctrl/regulator/mfd and not able to repro this because driver/base changes was not there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: ptp: Include new header file in ptp_pch.c
On Wed, Dec 18, 2013 at 05:43:59PM -0500, David Miller wrote: > > I think this begs an even more fundamental question, why isn't the PTP > driver abstraction providing the necessary methods and interfaces so > that pch_gbe doesn't have to call into the ptp_pch.c code directly? Really it is more of a driver issue. For MAC based PTP clocks, they are so tightly coupled to the MAC driver that it is better *not* to have the PTP functions in a separate module. Instead, if having the PTP stuff optional makes sense, then the PTP parts are just a compile time option in the MAC driver. This is how the other MAC drivers with optional PTP are structured. > Moving ptp_pch.c elsehwere is not desirable, it's a PTP driver so > it belongs under drivers/ptp. > > Someone who understands all of these components needs to sort this > out cleanly, this patch isn't it. I am getting a bit tired of all the trouble over the past year caused by this particular driver. After it got merged, the original authors disappeared. I would really like to see this driver follow the pattern of bfin_mac, ti/cpts, and tile. Maybe I'll have to do it myself, like the Red Hen. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
On 12/18/2013 03:16 PM, Vladimir Davydov wrote: Signed-off-by: Vladimir Davydov Cc: Michal Hocko Cc: Johannes Weiner Cc: Glauber Costa Cc: Christoph Lameter Cc: Pekka Enberg Cc: Andrew Morton Look good to me. Even though this patch just touches slab, I think it should go through the memcg tree. Reviewed-by: Pekka Enberg Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/PATCHSET 00/18] perf report: Add support to accumulate hist periods (v3)
On Wed, 18 Dec 2013 14:47:15 -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Dec 18, 2013 at 11:37:49PM +0900, Namhyung Kim escreveu: >> 2013-12-18 (수), 10:46 +0100, Ingo Molnar: >> > * Namhyung Kim wrote: > >> > > I changed the option as a separate --cumulate and added a new >> > > "Total" column (and renamed the default "Overhead" column into >> > > "Self"). The output will be sorted by total (cumulative) overhead >> > > for now. The reason I changed to the --cumulate is that I still >> > > think it's much different from other --callchain options and I >> > > plan to add support for showing (remaining) callchains to >> > > cumulative entries too. The --callchain option will take care of >> > > it even with --cumulate option. > >> > So I still think this is a fantastic feature, and while this variant >> > of the user interface is an improvement over the previous version, we >> > are not there yet ;-) >> >> Right. But I want to finish the core part of this patchset first. And >> then I will work on the UI part since it'll be a quite large work by >> itself, I guess. > > I got the first few ones, that are not really related to this, to reduce > the patchkit size, will go thru the others next. Right. I missed to mention that they're independent cleanups, thanks. > >> > So the natural way to get this would something like: >> > >> >perf report --total >> > >> > Or, if '--total' does not feel good, maybe we should change 'Total' to >> > 'Siblings' or 'Children', and propagate that naming through the UI: >> >> Childrend looks better to me. > > --children, ack Okay. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Add check for number of available vectors before CPU down
On 12/19/13, Prarit Bhargava wrote: > > > On 12/03/2013 09:48 PM, rui wang wrote: >> On 11/20/13, Prarit Bhargava wrote: >> Have you considered the case when an IRQ is destined to more than one CPU? >> e.g.: >> >> bash# cat /proc/irq/89/smp_affinity_list >> 30,62 >> bash# >> >> In this case offlining CPU30 does not seem to require an empty vector >> slot. It seems that we only need to change the affinity mask of irq89. >> Your check_vectors() assumed that each irq on the offlining cpu >> requires a new vector slot. >> > > Rui, > > The smp_affinity_list only indicates a preferred destination of the IRQ, not > the > *actual* location of the CPU. So the IRQ is on one of cpu 30 or 62 but not > both > simultaneously. > It depends on how IOAPIC (or MSI/MSIx) is configured. An IRQ can be simultaneously broadcast to all destination CPUs (Fixed Mode) or delivered to the CPU with the lowest priority task (Lowest Priority Mode). It's programmed in the Delivery Mode bits of the IOAPIC's IO Redirection table registers, or the Message Data Register in the case of MSI/MSIx > If the case is that 62 is being brought down, then the smp_affinity mask > will be > updated to reflect only cpu 30 (and vice versa). > Yes the affinity mask should be updated. But if it was destined to more than one CPU, your "this_counter" does not seem to count the right numbers. Are you saying that smp_affinity mask is broken on Linux so that there's no way to configure an IRQ to target more than one CPU? Thanks Rui > P. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/18] perf sort: Compare addresses if no symbol info
Hi Arnaldo,
On Wed, 18 Dec 2013 14:39:07 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 18, 2013 at 02:35:28PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Dec 18, 2013 at 04:38:49PM +0100, Jiri Olsa escreveu:
>> > > +static int64_t _sort__addr_cmp(u64 left_ip, u64 right_ip)
>> > > +{
>> > > +return (int64_t)(right_ip - left_ip);
>> > > +}
>> > > +
>> >
>> > what's the reason for the leading '_' in the name?
>>
>> Yeah, I'm curious as well, the convention is to only use double _ in
>> front of functions when it does a little less than a function of the
>> same name without such prefix, like locking, etc.
>>
>> - Arnaldo
>>
>> > otherwise:
>> >
>> > Acked-by: Jiri Olsa
>
> Yeah, I'll apply it, it just keeps whatever convention that is there
> already.
Exactly. It's not a top-level sort/compare function, hence the leading
'_', I guess.
> I'll take a stab at fixing it all up after merging this
> --whatever-the-cumulate-option-becomes new code :-)
Thank you!
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/18] perf tools: Introduce struct add_entry_iter
Hi Jiri, On Wed, 18 Dec 2013 16:50:40 +0100, Jiri Olsa wrote: > On Wed, Dec 18, 2013 at 02:21:12PM +0900, Namhyung Kim wrote: >> From: Namhyung Kim >> >> There're some duplicate code when adding hist entries. They are >> different in that some have branch info or mem info but generally do >> same thing. So introduce new struct add_entry_iter and add callbacks >> to customize each case in general way. >> >> The new perf_evsel__add_entry() function will look like: >> >> iter->prepare_entry(); >> iter->add_single_entry(); >> >> while (iter->next_entry()) >> iter->add_next_entry(); >> >> iter->finish_entry(); >> >> This will help further work like the cumulative callchain patchset. > > cool, I was waiting for this one! I have another user > for it, I'll test by rebasing my code ;-) Great! I'd look forward to your feedback! :) Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: tegra: fix missing pincontrol configuration for Venice2
On Thursday 19 December 2013 02:26 AM, Stephen Warren wrote: On 12/18/2013 05:52 AM, Laxman Dewangan wrote: Compare the initial population of default pinmux configuration of Venice2 with the chrome branch and add/fix the missing configurations. Wow, that's a big chunk of changes. Are you sure this is correct? Why was the original patch (which added the pinctrl nodes) so incorrect? The pinmux which got added is based on the venice2 pinmux spreadsheet where I covered only the SFIO pin groups. https://wiki.nvidia.com/engwiki/index.php/Platform_Design_Center/Projects_Archive/PM371#pinmux After comparing with the chrome, I also added the pinmux for all pins which are used as GPIO and hence the change is big. This is complete pinmux based on chrome kernel-next. I booted chrome with this pinmux and not observe any behavioral change. Thierry, I thought you had mentioned comparing the pinctrl setup in linux-next with the downstream kernel for Venice2 and only found a difference in the PWM settings, which you sent a patch for. However, this patch is much larger than that. Where's the disconnect? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] memcg, slab: check and init memcg_cahes under slab_mutex
On 12/18/2013 09:41 PM, Michal Hocko wrote:
> On Wed 18-12-13 17:16:55, Vladimir Davydov wrote:
>> The memcg_params::memcg_caches array can be updated concurrently from
>> memcg_update_cache_size() and memcg_create_kmem_cache(). Although both
>> of these functions take the slab_mutex during their operation, the
>> latter checks if memcg's cache has already been allocated w/o taking the
>> mutex. This can result in a race as described below.
>>
>> Asume two threads schedule kmem_cache creation works for the same
>> kmem_cache of the same memcg from __memcg_kmem_get_cache(). One of the
>> works successfully creates it. Another work should fail then, but if it
>> interleaves with memcg_update_cache_size() as follows, it does not:
> I am not sure I understand the race. memcg_update_cache_size is called
> when we start accounting a new memcg or a child is created and it
> inherits accounting from the parent. memcg_create_kmem_cache is called
> when a new cache is first allocated from, right?
memcg_update_cache_size() is called when kmem accounting is activated
for a memcg, no matter how.
memcg_create_kmem_cache() is scheduled from __memcg_kmem_get_cache().
It's OK to have a bunch of such methods trying to create the same memcg
cache concurrently, but only one of them should succeed.
> Why cannot we simply take slab_mutex inside memcg_create_kmem_cache?
> it is running from the workqueue context so it should clash with other
> locks.
Hmm, Glauber's code never takes the slab_mutex inside memcontrol.c. I
have always been wondering why, because it could simplify flow paths
significantly (e.g. update_cache_sizes() -> update_all_caches() ->
update_cache_size() - from memcontrol.c to slab_common.c and back again
just to take the mutex).
I don't see any reason preventing us from taking the mutex in
memcontrol.c. This would allow us to move all memcg-related kmem cache
initialization (addition to the memcg slab list, initialization of the
pointer in memcg_caches) to memcg_kmem_cache_create() and remove a bunch
of public functions. I guess I'll do this in my next iteration.
Thanks.
>
>> memcg_create_kmem_cache() memcg_update_cache_size()
>> (called w/o mutexes held) (called with slab_mutex held)
>> - -
>> mutex_lock(_cache_mutex)
>> s->memcg_params=kzalloc(...)
>> new_cachep=cache_from_memcg_idx(cachep,idx)
>> // new_cachep==NULL => proceed to creation
>>
>> s->memcg_params->memcg_caches[i]
>>
>> =cur_params->memcg_caches[i]
>> // kmem_cache_dup takes slab_mutex so we will
>> // hang around here until memcg_update_cache_size()
>> // finishes, but ...
>> new_cachep = kmem_cache_dup(memcg, cachep)
>> // nothing will prevent kmem_cache_dup from
>> // succeeding so ...
>> cachep->memcg_params->memcg_caches[idx]=new_cachep
>> // we've overwritten an existing cache ptr!
>>
>> Let's fix this by moving both the check and the update of
>> memcg_params::memcg_caches from memcg_create_kmem_cache() to
>> kmem_cache_create_memcg() to be called under the slab_mutex.
>>
>> Signed-off-by: Vladimir Davydov
>> Cc: Michal Hocko
>> Cc: Johannes Weiner
>> Cc: Glauber Costa
>> Cc: Christoph Lameter
>> Cc: Pekka Enberg
>> Cc: Andrew Morton
>> ---
>> include/linux/memcontrol.h |9 ++--
>> mm/memcontrol.c| 98
>> +++-
>> mm/slab_common.c |8 +++-
>> 3 files changed, 44 insertions(+), 71 deletions(-)
>>
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index b357ae3..fdd3f30 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -500,8 +500,8 @@ int memcg_cache_id(struct mem_cgroup *memcg);
>> int memcg_init_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
>> struct kmem_cache *root_cache);
>> void memcg_free_cache_params(struct kmem_cache *s);
>> -void memcg_release_cache(struct kmem_cache *cachep);
>> -void memcg_cache_list_add(struct mem_cgroup *memcg, struct kmem_cache
>> *cachep);
>> +void memcg_register_cache(struct kmem_cache *s);
>> +void memcg_release_cache(struct kmem_cache *s);
>>
>> int memcg_update_cache_size(struct kmem_cache *s, int num_groups);
>> void memcg_update_array_size(int num_groups);
>> @@ -652,12 +652,11 @@ static inline void memcg_free_cache_params(struct
>> kmem_cache *s);
>> {
>> }
>>
>> -static inline void memcg_release_cache(struct kmem_cache *cachep)
>> +static inline void memcg_register_cache(struct kmem_cache *s)
>> {
>> }
>>
>> -static inline void memcg_cache_list_add(struct mem_cgroup *memcg,
>> -struct kmem_cache *s)
>> +static inline void memcg_release_cache(struct kmem_cache *s)
>> {
>> }
>>
>>
[PATCH 5/6] perf ui/tui: Implement log window
From: Namhyung Kim
Implement a simple, full-screen log window which shows error messages
saved so far. Press 'l' (lower-case 'L') key to display the log
window. It'll be used usually with -v option.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile.perf | 1 +
tools/perf/ui/browser.h| 1 +
tools/perf/ui/browsers/hists.c | 4 ++
tools/perf/ui/browsers/log.c | 92 ++
4 files changed, 98 insertions(+)
create mode 100644 tools/perf/ui/browsers/log.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index ec8184014a76..30aabace33a0 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -490,6 +490,7 @@ ifndef NO_SLANG
LIB_OBJS += $(OUTPUT)ui/browsers/hists.o
LIB_OBJS += $(OUTPUT)ui/browsers/map.o
LIB_OBJS += $(OUTPUT)ui/browsers/scripts.o
+ LIB_OBJS += $(OUTPUT)ui/browsers/log.o
LIB_OBJS += $(OUTPUT)ui/tui/setup.o
LIB_OBJS += $(OUTPUT)ui/tui/util.o
LIB_OBJS += $(OUTPUT)ui/tui/helpline.o
diff --git a/tools/perf/ui/browser.h b/tools/perf/ui/browser.h
index 7d45d2f53601..fff46942a8c7 100644
--- a/tools/perf/ui/browser.h
+++ b/tools/perf/ui/browser.h
@@ -59,6 +59,7 @@ int ui_browser__help_window(struct ui_browser *browser, const
char *text);
bool ui_browser__dialog_yesno(struct ui_browser *browser, const char *text);
int ui_browser__input_window(const char *title, const char *text, char *input,
const char *exit_msg, int delay_sec);
+int tui__log_window(void);
void ui_browser__argv_seek(struct ui_browser *browser, off_t offset, int
whence);
unsigned int ui_browser__argv_refresh(struct ui_browser *browser);
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a440e03cd8c2..8cc6f5eaa2cf 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1484,6 +1484,9 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
if (is_report_browser(hbt))
goto do_data_switch;
continue;
+ case 'l':
+ tui__log_window();
+ continue;
case K_F1:
case 'h':
case '?':
@@ -1506,6 +1509,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
"s Switch to another data
file in PWD ('perf report' only)\n"
"P Print histograms to
perf.hist.N\n"
"V Verbose (DSO names in
callchains, etc)\n"
+ "l Show log messages\n"
"/ Filter symbol by name");
continue;
case K_ENTER:
diff --git a/tools/perf/ui/browsers/log.c b/tools/perf/ui/browsers/log.c
new file mode 100644
index ..f1610d6bb9d2
--- /dev/null
+++ b/tools/perf/ui/browsers/log.c
@@ -0,0 +1,92 @@
+#include
+
+#include "perf.h"
+#include "util/util.h"
+#include "util/cache.h"
+#include "util/debug.h"
+#include "ui/ui.h"
+#include "ui/util.h"
+#include "ui/browser.h"
+#include "ui/libslang.h"
+#include "ui/keysyms.h"
+#include "ui/tui/tui.h"
+
+static void ui_browser__file_seek(struct ui_browser *browser __maybe_unused,
+ off_t offset __maybe_unused,
+ int whence __maybe_unused)
+{
+ /* do nothing */
+}
+
+static void ui_browser__file_write(struct ui_browser *browser,
+ void *entry, int row)
+{
+ char buf[1024];
+ FILE *fp = perf_log.fp;
+ bool current_entry = ui_browser__is_current_entry(browser, row);
+ off_t *linemap = perf_log.linemap;
+ unsigned int idx = *(unsigned int *)entry;
+
+ fseek(fp, linemap[idx], SEEK_SET);
+ if (fgets(buf, sizeof(buf), fp) == NULL)
+ return;
+
+ ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
+ HE_COLORSET_NORMAL);
+ slsmg_write_nstring(buf, browser->width);
+}
+
+static unsigned int ui_browser__file_refresh(struct ui_browser *browser)
+{
+ unsigned int row = 0;
+ unsigned int idx = browser->top_idx;
+
+ while (idx < browser->nr_entries) {
+ ui_browser__gotorc(browser, row, 0);
+ browser->write(browser, , row);
+ if (++row == browser->height)
+ break;
+
+ ++idx;
+ }
+
+ return row;
+}
+
+static int log_menu__run(struct ui_browser *menu)
+{
+ int key;
+
+ if (ui_browser__show(menu, "Log messages", "Press 'q' to exit") < 0)
+ return -1;
+
+ while (1) {
+ key = ui_browser__run(menu, 0);
+ switch (key) {
+
[PATCH 3/6] perf tools: Get rid of a duplicate va_end()
From: Namhyung Kim The va_end() in _eprintf() should be removed since the caller also invokes va_end(). Signed-off-by: Namhyung Kim --- tools/perf/util/debug.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c index 8640a9121e72..299b55586502 100644 --- a/tools/perf/util/debug.c +++ b/tools/perf/util/debug.c @@ -25,7 +25,6 @@ static int _eprintf(int level, const char *fmt, va_list args) ui_helpline__vshow(fmt, args); else ret = vfprintf(stderr, fmt, args); - va_end(args); } return ret; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Tracing events with GPIOs
On Tue, Dec 17, 2013 at 9:22 AM, Jean-Jacques Hiblot wrote: > > This patch implements a new tracing mechanism based on kprobes and using GPIO. > Debugging with GPIO is very common in the embedded world. At least for those > of us > fortunate enough to have an oscilloscope or a logic analyzer on their bench... > This is especially true if the issue results of a hardware/sofware > interaction. > > Typical use cases are : > * mixed software/hardware debugging. For example when the software detects a > situation of interest (typically an error) it toggles a GPIO to trigger the > oscilloscope acquisition. > * direct latency/duration measurements. > > examples: > To trig the oscilloscope whenever a mmc command error: > echo "p:my_mmc_blk_error mmc_blk_cmd_error gpiopulse@13" > > /sys/kernel/debug/tracing/kprobe_events > echo 1 > /sys/kernel/debug/tracing/events/kprobes/my_mmc_blk_error/enable I do like this idea, however I wonder if you could try and make it use the new gpio descriptor API (see Documentation/gpio/) instead of the GPIO integers we are trying to deprecate (well ok, we just *started* claiming they are deprecated). This would probably make things a little bit more complicated on your side, due to the fact the gpiod API is new and probably does not cover all your needs. But it would also make your approach safer and more future proof, on top of helping us refine gpiod for various use cases. The problems I can see so far: - Using gpiod, GPIOs are not specified as integers, but are typically mapped to a given (device, function) pair (device can be NULL) using device tree/platform data/ACPI and obtained by the corresponding device driver through gpiod_get(). You would need to find a different way to specify GPIOs, maybe using the gpio_chip's label and the GPIO hardware number. - Even if you do so, there is currently no way to arbitrarily obtain a GPIO that has not been explicitly mapped to a (device, function), and IIUC you need to specify the tracing GPIO freely from user-space. This hints that we will need to add a function that is sensibly the same as gpio_request_one() to the gpiod API, but I wonder if that does not defeats the purpose somehow. So using gpiod we would have the dual problem of how to represent the GPIO you need from user-space, and how you can safely obtain it. It would be interesting to hear what Linus thinks about it, and if he has better ideas about how we could solve these issues (as he usually has ;) ). (note that it is *not* a hard requirement to use gpiod over the legacy integer API, but considering this is the direction we are taking, it would be nice to consider it and see how we could solve the issues mentioned above) Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] perf tools: Introduce struct perf_log
From: Namhyung Kim
Add new functions to save error messages in a temp file. It'll be
used by some UI front-ends to see the messages.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile.perf | 1 +
tools/perf/perf.c| 3 ++
tools/perf/util/debug.h | 15 +++
tools/perf/util/log.c| 105 +++
4 files changed, 124 insertions(+)
create mode 100644 tools/perf/util/log.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 97a2145e4cc6..ec8184014a76 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -372,6 +372,7 @@ LIB_OBJS += $(OUTPUT)util/stat.o
LIB_OBJS += $(OUTPUT)util/record.o
LIB_OBJS += $(OUTPUT)util/srcline.o
LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/log.o
LIB_OBJS += $(OUTPUT)ui/setup.o
LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 431798a4110d..bdf7bd8e4394 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -10,6 +10,7 @@
#include "util/exec_cmd.h"
#include "util/cache.h"
+#include "util/debug.h"
#include "util/quote.h"
#include "util/run-command.h"
#include "util/parse-events.h"
@@ -524,6 +525,7 @@ int main(int argc, const char **argv)
*/
pthread__block_sigwinch();
+ perf_log_init();
while (1) {
static int done_help;
int was_alias = run_argv(, );
@@ -543,6 +545,7 @@ int main(int argc, const char **argv)
} else
break;
}
+ perf_log_exit();
fprintf(stderr, "Failed to run command '%s': %s\n",
cmd, strerror(errno));
diff --git a/tools/perf/util/debug.h b/tools/perf/util/debug.h
index 443694c36b03..ea160abc2ae0 100644
--- a/tools/perf/util/debug.h
+++ b/tools/perf/util/debug.h
@@ -19,4 +19,19 @@ int ui__warning(const char *format, ...)
__attribute__((format(printf, 1, 2)));
void pr_stat(const char *fmt, ...);
+struct perf_log {
+ FILE *fp;
+ off_t *linemap;
+ u32 lines;
+ u32 nr_alloc;
+ bool seen_newline;
+};
+
+extern struct perf_log perf_log;
+
+int perf_log_init(void);
+int perf_log_exit(void);
+void perf_log_add(const char *msg);
+void perf_log_addv(const char *fmt, va_list ap);
+
#endif /* __PERF_DEBUG_H */
diff --git a/tools/perf/util/log.c b/tools/perf/util/log.c
new file mode 100644
index ..4a34bed2af44
--- /dev/null
+++ b/tools/perf/util/log.c
@@ -0,0 +1,105 @@
+#include
+#include
+#include "util/debug.h"
+
+#define LINEMAP_GROW 128
+
+struct perf_log perf_log = {
+ .seen_newline = true,
+};
+
+int perf_log_init(void)
+{
+ FILE *fp;
+ char name[] = "/tmp/perf-tui-log-XX";
+ int fd = mkstemp(name);
+
+ if (fd < 0)
+ return -1;
+
+ fp = fdopen(fd, "r+");
+ if (fp == NULL) {
+ close(fd);
+ return -1;
+ }
+
+ perf_log.fp = fp;
+
+ return 0;
+}
+
+int perf_log_exit(void)
+{
+ FILE *fp = perf_log.fp;
+ if (fp)
+ fclose(fp);
+
+ free(perf_log.linemap);
+
+ perf_log.fp = NULL;
+ perf_log.linemap = NULL;
+ return 0;
+}
+
+static int grow_linemap(struct perf_log *log)
+{
+ off_t *newmap;
+ int newsize = log->nr_alloc + LINEMAP_GROW;
+
+ newmap = realloc(log->linemap, newsize * sizeof(*log->linemap));
+ if (newmap == NULL)
+ return -1;
+
+ log->nr_alloc = newsize;
+ log->linemap = newmap;
+ return 0;
+}
+
+static int __add_to_linemap(struct perf_log *log, off_t index)
+{
+ if (log->lines == log->nr_alloc)
+ if (grow_linemap(log) < 0)
+ return -1;
+
+ log->linemap[log->lines++] = index;
+ return 0;
+}
+
+static void add_to_linemap(struct perf_log *log, const char *msg, off_t base)
+{
+ const char *pos;
+
+ if (strlen(msg) == 0)
+ return;
+
+ if (log->seen_newline) {
+ if (__add_to_linemap(log, base) < 0)
+ return;
+ }
+
+ if ((pos = strchr(msg, '\n')) != NULL) {
+ log->seen_newline = true;
+ pos++;
+ add_to_linemap(log, pos, base + (pos - msg));
+ } else {
+ log->seen_newline = false;
+ }
+}
+
+void perf_log_add(const char *msg)
+{
+ FILE *fp = perf_log.fp;
+ off_t offset = ftello(fp);
+
+ add_to_linemap(_log, msg, offset);
+
+ fwrite(msg, 1, strlen(msg), fp);
+}
+
+void perf_log_addv(const char *fmt, va_list ap)
+{
+ char buf[4096];
+
+ vsnprintf(buf, sizeof(buf), fmt, ap);
+ perf_log_add(buf);
+}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET 0/6] perf tools: A couple of TUI improvements
Hello, I was playing with TUI code and added two new windows. One for showing log messages and another for showing header information. (Maybe they can be implemented on the GTK code too someday.) Please try to use it! :) I put the patches on 'perf/tui-v1' branch in my tree: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Any feedbacks are more than welcome, thanks Namhyung Namhyung Kim (6): perf report: Use pr_*() functions if possible perf tools: Introduce struct perf_log perf tools: Get rid of a duplicate va_end() perf tools: Save message when pr_*() was called perf ui/tui: Implement log window perf ui/tui: Implement header window tools/perf/Makefile.perf| 3 ++ tools/perf/builtin-report.c | 24 + tools/perf/perf.c | 3 ++ tools/perf/ui/browser.h | 3 ++ tools/perf/ui/browsers/header.c | 116 tools/perf/ui/browsers/hists.c | 8 +++ tools/perf/ui/browsers/log.c| 92 +++ tools/perf/util/debug.c | 7 ++- tools/perf/util/debug.h | 15 ++ tools/perf/util/log.c | 105 10 files changed, 364 insertions(+), 12 deletions(-) create mode 100644 tools/perf/ui/browsers/header.c create mode 100644 tools/perf/ui/browsers/log.c create mode 100644 tools/perf/util/log.c -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] perf tools: Save message when pr_*() was called
From: Namhyung Kim
The message will be saved in a temp file so that it can be shown at a
UI dialog at any time.
Signed-off-by: Namhyung Kim
---
tools/perf/util/debug.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index 299b55586502..f55b499c93fb 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -19,12 +19,18 @@ bool dump_trace = false, quiet = false;
static int _eprintf(int level, const char *fmt, va_list args)
{
int ret = 0;
+ va_list ap;
if (verbose >= level) {
+ va_copy(ap, args);
+
if (use_browser >= 1)
ui_helpline__vshow(fmt, args);
else
ret = vfprintf(stderr, fmt, args);
+
+ perf_log_addv(fmt, ap);
+ va_end(ap);
}
return ret;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] perf report: Use pr_*() functions if possible
From: Namhyung Kim
There're some places printing a message to stdout/err directly. It
should be converted to use proper error printing functions instead.
If it's not possible, just do it when --stdio was enabled only.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 3a14dbed387c..a1f72b471a96 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -321,8 +321,8 @@ static int process_sample_event(struct perf_tool *tool,
int ret;
if (perf_event__preprocess_sample(event, machine, , sample) < 0) {
- fprintf(stderr, "problem processing %d event, skipping it.\n",
- event->header.type);
+ pr_debug("problem processing %d event, skipping it.\n",
+event->header.type);
return -1;
}
@@ -552,15 +552,17 @@ static int __cmd_report(struct perf_report *rep)
desc);
}
- if (verbose > 3)
- perf_session__fprintf(session, stdout);
+ if (use_browser == 0) {
+ if (verbose > 3)
+ perf_session__fprintf(session, stdout);
- if (verbose > 2)
- perf_session__fprintf_dsos(session, stdout);
+ if (verbose > 2)
+ perf_session__fprintf_dsos(session, stdout);
- if (dump_trace) {
- perf_session__fprintf_nr_events(session, stdout);
- return 0;
+ if (dump_trace) {
+ perf_session__fprintf_nr_events(session, stdout);
+ return 0;
+ }
}
nr_samples = 0;
@@ -720,7 +722,7 @@ parse_callchain_opt(const struct option *opt, const char
*arg, int unset)
return -1;
setup:
if (callchain_register_param(_param) < 0) {
- fprintf(stderr, "Can't register callchain params\n");
+ pr_err("Can't register callchain params\n");
return -1;
}
return 0;
@@ -942,7 +944,7 @@ repeat:
}
if (report.mem_mode) {
if (sort__mode == SORT_MODE__BRANCH) {
- fprintf(stderr, "branch and mem mode incompatible\n");
+ pr_err("branch and mem mode incompatible\n");
goto error;
}
sort__mode = SORT_MODE__MEMORY;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] perf ui/tui: Implement header window
From: Namhyung Kim
Implement a simple, full-screen header window which shows session
header (metadata) information. Press 'i' key to display the header
window.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile.perf| 1 +
tools/perf/ui/browser.h | 2 +
tools/perf/ui/browsers/header.c | 116
tools/perf/ui/browsers/hists.c | 4 ++
4 files changed, 123 insertions(+)
create mode 100644 tools/perf/ui/browsers/header.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 30aabace33a0..4d046e97d0e7 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -491,6 +491,7 @@ ifndef NO_SLANG
LIB_OBJS += $(OUTPUT)ui/browsers/map.o
LIB_OBJS += $(OUTPUT)ui/browsers/scripts.o
LIB_OBJS += $(OUTPUT)ui/browsers/log.o
+ LIB_OBJS += $(OUTPUT)ui/browsers/header.o
LIB_OBJS += $(OUTPUT)ui/tui/setup.o
LIB_OBJS += $(OUTPUT)ui/tui/util.o
LIB_OBJS += $(OUTPUT)ui/tui/helpline.o
diff --git a/tools/perf/ui/browser.h b/tools/perf/ui/browser.h
index fff46942a8c7..b77d8728b3f0 100644
--- a/tools/perf/ui/browser.h
+++ b/tools/perf/ui/browser.h
@@ -60,6 +60,8 @@ bool ui_browser__dialog_yesno(struct ui_browser *browser,
const char *text);
int ui_browser__input_window(const char *title, const char *text, char *input,
const char *exit_msg, int delay_sec);
int tui__log_window(void);
+struct perf_session_env;
+int tui__header_window(struct perf_session_env *env);
void ui_browser__argv_seek(struct ui_browser *browser, off_t offset, int
whence);
unsigned int ui_browser__argv_refresh(struct ui_browser *browser);
diff --git a/tools/perf/ui/browsers/header.c b/tools/perf/ui/browsers/header.c
new file mode 100644
index ..b5f0961bf793
--- /dev/null
+++ b/tools/perf/ui/browsers/header.c
@@ -0,0 +1,116 @@
+#include "util/cache.h"
+#include "util/debug.h"
+#include "ui/browser.h"
+#include "ui/ui.h"
+#include "ui/util.h"
+#include "ui/libslang.h"
+#include "util/header.h"
+#include "util/session.h"
+
+static void ui_browser__argv_write(struct ui_browser *browser,
+ void *entry, int row)
+{
+ char **arg = entry;
+ char *str = *arg;
+ char empty[] = " ";
+ bool current_entry = ui_browser__is_current_entry(browser, row);
+ unsigned long offset = (unsigned long)browser->priv;
+
+ if (offset >= strlen(str))
+ str = empty;
+ else
+ str = str + offset;
+
+ ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
+ HE_COLORSET_NORMAL);
+
+ slsmg_write_nstring(str, browser->width);
+}
+
+static int list_menu__run(struct ui_browser *menu)
+{
+ int key;
+ unsigned long offset;
+
+ if (ui_browser__show(menu, "Header information", "Press 'q' to exit") <
0)
+ return -1;
+
+ while (1) {
+ key = ui_browser__run(menu, 0);
+
+ switch (key) {
+ case K_RIGHT:
+ offset = (unsigned long)menu->priv;
+ offset += 10;
+ menu->priv = (void *)offset;
+ continue;
+ case K_LEFT:
+ offset = (unsigned long)menu->priv;
+ if (offset >= 10)
+ offset -= 10;
+ menu->priv = (void *)offset;
+ continue;
+ case K_ESC:
+ case 'q':
+ case CTRL('c'):
+ key = -1;
+ break;
+ default:
+ continue;
+ }
+
+ break;
+ }
+
+ ui_browser__hide(menu);
+ return key;
+}
+
+static int ui__list_menu(int argc, char * const argv[])
+{
+ struct ui_browser menu = {
+ .entries= (void *)argv,
+ .refresh= ui_browser__argv_refresh,
+ .seek = ui_browser__argv_seek,
+ .write = ui_browser__argv_write,
+ .nr_entries = argc,
+ };
+
+ return list_menu__run();
+}
+
+int tui__header_window(struct perf_session_env *env)
+{
+ int i, argc = 0;
+ char **argv;
+ struct perf_session *session;
+ char *ptr, *pos;
+ size_t size;
+ FILE *fp = open_memstream(, );
+
+ session = container_of(env, struct perf_session, header.env);
+ perf_header__fprintf_info(session, fp, true);
+ fclose(fp);
+
+ for (pos = ptr, argc = 0; (pos = strchr(pos, '\n')) != NULL; pos++)
+ argc++;
+
+ argv = calloc(argc + 1, sizeof(*argv));
+ if (argv == NULL)
+ goto out;
+
+ argv[0] = pos = ptr;
+ for (i = 1; (pos = strchr(pos, '\n')) != NULL; i++) {
+ *pos++ = '\0';
+ argv[i] = pos;
+ }
+
+ BUG_ON(i !=
Re: [RFC PATCH] ixgbe: acquire RCU read lock when calling netdev_for_each_all_upper_dev_rcu()
On 12/18/2013 10:00 PM, Jiang Liu wrote: According to documentation for netdev_for_each_all_upper_dev_rcu(), caller should take RCU read lock, otherwise it will trigger following warnings. The simplest fix is to protect with rcu_read_lock()/ rcu_read_unlock(). And this solutions passes basic tests. Otherwise we may need to introduce netdev_for_each_all_upper_dev() as netdev_lower_get_next_private(), which assumes the caller has gained the lock to protect the list. Signed-off-by: Jiang Liu --- Jiang, The following patch addresses the same issue, http://patchwork.ozlabs.org/patch/302711/ [net,1/5] net: allow netdev_all_upper_get_next_dev_rcu with rtnl lock held It is under review and solves the problem by having the call check for the rtnl lock as well. Take a look. I think it is a slightly better fix in that it doesn't clutter the driver with unnecessary rcu_read_lock() and rcu_read_unlock() calls. Thanks, John -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] memcg, slab: cleanup barrier usage when accessing memcg_caches
On 12/18/2013 09:14 PM, Michal Hocko wrote:
> On Wed 18-12-13 17:16:54, Vladimir Davydov wrote:
>> First, in memcg_create_kmem_cache() we should issue the write barrier
>> after the kmem_cache is initialized, but before storing the pointer to
>> it in its parent's memcg_params.
>>
>> Second, we should always issue the read barrier after
>> cache_from_memcg_idx() to conform with the write barrier.
>>
>> Third, its better to use smp_* versions of barriers, because we don't
>> need them on UP systems.
> Please be (much) more verbose on Why. Barriers are tricky and should be
> documented accordingly. So if you say that we should issue a barrier
> always be specific why we should do it.
In short, we have kmem_cache::memcg_params::memcg_caches is an array of
pointers to per-memcg caches. We access it lock-free so we should use
memory barriers during initialization. Obviously we should place a write
barrier just before we set the pointer in order to make sure nobody will
see a partially initialized structure. Besides there must be a read
barrier between reading the pointer and accessing the structure, to
conform with the write barrier. It's all that similar to rcu_assign and
rcu_deref. Currently the barrier usage looks rather strange:
memcg_create_kmem_cache:
initialize kmem
set the pointer in memcg_caches
wmb() // ???
__memcg_kmem_get_cache:
<...>
read_barrier_depends() // ???
cachep = root_cache->memcg_params->memcg_caches[memcg_id]
<...>
Nothing prevents some archs from moving initialization after setting the
pointer, or reading data before reading the pointer to it.
Of course, I will include a detailed description in the next version of
this patch.
Thanks.
>> Signed-off-by: Vladimir Davydov
>> Cc: Michal Hocko
>> Cc: Johannes Weiner
>> Cc: Glauber Costa
>> Cc: Christoph Lameter
>> Cc: Pekka Enberg
>> Cc: Andrew Morton
>> ---
>> mm/memcontrol.c | 24 ++--
>> mm/slab.h |6 +-
>> 2 files changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index e6ad6ff..e37fdb5 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -3429,12 +3429,14 @@ static struct kmem_cache
>> *memcg_create_kmem_cache(struct mem_cgroup *memcg,
>>
>> atomic_set(_cachep->memcg_params->nr_pages , 0);
>>
>> -cachep->memcg_params->memcg_caches[idx] = new_cachep;
>> /*
>> - * the readers won't lock, make sure everybody sees the updated value,
>> - * so they won't put stuff in the queue again for no reason
>> + * Since readers won't lock (see cache_from_memcg_idx()), we need a
>> + * barrier here to ensure nobody will see the kmem_cache partially
>> + * initialized.
>> */
>> -wmb();
>> +smp_wmb();
>> +
>> +cachep->memcg_params->memcg_caches[idx] = new_cachep;
>> out:
>> mutex_unlock(_cache_mutex);
>> return new_cachep;
>> @@ -3573,7 +3575,7 @@ struct kmem_cache *__memcg_kmem_get_cache(struct
>> kmem_cache *cachep,
>>gfp_t gfp)
>> {
>> struct mem_cgroup *memcg;
>> -int idx;
>> +struct kmem_cache *memcg_cachep;
>>
>> VM_BUG_ON(!cachep->memcg_params);
>> VM_BUG_ON(!cachep->memcg_params->is_root_cache);
>> @@ -3587,15 +3589,9 @@ struct kmem_cache *__memcg_kmem_get_cache(struct
>> kmem_cache *cachep,
>> if (!memcg_can_account_kmem(memcg))
>> goto out;
>>
>> -idx = memcg_cache_id(memcg);
>> -
>> -/*
>> - * barrier to mare sure we're always seeing the up to date value. The
>> - * code updating memcg_caches will issue a write barrier to match this.
>> - */
>> -read_barrier_depends();
>> -if (likely(cache_from_memcg_idx(cachep, idx))) {
>> -cachep = cache_from_memcg_idx(cachep, idx);
>> +memcg_cachep = cache_from_memcg_idx(cachep, memcg_cache_id(memcg));
>> +if (likely(memcg_cachep)) {
>> +cachep = memcg_cachep;
>> goto out;
>> }
>>
>> diff --git a/mm/slab.h b/mm/slab.h
>> index 0859c42..1d8b53f 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
>> @@ -163,9 +163,13 @@ static inline const char *cache_name(struct kmem_cache
>> *s)
>> static inline struct kmem_cache *
>> cache_from_memcg_idx(struct kmem_cache *s, int idx)
>> {
>> +struct kmem_cache *cachep;
>> +
>> if (!s->memcg_params)
>> return NULL;
>> -return s->memcg_params->memcg_caches[idx];
>> +cachep = s->memcg_params->memcg_caches[idx];
>> +smp_read_barrier_depends(); /* see memcg_register_cache() */
>> +return cachep;
>> }
>>
>> static inline struct kmem_cache *memcg_root_cache(struct kmem_cache *s)
>> --
>> 1.7.10.4
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail
On Thu, Dec 19, 2013 at 11:51:45AM +0530, Roger Quadros wrote: > On 12/19/2013 11:16 AM, Huang Rui wrote: > > On Thu, Dec 19, 2013 at 12:01:47PM +0800, Huang Rui wrote: > >> On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote: > >>> In test_halt() we set an endpoint halt condition and return on halt > >>> verification > >>> failure, then the enpoint will remain halted and all further tests related > > ^^^ > >>> to that enpoint will fail. This is because we don't tackle endpoint halt > >>> error condition > > ^^^ > > BTW, please fix these typo. > > Hi Rui, > > These patches have been already applied to Greg's usb tree without your Ack's > or the typo fix. > > Greg, > > do you want me to resend the patches? Nope, it's not a big deal, typo's in changelog comments isn't a worry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/118] 3.12.6-stable review
On Wed, Dec 18, 2013 at 10:17:23PM -0800, Guenter Roeck wrote: > On 12/18/2013 07:27 PM, Greg Kroah-Hartman wrote: > > On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote: > >> This is the start of the stable review cycle for the 3.12.6 release. > >> There are 118 patches in this series, all will be posted as a response > >> to this one. If anyone has any issues with these being applied, please > >> let me know. > >> > >> Responses should be made by Fri Dec 20 21:12:03 UTC 2013. > >> Anything received after that time might be too late. > >> > >> The whole patch series can be found in one patch at: > >>kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz > >> and the diffstat can be found below. > > > > Thanks to a bug on my part, there's now a -rc2 out for people to test > > with: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc2.gz > > > > Note, if you didn't have a build-failure with -rc1 then no need to test > > -rc2, it's only a specific staging driver that had an issue. > > > > Build results are much better: > total: 110 pass: 107 skipped: 3 fail: 0 > > qemu tests still all pass. Wonderful, thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] memcg, slab: kmem_cache_create_memcg(): free memcg params on error
On 12/18/2013 09:06 PM, Michal Hocko wrote:
> On Wed 18-12-13 17:16:53, Vladimir Davydov wrote:
>> Plus, rename memcg_register_cache() to memcg_init_cache_params(),
>> because it actually does not register the cache anywhere, but simply
>> initialize kmem_cache::memcg_params.
> I've almost missed this is a memory leak fix.
Yeah, the comment is poor, sorry about that. Will fix it.
> I do not mind renaming and the name but wouldn't
> memcg_alloc_cache_params suit better?
As you wish. I don't have a strong preference for memcg_init_cache_params.
Thanks.
>
>> Signed-off-by: Vladimir Davydov
>> Cc: Michal Hocko
>> Cc: Johannes Weiner
>> Cc: Glauber Costa
>> Cc: Christoph Lameter
>> Cc: Pekka Enberg
>> Cc: Andrew Morton
>> ---
>> include/linux/memcontrol.h | 13 +
>> mm/memcontrol.c|9 +++--
>> mm/slab_common.c |3 ++-
>> 3 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index b3e7a66..b357ae3 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -497,8 +497,9 @@ void __memcg_kmem_commit_charge(struct page *page,
>> void __memcg_kmem_uncharge_pages(struct page *page, int order);
>>
>> int memcg_cache_id(struct mem_cgroup *memcg);
>> -int memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s,
>> - struct kmem_cache *root_cache);
>> +int memcg_init_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
>> +struct kmem_cache *root_cache);
>> +void memcg_free_cache_params(struct kmem_cache *s);
>> void memcg_release_cache(struct kmem_cache *cachep);
>> void memcg_cache_list_add(struct mem_cgroup *memcg, struct kmem_cache
>> *cachep);
>>
>> @@ -641,12 +642,16 @@ static inline int memcg_cache_id(struct mem_cgroup
>> *memcg)
>> }
>>
>> static inline int
>> -memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s,
>> - struct kmem_cache *root_cache)
>> +memcg_init_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
>> +struct kmem_cache *root_cache)
>> {
>> return 0;
>> }
>>
>> +static inline void memcg_free_cache_params(struct kmem_cache *s);
>> +{
>> +}
>> +
>> static inline void memcg_release_cache(struct kmem_cache *cachep)
>> {
>> }
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index bf5e894..e6ad6ff 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -3195,8 +3195,8 @@ int memcg_update_cache_size(struct kmem_cache *s, int
>> num_groups)
>> return 0;
>> }
>>
>> -int memcg_register_cache(struct mem_cgroup *memcg, struct kmem_cache *s,
>> - struct kmem_cache *root_cache)
>> +int memcg_init_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
>> +struct kmem_cache *root_cache)
>> {
>> size_t size;
>>
>> @@ -3224,6 +3224,11 @@ int memcg_register_cache(struct mem_cgroup *memcg,
>> struct kmem_cache *s,
>> return 0;
>> }
>>
>> +void memcg_free_cache_params(struct kmem_cache *s)
>> +{
>> +kfree(s->memcg_params);
>> +}
>> +
>> void memcg_release_cache(struct kmem_cache *s)
>> {
>> struct kmem_cache *root;
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index 5d6f743..62712fe 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -208,7 +208,7 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const
>> char *name, size_t size,
>> goto out_free_cache;
>> }
>>
>> -err = memcg_register_cache(memcg, s, parent_cache);
>> +err = memcg_init_cache_params(memcg, s, parent_cache);
>> if (err)
>> goto out_free_cache;
>>
>> @@ -238,6 +238,7 @@ out_unlock:
>> return s;
>>
>> out_free_cache:
>> +memcg_free_cache_params(s);
>> kfree(s->name);
>> kmem_cache_free(kmem_cache, s);
>> goto out_unlock;
>> --
>> 1.7.10.4
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
On 12/18/2013 08:56 PM, Michal Hocko wrote:
> On Wed 18-12-13 17:16:52, Vladimir Davydov wrote:
>> Signed-off-by: Vladimir Davydov
>> Cc: Michal Hocko
>> Cc: Johannes Weiner
>> Cc: Glauber Costa
>> Cc: Christoph Lameter
>> Cc: Pekka Enberg
>> Cc: Andrew Morton
> Dunno, is this really better to be worth the code churn?
>
> It even makes the generated code tiny bit bigger:
> textdata bss dec hex filename
> 4355 171 2364762129a mm/slab_common.o.after
> 4342 171 2364749128d mm/slab_common.o.before
>
> Or does it make the further changes much more easier? Be explicit in the
> patch description if so.
Hi, Michal
IMO, undoing under labels looks better than inside conditionals, because
we don't have to repeat the same deinitialization code then, like this
(note three calls to kmem_cache_free()):
s = kmem_cache_zalloc(kmem_cache, GFP_KERNEL);
if (s) {
s->object_size = s->size = size;
s->align = calculate_alignment(flags, align, size);
s->ctor = ctor;
if (memcg_register_cache(memcg, s, parent_cache)) {
kmem_cache_free(kmem_cache, s);
err = -ENOMEM;
goto out_locked;
}
s->name = kstrdup(name, GFP_KERNEL);
if (!s->name) {
kmem_cache_free(kmem_cache, s);
err = -ENOMEM;
goto out_locked;
}
err = __kmem_cache_create(s, flags);
if (!err) {
s->refcount = 1;
list_add(>list, _caches);
memcg_cache_list_add(memcg, s);
} else {
kfree(s->name);
kmem_cache_free(kmem_cache, s);
}
} else
err = -ENOMEM;
The next patch, which fixes the memcg_params leakage on error, would
make it even worse introducing two calls to memcg_free_cache_params()
after kstrdup and __kmem_cache_create.
If you think it isn't worthwhile applying this patch, just let me know,
I don't mind dropping it.
Anyway, I'll improve the comment and resend.
Thanks.
>
>> ---
>> mm/slab_common.c | 66
>> +++---
>> 1 file changed, 33 insertions(+), 33 deletions(-)
>>
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index 0b7bb39..5d6f743 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -176,8 +176,9 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const
>> char *name, size_t size,
>> get_online_cpus();
>> mutex_lock(_mutex);
>>
>> -if (!kmem_cache_sanity_check(memcg, name, size) == 0)
>> -goto out_locked;
>> +err = kmem_cache_sanity_check(memcg, name, size);
>> +if (err)
>> +goto out_unlock;
>>
>> /*
>> * Some allocators will constraint the set of valid flags to a subset
>> @@ -189,45 +190,41 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg,
>> const char *name, size_t size,
>>
>> s = __kmem_cache_alias(memcg, name, size, align, flags, ctor);
>> if (s)
>> -goto out_locked;
>> +goto out_unlock;
>>
>> s = kmem_cache_zalloc(kmem_cache, GFP_KERNEL);
>> -if (s) {
>> -s->object_size = s->size = size;
>> -s->align = calculate_alignment(flags, align, size);
>> -s->ctor = ctor;
>> -
>> -if (memcg_register_cache(memcg, s, parent_cache)) {
>> -kmem_cache_free(kmem_cache, s);
>> -err = -ENOMEM;
>> -goto out_locked;
>> -}
>> +if (!s) {
>> +err = -ENOMEM;
>> +goto out_unlock;
>> +}
>>
>> -s->name = kstrdup(name, GFP_KERNEL);
>> -if (!s->name) {
>> -kmem_cache_free(kmem_cache, s);
>> -err = -ENOMEM;
>> -goto out_locked;
>> -}
>> +s->object_size = s->size = size;
>> +s->align = calculate_alignment(flags, align, size);
>> +s->ctor = ctor;
>>
>> -err = __kmem_cache_create(s, flags);
>> -if (!err) {
>> -s->refcount = 1;
>> -list_add(>list, _caches);
>> -memcg_cache_list_add(memcg, s);
>> -} else {
>> -kfree(s->name);
>> -kmem_cache_free(kmem_cache, s);
>> -}
>> -} else
>> +s->name = kstrdup(name, GFP_KERNEL);
>> +if (!s->name) {
>> err = -ENOMEM;
>> +goto out_free_cache;
>> +}
>> +
>> +err = memcg_register_cache(memcg, s, parent_cache);
>> +if (err)
>> +goto out_free_cache;
>>
>> -out_locked:
>> +err = __kmem_cache_create(s, flags);
>> +if (err)
>> +goto out_free_cache;
>> +
>> +s->refcount = 1;
>> +list_add(>list, _caches);
>> +memcg_cache_list_add(memcg, s);
>> +
>> +out_unlock:
>> mutex_unlock(_mutex);
>> put_online_cpus();
>>
>> if (err) {
>> -
>> if (flags &
Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail
On 12/19/2013 11:16 AM, Huang Rui wrote:
> On Thu, Dec 19, 2013 at 12:01:47PM +0800, Huang Rui wrote:
>> On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote:
>>> In test_halt() we set an endpoint halt condition and return on halt
>>> verification
>>> failure, then the enpoint will remain halted and all further tests related
> ^^^
>>> to that enpoint will fail. This is because we don't tackle endpoint halt
>>> error condition
> ^^^
> BTW, please fix these typo.
Hi Rui,
These patches have been already applied to Greg's usb tree without your Ack's
or the typo fix.
Greg,
do you want me to resend the patches?
cheers,
-roger
>
> Thanks,
> Rui
>
>>> in any of the tests. To avoid that situation, make sure to clear the
>>> halt condition before exiting test_halt().
>>>
>>> Signed-off-by: Roger Quadros
>>> Reviewed-by: Felipe Balbi
>>
>> Acked-by: Huang Rui
>>
>>> ---
>>> drivers/usb/misc/usbtest.c | 11 ++-
>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
>>> index 6294e1b..300b726 100644
>>> --- a/drivers/usb/misc/usbtest.c
>>> +++ b/drivers/usb/misc/usbtest.c
>>> @@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int
>>> ep, struct urb *urb)
>>> return retval;
>>> }
>>> retval = verify_halted(tdev, ep, urb);
>>> - if (retval < 0)
>>> + if (retval < 0) {
>>> + int ret;
>>> +
>>> + /* clear halt anyways, else further tests will fail */
>>> + ret = usb_clear_halt(urb->dev, urb->pipe);
>>> + if (ret)
>>> + ERROR(tdev, "ep %02x couldn't clear halt, %d\n",
>>> + ep, ret);
>>> +
>>> return retval;
>>> + }
>>>
>>> /* clear halt (tests API + protocol), verify it worked */
>>> retval = usb_clear_halt(urb->dev, urb->pipe);
>>> --
>>> 1.8.3.2
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/118] 3.12.6-stable review
On 12/18/2013 07:27 PM, Greg Kroah-Hartman wrote: On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.12.6 release. There are 118 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Dec 20 21:12:03 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz and the diffstat can be found below. Thanks to a bug on my part, there's now a -rc2 out for people to test with: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc2.gz Note, if you didn't have a build-failure with -rc1 then no need to test -rc2, it's only a specific staging driver that had an issue. Build results are much better: total: 110 pass: 107 skipped: 3 fail: 0 qemu tests still all pass. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] Known exploit detection
On Thu, 12 Dec 2013, vegard.nos...@oracle.com wrote:
> diff --git a/security/exploit.c b/security/exploit.c
> new file mode 100644
> index 000..a732613
> --- /dev/null
> +++ b/security/exploit.c
> @@ -0,0 +1,28 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +void _exploit(const char *id)
> +{
> + /*
> + * This function needs to be super defensive/conservative, since
> + * userspace can easily get to it from several different contexts.
> + * We don't want it to become an attack vector in itself!
> + *
> + * We can assume that we're in process context, but spinlocks may
> + * be held, etc.
Not task_lock(current), though.
> + */
> +
> + struct task_struct *task = current;
> + pid_t pid = task_pid_nr(task);
> + uid_t uid = from_kuid(_user_ns, current_uid());
> + char comm[sizeof(task->comm)];
> +
> + get_task_comm(comm, task);
> +
> + pr_warn_ratelimited("warning: possible %s exploit attempt by pid=%u
> uid=%u comm=%s\n",
> + id, pid, uid, comm);
> +}
> +EXPORT_SYMBOL(_exploit);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/9] Input: pixcir_i2c_ts: Add device tree support
On 12/18/2013 07:39 PM, Dmitry Torokhov wrote:
> Hi Roger,
>
> On Wed, Dec 18, 2013 at 02:51:12PM +0530, Roger Quadros wrote:
>> Provide device tree support and binding information.
>> Change platform data parameters from x/y_max to x/y_size..
>
> I'd rather keep them as they were.
OK.
>
>>
>> Signed-off-by: Roger Quadros
>> Acked-by: Mugunthan V N
>> ---
>> .../bindings/input/touchscreen/pixcir_i2c_ts.txt | 26
>> drivers/input/touchscreen/pixcir_i2c_ts.c | 77
>> --
>> include/linux/input/pixcir_ts.h| 5 +-
>> 3 files changed, 101 insertions(+), 7 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
>> b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
>> new file mode 100644
>> index 000..c0b0b270
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
>> @@ -0,0 +1,26 @@
>> +* Pixcir I2C touchscreen controllers
>> +
>> +Required properties:
>> +- compatible: must be "pixcir,pixcir_ts"
>> +- reg: I2C address of the chip
>> +- interrupts: interrupt to which the chip is connected
>> +- attb-gpio: GPIO connected to the ATTB line of the chip
>> +- x-size: horizontal resolution of touchscreen
>> +- y-size: vertical resolution of touchscreen
>> +
>> +Example:
>> +
>> +i2c@ {
>> +/* ... */
>> +
>> +pixcir_ts@5c {
>> +compatible = "pixcir,pixcir_ts";
>> +reg = <0x5c>;
>> +interrupts = <2 0>;
>> +attb-gpio = < 2 0 2>;
>> +x-size = <800>;
>> +y-size = <600>;
>> +};
>> +
>> +/* ... */
>> +};
>> diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> index 6cc6b36..3a447c9 100644
>> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> @@ -24,6 +24,10 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>> +#include
>>
>> struct pixcir_i2c_ts_data {
>> struct i2c_client *client;
>> @@ -125,15 +129,65 @@ static int pixcir_i2c_ts_resume(struct device *dev)
>> static SIMPLE_DEV_PM_OPS(pixcir_dev_pm_ops,
>> pixcir_i2c_ts_suspend, pixcir_i2c_ts_resume);
>>
>> +#if defined(CONFIG_OF)
>
> #ifdef is preferred for simple conditions.
>
>> +static const struct of_device_id pixcir_of_match[];
>> +
>> +static struct pixcir_ts_platform_data *pixcir_parse_dt(struct device *dev)
>> +{
>> +struct pixcir_ts_platform_data *pdata;
>> +struct device_node *np = dev->of_node;
>> +const struct of_device_id *match;
>> +
>> +match = of_match_device(of_match_ptr(pixcir_of_match), dev);
>> +if (!match)
>> +return ERR_PTR(-EINVAL);
>
> Why do you need an explicit match here?
>
Right, it is not needed here for this patch but used later in patch 6
to get chip specific data. I'll fix this while re-arranging the patches.
>> +
>> +pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> +if (!pdata)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +pdata->gpio_attb = of_get_named_gpio(np, "attb-gpio", 0);
>> +if (!gpio_is_valid(pdata->gpio_attb))
>> +dev_err(dev, "Failed to get ATTB GPIO\n");
>> +
>> +if (of_property_read_u32(np, "x-size", >x_size)) {
>> +dev_err(dev, "Failed to get x-size property\n");
>> +return ERR_PTR(-EINVAL);
>> +}
>> +
>> +if (of_property_read_u32(np, "y-size", >y_size)) {
>> +dev_err(dev, "Failed to get y-size property\n");
>> +return ERR_PTR(-EINVAL);
>> +}
>> +
>> +dev_dbg(dev, "%s: x %d, y %d, gpio %d\n", __func__,
>> +pdata->x_size, pdata->y_size, pdata->gpio_attb);
>> +
>> +return pdata;
>> +}
>> +#else
>> +static struct pixcir_ts_platform_data *pixcir_parse_dt(struct device *dev)
>> +{
>> +return NULL;
>
> This should be
>
> return ERR_PTR(-EINVAL);
>
> since you test it with IS_ERR() later.
OK.
>
>> +}
>> +#endif
>> +
>> static int pixcir_i2c_ts_probe(struct i2c_client *client,
>> const struct i2c_device_id *id)
>> {
>> const struct pixcir_ts_platform_data *pdata = client->dev.platform_data;
>> +struct device *dev = >dev;
>> +struct device_node *np = dev->of_node;
>> struct pixcir_i2c_ts_data *tsdata;
>> struct input_dev *input;
>> int error;
>>
>> -if (!pdata) {
>> +if (np) {
>> +pdata = pixcir_parse_dt(dev);
>> +if (IS_ERR(pdata))
>> +return PTR_ERR(pdata);
>
> We should be favoring kernel-provided platform data if it is pesent even
> if there is dt-data available. This way user can
[PATCH v5 0/3] PCI: allocate 64bit mmio pref
mmio 64 allocation that could help Guo Chao on powerpc mmio allocation. It will try to assign 64 bit resource above 4g at first. And it is based on current pci/next and pci/resource. -v2: update after patch that move device_del down to pci_destroy_dev. add "Try best to allocate pref mmio 64bit above 4G" -v3: refresh and send out after pci_clip_resource() changes, as Bjorn is not happy with attachments. -v4: make pcibios_resource_to_bus take bus directly. -v5: fix non-pref mmio64 allocation problem found by Guo Chao. refresh last three as Bjorn update first two and put them in pci/resource Yinghai Lu (3): PCI: Try to allocate mem64 above 4G at first PCI: Try best to allocate pref mmio 64bit above 4g PCI: Sort pci root bus resources list drivers/pci/bus.c | 43 +++ drivers/pci/setup-bus.c | 138 drivers/pci/setup-res.c | 20 ++- 3 files changed, 144 insertions(+), 57 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] mm, memcg: avoid oom notification when current needs access to memory reserves
On Wed, 18 Dec 2013, Michal Hocko wrote: > > For memory isolation, we'd only want to bypass memcg charges when > > absolutely necessary and it seems like TIF_MEMDIE is the only case where > > that's required. We don't give processes with pending SIGKILLs or those > > in the exit() path access to memory reserves in the page allocator without > > first determining that reclaim can't make any progress for the same reason > > and then we only do so by setting TIF_MEMDIE when calling the oom killer. > > While I do understand arguments about isolation I would also like to be > practical here. How many charges are we talking about? Dozen pages? Much > more? The PF_EXITING bypass is indeed much less concerning than the fatal_signal_pending() bypass. > Besides that all of those should be very short lived because the task > is going to die very soon and so the memory will be freed. > We don't know how much memory is being allocated while fatal_signal_pending() is true before the process can handle the SIGKILL, so this could potentially bypass a significant amount of memory. If we are to have a configuration such as what Tejun recommended for oom handling: _root__ / \ user oom /\ / \ A B a b where the limit of A + B can be greater than the limit of user for overcommit, and the limit of user is the amount of RAM minus whatever is reserved for the oom hierarchy, then significant bypass to the root memcg will cause memcgs in the oom hierarchy to actually not be able to allocate memory from the page allocator. The PF_EXITING bypass is much less concerning because we shouldn't be doing significant memory allocation in the exit() path, but it's also true that neither the PF_EXITING nor the fatal_signal_pending() bypass is required. In Tejun's suggested configuration above, we absolutely do want to reclaim from the user hierarchy before declaring oom and setting TIF_MEMDIE, otherwise the oom hierarchy cannot allocate. > So from my POV I would like to see these heuristics as simple as > possible and placed at very few places. Doing a bypass before charge > - or even after a failed charge before doing reclaim sounds like an easy > enough heuristic without a big risk. It's a very significant risk of depleting memory that is available for oom handling in the suggested configuration. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v5 2/3] PCI: Try best to allocate pref mmio 64bit above 4g
When one of children resources does not support MEM_64, MEM_64 for
bridge get reset, so pull down whole pref resource on the bridge under 4G.
If the bridge support pref mem 64, will only allocate that with pref mem64 to
children that support it.
For children resources if they only support pref mem 32, will allocate them
from non pref mem instead.
If the bridge only support 32bit pref mmio, will still have all children pref
mmio under that.
-v2: Add release bridge res support with bridge mem res for pref_mem children
res.
-v3: refresh and make it can be applied early before for_each_dev_res patchset.
-v4: fix non-pref mmio 64bit support found by Guo Chao.
Signed-off-by: Yinghai Lu
Tested-by: Guo Chao
---
drivers/pci/setup-bus.c | 138
drivers/pci/setup-res.c | 20 ++-
2 files changed, 111 insertions(+), 47 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 138bdd6..b29504f 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -713,12 +713,11 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
bus resource of a given type. Note: we intentionally skip
the bus resources which have already been assigned (that is,
have non-NULL parent resource). */
-static struct resource *find_free_bus_resource(struct pci_bus *bus, unsigned
long type)
+static struct resource *find_free_bus_resource(struct pci_bus *bus,
+unsigned long type_mask, unsigned long type)
{
int i;
struct resource *r;
- unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
- IORESOURCE_PREFETCH;
pci_bus_for_each_resource(bus, r, i) {
if (r == _resource || r == _resource)
@@ -815,7 +814,8 @@ static void pbus_size_io(struct pci_bus *bus,
resource_size_t min_size,
resource_size_t add_size, struct list_head *realloc_head)
{
struct pci_dev *dev;
- struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO);
+ struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO,
+ IORESOURCE_IO);
resource_size_t size = 0, size0 = 0, size1 = 0;
resource_size_t children_add_size = 0;
resource_size_t min_align, align;
@@ -915,15 +915,17 @@ static inline resource_size_t
calculate_mem_align(resource_size_t *aligns,
* guarantees that all child resources fit in this size.
*/
static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
-unsigned long type, resource_size_t min_size,
- resource_size_t add_size,
- struct list_head *realloc_head)
+unsigned long type, unsigned long type2,
+unsigned long type3,
+resource_size_t min_size, resource_size_t add_size,
+struct list_head *realloc_head)
{
struct pci_dev *dev;
resource_size_t min_align, align, size, size0, size1;
resource_size_t aligns[12]; /* Alignments from 1Mb to 2Gb */
int order, max_order;
- struct resource *b_res = find_free_bus_resource(bus, type);
+ struct resource *b_res = find_free_bus_resource(bus,
+mask | IORESOURCE_PREFETCH, type);
unsigned int mem64_mask = 0;
resource_size_t children_add_size = 0;
@@ -944,7 +946,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long
mask,
struct resource *r = >resource[i];
resource_size_t r_size;
- if (r->parent || (r->flags & mask) != type)
+ if (r->parent || ((r->flags & mask) != type &&
+ (r->flags & mask) != type2 &&
+ (r->flags & mask) != type3))
continue;
r_size = resource_size(r);
#ifdef CONFIG_PCI_IOV
@@ -1117,8 +1121,9 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
struct list_head *realloc_head)
{
struct pci_dev *dev;
- unsigned long mask, prefmask;
+ unsigned long mask, prefmask, type2 = 0, type3 = 0;
resource_size_t additional_mem_size = 0, additional_io_size = 0;
+ struct resource *b_res;
list_for_each_entry(dev, >devices, bus_list) {
struct pci_bus *b = dev->subordinate;
@@ -1163,15 +1168,34 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
has already been allocated by arch code, try
non-prefetchable range for both types of PCI memory
resources. */
+ b_res = >self->resource[PCI_BRIDGE_RESOURCES];
mask = IORESOURCE_MEM;
prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-
[PATCH v5 1/3] PCI: Try to allocate mem64 above 4G at first
On system with more pcie cards, we do not have enough range under 4G
to allocate those pci devices.
On 64bit system, we could try to allocate mem64 above 4G at first,
and fall back to below 4g if it can not find any above 4g.
x86 32bit without X86_PAE support will have bottom set to 0, because
resource_size_t is 32bit.
For 32bit kernel that resource_size_t is 64bit when pae is support.
we are safe because iomem_resource is limited to 32bit according to
x86_phys_bits.
-v2: update bottom assigning to make it clear for non-pae support machine.
-v3: Bjorn's change:
use MAX_RESOURCE instead of -1
use start/end instead of bottom/max
for all arch instead of just x86_64
-v4: updated after PCI_MAX_RESOURCE_32 change.
-v5: restore io handling to use PCI_MAX_RESOURCE_32 as limit.
-v6: checking pcibios_resource_to_bus return for every bus res, to decide it
if we need to try high at first.
It supports all arches instead of just x86_64.
-v7: split 4G limit change out to another patch according to Bjorn.
also use pci_clip_resource instead.
-v8: refresh after changes in pci/resource.
Signed-off-by: Yinghai Lu
---
drivers/pci/bus.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 263b90c..1fd0bf8 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -100,6 +100,9 @@ void pci_bus_remove_resources(struct pci_bus *bus)
/* The region that can be mapped by a 32-bit BAR. */
static struct pci_bus_region pci_32_bit = {0, 0x};
+/* The region that can be mapped by a 64-bit BAR above 4G */
+static struct pci_bus_region pci_64_bit = {(resource_size_t)(1ULL<<32),
+ (resource_size_t)(-1ULL)};
/*
* @res contains CPU addresses. Clip it so the corresponding bus addresses
@@ -150,12 +153,12 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct
resource *res,
{
int i, ret = -ENOMEM;
struct resource *r;
- resource_size_t max;
type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
pci_bus_for_each_resource(bus, r, i) {
struct resource avail;
+ int try_again = 0;
if (!r)
continue;
@@ -174,12 +177,19 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct
resource *res,
* Unless this is a 64-bit BAR, we have to clip the
* available space to the part that maps to the region of
* 32-bit bus addresses.
+* If this is a 64-bit BAR, try above 4G first.
*/
avail = *r;
if (!(res->flags & IORESOURCE_MEM_64)) {
pci_clip_resource_to_bus(bus, , _32_bit);
if (!resource_size())
continue;
+ } else {
+ pci_clip_resource_to_bus(bus, , _64_bit);
+ if (!resource_size())
+ avail = *r;
+ else
+ try_again = 1;
}
/*
@@ -188,16 +198,18 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct
resource *res,
* this is an already-configured bridge window, its start
* overrides "min".
*/
- if (avail.start)
- min = avail.start;
-
- max = avail.end;
-
+again:
/* Ok, try it out.. */
- ret = allocate_resource(r, res, size, min, max,
- align, alignf, alignf_data);
+ ret = allocate_resource(r, res, size, avail.start ? : min,
+ avail.end, align, alignf, alignf_data);
if (ret == 0)
break;
+
+ if (try_again) {
+ avail = *r;
+ try_again = 0;
+ goto again;
+ }
}
return ret;
}
--
1.8.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 v5 3/3] PCI: Sort pci root bus resources list
Some x86 systems expose above 4G 64bit mmio in _CRS as non-pref mmio range.
[ 49.415281] PCI host bridge to bus :00
[ 49.419921] pci_bus :00: root bus resource [bus 00-1e]
[ 49.426107] pci_bus :00: root bus resource [io 0x-0x0cf7]
[ 49.433041] pci_bus :00: root bus resource [io 0x1000-0x5fff]
[ 49.440010] pci_bus :00: root bus resource [mem 0x000a-0x000b]
[ 49.447768] pci_bus :00: root bus resource [mem 0xfed8c000-0xfedf]
[ 49.455532] pci_bus :00: root bus resource [mem 0x9000-0x9fffbfff]
[ 49.463259] pci_bus :00: root bus resource [mem
0x3800-0x381f]
During assign unassigned 64bit mmio resource, it will go through
every non-pref mmio for root bus in pci_bus_alloc_resource().
As the loop is with pci_bus_for_each_resource(), and could have chance
to use under 4G mmio range instead of above 4G mmio range if the requested
range is not big enough, even it could handle above 4G 64bit pref mmio.
For root bus, we can order list from high to low in pci_add_resource_offset(),
during creating root bus, it will still keep the same order in final bus
resource list.
pci_acpi_scan_root
==> add_resources
==> pci_add_resource_offset: # Add to temp resources
==> pci_create_root_bus
==> pci_bus_add_resource # add to final bus resources.
After that, we can make sure 64bit pref mmio for pci bridges will be allocated
higest of mmio non-pref, and in this case it is above 4G instead of under 4G.
Signed-off-by: Yinghai Lu
---
drivers/pci/bus.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 1fd0bf8..b8a2370 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -21,7 +21,8 @@
void pci_add_resource_offset(struct list_head *resources, struct resource *res,
resource_size_t offset)
{
- struct pci_host_bridge_window *window;
+ struct pci_host_bridge_window *window, *tmp;
+ struct list_head *n;
window = kzalloc(sizeof(struct pci_host_bridge_window), GFP_KERNEL);
if (!window) {
@@ -31,7 +32,17 @@ void pci_add_resource_offset(struct list_head *resources,
struct resource *res,
window->res = res;
window->offset = offset;
- list_add_tail(>list, resources);
+
+ /* Keep list sorted according to res end */
+ n = resources;
+ list_for_each_entry(tmp, resources, list)
+ if (window->res->end > tmp->res->end) {
+ n = >list;
+ break;
+ }
+
+ /* Insert it just before n */
+ list_add_tail(>list, n);
}
EXPORT_SYMBOL(pci_add_resource_offset);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb: usbtest: Always clear halt else further tests will fail
On Thu, Dec 19, 2013 at 12:01:47PM +0800, Huang Rui wrote:
> On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote:
> > In test_halt() we set an endpoint halt condition and return on halt
> > verification
> > failure, then the enpoint will remain halted and all further tests related
^^^
> > to that enpoint will fail. This is because we don't tackle endpoint halt
> > error condition
^^^
BTW, please fix these typo.
Thanks,
Rui
> > in any of the tests. To avoid that situation, make sure to clear the
> > halt condition before exiting test_halt().
> >
> > Signed-off-by: Roger Quadros
> > Reviewed-by: Felipe Balbi
>
> Acked-by: Huang Rui
>
> > ---
> > drivers/usb/misc/usbtest.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
> > index 6294e1b..300b726 100644
> > --- a/drivers/usb/misc/usbtest.c
> > +++ b/drivers/usb/misc/usbtest.c
> > @@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int
> > ep, struct urb *urb)
> > return retval;
> > }
> > retval = verify_halted(tdev, ep, urb);
> > - if (retval < 0)
> > + if (retval < 0) {
> > + int ret;
> > +
> > + /* clear halt anyways, else further tests will fail */
> > + ret = usb_clear_halt(urb->dev, urb->pipe);
> > + if (ret)
> > + ERROR(tdev, "ep %02x couldn't clear halt, %d\n",
> > + ep, ret);
> > +
> > return retval;
> > + }
> >
> > /* clear halt (tests API + protocol), verify it worked */
> > retval = usb_clear_halt(urb->dev, urb->pipe);
> > --
> > 1.8.3.2
> >
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" 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/
[PATCH v12 4/4] ARM: dts: Exynos5420: Add device nodes for TMU blocks
Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.
This patch adds the device tree nodes to the DT device list.
Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
---
Changes since v11:
changed the secondary clock name to "tmu_triminfo_apbif"
from "tmu_apbif_triminfo"
Changes since previous version:
1. used lables instead of comment lines
2. pass the same clock as trimfo_apbif clock for TMU channel 2
arch/arm/boot/dts/exynos5420.dtsi | 40 +
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index b1fa334..c62cde6 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -402,4 +402,44 @@
clock-names = "gscl";
samsung,power-domain = <_pd>;
};
+
+ tmu_cpu0:tmu@1006 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x1006 0x100>;
+ interrupts = <0 65 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ tmu_cpu1:tmu@10064000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x10064000 0x100>;
+ interrupts = <0 183 0>;
+ clocks = < 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ tmu_cpu2:tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = < 318>, < 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ tmu_cpu3:tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = < 318>, < 319>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ tmu_gpu:tmu@100a {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = < 319>, < 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] mm/rmap: fix BUG at rmap_walk
On Thu, Dec 19, 2013 at 02:55:10PM +0900, Joonsoo Kim wrote: > On Thu, Dec 19, 2013 at 01:41:55PM +0800, Wanpeng Li wrote: > > This bug is introduced by commit 37f093cdf(mm/rmap: use rmap_walk() in > > page_referenced()). page_get_anon_vma() called in page_referenced_anon() > > will lock and increase the refcount of anon_vma. PageLocked is not required > > by page_referenced_anon() and there is not any assertion before, commit > > 37f093cdf introduced this extra BUG_ON() checking for anon page by mistake. > > This patch fix it by remove rmap_walk()'s VM_BUG_ON() and comment reason > > why > > the page must be locked for rmap_walk_ksm() and rmap_walk_file(). FYI. See following link to get more information. https://lkml.org/lkml/2004/7/12/241 Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v12 2/4] thermal: samsung: change base_common to more meaningful base_second
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Tomasz Figa
---
Changes since v11:
Added Reviewed by Tomasz
Changes since v10:
Documentation rephrased as per comments from Tomasz Figa
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 14 +++---
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c|2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..a1aa602 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
- belongs to each instance of TMU and second set belongs to common TMU
- registers.
+ belongs to register set of TMU instance and second set belongs to
+ registers shared with the TMU instance.
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index c493245..bbd0fc3 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
* @id: identifier of the one instance of the TMU controller.
* @pdata: pointer to the tmu platform/configuration data
* @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
* @irq: irq number of the TMU controller.
* @soc: id of the SOC type.
* @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
- void __iomem *base_common;
+ void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
- writel(0, data->base_common + reg->tmu_pmin);
+ writel(0, data->base_second + reg->tmu_pmin);
out:
clk_disable(data->clk);
mutex_unlock(>lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
- val_type = readl(data->base_common + reg->tmu_irqstatus);
+ val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
* Check if the TMU shares some registers and then try to map the
* memory of common registers.
*/
- if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+ if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
if (of_address_to_resource(pdev->dev.of_node, 1, )) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
- data->base_common = devm_ioremap(>dev, res.start,
+ data->base_second = devm_ioremap(>dev, res.start,
resource_size());
- if (!data->base_common) {
+ if (!data->base_second) {
dev_err(>dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 980859a..0d6b32f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
* state(active/idle) can be checked.
* TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
* sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This
[PATCH v12 3/4] thermal: samsung: Add TMU support for Exynos5420 SoCs
Exynos5420 has 5 TMU channels, the TRIMINFO register is
misplaced for TMU channels 2, 3 and 4
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2
This patch
1 Adds the neccessary register changes and arch information
to support Exynos5420 SoCs.
2. Handles the gate clock for misplaced TRIMINFO register
3. Updates the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
---
Changes since v11:
1. Added description for clocks in the Documentation
2. corrected the clock name in clk_get() function as per description
Changes since v10:
1. using renamed compatible "samsung,exynos5420-tmu-ext-triminfo"
and passing same clock as triminfo_apbif clock for channel 2
2. removed the "exynos5420-tmu-triminfo-clk" compatible
.../devicetree/bindings/thermal/exynos-thermal.txt | 45 -
drivers/thermal/samsung/exynos_tmu.c | 52 +-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 99
drivers/thermal/samsung/exynos_tmu_data.h |8 ++
5 files changed, 200 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index a1aa602..79c4055 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,9 @@
"samsung,exynos4412-tmu"
"samsung,exynos4210-tmu"
"samsung,exynos5250-tmu"
+ "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
+ "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
+ Exynos5420 (Must pass triminfo base and triminfo clock)
"samsung,exynos5440-tmu"
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,9 +16,24 @@
interrupt related then 2 set of register has to supplied. First set
belongs to register set of TMU instance and second set belongs to
registers shared with the TMU instance.
+
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+ Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced
+ register, also provide clock to access that base.
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
- interrupts : Should contain interrupt for thermal system
-- clocks : The main clock for TMU device
+- clocks : The main clocks for TMU device
+ -- 1. operational clock for TMU channel
+ -- 2. optional clock to access the shared registers of TMU channel
- clock-names : Thermal system clock name
+ -- "tmu_apbif" operational clock for current TMU channel
+ -- "tmu_triminfo_apbif" clock to access the shared triminfo register
+ for current TMU channel
- vtmu-supply: This entry is optional and provides the regulator node supplying
voltage to TMU. If needed this entry can be placed inside
board/platform specific dts file.
@@ -43,6 +61,31 @@ Example 2):
clock-names = "tmu_apbif";
};
+Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+ tmu_cpu2: tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = < 318>, < 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ tmu_cpu3: tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = < 318>, < 319>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ tmu_gpu: tmu@100a {
+ compatible = "samsung,exynos5420-tmu-ext-triminfo";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = < 319>, < 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in "aliases" node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index bbd0fc3..3246ace 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++
[PATCH v12 1/4] thermal: samsung: replace inten_ bit fields with intclr_
This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
to configure intclr related registers.
Description of H/W:
The offset for the bits in the CLEAR register are not consistent across TMU
modules in Exynso5250, 5420 and 5440.
On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.
On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.
On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0
Signed-off-by: Naveen Krishna Chatradhi
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Tomasz Figa
---
Changes since v11:
Added Reviewed by Tomasz
Changes since v10:
None
drivers/thermal/samsung/exynos_tmu.c |6 +++---
drivers/thermal/samsung/exynos_tmu.h | 16
drivers/thermal/samsung/exynos_tmu_data.c | 18 +-
drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..c493245 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -237,7 +237,7 @@ skip_calib_data:
writeb(pdata->trigger_levels[i], data->base +
reg->threshold_th0 + i * sizeof(reg->threshold_th0));
- writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
+ writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
for (i = 0;
@@ -264,8 +264,8 @@ skip_calib_data:
writel(falling_threshold,
data->base + reg->threshold_th1);
- writel((reg->inten_rise_mask << reg->inten_rise_shift) |
- (reg->inten_fall_mask << reg->inten_fall_shift),
+ writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
+ (reg->intclr_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..980859a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -122,10 +122,6 @@ enum soc_type {
* @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
* @tmu_inten: register containing the different threshold interrupt
enable bits.
- * @inten_rise_shift: shift bits of all rising interrupt bits.
- * @inten_rise_mask: mask bits of all rising interrupt bits.
- * @inten_fall_shift: shift bits of all rising interrupt bits.
- * @inten_fall_mask: mask bits of all rising interrupt bits.
* @inten_rise0_shift: shift bits of rising 0 interrupt bits.
* @inten_rise1_shift: shift bits of rising 1 interrupt bits.
* @inten_rise2_shift: shift bits of rising 2 interrupt bits.
@@ -136,6 +132,10 @@ enum soc_type {
* @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
+ * @intclr_rise_shift: shift bits of all rising interrupt bits.
+ * @intclr_rise_mask: mask bits of all rising interrupt bits.
+ * @intclr_fall_mask: mask bits of all rising interrupt bits.
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -191,10 +191,6 @@ struct exynos_tmu_registers {
u32 threshold_th3_l0_shift;
u32 tmu_inten;
- u32 inten_rise_shift;
- u32 inten_rise_mask;
- u32 inten_fall_shift;
- u32 inten_fall_mask;
u32 inten_rise0_shift;
u32 inten_rise1_shift;
u32 inten_rise2_shift;
@@ -207,6 +203,10 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
+ u32 intclr_rise_shift;
+ u32 intclr_fall_mask;
+ u32 intclr_rise_mask;
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 073c292..7cdb04e 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -40,13 +40,13 @@ static
[RFC PATCH] ixgbe: acquire RCU read lock when calling netdev_for_each_all_upper_dev_rcu()
According to documentation for netdev_for_each_all_upper_dev_rcu(),
caller should take RCU read lock, otherwise it will trigger following
warnings. The simplest fix is to protect with rcu_read_lock()/
rcu_read_unlock(). And this solutions passes basic tests.
Otherwise we may need to introduce netdev_for_each_all_upper_dev()
as netdev_lower_get_next_private(), which assumes the caller has
gained the lock to protect the list.
Signed-off-by: Jiang Liu
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cc06854..da72a5f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4336,6 +4336,7 @@ static void ixgbe_configure_dfwd(struct ixgbe_adapter
*adapter)
struct list_head *iter;
int err;
+ rcu_read_lock();
netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
if (netif_is_macvlan(upper)) {
struct macvlan_dev *dfwd = netdev_priv(upper);
@@ -4348,6 +4349,7 @@ static void ixgbe_configure_dfwd(struct ixgbe_adapter
*adapter)
}
}
}
+ rcu_read_unlock();
}
static void ixgbe_configure(struct ixgbe_adapter *adapter)
@@ -4601,6 +4603,7 @@ static void ixgbe_up_complete(struct ixgbe_adapter
*adapter)
netif_tx_start_all_queues(adapter->netdev);
/* enable any upper devices */
+ rcu_read_lock();
netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
if (netif_is_macvlan(upper)) {
struct macvlan_dev *vlan = netdev_priv(upper);
@@ -4609,6 +4612,7 @@ static void ixgbe_up_complete(struct ixgbe_adapter
*adapter)
netif_tx_start_all_queues(upper);
}
}
+ rcu_read_unlock();
/* bring the link up in the watchdog, this could race with our first
* link up interrupt but shouldn't be a problem */
@@ -4803,6 +4807,7 @@ void ixgbe_down(struct ixgbe_adapter *adapter)
netif_tx_disable(netdev);
/* disable any upper devices */
+ rcu_read_lock();
netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
if (netif_is_macvlan(upper)) {
struct macvlan_dev *vlan = netdev_priv(upper);
@@ -4814,6 +4819,7 @@ void ixgbe_down(struct ixgbe_adapter *adapter)
}
}
}
+ rcu_read_unlock();
ixgbe_irq_disable(adapter);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] Input: pixcir_i2c_ts: Initialize interrupt mode and power mode
On 12/18/2013 07:44 PM, Dmitry Torokhov wrote:
> On Wed, Dec 18, 2013 at 02:51:14PM +0530, Roger Quadros wrote:
>> +
>> +static int pixcir_stop(struct pixcir_i2c_ts_data *ts)
>> +{
>> +struct device *dev = >client->dev;
>> +int ret;
>> +
>> +/* disable interrupt generation */
>> +ret = pixcir_int_enable(ts, 0);
>> +if (ret) {
>> +dev_err(dev, "Failed to disable interrupt generation\n");
>> +return ret;
>> +}
>> +
>> +disable_irq(ts->client->irq);
>
> Why do you need to disable IRQ? If you disable interrupt generation in
> the chip I think you only need to call synchronize_irq() to make sure
> it's completed if it happens to be running. Also you need to move the
> code:
Agreed, no need to call disable_irq().
>
> tsdata->exiting = true;
> mb();
>
> here from pixcir_i2c_ts_remove() to make sure handler exits promptly.
>
> You will also need to reset tsdata->exiting in your start method.
>
OK.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] cpufreq: tegra: Re-model Tegra cpufreq driver
On 12/19/2013 01:29 PM, Viresh Kumar wrote: On 19 December 2013 10:56, bilhuang wrote: I'm not sure virtual regulator for CPU is a good idea, in addition to that, we don't have a single SoC OPP table, we need several which are speedo-id and process-id dependant, but generic cpufreq-cpu0 is assuming there is only one statically Can't that be handled via DT ? I don't think it can be handled via DT unless we separate DTB according to different CPU speedo/process-id but that is not a good idea. for some SoC the frequency table is not fixed, they are created at runtime combining our fast and slow CPU frequency table and dvfs table. So I'm really not sure is it worth adding so many tweaks in order to use the generic cpufreq-cpu0 driver. Hmm, maybe I got confused because I don't have a clear picture in my mind. It might be better to go ahead with your implementation for now and after everything is set, we can choose to use cpufreq-cpu0 if it is worth it. This makes more sense to me, thanks. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] mm/rmap: fix BUG at rmap_walk
On Thu, Dec 19, 2013 at 01:41:55PM +0800, Wanpeng Li wrote: > This bug is introduced by commit 37f093cdf(mm/rmap: use rmap_walk() in > page_referenced()). page_get_anon_vma() called in page_referenced_anon() > will lock and increase the refcount of anon_vma. PageLocked is not required > by page_referenced_anon() and there is not any assertion before, commit > 37f093cdf introduced this extra BUG_ON() checking for anon page by mistake. > This patch fix it by remove rmap_walk()'s VM_BUG_ON() and comment reason why > the page must be locked for rmap_walk_ksm() and rmap_walk_file(). > > [ 588.698828] kernel BUG at mm/rmap.c:1663! > [ 588.699380] invalid opcode: [#2] PREEMPT SMP DEBUG_PAGEALLOC > [ 588.700347] Dumping ftrace buffer: > [ 588.701186](ftrace buffer empty) > [ 588.702062] Modules linked in: > [ 588.702759] CPU: 0 PID: 4647 Comm: kswapd0 Tainted: G D W > 3.13.0-rc4-next-20131218-sasha-00012-g1962367-dirty #4155 > [ 588.704330] task: 880062bcb000 ti: 88006245 task.ti: > 88006245 > [ 588.705507] RIP: 0010:[] [] > rmap_walk+0x10/0x50 > [ 588.706800] RSP: 0018:8800624518d8 EFLAGS: 00010246 > [ 588.707515] RAX: 000f80080048 RBX: ea0227c0 RCX: > > [ 588.707515] RDX: RSI: 8800624518e8 RDI: > ea0227c0 > [ 588.707515] RBP: 8800624518d8 R08: 8800624518e8 R09: > > [ 588.707515] R10: R11: R12: > 8800624519d8 > [ 588.707515] R13: R14: ea0227e0 R15: > > [ 588.707515] FS: () GS:88006520() > knlGS: > [ 588.707515] CS: 0010 DS: ES: CR0: 8005003b > [ 588.707515] CR2: 7fec40cbe0f8 CR3: c2382000 CR4: > 06f0 > [ 588.707515] Stack: > [ 588.707515] 880062451958 81289f4b 880062451918 > 81289f80 > [ 588.707515] 8128af60 > > [ 588.707515] 0024 > 0286 > [ 588.707515] Call Trace: > [ 588.707515] [] page_referenced+0xcb/0x100 > [ 588.707515] [] ? page_referenced+0x100/0x100 > [ 588.707515] [] ? invalid_page_referenced_vma+0x170/0x170 > [ 588.707515] [] shrink_active_list+0x212/0x330 > [ 588.707515] [] ? inactive_file_is_low+0x33/0x50 > [ 588.707515] [] shrink_lruvec+0x2d5/0x300 > [ 588.707515] [] shrink_zone+0x96/0x1e0 > [ 588.707515] [] kswapd_shrink_zone+0xf6/0x1c0 > [ 588.707515] [] balance_pgdat+0x373/0x550 > [ 588.707515] [] kswapd+0x2f3/0x350 > [ 588.707515] [] ? > perf_trace_mm_vmscan_lru_isolate_template+0x120/0x120 > [ 588.707515] [] kthread+0x105/0x110 > [ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30 > [ 588.707515] [] ret_from_fork+0x7c/0xb0 > [ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30 > [ 588.707515] Code: c0 48 83 c4 18 89 d0 5b 41 5c 41 5d 41 5e 41 5f c9 c3 66 > 0f 1f 84 > 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 48 8b 07 a8 01 75 10 <0f> 0b 66 0f > 1f 44 00 0 > 0 eb fe 66 0f 1f 44 00 00 f6 47 08 01 74 > [ 588.707515] RIP [] rmap_walk+0x10/0x50 > [ 588.707515] RSP > > Reported-by: Sasha Levin > Signed-off-by: Wanpeng Li Reviewed-by: Joonsoo Kim Thanks for all relevant people. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] Input: pixcir_i2c_ts: Get rid of pdata->attb_read_val()
On 12/18/2013 07:50 PM, Dmitry Torokhov wrote:
> On Wed, Dec 18, 2013 at 02:51:16PM +0530, Roger Quadros wrote:
>> Get rid of the attb_read_val() platform hook. Instead,
>> read the ATTB gpio directly from the driver.
>>
>> Fail if valid ATTB gpio is not provided by patform data.
>
> Do you also need to define polarity?
>
In patch 3, in pixcir_start(), we explicitly configure the GPIO output
polarity as /* LEVEL_TOUCH interrupt with active low polarity */
So I don't think we need to define polarity.
cheers,
-roger
>>
>> Signed-off-by: Roger Quadros
>> Acked-by: Mugunthan V N
>> ---
>> drivers/input/touchscreen/pixcir_i2c_ts.c | 19 +--
>> include/linux/input/pixcir_ts.h | 1 -
>> 2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> index 3370fd9..a783d94 100644
>> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> @@ -91,11 +91,12 @@ static void pixcir_ts_poscheck(struct pixcir_i2c_ts_data
>> *data)
>> static irqreturn_t pixcir_ts_isr(int irq, void *dev_id)
>> {
>> struct pixcir_i2c_ts_data *tsdata = dev_id;
>> +const struct pixcir_ts_platform_data *pdata = tsdata->chip;
>>
>> while (!tsdata->exiting) {
>> pixcir_ts_poscheck(tsdata);
>>
>> -if (tsdata->chip->attb_read_val())
>> +if (gpio_get_value(pdata->gpio_attb))
>> break;
>>
>> msleep(20);
>> @@ -301,8 +302,10 @@ static struct pixcir_ts_platform_data
>> *pixcir_parse_dt(struct device *dev)
>> return ERR_PTR(-ENOMEM);
>>
>> pdata->gpio_attb = of_get_named_gpio(np, "attb-gpio", 0);
>> -if (!gpio_is_valid(pdata->gpio_attb))
>> +if (!gpio_is_valid(pdata->gpio_attb)) {
>> dev_err(dev, "Failed to get ATTB GPIO\n");
>> +return ERR_PTR(-EINVAL);
>> +}
>>
>> if (of_property_read_u32(np, "x-size", >x_size)) {
>> dev_err(dev, "Failed to get x-size property\n");
>> @@ -344,6 +347,11 @@ static int pixcir_i2c_ts_probe(struct i2c_client
>> *client,
>> } else if (!pdata) {
>> dev_err(>dev, "platform data not defined\n");
>> return -EINVAL;
>> +} else {
>> +if (!gpio_is_valid(pdata->gpio_attb)) {
>> +dev_err(dev, "Invalid gpio_attb in pdata\n");
>> +return -EINVAL;
>> +}
>> }
>>
>> tsdata = devm_kzalloc(dev, sizeof(*tsdata), GFP_KERNEL);
>> @@ -380,6 +388,13 @@ static int pixcir_i2c_ts_probe(struct i2c_client
>> *client,
>>
>> input_set_drvdata(input, tsdata);
>>
>> +error = devm_gpio_request_one(dev, pdata->gpio_attb,
>> +GPIOF_DIR_IN, "pixcir_i2c_attb");
>> +if (error) {
>> +dev_err(dev, "Failed to request ATTB gpio\n");
>> +return error;
>> +}
>> +
>> error = devm_request_threaded_irq(dev, client->irq, NULL, pixcir_ts_isr,
>> IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> client->name, tsdata);
>> diff --git a/include/linux/input/pixcir_ts.h
>> b/include/linux/input/pixcir_ts.h
>> index f17c192..88ffdb50 100644
>> --- a/include/linux/input/pixcir_ts.h
>> +++ b/include/linux/input/pixcir_ts.h
>> @@ -44,7 +44,6 @@ enum pixcir_int_mode {
>> #define PIXCIR_INT_POL_HIGH (1UL << 2)
>>
>> struct pixcir_ts_platform_data {
>> -int (*attb_read_val)(void);
>> unsigned int x_size;/* X axis resolution */
>> unsigned int y_size;/* Y axis resolution */
>> int gpio_attb; /* GPIO connected to ATTB line */
>> --
>> 1.8.3.2
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 8/9] phy: add Broadcom Kona USB2 PHY driver
Hi Felipe,
On Wednesday 18 December 2013 09:55 PM, Felipe Balbi wrote:
> On Tue, Dec 17, 2013 at 02:42:35PM -0500, Matt Porter wrote:
>> Add a driver for the internal Broadcom Kona USB 2.0 PHY found
>> on the BCM281xx family of SoCs.
>>
>> Signed-off-by: Matt Porter
>
> Kishon, are you ok with this driver ?
yeah. Since this patch touches phy/Kconfig (and Makefile) and there is one more
PHY driver to be merged that also modifies Kconfig there might be conflicts. So
thought I should be taking this patch?
>
>> +static int bcm_kona_usb2_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = >dev;
>> +struct bcm_kona_usb *phy;
>> +struct resource *res;
>> +struct phy *gphy;
>> +struct phy_provider *phy_provider;
>> +
>> +phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
>> +if (!phy)
>> +return -ENOMEM;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +phy->regs = devm_ioremap_resource(>dev, res);
>> +if (IS_ERR(phy->regs))
>> +return PTR_ERR(phy->regs);
>> +
>> +platform_set_drvdata(pdev, phy);
>> +
>> +phy_provider = devm_of_phy_provider_register(dev,
>> +of_phy_simple_xlate);
>> +if (IS_ERR(phy_provider))
>> +return PTR_ERR(phy_provider);
>> +
>> +gphy = devm_phy_create(dev, , NULL);
>> +if (IS_ERR(gphy))
>> +return PTR_ERR(gphy);
>> +
>> +/* The Kona PHY supports an 8-bit wide UTMI interface */
>> +phy_set_bus_width(gphy, 8);
>> +
>> +phy_set_drvdata(gphy, phy);
>
> I think this set_drvdata() should be done before registering the
> provider, no ?
hmm, right.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 19
Hi all, Changes since 20131218: The powerpc tree still had its build failure for which I applied a supplied patch. The pm tree lost its build failure. The net-next tree gained a new build failure so I used the version from next-20131217. The drm tree gained conflicts against Linus' tree. The mmc tree still had its build failure so I used the version from next-20131212. The modules tree gained a conflict against Linus' tree. The usb-gadget still had its build failure so I used the version from next-20131206. The akpm-current tree still had its build failures for which I applied patches. Non-merge commits (relative to Linus' tree): 4797 5000 files changed, 226604 insertions(+), 126857 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" as mentioned in the FAQ on the wiki (see below). 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 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 209 trees (counting Linus' and 29 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a36c160cbbf3 Merge tag 'usb-3.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (319e2e3f63c3 Linux 3.13-rc4) Merging arm-current/fixes (b713aa0b1501 ARM: fix asm/memory.h build error) Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (803c2d2f84da powerpc/powernv: Fix OPAL LPC access in Little Endian) Merging sparc/master (1de425c7b271 sparc64: Fix build regression) Merging net/master (4263c86dca51 dm9601: work around tx fifo sync issue on dm962x) Merging ipsec/master (239c78db9c41 net: clear local_df when passing skb between namespaces) Merging sound-current/for-linus (3a6c5d8ad0a9 ALSA: hda - Add Dell headset detection quirk for one more laptop model) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (b7e047358449 Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) Merging driver-core.current/driver-core-linus (a8b14744429f sysfs: give different locking key to regular and bin files) Merging tty.current/tty-linus (c2db11eca089 tty: xuartps: Properly guard sysrq specific code) Merging usb.current/usb-linus (fb5f1834c322 usb: ohci-at91: fix irq and iomem resource retrieval) Merging staging.current/staging-linus (fd6040ed57d8 imx-drm: imx-drm-core: improve safety of imx_drm_add_crtc()) Merging char-misc.current/char-misc-linus (319e2e3f63c3 Linux 3.13-rc4) Merging input-current/for-linus (2a4d81547b88 Input: define KEY_WWAN for Wireless WAN) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (389a5390583a crypto: scatterwalk - Use sg_chain_ptr on chain entries) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99
Re: [PATCH 7/9] Input: pixcir_i2c_ts: Implement Type B Multi Touch reporting
Hi Dmitry,
On 12/18/2013 07:48 PM, Dmitry Torokhov wrote:
> On Wed, Dec 18, 2013 at 02:51:18PM +0530, Roger Quadros wrote:
>> Some pixcir controllers e.g. tangoC family report finger IDs with
>> the co-ordinates and are more suitable for Type-B MT protocol.
>>
>> Signed-off-by: Roger Quadros
>> Acked-by: Mugunthan V N
>> ---
>> drivers/input/touchscreen/pixcir_i2c_ts.c | 202
>> +++---
>> 1 file changed, 155 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> index ff68246..9e14415 100644
>> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> @@ -23,84 +23,173 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> +#define MAX_FINGERS 5 /* Maximum supported by the driver */
>> +
>> struct pixcir_i2c_ts_data {
>> struct i2c_client *client;
>> struct input_dev *input;
>> const struct pixcir_ts_platform_data *pdata;
>> bool exiting;
>> +u8 max_fingers; /* Maximum supported by the chip */
>> };
>>
>> -static void pixcir_ts_poscheck(struct pixcir_i2c_ts_data *data)
>> +static void pixcir_ts_typea_report(struct pixcir_i2c_ts_data *tsdata)
>
> Hmm, I do not think we should keep Type A reports if we can do Type B.
> The protocols are not new and userspace should be able to handle MT-B by
> now.
>
It seems the controller the original driver was written for does not report
touch ID and just reports 2 touch co-ordinates. I'm not sure how this fits into
Type B reporting model.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: remove CONFIG_COMMON_CLK_DEBUG
Populate ${DEBUGS_MOUNT_POINT}/clk if CONFIG_DEBUG_FS is set. This
eliminates the extra (annoying) step of enabling the config option
manually.
Signed-off-by: Mike Turquette
---
drivers/clk/Kconfig | 10 --
drivers/clk/clk.c | 2 +-
include/linux/clk-private.h | 2 +-
3 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 3089f05..407cffb 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -23,16 +23,6 @@ config COMMON_CLK
menu "Common Clock Framework"
depends on COMMON_CLK
-config COMMON_CLK_DEBUG
- bool "DebugFS representation of clock tree"
- select DEBUG_FS
- ---help---
- Creates a directory hierarchy in debugfs for visualizing the clk
- tree structure. Each directory contains read-only members
- that export information specific to that clk node: clk_rate,
- clk_flags, clk_prepare_count, clk_enable_count &
- clk_notifier_count.
-
config COMMON_CLK_WM831X
tristate "Clock driver for WM831x/2x PMICs"
depends on MFD_WM831X
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8312736..41e46df 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -92,7 +92,7 @@ static void clk_enable_unlock(unsigned long flags)
/***debugfs support***/
-#ifdef CONFIG_COMMON_CLK_DEBUG
+#ifdef CONFIG_DEBUG_FS
#include
static struct dentry *rootdir;
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 8138c94..98f8614 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -44,7 +44,7 @@ struct clk {
struct hlist_head children;
struct hlist_node child_node;
unsigned intnotifier_count;
-#ifdef CONFIG_COMMON_CLK_DEBUG
+#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
#endif
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] mm/rmap: fix BUG at rmap_walk
This bug is introduced by commit 37f093cdf(mm/rmap: use rmap_walk() in
page_referenced()). page_get_anon_vma() called in page_referenced_anon()
will lock and increase the refcount of anon_vma. PageLocked is not required
by page_referenced_anon() and there is not any assertion before, commit
37f093cdf introduced this extra BUG_ON() checking for anon page by mistake.
This patch fix it by remove rmap_walk()'s VM_BUG_ON() and comment reason why
the page must be locked for rmap_walk_ksm() and rmap_walk_file().
[ 588.698828] kernel BUG at mm/rmap.c:1663!
[ 588.699380] invalid opcode: [#2] PREEMPT SMP DEBUG_PAGEALLOC
[ 588.700347] Dumping ftrace buffer:
[ 588.701186](ftrace buffer empty)
[ 588.702062] Modules linked in:
[ 588.702759] CPU: 0 PID: 4647 Comm: kswapd0 Tainted: G D W
3.13.0-rc4-next-20131218-sasha-00012-g1962367-dirty #4155
[ 588.704330] task: 880062bcb000 ti: 88006245 task.ti:
88006245
[ 588.705507] RIP: 0010:[] []
rmap_walk+0x10/0x50
[ 588.706800] RSP: 0018:8800624518d8 EFLAGS: 00010246
[ 588.707515] RAX: 000f80080048 RBX: ea0227c0 RCX:
[ 588.707515] RDX: RSI: 8800624518e8 RDI: ea0227c0
[ 588.707515] RBP: 8800624518d8 R08: 8800624518e8 R09:
[ 588.707515] R10: R11: R12: 8800624519d8
[ 588.707515] R13: R14: ea0227e0 R15:
[ 588.707515] FS: () GS:88006520()
knlGS:
[ 588.707515] CS: 0010 DS: ES: CR0: 8005003b
[ 588.707515] CR2: 7fec40cbe0f8 CR3: c2382000 CR4: 06f0
[ 588.707515] Stack:
[ 588.707515] 880062451958 81289f4b 880062451918
81289f80
[ 588.707515] 8128af60
[ 588.707515] 0024
0286
[ 588.707515] Call Trace:
[ 588.707515] [] page_referenced+0xcb/0x100
[ 588.707515] [] ? page_referenced+0x100/0x100
[ 588.707515] [] ? invalid_page_referenced_vma+0x170/0x170
[ 588.707515] [] shrink_active_list+0x212/0x330
[ 588.707515] [] ? inactive_file_is_low+0x33/0x50
[ 588.707515] [] shrink_lruvec+0x2d5/0x300
[ 588.707515] [] shrink_zone+0x96/0x1e0
[ 588.707515] [] kswapd_shrink_zone+0xf6/0x1c0
[ 588.707515] [] balance_pgdat+0x373/0x550
[ 588.707515] [] kswapd+0x2f3/0x350
[ 588.707515] [] ?
perf_trace_mm_vmscan_lru_isolate_template+0x120/0x120
[ 588.707515] [] kthread+0x105/0x110
[ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30
[ 588.707515] [] ret_from_fork+0x7c/0xb0
[ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30
[ 588.707515] Code: c0 48 83 c4 18 89 d0 5b 41 5c 41 5d 41 5e 41 5f c9 c3 66
0f 1f 84
00 00 00 00 00 55 48 89 e5 66 66 66 66 90 48 8b 07 a8 01 75 10 <0f> 0b 66 0f 1f
44 00 0
0 eb fe 66 0f 1f 44 00 00 f6 47 08 01 74
[ 588.707515] RIP [] rmap_walk+0x10/0x50
[ 588.707515] RSP
Reported-by: Sasha Levin
Signed-off-by: Wanpeng Li
---
mm/ksm.c | 5 +
mm/rmap.c | 10 --
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/mm/ksm.c b/mm/ksm.c
index c9a28dd..76d96df 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1899,6 +1899,11 @@ int rmap_walk_ksm(struct page *page, struct
rmap_walk_control *rwc)
int search_new_forks = 0;
VM_BUG_ON(!PageKsm(page));
+
+ /*
+* Rely on the page lock to protect against concurrent modifications
+* to that page's node of the stable tree.
+*/
VM_BUG_ON(!PageLocked(page));
stable_node = page_stable_node(page);
diff --git a/mm/rmap.c b/mm/rmap.c
index d792e71..a0a199d 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1629,6 +1629,14 @@ static int rmap_walk_file(struct page *page, struct
rmap_walk_control *rwc)
struct vm_area_struct *vma;
int ret = SWAP_AGAIN;
+ /*
+* The page lock not only makes sure that page->mapping cannot
+* suddenly be NULLified by truncation, it makes sure that the
+* structure at mapping cannot be freed and reused yet,
+* so we can safely take mapping->i_mmap_mutex.
+*/
+ VM_BUG_ON(!PageLocked(page));
+
if (!mapping)
return ret;
mutex_lock(>i_mmap_mutex);
@@ -1660,8 +1668,6 @@ done:
int rmap_walk(struct page *page, struct rmap_walk_control *rwc)
{
- VM_BUG_ON(!PageLocked(page));
-
if (unlikely(PageKsm(page)))
return rmap_walk_ksm(page, rwc);
else if (PageAnon(page))
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ext4: crash in ext4_superblock_csum_set
Hi! While debugging some kernel stuff, I got a series crashes and got my root FS broken, this happens, no big deal. But once I got a file system so damaged so EXT4 driver crashed on mount, as below. The broken kernel is quite old and the issue might have been fixed already but I am still sending it just for the case. Thanks! Kernel 3.10.0-rc2, gcc version 4.7.3, POWER7 machine. Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0201280 cpu 0x12: Vector: 300 (Data Access) at [c01f6cd96b20] pc: c0201280: .ext4_superblock_csum+0x14/0x70 lr: c0201fbc: .ext4_superblock_csum_set+0x28/0x34 sp: c01f6cd96da0 msr: 90009032 dar: 0 dsisr: 4000 current = 0xc01f6bc5 paca= 0xcffe7f00 softe: 0irq_happened: 0x08 pid = 5222, comm = mount enter ? for help [c01f6cd96e30] c0201fbc .ext4_superblock_csum_set+0x28/0x34 [c01f6cd96eb0] c0202644 .ext4_commit_super+0x1f0/0x270 [c01f6cd96f70] c0203440 .ext4_error_inode+0x60/0xf0 [c01f6cd97030] c01f2dbc .__check_block_validity.constprop.53+0x64/0x7c [c01f6cd970c0] c01f31e0 .ext4_map_blocks+0x1d4/0x400 [c01f6cd971a0] c01f4ac0 ._ext4_get_block+0xcc/0x174 [c01f6cd97260] c015c6e0 .generic_block_bmap+0x50/0x68 [c01f6cd97340] c01f233c .ext4_bmap+0x94/0x10c [c01f6cd973d0] c01488a4 .bmap+0x34/0x54 [c01f6cd97440] c023a3d0 .jbd2_journal_bmap+0x28/0xa8 [c01f6cd974d0] c02356b0 .jread+0x50/0x24c [c01f6cd975e0] c0235ccc .do_one_pass+0x380/0x9f8 [c01f6cd97740] c02363c4 .jbd2_journal_recover+0x80/0xf0 [c01f6cd977e0] c023a1c0 .jbd2_journal_load+0x36c/0x388 [c01f6cd978b0] c0206890 .ext4_fill_super+0x1cd8/0x2968 [c01f6cd97a00] c013375c .mount_bdev+0x174/0x1f8 [c01f6cd97ad0] c0200824 .ext4_mount+0x18/0x2c [c01f6cd97b40] c0134284 .mount_fs+0x28/0xc4 [c01f6cd97bd0] c014e964 .vfs_kern_mount+0x54/0xe8 [c01f6cd97c80] c0150f80 .do_mount+0x804/0x930 [c01f6cd97d70] c017af74 .compat_sys_mount+0x1d8/0x220 [c01f6cd97e30] c0009ca4 syscall_exit+0x0/0x98 --- Exception: c01 (System Call) at f7f64ca4 SP (ff9374d0) is in userspace 12:mon> -- Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/16] ARM: support for ICP DAS LP-8x4x (with dts)
On Wednesday 18 December 2013, Sergei Ianovich wrote: > > You would still be able to boot a kernel with an old dts file on a new > > kernel if it just contains a "simple-bus" node here, as long as it doesn't > > need any boot-time setup at the bus controller. We can change the dts > > file later if we need to add this functionality, which would break booting > > old kernels with the new dts files, which isn't much of a problem in > > general. > > It should actually only break old kernels which require new > functionally. Otherwise, dts can have > > compatible = "marvell,pxa-extbus", "simple-bus"; > > and an older kernel will be happy with "simple-bus". Please correct me > if I'm wrong. This would work only if we can probe the devices behind the external bus controller before the controller itsef has been set up, since the initialization order can depend on a number of things but not the bus hierarchy. It will also work if the code setting up the bus controller can be guaranteed to run before we call of_platform_populate for the regular devices, which is probably the best solution here. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] cpufreq: tegra: Re-model Tegra cpufreq driver
On 19 December 2013 10:56, bilhuang wrote: > I'm not sure virtual regulator for CPU is a good idea, in addition to that, > we don't have a single SoC OPP table, we need several which are speedo-id > and process-id dependant, but generic cpufreq-cpu0 is assuming there is only > one statically Can't that be handled via DT ? > for some SoC the frequency table is not fixed, they are > created at runtime combining our fast and slow CPU frequency table and dvfs > table. So I'm really not sure is it worth adding so many tweaks in order to > use the generic cpufreq-cpu0 driver. Hmm, maybe I got confused because I don't have a clear picture in my mind. It might be better to go ahead with your implementation for now and after everything is set, we can choose to use cpufreq-cpu0 if it is worth 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 v3 2/2] cpufreq: tegra: Re-model Tegra cpufreq driver
On 12/18/2013 10:39 PM, Viresh Kumar wrote: On 18 December 2013 17:03, bilhuang wrote: cpufreq-cpu0 driver will call regulator_set_voltage_tol() directly according to the pre-defined OPP freq/volt pairs, the regulator drivers could be shared by other SoC so is not suitable to handle this, or do I misunderstand? In case regulator's driver is shared, then you can probably add another virtual regulator for CPU which would have the special code you want. I'm not sure virtual regulator for CPU is a good idea, in addition to that, we don't have a single SoC OPP table, we need several which are speedo-id and process-id dependant, but generic cpufreq-cpu0 is assuming there is only one statically, for some SoC the frequency table is not fixed, they are created at runtime combining our fast and slow CPU frequency table and dvfs table. So I'm really not sure is it worth adding so many tweaks in order to use the generic cpufreq-cpu0 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: [net-next/master PATCH] lib: fix compile warning in hashlib_init
From: Daniel Borkmann Date: Thu, 19 Dec 2013 02:32:02 +0100 > On 12/19/2013 02:15 AM, Fengguang Wu wrote: >> CC the list. >> >> On Thu, Dec 19, 2013 at 09:08:34AM +0800, Wanlong Gao wrote: >>> /git/linux/lib/hash.c: In function 'hashlib_init': >>> /git/linux/lib/hash.c:35:2: warning: passing argument 1 of >>> 'setup_arch_fast_hash' from incompatible pointer type [enabled by >>> default] >>> /git/linux/include/asm-generic/hash.h:5:20: note: expected 'struct >>> arch_hash_ops *' but argument is of type 'struct fast_hash_ops *' >>> >>> Reported-by: Fengguang Wu >>> Signed-off-by: Wanlong Gao > > That's already in netdev patchwork: > > http://patchwork.ozlabs.org/patch/302908/ And I've applied it, 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: [RFC/PATCH 0/3] pm: Make SET_*_PM_OPS() macros more smart
On Thu, Dec 12, 2013 at 09:18:22PM -0800, David Cohen wrote: > Hi, > > These patches are proposal to extend the lack of #ifdef checks on PM callback > to its implementation too. > > Currently SET_*_PM_OPS() macros make #ifdefs checks not necessary when setting > the callback to PM ops, but the callbacks implementation don't see same > benefit. > > This RFC Solves a problem reported by Santosh on xhci-plat.c driver due to > wrong #ifdef checks: > > drivers/usb/host/xhci-plat.c:201:12: warning: ‘xhci_plat_suspend’ defined but > not used [-Wunused-function] > drivers/usb/host/xhci-plat.c:209:12: warning: ‘xhci_plat_resume’ defined but > not used [-Wunused-function] > > But instead of fixing the #ifdefs, we remove the need for it :) Ping. Comments here? :) Br, David > > Br, David Cohen > > --- > David Cohen (2): > pm: make PM macros more smart > usb/xhci: implement proper static inline stubs when !CONFIG_PM > > Santosh Shilimkar (1): > usb/xhci-plat: remove unnecessary #ifdef checks for CONFIG_PM_SLEEP > > drivers/usb/host/xhci-plat.c | 7 +-- > drivers/usb/host/xhci.h | 6 -- > include/linux/pm.h | 11 +-- > 3 files changed, 14 insertions(+), 10 deletions(-) > > -- > 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/rmap: fix BUG at rmap_walk
On 12/18/2013 11:29 PM, Wanpeng Li wrote: PageLocked is not required by page_referenced_anon() and there is not >any assertion before, commit 37f093cdf introduced this extra BUG_ON() There are two callsites shrink_active_list and page_check_references() of page_referenced(). shrink_active_list and its callee won't lock anonymous page, however, page_check_references() is called with anonymous page lock held in shrink_page_list. So page_check_references case need specail handling. This explanation seems to be based on current observed behaviour. I think it would be easier if you could point out the actual code in each function that requires a page to be locked, once we have that we don't have to care about what the callers currently do. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn't work.
On Wed, Dec 18, 2013 at 08:45:46PM +0100, Sander Eikelenboom wrote: > > Wednesday, December 18, 2013, 8:43:28 PM, you wrote: > > > On Wed, Dec 18, 2013 at 11:48:45AM +0100, Sander Eikelenboom wrote: > >> > >> Wednesday, December 18, 2013, 10:26:25 AM, you wrote: > >> > >> > Hi all, > >> > >> > We really should be asking Luis to look at this who hasn't yet chimed > >> > in, presumably because he's between jobs (and travelling IIRC) > >> > >> > On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > >> >> On 12/17/2013 11:06 PM, Linus Torvalds wrote: > >> >> > We have literally had this *exact* same issue with firmware loading. > >> >> > Network drivers shouldn't try to load firmware at module load time. > >> >> > Same deal. > >> >> > >> >> It is kind of a chicken and egg problem for (wireless) networking > >> >> drivers. To get IFF_UP from the network layer you have to register a > >> >> netdevice. For wireless drivers this means you have to register a wiphy > >> >> device with cfg80211 which flags capabilities and optionally are custom > >> >> regulatory domain. That information depends on the device and firmware > >> >> used. And there we have a full circle. > >> > >> > This is all really beside the point. > >> > >> > For this CRDA information, the kernel never actually *waits* for it, so > >> > in the case that there's no reply, it uses the built-in world domain. So > >> > it's not like request_firmware(), which will block boot forever, but > >> > it's also not like request_firmware_nowait() which will eventually time > >> > out and come back with an error if userspace isn't handling it (though > >> > now that firmware loading is built in ...) > >> > >> > The issue is that it uses the built-in data *forever*, and what Sander > >> > said was "or it will block forever" but just meant that it never was > >> > able to do any further updates. > >> > >> > It *doesn't* actually block the boot process or such. Everything Linus > >> > said is true but seems to have been written in understanding "blocks" as > >> > "blocking the boot process", rather than "blocking further updates". > >> > >> > Regardless of this, even blocking further updates is a really bad idea. > >> > There are a few ways to handle this, but I'll let Luis poke at that. > >> > >> Your description is correct, sorry if I was not clear. > > > We have a timeout handler for this, I'll check to see what's going on > > by trying to reproduce on my end. Are you using wireless-testing ? > > Originally 3.13-rc4, after that i tried with 3.13-rc4 with wireless-next > pulled on top of it > (since there were major changes to reg.c) but the problem occurs with both. OK I can reproduce and am working on the cleanest solution. Thanks for your report, I'll Cc ya when I have something reasonable baked up, hopefully rather soon! 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/
[PATCH] ASoC: simple-card: Use devm_snd_soc_register_card()
Makes the code slightly shorter.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 7a9b6b4..3d190d0 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -234,14 +234,7 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
cinfo->snd_card.num_links = 1;
cinfo->snd_card.dev = >dev;
- return snd_soc_register_card(>snd_card);
-}
-
-static int asoc_simple_card_remove(struct platform_device *pdev)
-{
- struct asoc_simple_card_info *cinfo = pdev->dev.platform_data;
-
- return snd_soc_unregister_card(>snd_card);
+ return devm_snd_soc_register_card(>dev, >snd_card);
}
static const struct of_device_id asoc_simple_of_match[] = {
@@ -257,7 +250,6 @@ static struct platform_driver asoc_simple_card = {
.of_match_table = asoc_simple_of_match,
},
.probe = asoc_simple_card_probe,
- .remove = asoc_simple_card_remove,
};
module_platform_driver(asoc_simple_card);
--
1.8.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] rds: prevent dereference of a NULL device
Binding might result in a NULL device, which is dereferenced
causing this BUG:
[ 1317.260548] BUG: unable to handle kernel NULL pointer dereference at
097
4
[ 1317.261847] IP: [] rds_ib_laddr_check+0x82/0x110
[ 1317.263315] PGD 418bcb067 PUD 3ceb21067 PMD 0
[ 1317.263502] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1317.264179] Dumping ftrace buffer:
[ 1317.264774](ftrace buffer empty)
[ 1317.265220] Modules linked in:
[ 1317.265824] CPU: 4 PID: 836 Comm: trinity-child46 Tainted: GW
3.13.0-rc4-
next-20131218-sasha-00013-g2cebb9b-dirty #4159
[ 1317.267415] task: 8803ddf33000 ti: 8803cd31a000 task.ti:
8803cd31a000
[ 1317.268399] RIP: 0010:[] []
rds_ib_laddr_check+
0x82/0x110
[ 1317.269670] RSP: :8803cd31bdf8 EFLAGS: 00010246
[ 1317.270230] RAX: RBX: 88020b0dd388 RCX:
[ 1317.270230] RDX: 8439822e RSI: 000c000a RDI: 0286
[ 1317.270230] RBP: 8803cd31be38 R08: R09:
[ 1317.270230] R10: R11: 0001 R12:
[ 1317.270230] R13: 54086700 R14: 00a25de0 R15: 0031
[ 1317.270230] FS: 7ff40251d700() GS:88022e20()
knlGS:
[ 1317.270230] CS: 0010 DS: ES: CR0: 8005003b
[ 1317.270230] CR2: 0974 CR3: 0003cd478000 CR4: 06e0
[ 1317.270230] DR0: DR1: DR2:
[ 1317.270230] DR3: DR6: 0ff0 DR7: 00090602
[ 1317.270230] Stack:
[ 1317.270230] 54086700 540867a25de0 54086702
[ 1317.270230] 84223542 ea54c767
86d26160
[ 1317.270230] 8803cd31be68 84223556 8803cd31beb8
8800c6765280
[ 1317.270230] Call Trace:
[ 1317.270230] [] ? rds_trans_get_preferred+0x42/0xa0
[ 1317.270230] [] rds_trans_get_preferred+0x56/0xa0
[ 1317.270230] [] rds_bind+0x73/0xf0
[ 1317.270230] [] SYSC_bind+0x92/0xf0
[ 1317.270230] [] ? context_tracking_user_exit+0xb8/0x1d0
[ 1317.270230] [] ? trace_hardirqs_on+0xd/0x10
[ 1317.270230] [] ? syscall_trace_enter+0x32/0x290
[ 1317.270230] [] SyS_bind+0xe/0x10
[ 1317.270230] [] tracesys+0xdd/0xe2
[ 1317.270230] Code: 00 8b 45 cc 48 8d 75 d0 48 c7 45 d8 00 00 00 00 66 c7 45
d0 02 00
89 45 d4 48 89 df e8 78 49 76 ff 41 89 c4 85 c0 75 0c 48 8b 03 <80> b8 74 09 00
00 01 7
4 06 41 bc 9d ff ff ff f6 05 2a b6 c2 02
[ 1317.270230] RIP [] rds_ib_laddr_check+0x82/0x110
[ 1317.270230] RSP
[ 1317.270230] CR2: 0974
Signed-off-by: Sasha Levin
---
net/rds/ib.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rds/ib.c b/net/rds/ib.c
index b4c8b00..ba2dffe 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -338,7 +338,8 @@ static int rds_ib_laddr_check(__be32 addr)
ret = rdma_bind_addr(cm_id, (struct sockaddr *));
/* due to this, we will claim to support iWARP devices unless we
check node_type. */
- if (ret || cm_id->device->node_type != RDMA_NODE_IB_CA)
+ if (ret || !cm_id->device ||
+ cm_id->device->node_type != RDMA_NODE_IB_CA)
ret = -EADDRNOTAVAIL;
rdsdebug("addr %pI4 ret %d node type %d\n",
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 3/4] thermal: samsung: Add TMU support for Exynos5420 SoCs
Hello Tomasz,
On 18 December 2013 21:20, Tomasz Figa wrote:
> Hi Naveen,
>
> On Tuesday 10 of December 2013 12:12:25 Naveen Krishna Chatradhi wrote:
>> Exynos5420 has 5 TMU channels, the TRIMINFO register is
>> misplaced for TMU channels 2, 3 and 4
>> TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> TRIMINFO at 0x100a contains data for TMU channel 4
>> TRIMINFO at 0x10068000 contains data for TMU channel 2
> [snip]
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index a1aa602..a3e78c0 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -6,6 +6,9 @@
>> "samsung,exynos4412-tmu"
>> "samsung,exynos4210-tmu"
>> "samsung,exynos5250-tmu"
>> +"samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
>> +"samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and
>> 4
>> + Exynos5420 (Must pass triminfo base and triminfo clock)
>
> Exact clock names must be specified in description of clock-names property.
Sure, will add them.
>
>> "samsung,exynos5440-tmu"
>> - interrupt-parent : The phandle for the interrupt controller
>> - reg : Address range of the thermal registers. For soc's which has multiple
>> @@ -13,6 +16,16 @@
>> interrupt related then 2 set of register has to supplied. First set
>> belongs to register set of TMU instance and second set belongs to
>> registers shared with the TMU instance.
>> +
>> + NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
>> + channels 2, 3 and 4
>> + Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a
>> misplaced
>> + register, also provide clock to access that base.
>> +
>> + TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> + TRIMINFO at 0x100a contains data for TMU channel 4
>> + TRIMINFO at 0x10068000 contains data for TMU channel 2
>> +
>> - interrupts : Should contain interrupt for thermal system
>> - clocks : The main clock for TMU device
>> - clock-names : Thermal system clock name
>> @@ -43,6 +56,31 @@ Example 2):
>> clock-names = "tmu_apbif";
>> };
>>
>> +Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
>> + tmu_cpu2: tmu@10068000 {
>> + compatible = "samsung,exynos5420-tmu-ext-triminfo";
>> + reg = <0x10068000 0x100>, <0x1006c000 0x4>;
>> + interrupts = <0 184 0>;
>> + clocks = < 318>, < 318>;
>> + clock-names = "tmu_apbif", "tmu_triminfo_apbif";
>
> Here you have "tmu_triminfo_apbif" clock, but in the driver you call
> clk_get() with "tmu_apbif_triminfo".
My bad, will correct this
>
>> + };
>> +
> [snip]
>>
>> + data->clk_sec = devm_clk_get(>dev, "tmu_apbif_triminfo");
>
> Here you try to get "tmu_apbif_triminfo" clock, but in binding
> documentation you have "tmu_triminfo_apbif" in example.
My bad, will correct this
>
>> + if (IS_ERR(data->clk_sec)) {
>> + if (data->soc == SOC_ARCH_EXYNOS5420_TRIMINFO) {
>> + dev_err(>dev, "Failed to get triminfo clock\n");
>> + return PTR_ERR(data->clk_sec);
>> + }
>> + } else {
>> + ret = clk_prepare(data->clk_sec);
>> + if (ret) {
>> + dev_err(>dev, "Failed to get clock\n");
>> + return ret;
>> + }
>> + }
>> +
>> ret = clk_prepare(data->clk);
>> - if (ret)
>> - return ret;
>> + if (ret) {
>> + dev_err(>dev, "Failed to get clock\n");
>> + goto err_clk_sec;
>> + }
>>
>> if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>> pdata->type == SOC_ARCH_EXYNOS4412 ||
>> pdata->type == SOC_ARCH_EXYNOS5250 ||
>> + pdata->type == SOC_ARCH_EXYNOS5420_TRIMINFO ||
TMU channel 0, 1 on Exynos5420 does not require a new pdata->type.
The are exactly similar to Exynos5250. Only the channels 2, 3 and 4
have the triminfo register misplaced.
Hence, just SOC_ARCH_EXYNOS5420_TRIMINFO should be enough
>
> Don't you also need SOC_ARCH_EXYNOS5420 here?
>
>> pdata->type == SOC_ARCH_EXYNOS5440)
>> data->soc = pdata->type;
>> else {
>> @@ -703,6 +742,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>> return 0;
>> err_clk:
>> clk_unprepare(data->clk);
>> +err_clk_sec:
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>> return ret;
>> }
>>
>> @@ -715,6 +757,8 @@ static int exynos_tmu_remove(struct platform_device
>> *pdev)
>> exynos_unregister_thermal(data->reg_conf);
>>
>> clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>>
>> if
Re: commit e38c0a1f breaks powerpc boards with uli1575 chip
> Reverting would break Tegra PCIe, but you should not have to change the > DT either. So we need a solution. > > Is this something like this sufficient to fix it? > > diff --git a/drivers/of/address.c b/drivers/of/address.c > index 4b9317b..378aebd 100644 > --- a/drivers/of/address.c > +++ b/drivers/of/address.c > @@ -74,7 +74,7 @@ static u64 of_bus_default_map(__be32 *addr, const > __be32 *range, > * mapping doesn't specify a physical address. Rather, the > address * specifies an identifier that must match exactly. > */ > - if (na > 2 && memcmp(range, addr, na * 4) != 0) > + if (na > 2 && memcmp(range, addr, (na - 2) * 4) != 0) > return OF_BAD_ADDR; > > if (da < cp || da >= (cp + s)) No, this does not help. I've dumped the actual content of 'range' and 'addr' at the failure point (i.e. ar point that returns error with e38c0a1f but passes without e38c0a1f ): OF: default map, cp=0, s=1, da=70 range: 01 00 00 00 00 00 00 00 00 00 00 00 addr: 00 00 00 00 00 00 00 00 00 00 00 70 Nikita -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: bad page state in 3.13-rc4
On Wed, Dec 18, 2013 at 8:07 PM, Dave Jones wrote: > Just hit this while fuzzing with lots of child processes. > (trinity -C128) Ok, there's a BUG_ON() in the middle, the "bad page" part is just this: > BUG: Bad page state in process trinity-c93 pfn:100499 > page:ea0004012640 count:0 mapcount:0 mapping: (null) index:0x389 > page flags: 0x2c(referenced|uptodate) > Call Trace: > [] dump_stack+0x4e/0x7a > [] bad_page.part.71+0xcf/0xe8 > [] free_pages_prepare+0x185/0x190 > [] free_hot_cold_page+0x35/0x180 > [] __put_single_page+0x23/0x30 > [] put_page+0x35/0x50 > [] aio_free_ring+0x55/0xf0 > [] SyS_io_setup+0x59a/0xbe0 > [] tracesys+0xdd/0xe2 at free_pages() time, and I don't see anything bad in the printout wrt the page counts of flags. Which makes me wonder if this is mem_cgroup_bad_page_check() triggering. Of course, if it's a race, it may be that by the time we print out the counts they all look good, even if they weren't good at the time we did that bad_page() *check*. And the fact that we do have a concurrent BUG_ON() triggering with a zero page count obviously does look suspicious. Looks like a possible race with memory compaction happening at the same time aio_free_ring() frees the page. Somebody who knows the migration code needs to look at this. ChristophL? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] audit: listen in all network namespaces
On 07/17/2013 04:32 AM, Richard Guy Briggs wrote:
> Convert audit from only listening in init_net to use register_pernet_subsys()
> to dynamically manage the netlink socket list.
>
> Signed-off-by: Richard Guy Briggs
> ---
I think it's the time for us to discuss if we should revert this
commit, since this one prevent me from continuing to achieve
audit namespace.
The major problem is in kaudit_send_skb, we have no idea which
audit sock the skb should send to.
in this patch, there only is one auditd proecess, so the
audit_sock is the only one. but when we have audit namespace.
there will be multi audit socks. we have to store audit_sock
into auditns(auditns will be passed to kauditd_send_skb),
this will cause auditns have to get a reference of netns.
and for some reason(netfilter audit target), netns will
get reference of auditns too. this is terrible...
So why not we revert this one, and use a very simple one to
replace it? the below patch will save us from the refer to
each other case, achieve the same effect.
what's your opinion?
Add a compare function which always return true for
audit netlink socket, this will cause audit netlink
sockets netns unaware, and no matter which netns the
user space audit netlink sockets belong to, they all
can find out and communicate with audit_sock.
This gets rid of the necessary to create per-netns
audit kernel side socket(audit_sock), it's pain to
depend on and get reference of netns for auditns.
Signed-off-by: Gao feng
---
kernel/audit.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/audit.c b/kernel/audit.c
index 7b0e23a..468950b 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -886,12 +886,18 @@ static void audit_receive(struct sk_buff *skb)
mutex_unlock(_cmd_mutex);
}
+static bool audit_compare(struct net *net, struct sock *sk)
+{
+ return true;
+}
+
/* Initialize audit support at boot time. */
static int __init audit_init(void)
{
int i;
struct netlink_kernel_cfg cfg = {
.input = audit_receive,
+ .compare = audit_compare,
};
if (audit_initialized == AUDIT_DISABLED)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [fs] inode_lru_isolate(): Move counter increment into spinlock section
On Wed, Dec 18, 2013 at 07:24:46PM +, Christoph Lameter wrote: > The counter increment in inode_lru_isolate is happening after > spinlocks have been dropped with preemption on using __count_vm_events > making counter increment races possible. That's a nasty, undocumented problem that __count_vm_events() has. Nobody who is modifying the fs/inode.c code is likely to know about this, so just moving the code under an unrelated lock is not sufficient to prevent this from happening again. Hence I'd prefer that you just change it to use count_vm_events() rather than try to be tricksy by replacing the landmine in the code that we've already stepped on once. 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 2/2] usb: usbtest: Always clear halt else further tests will fail
On Wed, Dec 18, 2013 at 03:40:11PM +0530, Roger Quadros wrote:
> In test_halt() we set an endpoint halt condition and return on halt
> verification
> failure, then the enpoint will remain halted and all further tests related
> to that enpoint will fail. This is because we don't tackle endpoint halt
> error condition
> in any of the tests. To avoid that situation, make sure to clear the
> halt condition before exiting test_halt().
>
> Signed-off-by: Roger Quadros
> Reviewed-by: Felipe Balbi
Acked-by: Huang Rui
> ---
> drivers/usb/misc/usbtest.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
> index 6294e1b..300b726 100644
> --- a/drivers/usb/misc/usbtest.c
> +++ b/drivers/usb/misc/usbtest.c
> @@ -1545,8 +1545,17 @@ static int test_halt(struct usbtest_dev *tdev, int ep,
> struct urb *urb)
> return retval;
> }
> retval = verify_halted(tdev, ep, urb);
> - if (retval < 0)
> + if (retval < 0) {
> + int ret;
> +
> + /* clear halt anyways, else further tests will fail */
> + ret = usb_clear_halt(urb->dev, urb->pipe);
> + if (ret)
> + ERROR(tdev, "ep %02x couldn't clear halt, %d\n",
> + ep, ret);
> +
> return retval;
> + }
>
> /* clear halt (tests API + protocol), verify it worked */
> retval = usb_clear_halt(urb->dev, urb->pipe);
> --
> 1.8.3.2
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] usb: usbtest: Add timetout to simple_io()
On Wed, Dec 18, 2013 at 10:37:44AM -0600, Felipe Balbi wrote: > On Wed, Dec 18, 2013 at 10:46:03PM +0800, Huang Rui wrote: > > Hi Roger, > > > > On Wed, Dec 18, 2013 at 03:40:10PM +0530, Roger Quadros wrote: > > > Without a timetout some tests e.g. test_halt() can remain stuck forever. > > > > > > Signed-off-by: Roger Quadros > > > Reviewed-by: Felipe Balbi > > > --- > > > drivers/usb/misc/usbtest.c | 14 +++--- > > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c > > > index b415282..6294e1b 100644 > > > --- a/drivers/usb/misc/usbtest.c > > > +++ b/drivers/usb/misc/usbtest.c > > > @@ -10,6 +10,7 @@ > > > > > > #include > > > > > > +#define SIMPLE_IO_TIMEOUT1 /* in milliseconds */ > > > > > > > Only one question, how do you confirm the timeout value? > > dude, it's just a timeout. It could be anything, really. 10 seconds is > just large enough value that would allow even the slowest scenarios > (host + device) to complete, while not being so slow that you would > wanna kill yourself after waiting for such a long time ;-) > OK. I've tested in my side. Acked-by: Huang Rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm/rmap: fix BUG at rmap_walk
On Thu, Dec 19, 2013 at 11:45 AM, Wanpeng Li wrote:
> page_get_anon_vma() called in page_referenced_anon() will lock and increase
> the refcount of anon_vma, page won't be locked for anonymous page if the page
> is not locked by the caller. This patch fix the BUG_ON by reuse referenced
> field in page_referenced_arg to capture locked anonymous page for
> page_referenced(),
> if the anonymous page is locked by the caller, the referenced field will
> remember
> it, rmap_walk_anon will check if page locked if caller lock it.
>
Better commit log, please.
This bug is introduced by commit 37f093cdf(mm/rmap: use rmap_walk()
in page_referenced()).
PageLocked is not required by page_referenced_anon() and there is not
any assertion before, commit 37f093cdf introduced this extra BUG_ON()
checking for anon page by mistake.
> [ 588.698828] kernel BUG at mm/rmap.c:1663!
> [ 588.699380] invalid opcode: [#2] PREEMPT SMP DEBUG_PAGEALLOC
> [ 588.700347] Dumping ftrace buffer:
> [ 588.701186](ftrace buffer empty)
> [ 588.702062] Modules linked in:
> [ 588.702759] CPU: 0 PID: 4647 Comm: kswapd0 Tainted: G D W
> 3.13.0-rc4-next-20131218-sasha-00012-g1962367-dirty #4155
> [ 588.704330] task: 880062bcb000 ti: 88006245 task.ti:
> 88006245
> [ 588.705507] RIP: 0010:[] []
> rmap_walk+0x10/0x50
> [ 588.706800] RSP: 0018:8800624518d8 EFLAGS: 00010246
> [ 588.707515] RAX: 000f80080048 RBX: ea0227c0 RCX:
>
> [ 588.707515] RDX: RSI: 8800624518e8 RDI:
> ea0227c0
> [ 588.707515] RBP: 8800624518d8 R08: 8800624518e8 R09:
>
> [ 588.707515] R10: R11: R12:
> 8800624519d8
> [ 588.707515] R13: R14: ea0227e0 R15:
>
> [ 588.707515] FS: () GS:88006520()
> knlGS:
> [ 588.707515] CS: 0010 DS: ES: CR0: 8005003b
> [ 588.707515] CR2: 7fec40cbe0f8 CR3: c2382000 CR4:
> 06f0
> [ 588.707515] Stack:
> [ 588.707515] 880062451958 81289f4b 880062451918
> 81289f80
> [ 588.707515] 8128af60
>
> [ 588.707515] 0024
> 0286
> [ 588.707515] Call Trace:
> [ 588.707515] [] page_referenced+0xcb/0x100
> [ 588.707515] [] ? page_referenced+0x100/0x100
> [ 588.707515] [] ? invalid_page_referenced_vma+0x170/0x170
> [ 588.707515] [] shrink_active_list+0x212/0x330
> [ 588.707515] [] ? inactive_file_is_low+0x33/0x50
> [ 588.707515] [] shrink_lruvec+0x2d5/0x300
> [ 588.707515] [] shrink_zone+0x96/0x1e0
> [ 588.707515] [] kswapd_shrink_zone+0xf6/0x1c0
> [ 588.707515] [] balance_pgdat+0x373/0x550
> [ 588.707515] [] kswapd+0x2f3/0x350
> [ 588.707515] [] ?
> perf_trace_mm_vmscan_lru_isolate_template+0x120/0x120
> [ 588.707515] [] kthread+0x105/0x110
> [ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30
> [ 588.707515] [] ret_from_fork+0x7c/0xb0
> [ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30
> [ 588.707515] Code: c0 48 83 c4 18 89 d0 5b 41 5c 41 5d 41 5e 41 5f c9 c3 66
> 0f 1f 84
> 00 00 00 00 00 55 48 89 e5 66 66 66 66 90 48 8b 07 a8 01 75 10 <0f> 0b 66 0f
> 1f 44 00 0
> 0 eb fe 66 0f 1f 44 00 00 f6 47 08 01 74
> [ 588.707515] RIP [] rmap_walk+0x10/0x50
> [ 588.707515] RSP
>
> Reported-by: Sasha Levin
> Signed-off-by: Wanpeng Li
> ---
> mm/ksm.c | 5 +
> mm/rmap.c | 20 ++--
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/mm/ksm.c b/mm/ksm.c
> index c9a28dd..76d96df 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -1899,6 +1899,11 @@ int rmap_walk_ksm(struct page *page, struct
> rmap_walk_control *rwc)
> int search_new_forks = 0;
>
> VM_BUG_ON(!PageKsm(page));
> +
> + /*
> +* Rely on the page lock to protect against concurrent modifications
> +* to that page's node of the stable tree.
> +*/
> VM_BUG_ON(!PageLocked(page));
>
> stable_node = page_stable_node(page);
> diff --git a/mm/rmap.c b/mm/rmap.c
> index d792e71..db83961 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -769,6 +769,10 @@ int page_referenced(struct page *page,
> struct page_referenced_arg pra = {
> .mapcount = page_mapcount(page),
> .memcg = memcg,
> + /*
> +* reuse referenced field for the locked anonymous page check
> +*/
> + .referenced = is_locked && PageAnon(page) &&
Re: Writeback threads and freezable
On Wed, Dec 18, 2013 at 06:43:43AM -0500, Tejun Heo wrote: > Hello, Dave. > > On Wed, Dec 18, 2013 at 11:35:10AM +1100, Dave Chinner wrote: > > Perhaps the function "invalidate_partition()" is badly named. To > > state the obvious, fsync != invalidation. What it does is: > > > > 1. sync filesystem > > 2. shrink the dcache > > 3. invalidates inodes and kills dirty inodes > > 4. invalidates block device (removes cached bdev pages) > > > > Basically, the first step is "flush", the remainder is "invalidate". > > > > Indeed, step 3 throws away dirty inodes, so why on earth would we > > even bother with step 1 to try to clean them in the first place? > > IOWs, the flush is irrelevant in the hot-unplug case as it will > > fail to flush stuff, and then we just throw the stuff we > > failed to write away. > > > > But in attempting to flush all the dirty data and metadata, we can > > cause all sorts of other potential re-entrancy based deadlocks due > > to attempting to issue IO. Whether they be freezer based or through > > IO error handling triggering device removal or some other means, it > > is irrelevant - it is the flush that causes all the problems. > > Isn't the root cause there hotunplug reentering anything above it in > the first place. The problem with your proposal is that filesystem > isn't the only place where this could happen. Even with no filesystem > involved, block device could still be dirty and IOs pending in > whatever form - dirty bdi, bios queued in dm, requests queued in > request_queue, whatever really - and if the hotunplug path reenters > any of the higher layers in a way which blocks IO processing, it will > deadlock. Entirely possible. > If knowing that the underlying device has gone away somehow helps > filesystem, maybe we can expose that interface and avoid flushing > after hotunplug but that merely hides the possible deadlock scenario > that you're concerned about. Nothing is really solved. Except that a user of the block device has been informed that it is now gone and has been freed from under it. i.e. we can *immediately* inform the user that their mounted filesystem is now stuffed and supress all the errors that are going to occur as a result of sync_filesystem() triggering IO failures all over the place and then having to react to that.i Indeed, there is no guarantee that sync_filesystem will result in the filesystem being shut down - if the filesystem is clean then nothing will happen, and it won't be until the user modifies some metadata that a shutdown will be triggered. That could be a long time after the device has been removed > We can try to do the same thing at each layer and implement quick exit > path for hot unplug all the way down to the driver but that kinda > sounds complex and fragile to me. It's a lot larger surface to cover > when the root cause is hotunplug allowed to reenter anything at all > from IO path. This is especially true because hotunplug can trivially > be made fully asynchronous in most cases. In terms of destruction of > higher level objects, warm and hot unplugs can and should behave > identical. I don't see that there is a difference between a warm and hot unplug from a filesystem point of view - both result in the filesystem's backing device being deleted and freed, and in both cases we have to take the same action > > We need to either get rid of the flush on device failure/hot-unplug, > > or turn it into a callout for the superblock to take an appropriate > > action (e.g. shutting down the filesystem) rather than trying to > > issue IO. i.e. allow the filesystem to take appropriate action of > > shutting down the filesystem and invalidating it's caches. > > There could be cases where some optimizations for hot unplug could be > useful. Maybe suppressing pointless duplicate warning messages or > whatnot but I'm highly doubtful anything will be actually fixed that > way. We'll be most likely making bugs just less reproducible. > > > Indeed, in XFS there's several other caches that could contain dirty > > metadata that isn't invalidated by invalidate_partition(), and so > > unless the filesystem is shut down it can continue to try to issue > > IO on those buffers to the removed device until the filesystem is > > shutdown or unmounted. > > Do you mean xfs never gives up after IO failures? There's this thing called a transient IO failure which we have to handle. e.g multipath taking several minutes to detect a path failure and fail over, whilst in the mean time IO errors are reported after a 30s timeout. So some types of async metadata write IO failures are simply rescheduled for a short time in the future. They'll either succeed, or continual failure will eventually trigger some kind of filesystem failure. If it's a synchronous write or a write that we cannot tolerate even transient errors on (e.g. journal writes), then we'll shut down the filesystem immediately. > > Seriously, Tejun, the
KGTP (dynamic tracer for Linux kernel and applications) 20131218 release (support Uprobes to trace user applications)
KGTP (http://kgtp.googlecode.com/) is a comprehensive dynamic tracer for
analysing Linux kernel and application (including Android) problems on
production systems in real time.
To use it, you don't need patch or rebuild the Linux kernel. Just build
KGTP module and insmod it is OK.
http://www.youtube.com/watch?v=7nfGAbNsEZY
or http://www.tudou.com/programs/view/fPu_koiKo38/ is the video that
introduced KGTP in English.
http://www.infoq.com/cn/presentations/gdb-sharp-knife-kgtp-linux-kernel
is the video that introduced KGTP in Chinese.
Please goto https://code.google.com/p/kgtp/wiki/HOWTO (English)
or https://code.google.com/p/kgtp/wiki/HOWTOCN (Chinese) to get howto use KGTP.
Or download the pdf version in
https://raw.github.com/teawater/kgtp/master/kgtp.pdf (English)
or https://raw.github.com/teawater/kgtp/master/kgtpcn.pdf(Chinese).
Now, KGTP 20131218 release.
To get it in github:
Get through https:
https://github.com/teawater/kgtp/archive/20131218.tar.gz
Get through git:
git clone https://github.com/teawater/kgtp.git
git checkout 20131218 -b 20131218
To get it in CSDN:
Get through https:
https://code.csdn.net/teawater/kgtp/repository/archive?ref=20131218
Get through git:
git clone git://code.csdn.net/teawater/kgtp.git
git checkout 20131218 -b 20131218
The main change of this release is:
Support Uprobes to trace user applications. So now, you can use GDB
trace or access the memory of user applications through KGTP without
stop them like what KGTP can do with Linux kernel. Please goto
https://code.google.com/p/kgtp/wiki/HOWTO#Use_KGTP_with_user_applications
get more info about howto use it.
Please goto https://github.com/teawater/kgtp/blob/20131218/UPDATE
get more info about this release.
The howto of KGTP doesn't introcue trace more than one user applications
or Linux kernel in same time. This is because multiprocess support of
GDB tracepoint is not complete. Without this support, KGTP need add
a special line in actions to support multiprocess tracepoint. So I make
some patches for GDB to make it works:
https://sourceware.org/ml/gdb-patches/2013-12/msg00730.html
https://sourceware.org/ml/gdb-patches/2013-12/msg00731.html
https://sourceware.org/ml/gdb-patches/2013-12/msg00732.html
https://sourceware.org/ml/gdb-patches/2013-12/msg00733.html
Hope they can get review before GDB 7.7 release. Maybe I need add them
to https://code.google.com/p/gdbt/ first.
So in the next release of KGTP, GDB can very easy to trace user applications
and Linux kernel through KGTP in same time.
According to the comments of Christoph, Geoff and Andi. I make KGTP
function lite patch for Linux kernel upstream. Please goto
http://lkml.org/lkml/2013/11/21/7 to got it.
And I also post it with this mail.
Signed-off-by: Hui Zhu
---
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -61,6 +61,7 @@ void pt_regs_to_gdb_regs(unsigned long *
to_gdb_regs(gdb_regs, kernel_regs, (struct callee_regs *)
current->thread.callee_reg);
}
+EXPORT_SYMBOL_GPL(pt_regs_to_gdb_regs);
void gdb_regs_to_pt_regs(unsigned long *gdb_regs, struct pt_regs *kernel_regs)
{
--- a/arch/blackfin/kernel/kgdb.c
+++ b/arch/blackfin/kernel/kgdb.c
@@ -73,6 +73,7 @@ void pt_regs_to_gdb_regs(unsigned long *
gdb_regs[BFIN_EXTRA3] = 0;
gdb_regs[BFIN_IPEND] = regs->ipend;
}
+EXPORT_SYMBOL_GPL(pt_regs_to_gdb_regs);
/*
* Extracts ebp, esp and eip values understandable by gdb from the values
--- a/arch/microblaze/kernel/kgdb.c
+++ b/arch/microblaze/kernel/kgdb.c
@@ -64,6 +64,7 @@ void pt_regs_to_gdb_regs(unsigned long *
__asm__ __volatile__ ("mfs %0, rtlbhi;" : "=r"(temp) : );
gdb_regs[GDB_RTLBHI] = temp;
}
+EXPORT_SYMBOL_GPL(pt_regs_to_gdb_regs);
void gdb_regs_to_pt_regs(unsigned long *gdb_regs, struct pt_regs *regs)
{
--- a/arch/mn10300/kernel/kgdb.c
+++ b/arch/mn10300/kernel/kgdb.c
@@ -66,6 +66,7 @@ void pt_regs_to_gdb_regs(unsigned long *
gdb_regs[GDB_FR_DUMMY1] = 0;
gdb_regs[GDB_FR_FS0]= 0;
}
+EXPORT_SYMBOL_GPL(pt_regs_to_gdb_regs);
/*
* Extracts kernel SP/PC values understandable by gdb from the values
--- a/arch/sparc/kernel/kgdb_32.c
+++ b/arch/sparc/kernel/kgdb_32.c
@@ -41,6 +41,7 @@ void pt_regs_to_gdb_regs(unsigned long *
gdb_regs[GDB_FSR] = 0;
gdb_regs[GDB_CSR] = 0;
}
+EXPORT_SYMBOL_GPL(pt_regs_to_gdb_regs);
void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
{
--- a/arch/sparc/kernel/kgdb_64.c
+++ b/arch/sparc/kernel/kgdb_64.c
@@ -37,6 +37,7 @@ void pt_regs_to_gdb_regs(unsigned long *
gdb_regs[GDB_FPRS] = 0;
gdb_regs[GDB_Y] = regs->y;
}
+EXPORT_SYMBOL_GPL(pt_regs_to_gdb_regs);
void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
{
--- /dev/null
+++ b/arch/x86/include/asm/gtp.h
@@ -0,0 +1,16 @@
+#ifndef _ASM_X86_GTP_H_
+#define _ASM_X86_GTP_H_
+
+static inline void gtp_copy_and_adju
bad page state in 3.13-rc4
Just hit this while fuzzing with lots of child processes. (trinity -C128) BUG: Bad page state in process trinity-c93 pfn:100499 [ cut here ] kernel BUG at include/linux/mm.h:439! invalid opcode: [#1] PREEMPT SMP Modules linked in: dlci sctp snd_seq_dummy hidp fuse rfcomm bnep tun can_raw can_bcm bluetooth can rose phonet pppoe pppox ppp_generic slhc llc2 af_rxrpc af_key netrom caif_socket caif ipt_ULOG nfnetlink nfc af_802154 irda crc_ccitt rds scsi_transport_iscsi x25 atm appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 rfkill xfs snd_hda_codec_hdmi snd_hda_codec_realtek libcrc32c snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd shpchp soundcore coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul crc32c_intel ghash_clmulni_intel microcode serio_raw pcspkr usb_debug e1000e ptp pps_core CPU: 0 PID: 4408 Comm: trinity-c39 Not tainted 3.13.0-rc4+ #5 task: 88021b1d5be0 ti: 88011fd4 task.ti: 88011fd4 RIP: 0010:[] [] get_page.part.20+0x4/0x6 RSP: 0018:88011fd418c8 EFLAGS: 00010246 RAX: RBX: 88024e20f780 RCX: 00017151 RDX: RSI: 0017 RDI: 0001 RBP: 88011fd418c8 R08: fffd R09: 000170f8 R10: 88024e5d3e80 R11: 0017 R12: ea0004012640 R13: R14: ea0004184200 R15: FS: 7f2203b5e740() GS:88024e20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 018ca000 CR3: 00014dcf4000 CR4: 001407f0 DR0: 00f88000 DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Stack: 88011fd418e8 81141385 ea0004012640 ea0004012642 88011fd418f8 8114161c 88011fd41920 81145572 ea0004012640 ea0004012600 ea0004012660 88011fd419a8 Call Trace: [] __lru_cache_add+0xa5/0xc0 [] lru_cache_add+0x1c/0x30 [] putback_lru_page+0x72/0xb0 [] migrate_pages+0x479/0x780 [] ? isolate_freepages_block+0x360/0x360 [] compact_zone+0x2aa/0x460 [] ? debug_check_no_locks_freed+0xb0/0x150 [] compact_zone_order+0x94/0xe0 [] try_to_compact_pages+0xe1/0x110 [] __alloc_pages_direct_compact+0xac/0x1d0 [] __alloc_pages_nodemask+0x90a/0xab0 [] alloc_pages_vma+0xf1/0x1b0 [] ? do_huge_pmd_anonymous_page+0xfd/0x3a0 [] do_huge_pmd_anonymous_page+0xfd/0x3a0 [] ? follow_page_mask+0x24c/0x510 [] handle_mm_fault+0x479/0xbb0 [] ? _raw_spin_unlock+0x31/0x50 [] __get_user_pages+0x1ae/0x5f0 [] __mlock_vma_pages_range+0x8c/0xa0 [] __mm_populate+0xc0/0x150 [] vm_mmap_pgoff+0xb6/0xc0 [] SyS_mmap_pgoff+0x116/0x270 [] ? syscall_trace_enter+0x145/0x270 [] SyS_mmap+0x22/0x30 [] tracesys+0xdd/0xe2 Code: 48 c8 48 85 d2 48 0f 49 c2 48 01 c8 49 89 06 58 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 <0f> 0b 80 3d 59 6a 60 00 00 75 1d 55 be 6c 00 00 00 48 c7 c7 e6 RIP [] get_page.part.20+0x4/0x6 RSP page:ea0004012640 count:0 mapcount:0 mapping: (null) index:0x389 page flags: 0x2c(referenced|uptodate) Modules linked in: dlci sctp snd_seq_dummy hidp fuse rfcomm bnep tun can_raw can_bcm bluetooth can rose phonet pppoe pppox ppp_generic slhc llc2 af_rxrpc af_key netrom caif_socket caif ipt_ULOG nfnetlink nfc af_802154 irda crc_ccitt rds scsi_transport_iscsi x25 atm appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 rfkill xfs snd_hda_codec_hdmi snd_hda_codec_realtek libcrc32c snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd shpchp soundcore coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul crc32c_intel ghash_clmulni_intel microcode serio_raw pcspkr usb_debug e1000e ptp pps_core CPU: 2 PID: 4395 Comm: trinity-c93 Tainted: G D 3.13.0-rc4+ #5 88004517fde8 816db2f5 ea0004012640 88004517fe00 816d8b05 ea0004012640 88004517fe38 8113a645 ea0004012640 0020001d Call Trace: [] dump_stack+0x4e/0x7a [] bad_page.part.71+0xcf/0xe8 [] free_pages_prepare+0x185/0x190 [] free_hot_cold_page+0x35/0x180 [] __put_single_page+0x23/0x30 [] put_page+0x35/0x50 [] aio_free_ring+0x55/0xf0 [] SyS_io_setup+0x59a/0xbe0 [] tracesys+0xdd/0xe2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm/rmap: fix BUG at rmap_walk
page_get_anon_vma() called in page_referenced_anon() will lock and increase
the refcount of anon_vma, page won't be locked for anonymous page if the page
is not locked by the caller. This patch fix the BUG_ON by reuse referenced
field in page_referenced_arg to capture locked anonymous page for
page_referenced(),
if the anonymous page is locked by the caller, the referenced field will
remember
it, rmap_walk_anon will check if page locked if caller lock it.
[ 588.698828] kernel BUG at mm/rmap.c:1663!
[ 588.699380] invalid opcode: [#2] PREEMPT SMP DEBUG_PAGEALLOC
[ 588.700347] Dumping ftrace buffer:
[ 588.701186](ftrace buffer empty)
[ 588.702062] Modules linked in:
[ 588.702759] CPU: 0 PID: 4647 Comm: kswapd0 Tainted: G D W
3.13.0-rc4-next-20131218-sasha-00012-g1962367-dirty #4155
[ 588.704330] task: 880062bcb000 ti: 88006245 task.ti:
88006245
[ 588.705507] RIP: 0010:[] []
rmap_walk+0x10/0x50
[ 588.706800] RSP: 0018:8800624518d8 EFLAGS: 00010246
[ 588.707515] RAX: 000f80080048 RBX: ea0227c0 RCX:
[ 588.707515] RDX: RSI: 8800624518e8 RDI: ea0227c0
[ 588.707515] RBP: 8800624518d8 R08: 8800624518e8 R09:
[ 588.707515] R10: R11: R12: 8800624519d8
[ 588.707515] R13: R14: ea0227e0 R15:
[ 588.707515] FS: () GS:88006520()
knlGS:
[ 588.707515] CS: 0010 DS: ES: CR0: 8005003b
[ 588.707515] CR2: 7fec40cbe0f8 CR3: c2382000 CR4: 06f0
[ 588.707515] Stack:
[ 588.707515] 880062451958 81289f4b 880062451918
81289f80
[ 588.707515] 8128af60
[ 588.707515] 0024
0286
[ 588.707515] Call Trace:
[ 588.707515] [] page_referenced+0xcb/0x100
[ 588.707515] [] ? page_referenced+0x100/0x100
[ 588.707515] [] ? invalid_page_referenced_vma+0x170/0x170
[ 588.707515] [] shrink_active_list+0x212/0x330
[ 588.707515] [] ? inactive_file_is_low+0x33/0x50
[ 588.707515] [] shrink_lruvec+0x2d5/0x300
[ 588.707515] [] shrink_zone+0x96/0x1e0
[ 588.707515] [] kswapd_shrink_zone+0xf6/0x1c0
[ 588.707515] [] balance_pgdat+0x373/0x550
[ 588.707515] [] kswapd+0x2f3/0x350
[ 588.707515] [] ?
perf_trace_mm_vmscan_lru_isolate_template+0x120/0x120
[ 588.707515] [] kthread+0x105/0x110
[ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30
[ 588.707515] [] ret_from_fork+0x7c/0xb0
[ 588.707515] [] ? set_kthreadd_affinity+0x30/0x30
[ 588.707515] Code: c0 48 83 c4 18 89 d0 5b 41 5c 41 5d 41 5e 41 5f c9 c3 66
0f 1f 84
00 00 00 00 00 55 48 89 e5 66 66 66 66 90 48 8b 07 a8 01 75 10 <0f> 0b 66 0f 1f
44 00 0
0 eb fe 66 0f 1f 44 00 00 f6 47 08 01 74
[ 588.707515] RIP [] rmap_walk+0x10/0x50
[ 588.707515] RSP
Reported-by: Sasha Levin
Signed-off-by: Wanpeng Li
---
mm/ksm.c | 5 +
mm/rmap.c | 20 ++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/mm/ksm.c b/mm/ksm.c
index c9a28dd..76d96df 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1899,6 +1899,11 @@ int rmap_walk_ksm(struct page *page, struct
rmap_walk_control *rwc)
int search_new_forks = 0;
VM_BUG_ON(!PageKsm(page));
+
+ /*
+* Rely on the page lock to protect against concurrent modifications
+* to that page's node of the stable tree.
+*/
VM_BUG_ON(!PageLocked(page));
stable_node = page_stable_node(page);
diff --git a/mm/rmap.c b/mm/rmap.c
index d792e71..db83961 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -769,6 +769,10 @@ int page_referenced(struct page *page,
struct page_referenced_arg pra = {
.mapcount = page_mapcount(page),
.memcg = memcg,
+ /*
+* reuse referenced field for the locked anonymous page check
+*/
+ .referenced = is_locked && PageAnon(page) && !PageKsm(page),
};
struct rmap_walk_control rwc = {
.rmap_one = page_referenced_one,
@@ -1587,6 +1591,12 @@ static int rmap_walk_anon(struct page *page, struct
rmap_walk_control *rwc)
pgoff_t pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
struct anon_vma_chain *avc;
int ret = SWAP_AGAIN;
+ struct page_referenced_arg *pra = rwc->arg;
+
+ if (pra->referenced) {
+ VM_BUG_ON(!PageLocked(page));
+ pra->referenced = 0;
+ }
anon_vma = rmap_walk_anon_lock(page, rwc);
if (!anon_vma)
@@ -1629,6 +1639,14 @@ static int rmap_walk_file(struct page *page, struct
rmap_walk_control *rwc)
struct vm_area_struct *vma;
int ret = SWAP_AGAIN;
+ /*
+* The page lock not only makes sure that
Re: [PATCH 3.4 00/31] 3.4.75-stable review
On Wed, Dec 18, 2013 at 06:02:45PM -0800, Guenter Roeck wrote: > On 12/18/2013 01:08 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.75 release. > > There are 31 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri Dec 20 21:05:11 UTC 2013. > > Anything received after that time might be too late. > > > Build results: > total: 103 pass: 89 skipped: 10 fail: 4 > > qemu tests all passed. > > Results are as expected. > Details are available as usual at http://server.roeck-us.net:8010/builders. Thanks for testing. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/78] 3.10.25-stable review
On Wed, Dec 18, 2013 at 06:04:09PM -0800, Guenter Roeck wrote: > On 12/18/2013 01:10 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.10.25 release. > > There are 78 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri Dec 20 21:10:56 UTC 2013. > > Anything received after that time might be too late. > > > > Build results: > total: 110 pass: 109 skipped: 0 fail: 1 > > Build avr32:atngw100mkii_evklcd101_defconfig still fails. > > qemu tests all passed. > > Results are as expected. > Details are available as usual at http://server.roeck-us.net:8010/builders. Thanks for testing and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/118] 3.12.6-stable review
On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.12.6 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Dec 20 21:12:03 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc1.gz > and the diffstat can be found below. Thanks to a bug on my part, there's now a -rc2 out for people to test with: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.12.6-rc2.gz Note, if you didn't have a build-failure with -rc1 then no need to test -rc2, it's only a specific staging driver that had an issue. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 000/118] 3.12.6-stable review
On Wed, Dec 18, 2013 at 07:00:22PM -0800, Greg Kroah-Hartman wrote: > On Wed, Dec 18, 2013 at 06:56:58PM -0800, Greg Kroah-Hartman wrote: > > On Wed, Dec 18, 2013 at 03:48:57PM -0800, Guenter Roeck wrote: > > > On Wed, Dec 18, 2013 at 01:10:37PM -0800, Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 3.12.6 release. > > > > There are 118 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Fri Dec 20 21:12:03 UTC 2013. > > > > Anything received after that time might be too late. > > > > > > > > > > Hi greg, > > > > > > I see a couple of failed builds. > > > > > > m68k:allmodconfig ... failed > > > mips:allmodconfig ... failed > > > sparc64:allmodconfig ... failed > > > x86_64:allyesconfig ... failed > > > x86_64:allmodconfig ... failed > > > > > > Build is still going on, so there may be more. > > > > > > Error log: > > > > > > drivers/staging/comedi/drivers/ssv_dnp.c: In function 'dnp_dio_insn_bits': > > > drivers/staging/comedi/drivers/ssv_dnp.c:63:2: error: implicit > > > declaration of function 'comedi_dio_update_state' > > > [-Werror=implicit-function-declaration] > > > cc1: some warnings being treated as errors > > > make[4]: *** [drivers/staging/comedi/drivers/ssv_dnp.o] Error 1 > > > > > > Function comedi_dio_update_state() is not defined anywhere in 3.12, > > > so patches > > >staging: comedi: ssv_dnp: use comedi_dio_update_state() > > >staging: comedi: drivers: use comedi_dio_update_state() for simple > > > cases > > > > > > won't apply without additional changes. > > > > Odd, let me see what happened, as I thought this was building properly > > on my test boxes... > > Ah, I didn't have COMPILE_TEST enabled, now I see the problem, my fault, > I'll go fix this up now... Ok, found this, it was my fault, I tried to take more of one of Ian's patches than what he had actually sent me. I'll do a -rc2 in a few minutes, thanks so much for the build testing. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] AX88179_178A: Add FLAG_HW_IPALIGN to determine whether reserving NET_IP_ALIGN bytes for an SKB.
On 2013年12月16日 18:09, David Laight wrote: I was thinking of something like: skb = netdev_alloc_skb(dev, length + dev->skb_align, gfp); if (NET_IP_ALIGN && skb && !(ev->driver_flags & FLAG_HW_IPALIGN)) skb_reserve(skb, NET_IP_ALIGN); It might even be reasonable to remove the length adjustment - provided that all the later code uses the skb length. David Thanks for your advice. In the way you advised, does the dev->skb_align equal to NET_IP_ALIGN in the case that HW doesn't supoort IP alignment? In other words, dev->skb_align should be initialized to NET_IP_ALIGN in USBNET, and I can change its value to 0 in AX88179_178A driver, right? Freddy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
