* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-22 10:27 UTC (permalink / raw)
To: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <BN8PR12MB326667E86622C3ABD5CDE642D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On 22/07/2019 10:57, Jose Abreu wrote:
...
> Also, please add attached patch. You'll get a compiler warning, just
> disregard it.
Here you are ...
https://paste.ubuntu.com/p/H9Mvv37vN9/
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Ilias Apalodimas @ 2019-07-22 10:18 UTC (permalink / raw)
To: Jose Abreu
Cc: Jon Hunter, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai, linux-tegra
In-Reply-To: <BN8PR12MB32661E919A8DEBC7095BAA12D3C80@BN8PR12MB3266.namprd12.prod.outlook.com>
On Thu, Jul 18, 2019 at 07:48:04AM +0000, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/17/2019, 19:58:53 (UTC+00:00)
>
> > Let me know if you have any thoughts.
>
> Can you try attached patch ?
>
The log says someone calls panic() right?
Can we trye and figure were that happens during the stmmac init phase?
Thanks
/Ilias
^ permalink raw reply
* Re: [PATCH 4/4] ipvs: reduce kernel stack usage
From: Arnd Bergmann @ 2019-07-22 10:16 UTC (permalink / raw)
To: Julian Anastasov
Cc: Kees Cook, Wensong Zhang, Simon Horman, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, James Smart, Dick Kennedy,
James E . J . Bottomley, Martin K . Petersen, Larry Finger,
Florian Schilhabel, Greg Kroah-Hartman, James Morris, linux-scsi,
Linux Kernel Mailing List, driverdevel, Networking, lvs-devel,
netfilter-devel, coreteam, Ard Biesheuvel
In-Reply-To: <alpine.LFD.2.21.1906302308280.3788@ja.home.ssi.bg>
On Sun, Jun 30, 2019 at 10:37 PM Julian Anastasov <ja@ssi.bg> wrote:
> On Fri, 28 Jun 2019, Arnd Bergmann wrote:
> > struct ip_vs_conn *ctl_cp = cp->control;
> > if (!ctl_cp) {
> > - IP_VS_ERR_BUF("request control DEL for uncontrolled: "
> > - "%s:%d to %s:%d\n",
> > - IP_VS_DBG_ADDR(cp->af, &cp->caddr),
> > - ntohs(cp->cport),
> > - IP_VS_DBG_ADDR(cp->af, &cp->vaddr),
> > - ntohs(cp->vport));
> > + pr_err("request control DEL for uncontrolled: "
> > + "%pISp to %pISp\n",
(replying a bit late)
> ip_vs_dbg_addr() used compact form (%pI6c), so it would be
> better to use %pISc and %pISpc everywhere in IPVS...
done
> Also, note that before now port was printed with %d and
> ntohs() was used, now port should be in network order, so:
>
> - ntohs() should be removed
done
> - htons() should be added, if missing. At first look, this case
> is not present in IPVS, we have only ntohs() usage
I found one case in ip_vs_ftp_in() that needs it in order to subtract one:
IP_VS_DBG(7, "protocol %s %pISpc %pISpc\n",
ip_vs_proto_name(ipvsh->protocol),
- IP_VS_DBG_SOCKADDR(cp->af, &to, ntohs(port)),
+ IP_VS_DBG_SOCKADDR(cp->af, &to, port),
IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr,
- ntohs(cp->vport)-1));
+ htons(ntohs(cp->vport)-1)));
Thanks for the review, I'll send a new patch after some more
build testing on the new version.
Arnd
^ permalink raw reply
* Re: INFO: rcu detected stall in ext4_write_checks
From: Dmitry Vyukov @ 2019-07-22 10:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Paul E. McKenney, Theodore Ts'o, syzbot, Andreas Dilger,
David Miller, eladr, Ido Schimmel, Jiri Pirko, John Stultz,
linux-ext4, LKML, netdev, syzkaller-bugs, Thomas Gleixner,
Ingo Molnar
In-Reply-To: <20190715134651.GI3419@hirez.programming.kicks-ass.net>
On Mon, Jul 15, 2019 at 3:46 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Jul 15, 2019 at 03:33:11PM +0200, Dmitry Vyukov wrote:
> > On Mon, Jul 15, 2019 at 3:29 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Sun, Jul 14, 2019 at 11:49:15AM -0700, Paul E. McKenney wrote:
> > > > On Sun, Jul 14, 2019 at 05:48:00PM +0300, Dmitry Vyukov wrote:
> > > > > But short term I don't see any other solution than stop testing
> > > > > sched_setattr because it does not check arguments enough to prevent
> > > > > system misbehavior. Which is a pity because syzkaller has found some
> > > > > bad misconfigurations that were oversight on checking side.
> > > > > Any other suggestions?
> > > >
> > > > Keep the times down to a few seconds? Of course, that might also
> > > > fail to find interesting bugs.
> > >
> > > Right, if syzcaller can put a limit on the period/deadline parameters
> > > (and make sure to not write "-1" to
> > > /proc/sys/kernel/sched_rt_runtime_us) then per the in-kernel
> > > access-control should not allow these things to happen.
> >
> > Since we are racing with emails, could you suggest a 100% safe
> > parameters? Because I only hear people saying "safe", "sane",
> > "well-behaving" :)
> > If we move the check to user-space, it does not mean that we can get
> > away without actually defining what that means.
>
> Right, well, that's part of the problem. I think Paul just did the
> reverse math and figured that 95% of X must not be larger than my
> watchdog timeout and landed on 14 seconds.
>
> I'm thinking 4 seconds (or rather 4.294967296) would be a very nice
> number.
>
> > Now thinking of this, if we come up with some simple criteria, could
> > we have something like a sysctl that would allow only really "safe"
> > parameters?
>
> I suppose we could do that, something like:
> sysctl_deadline_period_{min,max}. I'll have to dig back a bit on where
> we last talked about that and what the problems where.
>
> For one, setting the min is a lot harder, but I suppose we can start at
> TICK_NSEC or something.
Now syzkaller will drop CAP_SYS_NICE for the test process:
https://github.com/google/syzkaller/commit/f3ad68446455acbe562e0057931e6256b8b991e8
I will close this bug report as invalid once the change reaches all
syzbot instances, if nobody plans any other on this bug.
^ permalink raw reply
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-22 9:57 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <BN8PR12MB3266362102CCB6B4DDE4BEA0D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]
From: Jose Abreu <joabreu@synopsys.com>
Date: Jul/22/2019, 10:47:44 (UTC+00:00)
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/22/2019, 10:37:18 (UTC+00:00)
>
> >
> > On 22/07/2019 08:23, Jose Abreu wrote:
> > > From: Jon Hunter <jonathanh@nvidia.com>
> > > Date: Jul/19/2019, 14:35:52 (UTC+00:00)
> > >
> > >>
> > >> On 19/07/2019 13:32, Jose Abreu wrote:
> > >>> From: Jon Hunter <jonathanh@nvidia.com>
> > >>> Date: Jul/19/2019, 13:30:10 (UTC+00:00)
> > >>>
> > >>>> I booted the board without using NFS and then started used dhclient to
> > >>>> bring up the network interface and it appears to be working fine. I can
> > >>>> even mount the NFS share fine. So it does appear to be particular to
> > >>>> using NFS to mount the rootfs.
> > >>>
> > >>> Damn. Can you send me your .config ?
> > >>
> > >> Yes no problem. Attached.
> > >
> > > Can you compile your image without modules (i.e. all built-in) and let
> > > me know if the error still happens ?
> >
> > I simply removed the /lib/modules directory from the NFS share and
> > verified that I still see the same issue. So it is not loading the
> > modules that is a problem.
>
> Well, I meant that loading modules can be an issue but that's not the
> way to verify that.
>
> You need to have all modules built-in so that it proves that no module
> will try to be loaded.
>
> Anyway, this is probably not the cause as you wouldn't even be able to
> compile kernel if you need a symbol from a module with stmmac built-in.
> Kconfig would complain about that.
>
> The other cause could be data corruption in the RX path. Are you able to
> send me packet dump by running wireshark either in the transmitter side
> (i.e. NFS server), or using some kind of switch ?
>
> ---
> Thanks,
> Jose Miguel Abreu
Also, please add attached patch. You'll get a compiler warning, just
disregard it.
---
Thanks,
Jose Miguel Abreu
[-- Attachment #2: 0001-net-stmmac-Debug-print.patch --]
[-- Type: application/octet-stream, Size: 1514 bytes --]
From b78be4f19e57b6a4d5f67bda1c52c90f6cd901ab Mon Sep 17 00:00:00 2001
Message-Id: <b78be4f19e57b6a4d5f67bda1c52c90f6cd901ab.1563789387.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Mon, 22 Jul 2019 11:52:28 +0200
Subject: [PATCH net] net: stmmac: Debug print
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0ac79f3e2cee..7a6920098dd0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3433,6 +3433,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
dma_sync_single_for_device(priv->device, buf->addr,
frame_len, DMA_FROM_DEVICE);
+ pr_info("%s: paddr=0x%llx, vaddr=0x%llx, len=%d", __func__,
+ buf->addr, page_address(buf->page),
+ frame_len);
+
if (netif_msg_pktdata(priv)) {
netdev_dbg(priv->dev, "frame received (%dbytes)",
frame_len);
--
2.7.4
^ permalink raw reply related
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-22 9:47 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <49efad87-2f74-5804-af4c-33730f865c41@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Jul/22/2019, 10:37:18 (UTC+00:00)
>
> On 22/07/2019 08:23, Jose Abreu wrote:
> > From: Jon Hunter <jonathanh@nvidia.com>
> > Date: Jul/19/2019, 14:35:52 (UTC+00:00)
> >
> >>
> >> On 19/07/2019 13:32, Jose Abreu wrote:
> >>> From: Jon Hunter <jonathanh@nvidia.com>
> >>> Date: Jul/19/2019, 13:30:10 (UTC+00:00)
> >>>
> >>>> I booted the board without using NFS and then started used dhclient to
> >>>> bring up the network interface and it appears to be working fine. I can
> >>>> even mount the NFS share fine. So it does appear to be particular to
> >>>> using NFS to mount the rootfs.
> >>>
> >>> Damn. Can you send me your .config ?
> >>
> >> Yes no problem. Attached.
> >
> > Can you compile your image without modules (i.e. all built-in) and let
> > me know if the error still happens ?
>
> I simply removed the /lib/modules directory from the NFS share and
> verified that I still see the same issue. So it is not loading the
> modules that is a problem.
Well, I meant that loading modules can be an issue but that's not the
way to verify that.
You need to have all modules built-in so that it proves that no module
will try to be loaded.
Anyway, this is probably not the cause as you wouldn't even be able to
compile kernel if you need a symbol from a module with stmmac built-in.
Kconfig would complain about that.
The other cause could be data corruption in the RX path. Are you able to
send me packet dump by running wireshark either in the transmitter side
(i.e. NFS server), or using some kind of switch ?
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Marc Kleine-Budde @ 2019-07-22 9:45 UTC (permalink / raw)
To: Ji-Ze Hong (Peter Hong), wg, peter_hong
Cc: davem, f.suligoi, linux-kernel, linux-can, netdev,
Ji-Ze Hong (Peter Hong)
In-Reply-To: <1563776521-28317-1-git-send-email-hpeter+linux_kernel@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1789 bytes --]
On 7/22/19 8:22 AM, Ji-Ze Hong (Peter Hong) wrote:
> This patch add support for Fintek PCIE to 2 CAN controller support
>
> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
> ---
> Changelog:
> v2:
> 1: Fix comment on the spinlock with write access.
> 2: Use ARRAY_SIZE instead of F81601_PCI_MAX_CHAN.
> 3: Check the strap pin outside the loop.
> 4: Fix the cleanup issue in f81601_pci_add_card().
> 5: Remove unused "channels" in struct f81601_pci_card.
>
> drivers/net/can/sja1000/Kconfig | 8 ++
> drivers/net/can/sja1000/Makefile | 1 +
> drivers/net/can/sja1000/f81601.c | 215 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/net/can/sja1000/f81601.c
> diff --git a/drivers/net/can/sja1000/f81601.c b/drivers/net/can/sja1000/f81601.c
> new file mode 100644
> index 000000000000..3c378de8764d
> --- /dev/null
> +++ b/drivers/net/can/sja1000/f81601.c
[...]
> +static void f81601_pci_del_card(struct pci_dev *pdev)
> +{
> + struct f81601_pci_card *card = pci_get_drvdata(pdev);
> + struct net_device *dev;
> + int i = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(card->net_dev); i++) {
> + dev = card->net_dev[i];
> + if (!dev)
> + continue;
> +
> + dev_info(&pdev->dev, "%s: Removing %s\n", __func__, dev->name);
> +
> + unregister_sja1000dev(dev);
> + free_sja1000dev(dev);
> + }
> +
> + pcim_iounmap(pdev, card->addr);
Why do you need iounmap()?
> +}
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-22 9:37 UTC (permalink / raw)
To: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <BN8PR12MB32665C1A106D3DCBF89CEA54D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On 22/07/2019 08:23, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/19/2019, 14:35:52 (UTC+00:00)
>
>>
>> On 19/07/2019 13:32, Jose Abreu wrote:
>>> From: Jon Hunter <jonathanh@nvidia.com>
>>> Date: Jul/19/2019, 13:30:10 (UTC+00:00)
>>>
>>>> I booted the board without using NFS and then started used dhclient to
>>>> bring up the network interface and it appears to be working fine. I can
>>>> even mount the NFS share fine. So it does appear to be particular to
>>>> using NFS to mount the rootfs.
>>>
>>> Damn. Can you send me your .config ?
>>
>> Yes no problem. Attached.
>
> Can you compile your image without modules (i.e. all built-in) and let
> me know if the error still happens ?
I simply removed the /lib/modules directory from the NFS share and
verified that I still see the same issue. So it is not loading the
modules that is a problem.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 2/3] net/xdp: convert put_page() to put_user_page*()
From: Christoph Hellwig @ 2019-07-22 9:34 UTC (permalink / raw)
To: john.hubbard
Cc: Andrew Morton, Alexander Viro, Björn Töpel,
Boaz Harrosh, Christoph Hellwig, Daniel Vetter, Dan Williams,
Dave Chinner, David Airlie, David S . Miller, Ilya Dryomov,
Jan Kara, Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard
In-Reply-To: <20190722043012.22945-3-jhubbard@nvidia.com>
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 83de74ca729a..9cbbb96c2a32 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -171,8 +171,7 @@ static void xdp_umem_unpin_pages(struct xdp_umem *umem)
> for (i = 0; i < umem->npgs; i++) {
> struct page *page = umem->pgs[i];
>
> - set_page_dirty_lock(page);
> - put_page(page);
> + put_user_pages_dirty_lock(&page, 1);
Same here, we really should avoid the need for the loop here and
do the looping inside the helper.
^ permalink raw reply
* Re: [PATCH 1/3] drivers/gpu/drm/via: convert put_page() to put_user_page*()
From: Christoph Hellwig @ 2019-07-22 9:33 UTC (permalink / raw)
To: john.hubbard
Cc: Andrew Morton, Alexander Viro, Björn Töpel,
Boaz Harrosh, Christoph Hellwig, Daniel Vetter, Dan Williams,
Dave Chinner, David Airlie, David S . Miller, Ilya Dryomov,
Jan Kara, Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard
In-Reply-To: <20190722043012.22945-2-jhubbard@nvidia.com>
On Sun, Jul 21, 2019 at 09:30:10PM -0700, john.hubbard@gmail.com wrote:
> for (i = 0; i < vsg->num_pages; ++i) {
> if (NULL != (page = vsg->pages[i])) {
> if (!PageReserved(page) && (DMA_FROM_DEVICE == vsg->direction))
> - SetPageDirty(page);
> - put_page(page);
> + put_user_pages_dirty(&page, 1);
> + else
> + put_user_page(page);
> }
Can't just pass a dirty argument to put_user_pages? Also do we really
need a separate put_user_page for the single page case?
put_user_pages_dirty?
Also the PageReserved check looks bogus, as I can't see how a reserved
page can end up here. So IMHO the above snippled should really look
something like this:
put_user_pages(vsg->pages[i], vsg->num_pages,
vsg->direction == DMA_FROM_DEVICE);
in the end.
^ permalink raw reply
* Re: [PATCH v4 0/5] vsock/virtio: optimizations to increase the throughput
From: Stefano Garzarella @ 2019-07-22 9:14 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190722090835.GF24934@stefanha-x1.localdomain>
On Mon, Jul 22, 2019 at 10:08:35AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jul 17, 2019 at 01:30:25PM +0200, Stefano Garzarella wrote:
> > This series tries to increase the throughput of virtio-vsock with slight
> > changes.
> > While I was testing the v2 of this series I discovered an huge use of memory,
> > so I added patch 1 to mitigate this issue. I put it in this series in order
> > to better track the performance trends.
> >
> > v4:
> > - rebased all patches on current master (conflicts is Patch 4)
> > - Patch 1: added Stefan's R-b
> > - Patch 3: removed lock when buf_alloc is written [David];
> > moved this patch after "vsock/virtio: reduce credit update messages"
> > to make it clearer
> > - Patch 4: vhost_exceeds_weight() is recently introduced, so I've solved some
> > conflicts
>
> Stefano: Do you want to continue experimenting before we merge this
> patch series? The code looks functionally correct and the performance
> increases, so I'm happy for it to be merged.
I think we can merge this series.
I'll continue to do other experiments (e.g. removing TX workers, allocating
pages, etc.) but I think these changes are prerequisites for the other patches,
so we can merge them.
Thank you very much for the reviews!
Stefano
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Marc Kleine-Budde @ 2019-07-22 9:11 UTC (permalink / raw)
To: Ji-Ze Hong (Peter Hong), wg, peter_hong
Cc: davem, f.suligoi, linux-kernel, linux-can, netdev,
Ji-Ze Hong (Peter Hong)
In-Reply-To: <b7c9026a-a887-bc84-3297-c319d18686c3@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1077 bytes --]
On 7/22/19 10:36 AM, Ji-Ze Hong (Peter Hong) wrote:
> Hi Marc,
>
> Marc Kleine-Budde 於 2019/7/22 下午 04:15 寫道:
>> On 7/22/19 8:22 AM, Ji-Ze Hong (Peter Hong) wrote: >> +/* Probe F81601 based device for the SJA1000 chips and register each
>>> + * available CAN channel to SJA1000 Socket-CAN subsystem.
>>> + */
>>> +static int f81601_pci_add_card(struct pci_dev *pdev,
>>> + const struct pci_device_id *ent)
>>> +{
>>> + struct sja1000_priv *priv;
>>> + struct net_device *dev;
>>> + struct f81601_pci_card *card;
>>> + int err, i, count;
>>> + u8 tmp;
>>> +
>>> + if (pcim_enable_device(pdev) < 0) {
>>
>> I'm missing a corresponding disable_device().
>>
> I'm using managed pcim_enable_device(), Does it need call
> pci_disable_device() ??
Right.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/5] vsock/virtio: optimizations to increase the throughput
From: Stefan Hajnoczi @ 2019-07-22 9:08 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-1-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On Wed, Jul 17, 2019 at 01:30:25PM +0200, Stefano Garzarella wrote:
> This series tries to increase the throughput of virtio-vsock with slight
> changes.
> While I was testing the v2 of this series I discovered an huge use of memory,
> so I added patch 1 to mitigate this issue. I put it in this series in order
> to better track the performance trends.
>
> v4:
> - rebased all patches on current master (conflicts is Patch 4)
> - Patch 1: added Stefan's R-b
> - Patch 3: removed lock when buf_alloc is written [David];
> moved this patch after "vsock/virtio: reduce credit update messages"
> to make it clearer
> - Patch 4: vhost_exceeds_weight() is recently introduced, so I've solved some
> conflicts
Stefano: Do you want to continue experimenting before we merge this
patch series? The code looks functionally correct and the performance
increases, so I'm happy for it to be merged.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/5] vsock/virtio: change the maximum packet size allowed
From: Stefan Hajnoczi @ 2019-07-22 9:07 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-6-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
On Wed, Jul 17, 2019 at 01:30:30PM +0200, Stefano Garzarella wrote:
> Since now we are able to split packets, we can avoid limiting
> their sizes to VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE.
> Instead, we can use VIRTIO_VSOCK_MAX_PKT_BUF_SIZE as the max
> packet size.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> net/vmw_vsock/virtio_transport_common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/5] vhost/vsock: split packets to send using multiple buffers
From: Stefan Hajnoczi @ 2019-07-22 9:06 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-5-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
On Wed, Jul 17, 2019 at 01:30:29PM +0200, Stefano Garzarella wrote:
> If the packets to sent to the guest are bigger than the buffer
> available, we can split them, using multiple buffers and fixing
> the length in the packet header.
> This is safe since virtio-vsock supports only stream sockets.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> drivers/vhost/vsock.c | 66 ++++++++++++++++++-------
> net/vmw_vsock/virtio_transport_common.c | 15 ++++--
> 2 files changed, 60 insertions(+), 21 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/5] vsock/virtio: fix locking in virtio_transport_inc_tx_pkt()
From: Stefan Hajnoczi @ 2019-07-22 8:53 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-4-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
On Wed, Jul 17, 2019 at 01:30:28PM +0200, Stefano Garzarella wrote:
> fwd_cnt and last_fwd_cnt are protected by rx_lock, so we should use
> the same spinlock also if we are in the TX path.
>
> Move also buf_alloc under the same lock.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> include/linux/virtio_vsock.h | 2 +-
> net/vmw_vsock/virtio_transport_common.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net 1/2] net: stmmac: RX Descriptors need to be clean before setting buffers
From: Jose Abreu @ 2019-07-22 8:39 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1563784666.git.joabreu@synopsys.com>
RX Descriptors are being cleaned after setting the buffers which may
lead to buffer addresses being wiped out.
Fix this by clearing earlier the RX Descriptors.
Fixes: 2af6106ae949 ("net: stmmac: Introducing support for Page Pool")
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c7c9e5f162e6..5f1294ce0216 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1295,6 +1295,8 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
"(%s) dma_rx_phy=0x%08x\n", __func__,
(u32)rx_q->dma_rx_phy);
+ stmmac_clear_rx_descriptors(priv, queue);
+
for (i = 0; i < DMA_RX_SIZE; i++) {
struct dma_desc *p;
@@ -1312,8 +1314,6 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
rx_q->cur_rx = 0;
rx_q->dirty_rx = (unsigned int)(i - DMA_RX_SIZE);
- stmmac_clear_rx_descriptors(priv, queue);
-
/* Setup the chained descriptor addresses */
if (priv->mode == STMMAC_CHAIN_MODE) {
if (priv->extend_desc)
--
2.7.4
^ permalink raw reply related
* [PATCH net 2/2] net: stmmac: Use kcalloc() instead of kmalloc_array()
From: Jose Abreu @ 2019-07-22 8:39 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1563784666.git.joabreu@synopsys.com>
We need the memory to be zeroed upon allocation so use kcalloc()
instead.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5f1294ce0216..0ac79f3e2cee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1555,9 +1555,8 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
goto err_dma;
}
- rx_q->buf_pool = kmalloc_array(DMA_RX_SIZE,
- sizeof(*rx_q->buf_pool),
- GFP_KERNEL);
+ rx_q->buf_pool = kcalloc(DMA_RX_SIZE, sizeof(*rx_q->buf_pool),
+ GFP_KERNEL);
if (!rx_q->buf_pool)
goto err_dma;
@@ -1608,15 +1607,15 @@ static int alloc_dma_tx_desc_resources(struct stmmac_priv *priv)
tx_q->queue_index = queue;
tx_q->priv_data = priv;
- tx_q->tx_skbuff_dma = kmalloc_array(DMA_TX_SIZE,
- sizeof(*tx_q->tx_skbuff_dma),
- GFP_KERNEL);
+ tx_q->tx_skbuff_dma = kcalloc(DMA_TX_SIZE,
+ sizeof(*tx_q->tx_skbuff_dma),
+ GFP_KERNEL);
if (!tx_q->tx_skbuff_dma)
goto err_dma;
- tx_q->tx_skbuff = kmalloc_array(DMA_TX_SIZE,
- sizeof(struct sk_buff *),
- GFP_KERNEL);
+ tx_q->tx_skbuff = kcalloc(DMA_TX_SIZE,
+ sizeof(struct sk_buff *),
+ GFP_KERNEL);
if (!tx_q->tx_skbuff)
goto err_dma;
--
2.7.4
^ permalink raw reply related
* [PATCH net 0/2] net: stmmac: Two fixes
From: Jose Abreu @ 2019-07-22 8:39 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
Two fixes targeting -net.
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Jose Abreu (2):
net: stmmac: RX Descriptors need to be clean before setting buffers
net: stmmac: Use kcalloc() instead of kmalloc_array()
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Ji-Ze Hong (Peter Hong) @ 2019-07-22 8:36 UTC (permalink / raw)
To: Marc Kleine-Budde, wg, peter_hong
Cc: davem, f.suligoi, linux-kernel, linux-can, netdev,
Ji-Ze Hong (Peter Hong)
In-Reply-To: <563b0d71-3c60-d32c-cf19-73611f68d45a@pengutronix.de>
Hi Marc,
Marc Kleine-Budde 於 2019/7/22 下午 04:15 寫道:
> On 7/22/19 8:22 AM, Ji-Ze Hong (Peter Hong) wrote: >> +/* Probe F81601 based device for the SJA1000 chips and register each
>> + * available CAN channel to SJA1000 Socket-CAN subsystem.
>> + */
>> +static int f81601_pci_add_card(struct pci_dev *pdev,
>> + const struct pci_device_id *ent)
>> +{
>> + struct sja1000_priv *priv;
>> + struct net_device *dev;
>> + struct f81601_pci_card *card;
>> + int err, i, count;
>> + u8 tmp;
>> +
>> + if (pcim_enable_device(pdev) < 0) {
>
> I'm missing a corresponding disable_device().
>
I'm using managed pcim_enable_device(), Does it need call
pci_disable_device() ??
Thanks
--
With Best Regards,
Peter Hong
^ permalink raw reply
* Re: [PATCH v4 2/5] vsock/virtio: reduce credit update messages
From: Stefan Hajnoczi @ 2019-07-22 8:36 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-3-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Wed, Jul 17, 2019 at 01:30:27PM +0200, Stefano Garzarella wrote:
> In order to reduce the number of credit update messages,
> we send them only when the space available seen by the
> transmitter is less than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> include/linux/virtio_vsock.h | 1 +
> net/vmw_vsock/virtio_transport_common.c | 16 +++++++++++++---
> 2 files changed, 14 insertions(+), 3 deletions(-)
It's an arbitrary limit but the risk of regressions is low since the
credit update traffic was so excessive:
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH V4] can: flexcan: fix stop mode acknowledgment
From: Joakim Zhang @ 2019-07-22 8:28 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx
In-Reply-To: <20190702014316.26444-1-qiangqing.zhang@nxp.com>
Kindly Ping...
Best Regards,
Joakim Zhang
> -----Original Message-----
> From: Joakim Zhang
> Sent: 2019年7月2日 9:46
> To: mkl@pengutronix.de; linux-can@vger.kernel.org
> Cc: wg@grandegger.com; netdev@vger.kernel.org; dl-linux-imx
> <linux-imx@nxp.com>; Joakim Zhang <qiangqing.zhang@nxp.com>
> Subject: [PATCH V4] can: flexcan: fix stop mode acknowledgment
>
> To enter stop mode, the CPU should manually assert a global Stop Mode
> request and check the acknowledgment asserted by FlexCAN. The CPU must
> only consider the FlexCAN in stop mode when both request and
> acknowledgment conditions are satisfied.
>
> Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
> Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
>
> ChangeLog:
> V1->V2:
> * regmap_read()-->regmap_read_poll_timeout()
> V2->V3:
> * change the way of error return, it will make easy for function
> extension.
> V3->V4:
> * rebase to linux-next/master, as this is a fix.
> ---
> drivers/net/can/flexcan.c | 31 +++++++++++++++++++++++++++----
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index
> 1c66fb2ad76b..bf1bd6f5dbb1 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -400,9 +400,10 @@ static void flexcan_enable_wakeup_irq(struct
> flexcan_priv *priv, bool enable)
> priv->write(reg_mcr, ®s->mcr);
> }
>
> -static inline void flexcan_enter_stop_mode(struct flexcan_priv *priv)
> +static inline int flexcan_enter_stop_mode(struct flexcan_priv *priv)
> {
> struct flexcan_regs __iomem *regs = priv->regs;
> + unsigned int ackval;
> u32 reg_mcr;
>
> reg_mcr = priv->read(®s->mcr);
> @@ -412,20 +413,37 @@ static inline void flexcan_enter_stop_mode(struct
> flexcan_priv *priv)
> /* enable stop request */
> regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
> 1 << priv->stm.req_bit, 1 << priv->stm.req_bit);
> +
> + /* get stop acknowledgment */
> + if (regmap_read_poll_timeout(priv->stm.gpr, priv->stm.ack_gpr,
> + ackval, ackval & (1 << priv->stm.ack_bit),
> + 0, FLEXCAN_TIMEOUT_US))
> + return -ETIMEDOUT;
> +
> + return 0;
> }
>
> -static inline void flexcan_exit_stop_mode(struct flexcan_priv *priv)
> +static inline int flexcan_exit_stop_mode(struct flexcan_priv *priv)
> {
> struct flexcan_regs __iomem *regs = priv->regs;
> + unsigned int ackval;
> u32 reg_mcr;
>
> /* remove stop request */
> regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
> 1 << priv->stm.req_bit, 0);
>
> + /* get stop acknowledgment */
> + if (regmap_read_poll_timeout(priv->stm.gpr, priv->stm.ack_gpr,
> + ackval, !(ackval & (1 << priv->stm.ack_bit)),
> + 0, FLEXCAN_TIMEOUT_US))
> + return -ETIMEDOUT;
> +
> reg_mcr = priv->read(®s->mcr);
> reg_mcr &= ~FLEXCAN_MCR_SLF_WAK;
> priv->write(reg_mcr, ®s->mcr);
> +
> + return 0;
> }
>
> static inline void flexcan_error_irq_enable(const struct flexcan_priv *priv)
> @@ -1615,7 +1633,9 @@ static int __maybe_unused flexcan_suspend(struct
> device *device)
> */
> if (device_may_wakeup(device)) {
> enable_irq_wake(dev->irq);
> - flexcan_enter_stop_mode(priv);
> + err = flexcan_enter_stop_mode(priv);
> + if (err)
> + return err;
> } else {
> err = flexcan_chip_disable(priv);
> if (err)
> @@ -1665,10 +1685,13 @@ static int __maybe_unused
> flexcan_noirq_resume(struct device *device) {
> struct net_device *dev = dev_get_drvdata(device);
> struct flexcan_priv *priv = netdev_priv(dev);
> + int err;
>
> if (netif_running(dev) && device_may_wakeup(device)) {
> flexcan_enable_wakeup_irq(priv, false);
> - flexcan_exit_stop_mode(priv);
> + err = flexcan_exit_stop_mode(priv);
> + if (err)
> + return err;
> }
>
> return 0;
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH 3/3] riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver
From: Sagar Kadam @ 2019-07-22 8:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, devicetree, Albert Ou, netdev, Palmer Dabbelt,
ynezz, Linux Kernel Mailing List, nicolas.ferre, Sachin Ghadi,
Yash Shah, Rob Herring, Paul Walmsley, linux-riscv, davem
In-Reply-To: <20190719132657.GD24930@lunn.ch>
Hello Andrew,
On Fri, Jul 19, 2019 at 6:57 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Fri, Jul 19, 2019 at 05:23:45PM +0530, Sagar Kadam wrote:
> > > +ð0 {
> > > + status = "okay";
> > > + phy-mode = "gmii";
> > > + phy-handle = <&phy1>;
> > > + phy1: ethernet-phy@0 {
> > > + reg = <0>;
> > > + };
>
> Hi Sagar
>
> Is there a good reason to call it phy1? Is there a phy0?
>
Sorry for the delayed response.
There is a single phy, so yes phy0 is a better name.
Thank you for pointing this out.
Thanks & Regards,
Sagar Kadam
> Thanks
>
> Andrew
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Marc Kleine-Budde @ 2019-07-22 8:15 UTC (permalink / raw)
To: Ji-Ze Hong (Peter Hong), wg, peter_hong
Cc: davem, f.suligoi, linux-kernel, linux-can, netdev,
Ji-Ze Hong (Peter Hong)
In-Reply-To: <1563776521-28317-1-git-send-email-hpeter+linux_kernel@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 8763 bytes --]
On 7/22/19 8:22 AM, Ji-Ze Hong (Peter Hong) wrote:
> This patch add support for Fintek PCIE to 2 CAN controller support
>
> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
> ---
> Changelog:
> v2:
> 1: Fix comment on the spinlock with write access.
> 2: Use ARRAY_SIZE instead of F81601_PCI_MAX_CHAN.
> 3: Check the strap pin outside the loop.
> 4: Fix the cleanup issue in f81601_pci_add_card().
> 5: Remove unused "channels" in struct f81601_pci_card.
>
> drivers/net/can/sja1000/Kconfig | 8 ++
> drivers/net/can/sja1000/Makefile | 1 +
> drivers/net/can/sja1000/f81601.c | 215 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/net/can/sja1000/f81601.c
>
> diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
> index f6dc89927ece..8588323c5138 100644
> --- a/drivers/net/can/sja1000/Kconfig
> +++ b/drivers/net/can/sja1000/Kconfig
> @@ -101,4 +101,12 @@ config CAN_TSCAN1
> IRQ numbers are read from jumpers JP4 and JP5,
> SJA1000 IO base addresses are chosen heuristically (first that works).
>
> +config CAN_F81601
> + tristate "Fintek F81601 PCIE to 2 CAN Controller"
> + depends on PCI
> + help
> + This driver adds support for Fintek F81601 PCIE to 2 CAN Controller.
> + It had internal 24MHz clock source, but it can be changed by
> + manufacturer. We can use modinfo to get usage for parameters.
> + Visit http://www.fintek.com.tw to get more information.
> endif
> diff --git a/drivers/net/can/sja1000/Makefile b/drivers/net/can/sja1000/Makefile
> index 9253aaf9e739..6f6268543bd9 100644
> --- a/drivers/net/can/sja1000/Makefile
> +++ b/drivers/net/can/sja1000/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_CAN_PEAK_PCMCIA) += peak_pcmcia.o
> obj-$(CONFIG_CAN_PEAK_PCI) += peak_pci.o
> obj-$(CONFIG_CAN_PLX_PCI) += plx_pci.o
> obj-$(CONFIG_CAN_TSCAN1) += tscan1.o
> +obj-$(CONFIG_CAN_F81601) += f81601.o
> diff --git a/drivers/net/can/sja1000/f81601.c b/drivers/net/can/sja1000/f81601.c
> new file mode 100644
> index 000000000000..3c378de8764d
> --- /dev/null
> +++ b/drivers/net/can/sja1000/f81601.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Fintek F81601 PCIE to 2 CAN controller driver
> + *
> + * Copyright (C) 2019 Peter Hong <peter_hong@fintek.com.tw>
> + * Copyright (C) 2019 Linux Foundation
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/netdevice.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/pci.h>
> +#include <linux/can/dev.h>
> +#include <linux/io.h>
> +#include <linux/version.h>
> +
> +#include "sja1000.h"
> +
> +#define F81601_PCI_MAX_CHAN 2
> +
> +#define F81601_DECODE_REG 0x209
> +#define F81601_IO_MODE BIT(7)
> +#define F81601_MEM_MODE BIT(6)
> +#define F81601_CFG_MODE BIT(5)
> +#define F81601_CAN2_INTERNAL_CLK BIT(3)
> +#define F81601_CAN1_INTERNAL_CLK BIT(2)
> +#define F81601_CAN2_EN BIT(1)
> +#define F81601_CAN1_EN BIT(0)
> +
> +#define F81601_TRAP_REG 0x20a
> +#define F81601_CAN2_HAS_EN BIT(4)
> +
> +struct f81601_pci_card {
> + void __iomem *addr;
> + spinlock_t lock; /* use this spin lock only for write access */
> + struct pci_dev *dev;
> + struct net_device *net_dev[F81601_PCI_MAX_CHAN];
> +};
> +
> +static const struct pci_device_id f81601_pci_tbl[] = {
> + { PCI_DEVICE(0x1c29, 0x1703) },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(pci, f81601_pci_tbl);
> +
> +static bool internal_clk = 1;
true
> +module_param(internal_clk, bool, 0444);
> +MODULE_PARM_DESC(internal_clk, "Use internal clock, default 1 (24MHz)");
> +
> +static unsigned int external_clk;
> +module_param(external_clk, uint, 0444);
> +MODULE_PARM_DESC(external_clk, "External Clock, must spec when internal_clk = 0");
> +
> +static u8 f81601_pci_read_reg(const struct sja1000_priv *priv, int port)
> +{
> + return readb(priv->reg_base + port);
> +}
> +
> +static void f81601_pci_write_reg(const struct sja1000_priv *priv, int port,
> + u8 val)
> +{
> + struct f81601_pci_card *card = priv->priv;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&card->lock, flags);
> + writeb(val, priv->reg_base + port);
> + readb(priv->reg_base);
> + spin_unlock_irqrestore(&card->lock, flags);
> +}
> +
> +static void f81601_pci_del_card(struct pci_dev *pdev)
> +{
> + struct f81601_pci_card *card = pci_get_drvdata(pdev);
> + struct net_device *dev;
> + int i = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(card->net_dev); i++) {
> + dev = card->net_dev[i];
> + if (!dev)
> + continue;
> +
> + dev_info(&pdev->dev, "%s: Removing %s\n", __func__, dev->name);
> +
> + unregister_sja1000dev(dev);
> + free_sja1000dev(dev);
> + }
> +
> + pcim_iounmap(pdev, card->addr);
> +}
> +
> +/* Probe F81601 based device for the SJA1000 chips and register each
> + * available CAN channel to SJA1000 Socket-CAN subsystem.
> + */
> +static int f81601_pci_add_card(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + struct sja1000_priv *priv;
> + struct net_device *dev;
> + struct f81601_pci_card *card;
> + int err, i, count;
> + u8 tmp;
> +
> + if (pcim_enable_device(pdev) < 0) {
I'm missing a corresponding disable_device().
> + dev_err(&pdev->dev, "Failed to enable PCI device\n");
> + return -ENODEV;
> + }
> +
> + dev_info(&pdev->dev, "Detected card at slot #%i\n",
> + PCI_SLOT(pdev->devfn));
> +
> + card = devm_kzalloc(&pdev->dev, sizeof(*card), GFP_KERNEL);
> + if (!card)
> + return -ENOMEM;
> +
> + card->dev = pdev;
> + spin_lock_init(&card->lock);
> +
> + pci_set_drvdata(pdev, card);
> +
> + tmp = F81601_IO_MODE | F81601_MEM_MODE | F81601_CFG_MODE |
> + F81601_CAN2_EN | F81601_CAN1_EN;
> +
> + if (internal_clk) {
> + tmp |= F81601_CAN2_INTERNAL_CLK | F81601_CAN1_INTERNAL_CLK;
> +
> + dev_info(&pdev->dev,
> + "F81601 running with internal clock: 24Mhz\n");
> + } else {
> + dev_info(&pdev->dev,
> + "F81601 running with external clock: %dMhz\n",
> + external_clk / 1000000);
> + }
> +
> + pci_write_config_byte(pdev, F81601_DECODE_REG, tmp);
> +
> + card->addr = pcim_iomap(pdev, 0, pci_resource_len(pdev, 0));
> +
> + if (!card->addr) {
> + err = -ENOMEM;
> + dev_err(&pdev->dev, "%s: Failed to remap BAR\n", __func__);
> + goto failure_cleanup;
> + }
> +
> + /* read CAN2_HW_EN strap pin to detect how many CANBUS do we have */
> + count = ARRAY_SIZE(card->net_dev);
> + pci_read_config_byte(pdev, F81601_TRAP_REG, &tmp);
> + if (!(tmp & F81601_CAN2_HAS_EN))
> + count = 1;
> +
> + /* Detect available channels */
> + for (i = 0; i < count; i++) {
> + dev = alloc_sja1000dev(0);
> + if (!dev) {
> + err = -ENOMEM;
> + goto failure_cleanup;
> + }
> +
> + priv = netdev_priv(dev);
> + priv->priv = card;
> + priv->irq_flags = IRQF_SHARED;
> + priv->reg_base = card->addr + 0x80 * i;
> + priv->read_reg = f81601_pci_read_reg;
> + priv->write_reg = f81601_pci_write_reg;
> +
> + if (internal_clk)
> + priv->can.clock.freq = 24000000 / 2;
> + else
> + priv->can.clock.freq = external_clk / 2;
> +
> + priv->ocr = OCR_TX0_PUSHPULL | OCR_TX1_PUSHPULL;
> + priv->cdr = CDR_CBP;
> +
> + SET_NETDEV_DEV(dev, &pdev->dev);
> + dev->dev_id = i;
> + dev->irq = pdev->irq;
> +
> + /* Register SJA1000 device */
> + err = register_sja1000dev(dev);
> + if (err) {
> + dev_err(&pdev->dev,
> + "%s: Registering device failed: %x\n", __func__,
> + err);
> + free_sja1000dev(dev);
> + goto failure_cleanup;
> + }
> +
> + card->net_dev[i] = dev;
> + dev_info(&pdev->dev, "Channel #%d, %s at 0x%p, irq %d\n", i,
> + dev->name, priv->reg_base, dev->irq);
> + }
> +
> + return 0;
> +
> +failure_cleanup:
> + dev_err(&pdev->dev, "%s: failed: %d. Cleaning Up.\n", __func__, err);
> + f81601_pci_del_card(pdev);
> +
> + return err;
> +}
> +
> +static struct pci_driver f81601_pci_driver = {
> + .name = "f81601",
> + .id_table = f81601_pci_tbl,
> + .probe = f81601_pci_add_card,
> + .remove = f81601_pci_del_card,
> +};
> +
> +MODULE_DESCRIPTION("Fintek F81601 PCIE to 2 CANBUS adaptor driver");
> +MODULE_AUTHOR("Peter Hong <peter_hong@fintek.com.tw>");
> +MODULE_LICENSE("GPL v2");
> +
> +module_pci_driver(f81601_pci_driver);
>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] net: usb: Merge cpu_to_le32s + memcpy to put_unaligned_le32
From: Chuhong Yuan @ 2019-07-22 7:41 UTC (permalink / raw)
Cc: David S . Miller, Woojung Huh, Microchip Linux Driver Support,
Steve Glendinning, linux-usb, netdev, linux-kernel, Chuhong Yuan
Merge the combo uses of cpu_to_le32s and memcpy.
Use put_unaligned_le32 instead.
This simplifies the code.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/usb/asix_common.c | 9 ++++-----
drivers/net/usb/ax88179_178a.c | 11 ++++-------
drivers/net/usb/lan78xx.c | 11 ++++-------
drivers/net/usb/smsc75xx.c | 11 ++++-------
drivers/net/usb/sr9800.c | 9 ++++-----
5 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index b39ee714fb01..e39f41efda3e 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -221,6 +221,7 @@ struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
int tailroom = skb_tailroom(skb);
u32 packet_len;
u32 padbytes = 0xffff0000;
+ void *ptr;
padlen = ((skb->len + 4) & (dev->maxpacket - 1)) ? 0 : 4;
@@ -256,13 +257,11 @@ struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
}
packet_len = ((skb->len ^ 0x0000ffff) << 16) + skb->len;
- skb_push(skb, 4);
- cpu_to_le32s(&packet_len);
- skb_copy_to_linear_data(skb, &packet_len, sizeof(packet_len));
+ ptr = skb_push(skb, 4);
+ put_unaligned_le32(packet_len, ptr);
if (padlen) {
- cpu_to_le32s(&padbytes);
- memcpy(skb_tail_pointer(skb), &padbytes, sizeof(padbytes));
+ put_unaligned_le32(padbytes, skb_tail_pointer(skb));
skb_put(skb, sizeof(padbytes));
}
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index 72d165114b67..daa54486ab09 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1421,6 +1421,7 @@ ax88179_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
int frame_size = dev->maxpacket;
int mss = skb_shinfo(skb)->gso_size;
int headroom;
+ void *ptr;
tx_hdr1 = skb->len;
tx_hdr2 = mss;
@@ -1435,13 +1436,9 @@ ax88179_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
return NULL;
}
- skb_push(skb, 4);
- cpu_to_le32s(&tx_hdr2);
- skb_copy_to_linear_data(skb, &tx_hdr2, 4);
-
- skb_push(skb, 4);
- cpu_to_le32s(&tx_hdr1);
- skb_copy_to_linear_data(skb, &tx_hdr1, 4);
+ ptr = skb_push(skb, 8);
+ put_unaligned_le32(tx_hdr1, ptr);
+ put_unaligned_le32(tx_hdr2, ptr + 4);
return skb;
}
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 9c33b35bd155..769bb262fbec 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2729,6 +2729,7 @@ static struct sk_buff *lan78xx_tx_prep(struct lan78xx_net *dev,
struct sk_buff *skb, gfp_t flags)
{
u32 tx_cmd_a, tx_cmd_b;
+ void *ptr;
if (skb_cow_head(skb, TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
@@ -2757,13 +2758,9 @@ static struct sk_buff *lan78xx_tx_prep(struct lan78xx_net *dev,
tx_cmd_b |= skb_vlan_tag_get(skb) & TX_CMD_B_VTAG_MASK_;
}
- skb_push(skb, 4);
- cpu_to_le32s(&tx_cmd_b);
- memcpy(skb->data, &tx_cmd_b, 4);
-
- skb_push(skb, 4);
- cpu_to_le32s(&tx_cmd_a);
- memcpy(skb->data, &tx_cmd_a, 4);
+ ptr = skb_push(skb, 8);
+ put_unaligned_le32(tx_cmd_a, ptr);
+ put_unaligned_le32(tx_cmd_b, ptr + 4);
return skb;
}
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 7fac9db5380d..9556d431885f 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2255,6 +2255,7 @@ static struct sk_buff *smsc75xx_tx_fixup(struct usbnet *dev,
struct sk_buff *skb, gfp_t flags)
{
u32 tx_cmd_a, tx_cmd_b;
+ void *ptr;
if (skb_cow_head(skb, SMSC75XX_TX_OVERHEAD)) {
dev_kfree_skb_any(skb);
@@ -2275,13 +2276,9 @@ static struct sk_buff *smsc75xx_tx_fixup(struct usbnet *dev,
tx_cmd_b = 0;
}
- skb_push(skb, 4);
- cpu_to_le32s(&tx_cmd_b);
- memcpy(skb->data, &tx_cmd_b, 4);
-
- skb_push(skb, 4);
- cpu_to_le32s(&tx_cmd_a);
- memcpy(skb->data, &tx_cmd_a, 4);
+ ptr = skb_push(skb, 8);
+ put_unaligned_le32(tx_cmd_a, ptr);
+ put_unaligned_le32(tx_cmd_b, ptr + 4);
return skb;
}
diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
index 35f39f23d881..c5d4a0060124 100644
--- a/drivers/net/usb/sr9800.c
+++ b/drivers/net/usb/sr9800.c
@@ -115,6 +115,7 @@ static struct sk_buff *sr_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
u32 padbytes = 0xffff0000;
u32 packet_len;
int padlen;
+ void *ptr;
padlen = ((skb->len + 4) % (dev->maxpacket - 1)) ? 0 : 4;
@@ -133,14 +134,12 @@ static struct sk_buff *sr_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
return NULL;
}
- skb_push(skb, 4);
+ ptr = skb_push(skb, 4);
packet_len = (((skb->len - 4) ^ 0x0000ffff) << 16) + (skb->len - 4);
- cpu_to_le32s(&packet_len);
- skb_copy_to_linear_data(skb, &packet_len, sizeof(packet_len));
+ put_unaligned_le32(packet_len, ptr);
if (padlen) {
- cpu_to_le32s(&padbytes);
- memcpy(skb_tail_pointer(skb), &padbytes, sizeof(padbytes));
+ put_unaligned_le32(padbytes, skb_tail_pointer(skb));
skb_put(skb, sizeof(padbytes));
}
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox