Re: [PATCH v2] lib: make sg_pool tristate instead of bool

> "Paul" == Paul Gortmaker writes: Paul> The recently added Kconfig controlling compilation of this code Paul> is: lib/Kconfig:config SG_POOL lib/Kconfig: def_bool n Paul> ...meaning that it currently is not being built as a module by Paul> anyone, and that

Re: [PATCH v2] lib: make sg_pool tristate instead of bool

> "Paul" == Paul Gortmaker writes: Paul> The recently added Kconfig controlling compilation of this code Paul> is: lib/Kconfig:config SG_POOL lib/Kconfig: def_bool n Paul> ...meaning that it currently is not being built as a module by Paul> anyone, and that tripped my audit looking for

Re: [PATCH 0/9] thermal: rockchip: Support rk3366/rk3399 SoCS and fixes the driver

On Mon, Apr 18, 2016 at 11:35:52AM +0800, Caesar Wang wrote: > Hello Eduardo, Heiko > This series pacthes to support the rk3366/rk3399 SoCs thermal, and fixes the > driver. > > 65ae684 thermal: rockchip: disable thermal->clk in err case > 31e6d69 thermal: rockchip: fixes the code_to_temp for

Re: [PATCH 0/9] thermal: rockchip: Support rk3366/rk3399 SoCS and fixes the driver

On Mon, Apr 18, 2016 at 11:35:52AM +0800, Caesar Wang wrote: > Hello Eduardo, Heiko > This series pacthes to support the rk3366/rk3399 SoCs thermal, and fixes the > driver. > > 65ae684 thermal: rockchip: disable thermal->clk in err case > 31e6d69 thermal: rockchip: fixes the code_to_temp for

Re: [PATCH v4 00/13] Support non-lru page migration

Hello Andrew, On Wed, Apr 27, 2016 at 01:20:35PM -0700, Andrew Morton wrote: > On Wed, 27 Apr 2016 16:48:13 +0900 Minchan Kim wrote: > > > Recently, I got many reports about perfermance degradation in embedded > > system(Android mobile phone, webOS TV and so on) and easy

Re: [PATCH v4 00/13] Support non-lru page migration

Hello Andrew, On Wed, Apr 27, 2016 at 01:20:35PM -0700, Andrew Morton wrote: > On Wed, 27 Apr 2016 16:48:13 +0900 Minchan Kim wrote: > > > Recently, I got many reports about perfermance degradation in embedded > > system(Android mobile phone, webOS TV and so on) and easy fork fail. > > > > The

Re: [PATCH 4/9] thermal: rockchip: handle the power sequence for tsadc controller

On Mon, Apr 18, 2016 at 11:35:56AM +0800, Caesar Wang wrote: > This adds the grf property to handle the tsadc power sequence on > rockchip some SoCs. > > Verified on rk3399 can work with this patch on now. > > while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp > sleep .5; done >

Re: [PATCH 4/9] thermal: rockchip: handle the power sequence for tsadc controller

On Mon, Apr 18, 2016 at 11:35:56AM +0800, Caesar Wang wrote: > This adds the grf property to handle the tsadc power sequence on > rockchip some SoCs. > > Verified on rk3399 can work with this patch on now. > > while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp > sleep .5; done >

Re: [PATCH] fujitsu-laptop: Use IS_ENABLED() instead of checking for built-in or module

On Tue, Apr 26, 2016 at 06:28:17PM -0400, Javier Martinez Canillas wrote: > The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either > built-in or as a module, use that macro instead of open coding the same. > > Signed-off-by: Javier Martinez Canillas

Re: [PATCH] fujitsu-laptop: Use IS_ENABLED() instead of checking for built-in or module

On Tue, Apr 26, 2016 at 06:28:17PM -0400, Javier Martinez Canillas wrote: > The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either > built-in or as a module, use that macro instead of open coding the same. > > Signed-off-by: Javier Martinez Canillas Acked-by: Jonathan Woithe

Re: [PATCH v2 1/9] thermal: tegra: add Tegra132 specific SOC_THERM driver

On Wed, Apr 27, 2016 at 11:25:46AM +0800, Wei Ni wrote: > add Tegra132 specific SOC_THERM driver. Applied this one. You may also add my Acked-by: Eduardo Valentin for patches 2 and 3. Remaining of the patches need to be further discussed. > > Signed-off-by: Wei Ni

Re: [PATCH v2 1/9] thermal: tegra: add Tegra132 specific SOC_THERM driver

On Wed, Apr 27, 2016 at 11:25:46AM +0800, Wei Ni wrote: > add Tegra132 specific SOC_THERM driver. Applied this one. You may also add my Acked-by: Eduardo Valentin for patches 2 and 3. Remaining of the patches need to be further discussed. > > Signed-off-by: Wei Ni

Re: [PATCH] Documentation: Fix typos on several lines

On 04/27/16 12:39, Kyeongmin Cho wrote: > There are many lines containing incorrect spelling words and needless spaces. > They should be fixed. > > Signed-off-by: Kyeongmin Cho Acked-by: Randy Dunlap Thanks. > --- > Documentation/cpu-hotplug.txt

Re: [PATCH] Documentation: Fix typos on several lines

On 04/27/16 12:39, Kyeongmin Cho wrote: > There are many lines containing incorrect spelling words and needless spaces. > They should be fixed. > > Signed-off-by: Kyeongmin Cho Acked-by: Randy Dunlap Thanks. > --- > Documentation/cpu-hotplug.txt | 2 +- > Documentation/devices.txt

Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions

On 27-04-16 05:40, Jarkko Sakkinen wrote: >> The hardware supports calling EEXTEND on only a part of a page, I think the >> driver should also support that. > > Why would you want to do that? You might have segments in a binary that don't start at the beginning of a page or that end before the

Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions

On 27-04-16 05:40, Jarkko Sakkinen wrote: >> The hardware supports calling EEXTEND on only a part of a page, I think the >> driver should also support that. > > Why would you want to do that? You might have segments in a binary that don't start at the beginning of a page or that end before the

Re: [PATCH v2 4/9] of: Add bindings of hw throttle for soctherm

From: Eduardo Valentin To: Wei Ni Cc: thierry.red...@gmail.com, robh...@kernel.org, rui.zh...@intel.com, mlongnec...@nvidia.com, swar...@wwwdotorg.org, mikko.perttu...@kapsi.fi, linux-te...@vger.kernel.org, linux...@vger.kernel.org,

Re: [PATCH v2 4/9] of: Add bindings of hw throttle for soctherm

From: Eduardo Valentin To: Wei Ni Cc: thierry.red...@gmail.com, robh...@kernel.org, rui.zh...@intel.com, mlongnec...@nvidia.com, swar...@wwwdotorg.org, mikko.perttu...@kapsi.fi, linux-te...@vger.kernel.org, linux...@vger.kernel.org, devicet...@vger.kernel.org,

Re: [PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly

On Thu, Apr 28, 2016 at 12:34:18AM +0200, Arnd Bergmann wrote: > The rtc-generic driver provides an architecture specific > wrapper on top of the generic rtc_class_ops abstraction, > and on sh, that goes through another indirection using > the rtc_sh_get_time/rtc_sh_set_time functions. > > This

Re: [PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly

On Thu, Apr 28, 2016 at 12:34:18AM +0200, Arnd Bergmann wrote: > The rtc-generic driver provides an architecture specific > wrapper on top of the generic rtc_class_ops abstraction, > and on sh, that goes through another indirection using > the rtc_sh_get_time/rtc_sh_set_time functions. > > This

Re: [RFC 12/20] net: dsa: rename dst->ds to dst->switches

On Wed, Apr 27, 2016 at 06:30:09PM -0400, Vivien Didelot wrote: > dsa_switch stores the net_device pointers in a "ports" member. Be > consistent and store the dsa_switch pointer in a "switches" member of > the dsa_switch_tree structure. > > This free us the "ds" member for a future dsa_switch

Re: [RFC 12/20] net: dsa: rename dst->ds to dst->switches

On Wed, Apr 27, 2016 at 06:30:09PM -0400, Vivien Didelot wrote: > dsa_switch stores the net_device pointers in a "ports" member. Be > consistent and store the dsa_switch pointer in a "switches" member of > the dsa_switch_tree structure. > > This free us the "ds" member for a future dsa_switch

Re: [RFC 07/20] net: dsa: list ports in switch\\

On Wed, Apr 27, 2016 at 06:30:04PM -0400, Vivien Didelot wrote: > List DSA port structures in their switch structure, so that drivers can > iterate on them to retrieve information such as their ports membership. And this would be so much easier using a plan array. Andrew > > Signed-off-by:

[PATCH] cpufreq: governor: Change confusing struct field and variable names

From: Rafael J. Wysocki The name of the prev_cpu_wall field in struct cpu_dbs_info is confusing, because it doesn't represent wall time, but the previous update time as returned by get_cpu_idle_time() (that may be the current value of jiffies_64 in some cases, for

Re: [RFC 07/20] net: dsa: list ports in switch\\

On Wed, Apr 27, 2016 at 06:30:04PM -0400, Vivien Didelot wrote: > List DSA port structures in their switch structure, so that drivers can > iterate on them to retrieve information such as their ports membership. And this would be so much easier using a plan array. Andrew > > Signed-off-by:

[PATCH] cpufreq: governor: Change confusing struct field and variable names

From: Rafael J. Wysocki The name of the prev_cpu_wall field in struct cpu_dbs_info is confusing, because it doesn't represent wall time, but the previous update time as returned by get_cpu_idle_time() (that may be the current value of jiffies_64 in some cases, for example). Moreover, the names

Re: [RFC 03/20] net: dsa: pass dsa_port down to drivers bridge ops

On Wed, Apr 27, 2016 at 06:30:00PM -0400, Vivien Didelot wrote: > Now that DSA as proper structure for DSA ports, pass it down to the > port_bridge_join and port_bridge_leave driver functions. I should look at the later patches, but this looks like a step backwards. If your ports array is a

Re: [RFC 03/20] net: dsa: pass dsa_port down to drivers bridge ops

On Wed, Apr 27, 2016 at 06:30:00PM -0400, Vivien Didelot wrote: > Now that DSA as proper structure for DSA ports, pass it down to the > port_bridge_join and port_bridge_leave driver functions. I should look at the later patches, but this looks like a step backwards. If your ports array is a

Re: [RFC 01/20] net: dsa: introduce a dsa_port structure

> @@ -230,6 +231,13 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, > struct device *parent) > for (i = 0; i < DSA_MAX_PORTS; i++) { > char *name; > > + dp[i] = devm_kzalloc(parent, sizeof(*dp), GFP_KERNEL); > + if (dp[i] == NULL) > +

Re: [RFC 01/20] net: dsa: introduce a dsa_port structure

> @@ -230,6 +231,13 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, > struct device *parent) > for (i = 0; i < DSA_MAX_PORTS; i++) { > char *name; > > + dp[i] = devm_kzalloc(parent, sizeof(*dp), GFP_KERNEL); > + if (dp[i] == NULL) > +

Re: [PATCH v3 09/16] rtc: m68k: provide rtc_class_ops directly

On Thursday 28 April 2016 00:34:23 Arnd Bergmann wrote: > return -ENODEV; > > - pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0); > + /* or just call devm_rtc_device_register instead? */ Oops, I was planning to remove the comment here. I probably

Re: [PATCH v3 09/16] rtc: m68k: provide rtc_class_ops directly

On Thursday 28 April 2016 00:34:23 Arnd Bergmann wrote: > return -ENODEV; > > - pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0); > + /* or just call devm_rtc_device_register instead? */ Oops, I was planning to remove the comment here. I probably

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Wed, Apr 27, 2016 at 10:03:11AM +0200, Michal Hocko wrote: > On Wed 27-04-16 08:58:45, Dave Chinner wrote: > > On Tue, Apr 26, 2016 at 01:56:12PM +0200, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > THIS PATCH IS FOR TESTING ONLY AND NOT MEANT TO HIT LINUS TREE > >

Re: [PATCH 2/2] mm, debug: report when GFP_NO{FS,IO} is used explicitly from memalloc_no{fs,io}_{save,restore} context

On Wed, Apr 27, 2016 at 10:03:11AM +0200, Michal Hocko wrote: > On Wed 27-04-16 08:58:45, Dave Chinner wrote: > > On Tue, Apr 26, 2016 at 01:56:12PM +0200, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > THIS PATCH IS FOR TESTING ONLY AND NOT MEANT TO HIT LINUS TREE > > > > > > It is

[PATCH v3 00/16] genrtc removal

I ended up stuffing the two patch series into one, as they are now more dependent on one another. This now thoroughly removes the genrtc driver including the asm/rtc.h headers it uses. For all architectures that still have a meaningful asm/rtc.h, this goes through two stages: 1) make the

[PATCH v3 09/16] rtc: m68k: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and m68k has another abstraction on top, which is a bit silly. This changes the m68k rtc-generic device to provide its rtc_class_ops directly, to reduce the number of layers by one.

[PATCH v3 00/16] genrtc removal

I ended up stuffing the two patch series into one, as they are now more dependent on one another. This now thoroughly removes the genrtc driver including the asm/rtc.h headers it uses. For all architectures that still have a meaningful asm/rtc.h, this goes through two stages: 1) make the

[PATCH v3 09/16] rtc: m68k: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and m68k has another abstraction on top, which is a bit silly. This changes the m68k rtc-generic device to provide its rtc_class_ops directly, to reduce the number of layers by one.

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote: > A bit of digging will tell us that this is the failing line: > > m_n_config.v = uv_read_local_mmr(UVH_RH_GAM_CONFIG_MMR ); That looks like All code 0: 65 48 03 05 1d b8 49add%gs:0x7e49b81d(%rip),%rax#

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote: > A bit of digging will tell us that this is the failing line: > > m_n_config.v = uv_read_local_mmr(UVH_RH_GAM_CONFIG_MMR ); That looks like All code 0: 65 48 03 05 1d b8 49add%gs:0x7e49b81d(%rip),%rax#

Re: [PATCH 05/15] staging: lustre: ldlm: use accessor macros for l_flags

Wow! I remember this stuff, even if from 3 years ago. Feels like a lifetime. Is this patch being applied to official Linux, hence this message? Xyratex collapsed, shed a mess of employees and sold the remnant to Seagate. Consequently, I don't really follow Lustre any more. Sorry. On

Re: [PATCH 05/15] staging: lustre: ldlm: use accessor macros for l_flags

Wow! I remember this stuff, even if from 3 years ago. Feels like a lifetime. Is this patch being applied to official Linux, hence this message? Xyratex collapsed, shed a mess of employees and sold the remnant to Seagate. Consequently, I don't really follow Lustre any more. Sorry. On

[PATCH v3 06/16] char/genrtc: remove mn10300 support

The genrtc driver serves no purpose on mn10300 because it drives the same hardware as the original rtc.c driver, and the newer rtc-generic.c or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h header. I assume it was initially only added for completeness when the mn10300 port

[PATCH v3 13/16] char/genrtc: remove powerpc support

PowerPC is the last architecture using the GEN_RTC driver on some machines, but we can migrate them all to using the RTC_DRV_GENERIC driver instead now. This moves over the CONFIG_GEN_RTC option from drivers/char into arch/powerpc/platforms/Kconfig and makes it just select the replacement driver

[PATCH v3 06/16] char/genrtc: remove mn10300 support

The genrtc driver serves no purpose on mn10300 because it drives the same hardware as the original rtc.c driver, and the newer rtc-generic.c or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h header. I assume it was initially only added for completeness when the mn10300 port

[PATCH v3 13/16] char/genrtc: remove powerpc support

PowerPC is the last architecture using the GEN_RTC driver on some machines, but we can migrate them all to using the RTC_DRV_GENERIC driver instead now. This moves over the CONFIG_GEN_RTC option from drivers/char into arch/powerpc/platforms/Kconfig and makes it just select the replacement driver

[PATCH v3 05/16] char/genrtc: remove alpha support

The genrtc driver serves no purpose on Alpha because it drives the same hardware as the original rtc.c driver, and the newer rtc-generic.c or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h header. The defconfig uses CONFIG_RTC=y, so this driver is not used by default. At one

[PATCH v3 14/16] rtc: generic: remove get_rtc_time/set_rtc_time wrappers

All architectures using this driver are now converted to provide their own operations, so this one can be turned into a trivial stub driver relying on its platform data. Signed-off-by: Arnd Bergmann --- drivers/rtc/rtc-generic.c | 35 +-- 1 file

[PATCH v3 05/16] char/genrtc: remove alpha support

The genrtc driver serves no purpose on Alpha because it drives the same hardware as the original rtc.c driver, and the newer rtc-generic.c or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h header. The defconfig uses CONFIG_RTC=y, so this driver is not used by default. At one

[PATCH v3 14/16] rtc: generic: remove get_rtc_time/set_rtc_time wrappers

All architectures using this driver are now converted to provide their own operations, so this one can be turned into a trivial stub driver relying on its platform data. Signed-off-by: Arnd Bergmann --- drivers/rtc/rtc-generic.c | 35 +-- 1 file changed, 1

[RFC 05/20] net: dsa: pass dsa_port down to drivers VLAN ops

Now that DSA as proper structure for DSA ports, pass it down to the port_vlan_{filtering,prepare,add,del,dump} driver functions. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 41 +

[RFC 05/20] net: dsa: pass dsa_port down to drivers VLAN ops

Now that DSA as proper structure for DSA ports, pass it down to the port_vlan_{filtering,prepare,add,del,dump} driver functions. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 41 + drivers/net/dsa/mv88e6xxx.h | 10 +-

[RFC 00/20] net: dsa: dsa_port structure and tree-wide ops

In a previous RFC [1], I introduced the need to implement cross-chip operations in the DSA layer. Here's a summary. In a multiple switches setup such as the following, every switch of the tree must be aware of its configuration in order to configure a correct data path between chips.

[RFC 03/20] net: dsa: pass dsa_port down to drivers bridge ops

Now that DSA as proper structure for DSA ports, pass it down to the port_bridge_join and port_bridge_leave driver functions. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 28 ++-- drivers/net/dsa/mv88e6xxx.c | 10

[RFC 03/20] net: dsa: pass dsa_port down to drivers bridge ops

Now that DSA as proper structure for DSA ports, pass it down to the port_bridge_join and port_bridge_leave driver functions. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 28 ++-- drivers/net/dsa/mv88e6xxx.c | 10 +- drivers/net/dsa/mv88e6xxx.h

[RFC 00/20] net: dsa: dsa_port structure and tree-wide ops

In a previous RFC [1], I introduced the need to implement cross-chip operations in the DSA layer. Here's a summary. In a multiple switches setup such as the following, every switch of the tree must be aware of its configuration in order to configure a correct data path between chips.

[PATCH v3 12/16] rtc: powerpc: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and powerpc has another abstraction on top, which is a bit silly. This changes the powerpc rtc-generic device to provide its rtc_class_ops directly, to reduce the number of layers by

[PATCH v3 16/16] char/genrtc: remove the rest of the driver

No architecture uses the genrtc driver any more, so let's kill it off for good. This now also includes asm-generic/rtc.h, which is otherwise completely unused. Signed-off-by: Arnd Bergmann --- drivers/char/Kconfig | 26 --- drivers/char/Makefile | 1 -

[PATCH v3 08/16] char/genrtc: remove parisc support

This architecture selects RTC_CLASS unconditionally, so the GEN_RTC has not worked here for a long time. Now we can remove both the asm/rtc.h header and the Kconfig dependency for CONFIG_GEN_RTC. Signed-off-by: Arnd Bergmann --- arch/parisc/include/asm/rtc.h | 131

[PATCH v3 12/16] rtc: powerpc: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and powerpc has another abstraction on top, which is a bit silly. This changes the powerpc rtc-generic device to provide its rtc_class_ops directly, to reduce the number of layers by

[PATCH v3 16/16] char/genrtc: remove the rest of the driver

No architecture uses the genrtc driver any more, so let's kill it off for good. This now also includes asm-generic/rtc.h, which is otherwise completely unused. Signed-off-by: Arnd Bergmann --- drivers/char/Kconfig | 26 --- drivers/char/Makefile | 1 - drivers/char/genrtc.c |

[PATCH v3 08/16] char/genrtc: remove parisc support

This architecture selects RTC_CLASS unconditionally, so the GEN_RTC has not worked here for a long time. Now we can remove both the asm/rtc.h header and the Kconfig dependency for CONFIG_GEN_RTC. Signed-off-by: Arnd Bergmann --- arch/parisc/include/asm/rtc.h | 131

[PATCH v3 07/16] rtc: parisc: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and on pa-risc, that is implemented using an open-coded version of rtc_time_to_tm/rtc_tm_to_time. This changes the parisc rtc-generic device to provide its rtc_class_ops directly,

[PATCH v3 03/16] char/genrtc: x86: remove remnants of asm/rtc.h

Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had the side-effect of unconditionally enabling the RTC_LIB symbol on x86, which in turn disables the selection of the CONFIG_RTC and CONFIG_GEN_RTC drivers that contain a two older implementations of the CONFIG_RTC_DRV_CMOS driver.

[PATCH v3 07/16] rtc: parisc: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and on pa-risc, that is implemented using an open-coded version of rtc_time_to_tm/rtc_tm_to_time. This changes the parisc rtc-generic device to provide its rtc_class_ops directly,

[PATCH v3 03/16] char/genrtc: x86: remove remnants of asm/rtc.h

Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had the side-effect of unconditionally enabling the RTC_LIB symbol on x86, which in turn disables the selection of the CONFIG_RTC and CONFIG_GEN_RTC drivers that contain a two older implementations of the CONFIG_RTC_DRV_CMOS driver.

[RFC 11/20] net: dsa: mv88e6xxx: use bridge from dsa_port

Change the _mv88e6xxx_port_based_vlan_map function for a _mv88e6xxx_port_map_vlantable which takes a dsa_port structure as parameter. This allows us to iterate on dsa_port's bridge device pointer and thus get rid of the private bridge_dev structure. Signed-off-by: Vivien Didelot

[RFC 12/20] net: dsa: rename dst->ds to dst->switches

dsa_switch stores the net_device pointers in a "ports" member. Be consistent and store the dsa_switch pointer in a "switches" member of the dsa_switch_tree structure. This free us the "ds" member for a future dsa_switch list. Signed-off-by: Vivien Didelot

[PATCH v3 01/16] rtc: cmos: remove empty asm/mc146818rtc.h files

Nothing on these architectures ever includes the asm/mc146818rtc.h file, the drivers that used to do this have been fixed long ago, and the remaining users are all PC-specific. This removes the files for good. Signed-off-by: Arnd Bergmann Acked-by: Alexandre Belloni

[PATCH v3 10/16] rtc: m68k: provide ioctl for q40

The q40 platform is the only machine in the kernel that provides RTC_PLL_GET/RTC_PLL_SET ioctl commands in its rtc through the mach_get_rtc_pll/mach_set_rtc_pll callbacks. However, this currenctly works only in the old-style genrtc driver, not the (somewhat) modern rtc-generic driver replacing

[RFC 11/20] net: dsa: mv88e6xxx: use bridge from dsa_port

Change the _mv88e6xxx_port_based_vlan_map function for a _mv88e6xxx_port_map_vlantable which takes a dsa_port structure as parameter. This allows us to iterate on dsa_port's bridge device pointer and thus get rid of the private bridge_dev structure. Signed-off-by: Vivien Didelot ---

[RFC 12/20] net: dsa: rename dst->ds to dst->switches

dsa_switch stores the net_device pointers in a "ports" member. Be consistent and store the dsa_switch pointer in a "switches" member of the dsa_switch_tree structure. This free us the "ds" member for a future dsa_switch list. Signed-off-by: Vivien Didelot --- include/net/dsa.h | 2 +-

[PATCH v3 01/16] rtc: cmos: remove empty asm/mc146818rtc.h files

Nothing on these architectures ever includes the asm/mc146818rtc.h file, the drivers that used to do this have been fixed long ago, and the remaining users are all PC-specific. This removes the files for good. Signed-off-by: Arnd Bergmann Acked-by: Alexandre Belloni ---

[PATCH v3 10/16] rtc: m68k: provide ioctl for q40

The q40 platform is the only machine in the kernel that provides RTC_PLL_GET/RTC_PLL_SET ioctl commands in its rtc through the mach_get_rtc_pll/mach_set_rtc_pll callbacks. However, this currenctly works only in the old-style genrtc driver, not the (somewhat) modern rtc-generic driver replacing

[RFC 07/20] net: dsa: list ports in switch

List DSA port structures in their switch structure, so that drivers can iterate on them to retrieve information such as their ports membership. Signed-off-by: Vivien Didelot --- include/net/dsa.h | 9 + net/dsa/dsa.c | 4 2 files changed, 13

[PATCH v3 02/16] rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Drivers should not really include stuff from asm-generic directly, and the PC-style cmos rtc driver does this in order to reuse the mc146818 implementation of get_rtc_time/set_rtc_time rather than the architecture specific one for the architecture it gets built for. To make it more obvious what

[PATCH v3 11/16] char/genrtc: remove m68k support

The asm/rtc.h header is only used for the old gen_rtc driver that has been replaced by rtc-generic. According to Geert Uytterhoeven, nobody has used the old driver on m68k for a long time, so we can now just remove the header file and disallow the driver in Kconfig. All files that used to include

[RFC 07/20] net: dsa: list ports in switch

List DSA port structures in their switch structure, so that drivers can iterate on them to retrieve information such as their ports membership. Signed-off-by: Vivien Didelot --- include/net/dsa.h | 9 + net/dsa/dsa.c | 4 2 files changed, 13 insertions(+) diff --git

[PATCH v3 02/16] rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h

Drivers should not really include stuff from asm-generic directly, and the PC-style cmos rtc driver does this in order to reuse the mc146818 implementation of get_rtc_time/set_rtc_time rather than the architecture specific one for the architecture it gets built for. To make it more obvious what

[PATCH v3 11/16] char/genrtc: remove m68k support

The asm/rtc.h header is only used for the old gen_rtc driver that has been replaced by rtc-generic. According to Geert Uytterhoeven, nobody has used the old driver on m68k for a long time, so we can now just remove the header file and disallow the driver in Kconfig. All files that used to include

[PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and on sh, that goes through another indirection using the rtc_sh_get_time/rtc_sh_set_time functions. This changes the sh rtc-generic device to provide its rtc_class_ops directly,

[PATCH v3 15/16] char/genrtc: remove asm-generic/rtc.h from mips

arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason, and it works fine without that header, so lets remove the inclusion in preparation of deleting the file. Signed-off-by: Arnd Bergmann --- arch/mips/sni/time.c | 1 - 1 file changed, 1 deletion(-) diff --git

[RFC 10/20] net: dsa: mv88e6xxx: setup a dsa_port

Change the mv88e6xxx_setup_port function to take a dsa_port structure as parameter instead of a port index. This will help us get rid of the private bridge_dev pointer. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 64

[PATCH v3 15/16] char/genrtc: remove asm-generic/rtc.h from mips

arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason, and it works fine without that header, so lets remove the inclusion in preparation of deleting the file. Signed-off-by: Arnd Bergmann --- arch/mips/sni/time.c | 1 - 1 file changed, 1 deletion(-) diff --git

[RFC 10/20] net: dsa: mv88e6xxx: setup a dsa_port

Change the mv88e6xxx_setup_port function to take a dsa_port structure as parameter instead of a port index. This will help us get rid of the private bridge_dev pointer. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 64 - 1 file

[PATCH v3 04/16] rtc: sh: provide rtc_class_ops directly

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and on sh, that goes through another indirection using the rtc_sh_get_time/rtc_sh_set_time functions. This changes the sh rtc-generic device to provide its rtc_class_ops directly,

[RFC 17/20] net: dsa: mv88e6xxx: factorize port bridge change

Implement a mv88e6xxx_port_bridge_change function to factorize the configuration needed when a port joins or leaves a bridge group. This will simplify the implementation of cross-chip bridging. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c |

[RFC 17/20] net: dsa: mv88e6xxx: factorize port bridge change

Implement a mv88e6xxx_port_bridge_change function to factorize the configuration needed when a port joins or leaves a bridge group. This will simplify the implementation of cross-chip bridging. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 67

[RFC 09/20] net: dsa: mv88e6xxx: check HW vlan with dsa_port

Change the mv88e6xxx_port_check_hw_vlan function for a mv88e6xxx_port_check_vtu which takes a dsa_port structure as parameter. This will help us get rid of the bridge_dev pointer. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 25

[RFC 16/20] net: dsa: add tree-wide VLAN ops

In order to support cross-chip operations, we need to inform each switch driver when a port operation occurs in a DSA tree. Implement tree-wide VLAN operations. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 12 + net/dsa/dsa_priv.h

[RFC 14/20] net: dsa: add tree-wide bridge ops

In order to support cross-chip operations, we need to inform each switch driver when a port operation occurs in a DSA tree. This allows drivers to configure cross-chip port-based VLAN table, VTU or FDB entries on DSA links, in order to implement a correct hardware switching of frames. Add a new

[RFC 19/20] net: dsa: mv88e6xxx: conditionally init PVT

The current code initialize the Cross-chip Port VLAN Table to all ones, even tough the switch model doesn't have one. It also assumes that the switch is configured to support up to 32-switch/16-port cross-chip devices. Implement the access to the PVT and initialize it only if the switch has such

[RFC 09/20] net: dsa: mv88e6xxx: check HW vlan with dsa_port

Change the mv88e6xxx_port_check_hw_vlan function for a mv88e6xxx_port_check_vtu which takes a dsa_port structure as parameter. This will help us get rid of the bridge_dev pointer. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 25 - 1 file changed, 12

[RFC 16/20] net: dsa: add tree-wide VLAN ops

In order to support cross-chip operations, we need to inform each switch driver when a port operation occurs in a DSA tree. Implement tree-wide VLAN operations. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 12 + net/dsa/dsa_priv.h | 8 ++

[RFC 14/20] net: dsa: add tree-wide bridge ops

In order to support cross-chip operations, we need to inform each switch driver when a port operation occurs in a DSA tree. This allows drivers to configure cross-chip port-based VLAN table, VTU or FDB entries on DSA links, in order to implement a correct hardware switching of frames. Add a new

[RFC 19/20] net: dsa: mv88e6xxx: conditionally init PVT

The current code initialize the Cross-chip Port VLAN Table to all ones, even tough the switch model doesn't have one. It also assumes that the switch is configured to support up to 32-switch/16-port cross-chip devices. Implement the access to the PVT and initialize it only if the switch has such

[RFC 06/20] net: dsa: move bridge device in dsa_port

Move the pointer to the bridge device in the DSA port structure instead of cluttering the dsa_slave_priv structure. This can later be used by drivers to help them configuring their bridge group ports membership. Signed-off-by: Vivien Didelot ---

[RFC 06/20] net: dsa: move bridge device in dsa_port

Move the pointer to the bridge device in the DSA port structure instead of cluttering the dsa_slave_priv structure. This can later be used by drivers to help them configuring their bridge group ports membership. Signed-off-by: Vivien Didelot --- include/net/dsa.h | 2 ++ net/dsa/dsa_priv.h |

[RFC 18/20] net: dsa: mv88e6xxx: add flags to info

Add a flags bitmap to the mv88e6xxx_info structure to help describing features supported or not by a switch model. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.h | 11 +++ 1 file changed, 11 insertions(+) diff --git

[RFC 18/20] net: dsa: mv88e6xxx: add flags to info

Add a flags bitmap to the mv88e6xxx_info structure to help describing features supported or not by a switch model. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/dsa/mv88e6xxx.h

<    1   2   3   4   5   6   7   8   9   10   >