On Fri, Aug 30, 2019 at 02:45:36PM -0500, Eric W. Biederman wrote:
> Russell King - ARM Linux admin writes:
>
> > On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
> >> The function do_alignment can handle misaligned address for user and
> >> kern
On Fri, Aug 30, 2019 at 08:30:00AM -0700, Linus Torvalds wrote:
> On Fri, Aug 30, 2019 at 7:08 AM Russell King - ARM Linux admin
> wrote:
> >
> > which means that when probe_kernel_address() returns -EFAULT, the
> > destination is left uninitialised. In the case of
In commit 150593bf8693 ("sched/api: Introduce task_rcu_dereference() and
try_get_task_struct()") probe_kernel_address() is used without checking
it's return value, resulting in undefined behaviour of this function.
I stumbled over this due to looking at the definition of this function,
due to a
the
right to ignore your patches until this issue is resolved! ;)
On Fri, Aug 30, 2019 at 02:35:22PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
> > The function do_alignment can handle misaligned address for user and
&
On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
> The function do_alignment can handle misaligned address for user and
> kernel space. If it is a userspace access, do_alignment may fail on
> a low-memory situation, because page faults are disabled in
> probe_kernel_address.
>
>
On Fri, Aug 30, 2019 at 08:29:21AM +0200, Christoph Hellwig wrote:
> The arm architecture had a VM_ARM_DMA_CONSISTENT flag to mark DMA
> coherent remapping for a while. Lift this flag to common code so
> that we can use it generically. We also check it in the only place
> VM_USERMAP is directly
I'm sorry, I can't apply this, it produces loads of:
include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No
such file or directory
Since your patch 1 has been merged by the ARM64 people, I can't take
it until next cycle.
On Mon, Aug 19, 2019 at 05:18:08PM +0800, Leo Yan
On Tue, Aug 27, 2019 at 09:13:11PM +, Chris Packham wrote:
> On Tue, 2019-08-27 at 22:07 +0100, Russell King - ARM Linux admin
> wrote:
> > On Tue, Aug 27, 2019 at 08:56:05PM +, Chris Packham wrote:
> > > On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Li
On Tue, Aug 27, 2019 at 08:56:05PM +, Chris Packham wrote:
> On Tue, 2019-08-27 at 10:13 +0100, Russell King - ARM Linux admin
> wrote:
> > Just send the single patch to the patch tracker - having it against
> > 5.3-rc is fine (I don't think anything has chang
On Tue, Aug 27, 2019 at 03:52:17PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Aug 27, 2019 at 03:36:34PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Tue, Aug 27, 2019 at 03:55:23PM +0200, Ulf Hansson wrote:
> > > On Tue, 27 Aug 2019 at 15:43, Russell K
On Tue, Aug 27, 2019 at 03:36:34PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Aug 27, 2019 at 03:55:23PM +0200, Ulf Hansson wrote:
> > On Tue, 27 Aug 2019 at 15:43, Russell King - ARM Linux admin
> > wrote:
> > >
> > > Hi,
> > >
> > >
On Tue, Aug 27, 2019 at 03:55:23PM +0200, Ulf Hansson wrote:
> On Tue, 27 Aug 2019 at 15:43, Russell King - ARM Linux admin
> wrote:
> >
> > Hi,
> >
> > While dd'ing the contents of a SD card, I get hung task timeout
> > messages as per below. However, the d
Hi,
While dd'ing the contents of a SD card, I get hung task timeout
messages as per below. However, the dd is making progress. Any
ideas?
Presumably, mmc_rescan doesn't get a look-in while IO is progressing
for the card?
ARM64 host, Macchiatobin, uSD card.
Thanks.
root@arm-d063:~#
You need to find someone who is interested in Xen on 32-bit ARM, and
who knows this code - and therefore what impact your change causes.
That isn't me, sorry.
On Tue, Aug 27, 2019 at 09:27:53AM +, Peng Fan wrote:
> Ping again..
>
> +Julien
>
> > Subject: RE: [PATCH] arm: xen: mm: use
On Mon, Aug 26, 2019 at 12:46:44AM +, Chris Packham wrote:
> Hi Russell,
>
> On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux
> > admin wrote:
> > > I can't a
On Fri, Aug 23, 2019 at 11:40:50AM +0100, Will Deacon wrote:
> On Fri, Aug 23, 2019 at 11:36:54AM +0100, Russell King - ARM Linux admin
> wrote:
> > To everyone on the long Cc list...
> >
> > What's happening with this? I was about to merge the patches for 32-bit
>
On Fri, Aug 23, 2019 at 11:43:32AM +0100, Vincenzo Frascino wrote:
> Hi Russell,
>
> On 8/23/19 11:36 AM, Russell King - ARM Linux admin wrote:
> > Hi,
> >
> > To everyone on the long Cc list...
> >
> > What's happening with this? I was about to merge
On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> > From: Jan Luebbe
> >
> > The macro name is too generic, so add a AURORA_ prefix.
> >
> > Signed-off-by: Jan
On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> From: Jan Luebbe
>
> The macro name is too generic, so add a AURORA_ prefix.
>
> Signed-off-by: Jan Luebbe
> Reviewed-by: Gregory CLEMENT
> Signed-off-by: Chris Packham
> ---
> arch/arm/include/asm/hardware/cache-aurora-l2.h |
Hi,
To everyone on the long Cc list...
What's happening with this? I was about to merge the patches for 32-bit
ARM, which I don't want to do if doing so will cause this regression on
32-bit ARM as well.
Thanks.
On Thu, Aug 22, 2019 at 07:57:59AM +0100, Chris Clayton wrote:
> Hi everyone,
>
>
usar nuestros servicios en línea.
Zimbra Admin Help Desk.
Servicios de actualización 2019/2020
On Sun, Aug 18, 2019 at 11:20:35AM +0300, Mike Rapoport wrote:
> On Sun, Aug 18, 2019 at 03:46:51PM +0800, Zhaoyang Huang wrote:
> > On Sun, Aug 18, 2019 at 2:32 AM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Sat, Aug 17, 2019 at 11:00:13AM +0800, Z
On Sat, Aug 17, 2019 at 11:00:13AM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> pfn_valid can be wrong while the MSB of physical address be trimed as pfn
> larger than the max_pfn.
What scenario are you addressing here? At a guess, you're addressing
the non-LPAE case with PFNs that
On Fri, Aug 16, 2019 at 06:42:49PM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Aug 14, 2019 at 10:36:01AM +0200, Linus Walleij wrote:
> > On Mon, Aug 12, 2019 at 11:45 AM Martin Michlmayr wrote:
> > > As Arnd points out, Debian used to have support for various iop32x
> > > devices. While
On Wed, Aug 14, 2019 at 04:00:30PM -0700, Steve Longerbeam wrote:
>
>
> On 8/14/19 3:04 PM, Russell King - ARM Linux admin wrote:
> > On Wed, Aug 14, 2019 at 12:04:41PM -0700, Steve Longerbeam wrote:
> > >
> > > On 8/14/19 3:30 AM, Russell King - ARM Linux ad
On Wed, Aug 14, 2019 at 12:04:41PM -0700, Steve Longerbeam wrote:
>
>
> On 8/14/19 3:30 AM, Russell King - ARM Linux admin wrote:
> > On Tue, Aug 06, 2019 at 09:53:41AM -0700, Steve Longerbeam wrote:
> > > The full patchset doesn't seem to be up yet, but see [1] fo
On Tue, Aug 06, 2019 at 09:53:41AM -0700, Steve Longerbeam wrote:
> The full patchset doesn't seem to be up yet, but see [1] for the cover
> letter.
Was the entire series copied to the mailing lists, or just selected
patches? I only saw 4, 9, 11 and 13-22 via lakml.
In the absence of the other
I just did this:
rmmod imx-media
modprobe imx-media
and was greeted by the below kernel messages. I don't think this has
been the first issue I found with the iMX media stuff involving a module
unload/reload cycle - may I suggest that this is added to the testing
regime for this code? Thanks.
On Tue, Aug 06, 2019 at 06:39:36PM +0530, Manivannan Sadhasivam wrote:
> +Required Properties:
> +- compatible: Should be "sony,imx290"
> +- reg: I2C bus address of the device
> +- clocks: Reference to the xclk clock.
> +- clock-names: Should be "xclk".
> +- clock-frequency: Frequency of the xclk
On Fri, Aug 09, 2019 at 11:34:12AM -0700, Dan Williams wrote:
> [ add Martin (if cyrius.com address is still valid) ]
>
> On Fri, Aug 9, 2019 at 9:35 AM Arnd Bergmann wrote:
> >
> > There are three families of IOP machines we support in Linux: iop32x
> > (which includes EP80219), iop33x and
On Tue, Jul 30, 2019 at 03:18:31PM +0800, Chunyan Zhang wrote:
> Gentle ping
>
> probably this patch was missed or entered into spam?
Please submit it to the patch system, thanks.
>
> On Mon, 22 Jul 2019 at 15:14, Chunyan Zhang wrote:
> >
> > From: Lvqiang Huang
> >
> > In the commit
On Tue, Jul 30, 2019 at 12:43:26AM -0400, Luis Araneda wrote:
> This fixes a kernel panic (read overflow) on memcpy when
> FORTIFY_SOURCE is enabled.
>
> The computed size of memcpy args are:
> - p_size (dst): 4294967295 = (size_t) -1
> - q_size (src): 1
> - size (len): 8
>
> Additionally, the
On Thu, Jul 25, 2019 at 06:24:01PM -0400, George G. Davis wrote:
> Hello Russell,
>
> On Thu, Jul 25, 2019 at 10:55:40PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Thu, Jul 25, 2019 at 05:37:54PM -0400, George G. Davis wrote:
> > > Hello Russell,
> >
On Thu, Jul 25, 2019 at 02:42:22PM -0700, Matthew Wilcox wrote:
> On Thu, Jul 25, 2019 at 10:38:58PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Thu, Jul 25, 2019 at 07:39:21AM -0700, Matthew Wilcox wrote:
> > > But 'page' isn't necessarily PMD-aligned. I do
On Thu, Jul 25, 2019 at 05:37:54PM -0400, George G. Davis wrote:
> Hello Russell,
>
> Thanks for your prompt reply!
>
> On Sat, Jul 20, 2019 at 01:30:23PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, Jul 19, 2019 at 10:32:55PM -0400, George G. Davis wrote:
On Thu, Jul 25, 2019 at 12:25:23PM +0530, Anshuman Khandual wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
On Thu, Jul 25, 2019 at 07:39:21AM -0700, Matthew Wilcox wrote:
> On Thu, Jul 25, 2019 at 12:25:23PM +0530, Anshuman Khandual wrote:
> > This adds a test module which will validate architecture page table helpers
> > and accessors regarding compliance with generic MM semantics expectations.
> >
On Fri, Jul 19, 2019 at 01:35:23AM +0900, Masahiro Yamada wrote:
> When you run "make clean" for arm, it never visits mach-* or plat-*
> directories because machine-y and plat-y are just empty.
>
> When cleaning, all machine, plat directories are accumulated to
> machine-, plat-, respectively.
On Thu, Jul 25, 2019 at 01:27:58PM +, Parshuram Raju Thombare wrote:
> Hi Andrew,
>
> >One thing which was never clear is how you are testing the features you are
> >adding. Please could you describe your test setup and how each new feature
> >is tested using that hardware. I'm particularly
On Mon, Jul 22, 2019 at 01:47:57PM +0100, Marc Zyngier wrote:
> On 22/07/2019 12:25, Petr Mladek wrote:
> > On Mon 2019-07-22 11:33:28, Marc Zyngier wrote:
> >> printk currently relies on local_clock to time-stamp the kernel
> >> messages. In order to allow the timestamping (and only that)
> >> to
On Fri, Jul 19, 2019 at 10:32:55PM -0400, George G. Davis wrote:
> When an unhandled data or prefetch abort occurs, the die() string
> is empty resulting in backtrace messages similar to the following:
>
> Internal error: : 1 [#1] PREEMPT SMP ARM
>
> Replace the null string with the name
On Fri, Jul 12, 2019 at 06:04:40PM +0800, Cheng-Yi Chiang wrote:
> Allow codec driver register callback function for plug event.
>
> The callback registration flow:
> dw-hdmi <--- hw-hdmi-i2s-audio <--- hdmi-codec
>
> dw-hdmi-i2s-audio implements hook_plugged_cb op
> so codec driver can register
ng mem= kernel
> > > command-line). For these regions, pfn_valid would return "false" causing
> > > system RAM to be mapped as uncached. Use memblock instead to identify RAM.
> >
> > Once the remaining memory is outside of the kernel (as the admin would have
>
On Wed, Jul 10, 2019 at 07:43:19PM +0900, Masahiro Yamada wrote:
> On Wed, Jul 10, 2019 at 7:02 PM Russell King - ARM Linux admin
> wrote:
> >
> > On Wed, Jul 10, 2019 at 06:54:06PM +0900, Masahiro Yamada wrote:
> > > On Wed, Jul 10, 2019 at 5:23 PM Russell King - A
On Wed, Jul 10, 2019 at 11:02:06AM +0100, Russell King - ARM Linux admin wrote:
> On Wed, Jul 10, 2019 at 06:54:06PM +0900, Masahiro Yamada wrote:
> > On Wed, Jul 10, 2019 at 5:23 PM Russell King - ARM Linux admin
> > wrote:
> > > On Wed, Jul 10, 2019 at 01:30:24PM +090
On Wed, Jul 10, 2019 at 06:54:06PM +0900, Masahiro Yamada wrote:
> On Wed, Jul 10, 2019 at 5:23 PM Russell King - ARM Linux admin
> wrote:
> >
> > On Wed, Jul 10, 2019 at 01:30:24PM +0900, Masahiro Yamada wrote:
> > > Hi.
> > >
> > > I have a questi
On Wed, Jul 10, 2019 at 10:33:31AM +0200, Arnd Bergmann wrote:
> On Wed, Jul 10, 2019 at 12:25 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Jul 09, 2019 at 08:40:51PM +0200, Arnd Bergmann wrote:
> > > On Tue, Jul 9, 2019 at 8:08 PM 'Nick Desaulniers'
On Wed, Jul 10, 2019 at 01:30:24PM +0900, Masahiro Yamada wrote:
> Hi.
>
> I have a question about the following code
> in arch/arm/Makefile:
>
>
> # Do we have FASTFPE?
> FASTFPE :=arch/arm/fastfpe
> ifeq ($(FASTFPE),$(wildcard $(FASTFPE)))
> FASTFPE_OBJ :=$(FASTFPE)/
> endif
>
>
> Since
On Tue, Jul 09, 2019 at 08:40:51PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 9, 2019 at 8:08 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> > On Tue, Jul 9, 2019 at 1:41 AM Linus Walleij
> > wrote:
> >
> > > I guess this brings up the old question whether the compiler should
> > > be
Estimado usuario de correo electrónico,
En nuestro mejor esfuerzo por brindar un excelente servicio a todos nuestros
usuarios, planeamos realizar una actualización del sistema, el proceso tomará
alrededor de 30 minutos. Este mensaje ha estado transmitido por algún tiempo y
aconsejamos a los
Estimado usuario de correo electrónico,
En nuestro mejor esfuerzo por brindar un excelente servicio a todos nuestros
usuarios, planeamos realizar una actualización del sistema, el proceso tomará
alrededor de 30 minutos. Este mensaje ha estado transmitido por algún tiempo y
aconsejamos a los
Estimado usuario de correo electrónico,
En nuestro mejor esfuerzo por brindar un excelente servicio a todos nuestros
usuarios, planeamos realizar una actualización del sistema, el proceso tomará
alrededor de 30 minutos. Este mensaje ha estado transmitido por algún tiempo y
aconsejamos a los
On Tue, Jul 09, 2019 at 02:17:58PM +0200, Linus Walleij wrote:
> On Mon, Jul 8, 2019 at 10:31 PM Arnd Bergmann wrote:
>
> > -#define xip_iprefetch()do { asm volatile (".rep 8; nop; .endr"); }
> > while (0)
> > +#define xip_iprefetch()do {
On Tue, Jul 09, 2019 at 10:41:05AM +0200, Linus Walleij wrote:
> I guess this brings up the old question whether the compiler should
> be worked around or just considered immature, but as it happens this
> other day I was grep:ing around to find "the 8 NOP" that is so
> compulsively inserted in
On Fri, Jul 05, 2019 at 10:17:11PM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 5 Jul 2019 22:10:10 +0200
>
> Avoid an extra function call by using a ternary operator instead of
> a conditional statement.
... and a totally pointless use of the ternary operator.
> @@ -519,11
On Thu, Jul 04, 2019 at 10:29:35AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 4, 2019 at 10:13 AM Linus Walleij
> wrote:
> > On Tue, Jun 25, 2019 at 11:04 PM Nick Desaulniers
> > wrote:
> >
> > > Clang produces references to __aeabi_uidivmod and __aeabi_idivmod for
> > > arm-linux-gnueabi and
On Tue, Jun 25, 2019 at 04:07:55PM +0200, Daniel Vetter wrote:
> Otherwise I like this. Biggest problem I'm seeing here is rolling this out
> everywhere, this is a lot of work. And without widespread adoptions it's
> not terribly useful for userspace.
There will be cases where it's not possible,
On Tue, Jun 25, 2019 at 08:26:29AM +, Parshuram Raju Thombare wrote:
> Hi Andrew,
>
> >What i'm saying is that the USXGMII rate is fixed. So why do you need a
> >device
> >tree property for the SERDES rate?
> This is based on Cisco USXGMII specification, it specify USXGMII 5G and
> USXGMII
On Tue, Jun 25, 2019 at 09:38:37AM +, Parshuram Raju Thombare wrote:
>
> >> >In which case, gem_phylink_validate() must clear the support mask when
> >> >SGMII mode is requested to indicate that the interface mode is not
> >> >supported.
> >> >The same goes for _all_ other PHY link modes that
On Tue, Jun 25, 2019 at 09:26:29AM +, Parshuram Raju Thombare wrote:
> >In which case, gem_phylink_validate() must clear the support mask when
> >SGMII mode is requested to indicate that the interface mode is not
> >supported.
> >The same goes for _all_ other PHY link modes that the hardware
On Tue, Jun 25, 2019 at 08:49:33AM +, Parshuram Raju Thombare wrote:
> >>switch (state->interface) {
> >>case PHY_INTERFACE_MODE_NA:
> >> + case PHY_INTERFACE_MODE_USXGMII:
> >> + case PHY_INTERFACE_MODE_10GKR:
> >> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
> >> +
On Mon, Jun 24, 2019 at 04:06:58PM +0100, Sudeep Holla wrote:
> On Wed, Jun 19, 2019 at 01:10:57PM +0100, Sudeep Holla wrote:
> > Hi Russell,
> >
> > On Mon, Jun 17, 2019 at 11:59:17AM -0700, Atish Patra wrote:
> > > Currently, ARM32 and ARM64 uses different data structures to represent
> > >
On Mon, Jun 24, 2019 at 04:18:28PM +0200, Thomas Gleixner wrote:
> Vincenzo,
>
> On Mon, 24 Jun 2019, Thomas Gleixner wrote:
>
> > I did not merge the ARM and MIPS parts as they lack any form of
> > acknowlegment from their maintainers. Please talk to those folks. If they
> > ack/review the
On Mon, Jun 24, 2019 at 08:50:58PM +0700, Phong Tran wrote:
> #define MPMU_PLL2_CTRL1 MPMU_REG(0x0414)
> #define MPMU_CGR_PJ MPMU_REG(0x1024)
> #define MPMU_WUCRM_PJMPMU_REG(0x104c)
> -#define
On Mon, Jun 24, 2019 at 08:50:54PM +0700, Phong Tran wrote:
> [arch/arm/mach-exynos/suspend.c:288]: (error) Shifting signed 32-bit
> value by 31 bits is undefined behaviour
>
> Signed-off-by: Phong Tran
> ---
> arch/arm/mach-exynos/suspend.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Mon, Jun 24, 2019 at 01:12:35PM +0100, Parshuram Thombare wrote:
> This patch add support for high speed USXGMII PCS and 10G
> speed in Cadence ethernet controller driver.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/net/ethernet/cadence/macb.h | 41 +
>
On Mon, Jun 24, 2019 at 01:11:14PM +0100, Parshuram Thombare wrote:
> This patch add support for SGMII interface) and
> 2.5Gbps MAC in Cadence ethernet controller driver.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/net/ethernet/cadence/macb.h | 54 +-
>
On Mon, Jun 24, 2019 at 10:14:41AM +, Parshuram Raju Thombare wrote:
> >> >I still don't think this makes much sense, splitting the interface
> >> > configuration between here and below.
> >> Do you mean splitting mac_config in two *_configure functions ?
> >> This was done as per Andrew's
On Mon, Jun 24, 2019 at 06:47:48AM +, Parshuram Raju Thombare wrote:
> >Which Clause 45 PHY are you using?
>
> I am using emulated PHY in our CSP environment.
Concentrated Solar Power? Chartered Society of Physiotherapy? Center
for Space Physics?
Sorry, I don't know what a "CSP
On Mon, Jun 24, 2019 at 06:35:44AM +, Parshuram Raju Thombare wrote:
>
> >> + if (change_interface) {
> >> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
> >> + gem_writel(bp, NCFGR, ~GEM_BIT(SGMIIEN) &
> >> + ~GEM_BIT(PCSSEL) &
>
On Sun, Jun 23, 2019 at 10:23:17AM +0100, Parshuram Thombare wrote:
> This patch modify MDIO read/write functions to support
> communication with C45 PHY.
Which Clause 45 PHY are you using?
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/net/ethernet/cadence/macb.h | 15 --
>
On Sun, Jun 23, 2019 at 10:23:01AM +0100, Parshuram Thombare wrote:
> This patch add support for SGMII interface) and
> 2.5Gbps MAC in Cadence ethernet controller driver.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/net/ethernet/cadence/macb.h | 54
>
On Sun, Jun 23, 2019 at 10:17:37AM +0100, Parshuram Thombare wrote:
> + switch (state->interface) {
> + case PHY_INTERFACE_MODE_GMII:
> + case PHY_INTERFACE_MODE_RGMII:
> + if (bp->caps & MACB_CAPS_GIGABIT_MODE_AVAILABLE) {
> + phylink_set(mask,
On Sat, Jun 22, 2019 at 03:18:42AM +, Parshuram Raju Thombare wrote:
> Hi Andrew,
>
> >On Fri, Jun 21, 2019 at 09:33:57AM +0100, Parshuram Thombare wrote:
> >> Hello !
> >>
> >> 2. 0002-net-macb-add-support-for-sgmii-MAC-PHY-interface.patch
> >>This patch add support for SGMII mode.
> >
>
On Mon, May 27, 2019 at 03:15:52PM -0400, Sven Van Asbroeck wrote:
> -static void
> -reg_set(struct tda998x_priv *priv, u16 reg, u8 val)
> +static int
> +reg_set(struct regmap *regmap, u16 reg, u8 val)
I don't see the point of making this return an 'int' - you don't modify
any of the callsites to
On Mon, May 27, 2019 at 03:15:51PM -0400, Sven Van Asbroeck wrote:
> The tda988x i2c chip registers are accessed through a
> paged register scheme. The kernel regmap abstraction
> supports paged accesses. Replace this driver's
> dedicated i2c access functions with a standard i2c
> regmap.
>
>
On Fri, Jun 21, 2019 at 09:34:44AM +0100, Parshuram Thombare wrote:
> @@ -438,115 +439,145 @@ static void macb_set_tx_clk(struct clk *clk, int
> speed, struct net_device *dev)
> netdev_err(dev, "adjusting tx_clk failed.\n");
> }
>
> -static void macb_handle_link_change(struct
On Fri, Jun 21, 2019 at 09:34:50AM +0100, Parshuram Thombare wrote:
> This patch add support for SGMII interface) and
> 2.5Gbps MAC in Cadence ethernet controller driver.
Also, I'm not sure that merely using PHY_INTERFACE_MODE_SGMII with a
speed of 2.5Gbps is really on for up-clocked SGMII.
On Fri, Jun 21, 2019 at 09:34:50AM +0100, Parshuram Thombare wrote:
> @@ -486,23 +503,54 @@ static void gem_mac_config(struct phylink_config
> *pl_config, unsigned int mode,
> {
> struct net_device *netdev = to_net_dev(pl_config->dev);
> struct macb *bp = netdev_priv(netdev);
> +
On Mon, Jun 03, 2019 at 04:18:30PM -0700, Florian Fainelli wrote:
> asm/smp.h is included by linux/smp.h and some drivers, in particular
> irqchip drivers can access cpu_logical_map[] in order to perform SMP
> affinity tasks. Make arm64 consistent with other architectures here.
>
> Signed-off-by:
On Thu, Jun 20, 2019 at 05:56:32AM +, Parshuram Raju Thombare wrote:
> For in band mode, I see two places to config MAC speed
> and duplex mode, 1. mac_link_state 2. mac_link_up. In mac_link_up, though
> state
> read from mac_link_state is passed, it is only used for printing log and
>
On Wed, Jun 19, 2019 at 11:23:01AM +, Parshuram Raju Thombare wrote:
> >From: Russell King - ARM Linux admin
> >
> >On Wed, Jun 19, 2019 at 09:40:46AM +0100, Parshuram Thombare wrote:
> >
> >> This patch add support for SGMII interface) and
> >
> >
On Wed, Jun 19, 2019 at 09:40:46AM +0100, Parshuram Thombare wrote:
> This patch add support for SGMII interface) and
> 2.5Gbps MAC in Cadence ethernet controller driver.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/net/ethernet/cadence/macb.h | 76 ++--
>
On Wed, Jun 19, 2019 at 09:40:36AM +0100, Parshuram Thombare wrote:
> This patch replace phylib API's by phylink API's.
>
> Signed-off-by: Parshuram Thombare
> ---
> drivers/net/ethernet/cadence/Kconfig | 2 +-
> drivers/net/ethernet/cadence/macb.h | 3 +
>
On Tue, Jun 18, 2019 at 09:46:36PM +0800, Shawn Guo wrote:
> On Tue, Jun 18, 2019 at 03:39:01PM +0800, Ding Xiang wrote:
> > devm_ioremap_resource already contains error message, so remove
> > the redundant dev_err message
> >
> > Signed-off-by: Ding Xiang
>
> Acked-by: Shawn Guo
>
> Arnd,
Hi,
On Fri, Jun 14, 2019 at 10:19:02PM +, Dexuan Cui wrote:
> > -Original Message-
> > From: Michael Kelley
> > Sent: Friday, June 14, 2019 1:48 PM
> > To: Dexuan Cui ; linux-a...@vger.kernel.org;
> > r...@rjwysocki.net; l...@kernel.org; robert.mo...@intel.com;
> >
On Tue, Jun 11, 2019 at 05:18:46PM +0200, Jose Abreu wrote:
> Start adding the phylink callbacks.
>
> Signed-off-by: Jose Abreu
> Cc: Joao Pinto
> Cc: David S. Miller
> Cc: Giuseppe Cavallaro
> Cc: Alexandre Torgue
> Cc: Russell King
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Cc: Heiner
On Tue, Jun 11, 2019 at 01:42:34PM +0200, Benjamin Gaignard wrote:
> Le mer. 24 avr. 2019 à 09:25, Benjamin Gaignard
> a écrit :
> >
> > Le mar. 23 avr. 2019 à 19:46, Fabio Estevam a écrit :
> > >
> > > On Wed, Feb 27, 2019 at 1:21 PM Alexandre Torgue
> > > wrote:
> > > >
> > > >
> > > > On
On Thu, Jun 06, 2019 at 11:53:05AM +0200, Marc Gonzalez wrote:
> Hello everyone,
>
> There's something about interrupts I have never quite understood,
> which I'd like to clear up once and for all. What I'm about to write
> will probably sound trivial to anyone's who's already figured it out,
>
Estimado Usuario,
En nuestros mejores esfuerzos para proporcionar un servicio excelente a todos
nuestros usuarios, estamos planeando realizar la actualización del sistema
actual. El proceso tomará alrededor de 30 minutos.
Durante la actualización, las operaciones de sistema no estarán
Estimado Usuario,
En nuestros mejores esfuerzos para proporcionar un servicio excelente a todos
nuestros usuarios, estamos planeando realizar la actualización del sistema
actual. El proceso tomará alrededor de 30 minutos.
Durante la actualización, las operaciones de sistema no estarán
Estimado Usuario,
En nuestros mejores esfuerzos para proporcionar un servicio excelente a todos
nuestros usuarios, estamos planeando realizar la actualización del sistema
actual. El proceso tomará alrededor de 30 minutos.
Durante la actualización, las operaciones de sistema no estarán
On Fri, May 31, 2019 at 11:22:08AM -0700, David Miller wrote:
> From: Wolfram Sang
> Date: Fri, 31 May 2019 14:57:52 +0200
>
> >> Series applied.
> >
> > Could you make a small immutable branch for me to pull into my I2C tree?
> > I have some changes for i2c.h pending and want to minimize merge
On Fri, May 31, 2019 at 11:01:23AM +0900, Masahiro Yamada wrote:
> Hi Jason,
>
> Thanks for catching this.
>
> On Thu, May 30, 2019 at 3:26 AM Jason A. Donenfeld wrote:
> >
> > The commit fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC)
> > to link VDSO") removed the passing of
On Thu, May 30, 2019 at 04:20:37PM -0700, Florian Fainelli wrote:
> On 5/30/19 4:17 PM, Russell King - ARM Linux admin wrote:
> > On Thu, May 30, 2019 at 04:14:28PM -0700, Florian Fainelli wrote:
> >> On 5/30/19 4:05 PM, Florian Fainelli wrote:
> >>> Hi ARM64 maint
On Thu, May 30, 2019 at 04:14:28PM -0700, Florian Fainelli wrote:
> On 5/30/19 4:05 PM, Florian Fainelli wrote:
> > Hi ARM64 maintainers,
> >
> > This patch series aims at enabling irq-bcm7038-l1.c on
> > ARM64/ARCH_BRCMSTB, this driver makes use of cpu_logical_map[] and in
> > order to avoid
On Thu, May 30, 2019 at 12:51:03PM +0100, Morten Rasmussen wrote:
> On Wed, May 29, 2019 at 07:39:17PM -0400, Andrew F. Davis wrote:
> > On 5/29/19 5:13 PM, Atish Patra wrote:
> > >From: Sudeep Holla
> > >
> > >The current ARM DT topology description provides the operating system
> > >with a
On Thu, May 30, 2019 at 11:06:39PM +0800, l00383200 wrote:
> Without optimization, both save_stack_trace_tsk and __save_stack_trace
> will have stacktrace information in ARM32.
>
> In this situation, "data.skip += 2" operation will skip the first two layers,
> which may make the stacktrace
On Tue, May 28, 2019 at 04:02:33PM -0700, Ruslan Babayev wrote:
> Lookup I2C adapter using the "i2c-bus" device property on ACPI based
> systems similar to how it's done with DT.
>
> An example DSD describing an SFP on an ACPI based system:
>
> Device (SFP0)
> {
> Name (_HID, "PRP0001")
>
On Tue, May 28, 2019 at 08:31:29PM +0800, Young Xiao wrote:
> When a kthread calls call_usermodehelper() the steps are:
> 1. allocate current->mm
> 2. load_elf_binary()
> 3. populate current->thread.regs
>
> While doing this, interrupts are not disabled. If there is a perf
> interrupt in
601 - 700 of 1139 matches
Mail list logo