* [PATCH] net: can: ifi: Configure transmitter delay
From: Marek Vasut @ 2016-09-19 19:34 UTC (permalink / raw)
To: linux-can
Cc: Marek Vasut, Marc Kleine-Budde, Mark Rutland, Oliver Hartkopp,
Wolfgang Grandegger
Configure the transmitter delay register at +0x1c to correctly handle
the CAN FD bitrate switch (BRS). This moves the SSP (secondary sample
point) to a proper offset, so that the TDC mechanism works and won't
generate error frames on the CAN link.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/net/can/ifi_canfd/ifi_canfd.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 2d1d22e..368bb07 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -81,6 +81,10 @@
#define IFI_CANFD_TIME_SET_TIMEA_4_12_6_6 BIT(15)
#define IFI_CANFD_TDELAY 0x1c
+#define IFI_CANFD_TDELAY_DEFAULT 0xb
+#define IFI_CANFD_TDELAY_MASK 0x3fff
+#define IFI_CANFD_TDELAY_ABS BIT(14)
+#define IFI_CANFD_TDELAY_EN BIT(15)
#define IFI_CANFD_ERROR 0x20
#define IFI_CANFD_ERROR_TX_OFFSET 0
@@ -641,7 +645,7 @@ static void ifi_canfd_set_bittiming(struct net_device *ndev)
struct ifi_canfd_priv *priv = netdev_priv(ndev);
const struct can_bittiming *bt = &priv->can.bittiming;
const struct can_bittiming *dbt = &priv->can.data_bittiming;
- u16 brp, sjw, tseg1, tseg2;
+ u16 brp, sjw, tseg1, tseg2, tdc;
/* Configure bit timing */
brp = bt->brp - 2;
@@ -664,6 +668,11 @@ static void ifi_canfd_set_bittiming(struct net_device *ndev)
(brp << IFI_CANFD_TIME_PRESCALE_OFF) |
(sjw << IFI_CANFD_TIME_SJW_OFF_7_9_8_8),
priv->base + IFI_CANFD_FTIME);
+
+ /* Configure transmitter delay */
+ tdc = (dbt->brp * (dbt->phase_seg1 + 1)) & IFI_CANFD_TDELAY_MASK;
+ writel(IFI_CANFD_TDELAY_EN | IFI_CANFD_TDELAY_ABS | tdc,
+ priv->base + IFI_CANFD_TDELAY);
}
static void ifi_canfd_set_filter(struct net_device *ndev, const u32 id,
--
2.9.3
^ permalink raw reply related
* Re: j1939
From: Marc Kleine-Budde @ 2016-09-19 18:52 UTC (permalink / raw)
To: Oliver Hartkopp, linux-can; +Cc: David Jander, Kurt Van Dijck
In-Reply-To: <018c2e89-87c0-c1cc-686e-d5d715651ab3@hartkopp.net>
[-- Attachment #1.1: Type: text/plain, Size: 1275 bytes --]
On 09/19/2016 08:27 PM, Oliver Hartkopp wrote:
> On 09/19/2016 06:54 PM, Marc Kleine-Budde wrote:
>
>>
>> Another thing that IMHO has to be sorted out is the use of module
>> parameters:
>>
>>> ./main.c:49:MODULE_PARM_DESC(padding, "Pad all packets to 8 bytes, and stuff with 0xff");
>>> ./transport.c:60:MODULE_PARM_DESC(transport_burst_count, "Number of packets to send in burst between flow control (1..255, default 255)");
>>> ./transport.c:61:MODULE_PARM_DESC(transport_max_size, "Maximum packet size (default 100k)");
>>> ./transport.c:62:MODULE_PARM_DESC(transport_retry_time, "Packet retransmission timeout in msecs, used in case of buffer full. (default 20)");
>>> ./transport.c:63:MODULE_PARM_DESC(transport_packet_delay, "Delay between packets to avoid buffer overruns (default 0)");
>>
>> Better convert them to netlink options.
>>
>
> What about putting them into socket depended sockopts with setsockopt()?
Is it a per interface or a per socket setting?
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: 455 bytes --]
^ permalink raw reply
* Re: j1939
From: Oliver Hartkopp @ 2016-09-19 18:27 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can; +Cc: David Jander, Kurt Van Dijck
In-Reply-To: <a6ad3606-b295-dc72-c557-098c45769cb9@pengutronix.de>
On 09/19/2016 06:54 PM, Marc Kleine-Budde wrote:
>
> Another thing that IMHO has to be sorted out is the use of module
> parameters:
>
>> ./main.c:49:MODULE_PARM_DESC(padding, "Pad all packets to 8 bytes, and stuff with 0xff");
>> ./transport.c:60:MODULE_PARM_DESC(transport_burst_count, "Number of packets to send in burst between flow control (1..255, default 255)");
>> ./transport.c:61:MODULE_PARM_DESC(transport_max_size, "Maximum packet size (default 100k)");
>> ./transport.c:62:MODULE_PARM_DESC(transport_retry_time, "Packet retransmission timeout in msecs, used in case of buffer full. (default 20)");
>> ./transport.c:63:MODULE_PARM_DESC(transport_packet_delay, "Delay between packets to avoid buffer overruns (default 0)");
>
> Better convert them to netlink options.
>
What about putting them into socket depended sockopts with setsockopt()?
Regards,
Oliver
> Next think I'll do is to establish some communication with an external
> j1939 component. I'll keep you updated.
>
> regards,
> Marc
>
^ permalink raw reply
* j1939
From: Marc Kleine-Budde @ 2016-09-19 16:54 UTC (permalink / raw)
To: linux-can; +Cc: David Jander, Kurt Van Dijck
[-- Attachment #1.1: Type: text/plain, Size: 7204 bytes --]
Hello,
I've ported Kurt's latest j1939 patches to linux-4.7. I've squashed all
patches into one. Then a patch to undo unused modifications and a bunch
of patches to make checkpatch happy.
I've pushed the result to
https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/log/?h=j1939
The remaining warning is about a case statement without fall through
annotations and/or breaks:
> WARNING: Possible switch case/default not preceeded by break or fallthrough comment
> #4017: FILE: net/can/j1939/transport.c:1031:
> + case tp_cmd_cts:
>
> WARNING: Possible switch case/default not preceeded by break or fallthrough comment
> #4018: FILE: net/can/j1939/transport.c:1032:
> + case 0xff: /* did some data */
>
> WARNING: Possible switch case/default not preceeded by break or fallthrough comment
> #4019: FILE: net/can/j1939/transport.c:1033:
> + case etp_cmd_dpo:
The code in question is:
> /* transmit function */
> static int j1939tp_txnext(struct session *session)
> {
> u8 dat[8];
> const u8 *tpdat;
> int ret, offset, pkt_done, pkt_end;
> unsigned int pkt, len, pdelay;
>
> memset(dat, 0xff, sizeof(dat));
> get_session(session); /* do not loose it */
>
> switch (session->last_cmd) {
> case 0:
> if (!j1939tp_im_transmitter(session->skb))
> break;
> dat[1] = (session->skb->len >> 0) & 0xff;
> dat[2] = (session->skb->len >> 8) & 0xff;
> dat[3] = session->pkt.total;
> if (session->extd) {
> dat[0] = etp_cmd_rts;
> dat[1] = (session->skb->len >> 0) & 0xff;
> dat[2] = (session->skb->len >> 8) & 0xff;
> dat[3] = (session->skb->len >> 16) & 0xff;
> dat[4] = (session->skb->len >> 24) & 0xff;
> } else if (j1939cb_is_broadcast(session->cb)) {
> dat[0] = tp_cmd_bam;
> /* fake cts for broadcast */
> session->pkt.tx = 0;
> } else {
> dat[0] = tp_cmd_rts;
> dat[4] = dat[3];
> }
> if (dat[0] == session->last_txcmd)
> /* done already */
> break;
> ret = j1939tp_tx_ctl(session, 0, dat);
> if (ret < 0)
> goto failed;
> session->last_txcmd = dat[0];
> /* must lock? */
> if (tp_cmd_bam == dat[0])
> j1939tp_schedule_txtimer(session, 50);
> j1939tp_set_rxtimeout(session, 1250);
> break;
> case tp_cmd_rts:
> case etp_cmd_rts:
> if (!j1939tp_im_receiver(session->skb))
> break;
> tx_cts:
> ret = 0;
> len = session->pkt.total - session->pkt.done;
> len = min(max(len, session->pkt.block), block ?: 255);
>
> if (session->extd) {
> pkt = session->pkt.done + 1;
> dat[0] = etp_cmd_cts;
> dat[1] = len;
> dat[2] = (pkt >> 0) & 0xff;
> dat[3] = (pkt >> 8) & 0xff;
> dat[4] = (pkt >> 16) & 0xff;
> } else {
> dat[0] = tp_cmd_cts;
> dat[1] = len;
> dat[2] = session->pkt.done + 1;
> }
> if (dat[0] == session->last_txcmd)
> /* done already */
> break;
> ret = j1939tp_tx_ctl(session, 1, dat);
> if (ret < 0)
> goto failed;
> if (len)
> /* only mark cts done when len is set */
> session->last_txcmd = dat[0];
> j1939tp_set_rxtimeout(session, 1250);
> break;
> case etp_cmd_cts:
> if (j1939tp_im_transmitter(session->skb) && session->extd &&
> (etp_cmd_dpo != session->last_txcmd)) {
> /* do dpo */
> dat[0] = etp_cmd_dpo;
> session->pkt.dpo = session->pkt.done;
> pkt = session->pkt.dpo;
> dat[1] = session->pkt.last - session->pkt.done;
> dat[2] = (pkt >> 0) & 0xff;
> dat[3] = (pkt >> 8) & 0xff;
> dat[4] = (pkt >> 16) & 0xff;
> ret = j1939tp_tx_ctl(session, 0, dat);
> if (ret < 0)
> goto failed;
> session->last_txcmd = dat[0];
> j1939tp_set_rxtimeout(session, 1250);
> session->pkt.tx = session->pkt.done;
> }
> case tp_cmd_cts:
> case 0xff: /* did some data */
> case etp_cmd_dpo:
> if ((session->extd || !j1939cb_is_broadcast(session->cb)) &&
> j1939tp_im_receiver(session->skb)) {
> if (session->pkt.done >= session->pkt.total) {
> if (session->extd) {
> dat[0] = etp_cmd_eof;
> dat[1] = session->skb->len >> 0;
> dat[2] = session->skb->len >> 8;
> dat[3] = session->skb->len >> 16;
> dat[4] = session->skb->len >> 24;
> } else {
> dat[0] = tp_cmd_eof;
> dat[1] = session->skb->len;
> dat[2] = session->skb->len >> 8;
> dat[3] = session->pkt.total;
> }
> if (dat[0] == session->last_txcmd)
> /* done already */
> break;
> ret = j1939tp_tx_ctl(session, 1, dat);
> if (ret < 0)
> goto failed;
> session->last_txcmd = dat[0];
> j1939tp_set_rxtimeout(session, 1250);
> /* wait for the EOF packet to come in */
> break;
> } else if (session->pkt.done >= session->pkt.last) {
> session->last_txcmd = 0;
> goto tx_cts;
> }
> }
> case tp_cmd_bam:
> if (!j1939tp_im_transmitter(session->skb))
> break;
> tpdat = session->skb->data;
> ret = 0;
> pkt_done = 0;
> pkt_end = (!session->extd && j1939cb_is_broadcast(session->cb))
> ? session->pkt.total : session->pkt.last;
>
> while (session->pkt.tx < pkt_end) {
> dat[0] = session->pkt.tx - session->pkt.dpo + 1;
> offset = session->pkt.tx * 7;
> len = session->skb->len - offset;
> if (len > 7)
> len = 7;
> memcpy(&dat[1], &tpdat[offset], len);
> ret = j1939tp_tx_dat(session->skb, session->extd,
> dat, len + 1);
> if (ret < 0)
> break;
> session->last_txcmd = 0xff;
> ++pkt_done;
> ++session->pkt.tx;
> pdelay = j1939cb_is_broadcast(session->cb) ? 50 :
> packet_delay;
> if ((session->pkt.tx < session->pkt.total) && pdelay) {
> j1939tp_schedule_txtimer(session, pdelay);
> break;
> }
> }
> if (pkt_done)
> j1939tp_set_rxtimeout(session, 250);
> if (ret)
> goto failed;
> break;
> }
> put_session(session);
> return 0;
> failed:
> put_session(session);
> return ret;
> }
Is here someone with insight and can tell if the code is correct this way?
Another thing that IMHO has to be sorted out is the use of module
parameters:
> ./main.c:49:MODULE_PARM_DESC(padding, "Pad all packets to 8 bytes, and stuff with 0xff");
> ./transport.c:60:MODULE_PARM_DESC(transport_burst_count, "Number of packets to send in burst between flow control (1..255, default 255)");
> ./transport.c:61:MODULE_PARM_DESC(transport_max_size, "Maximum packet size (default 100k)");
> ./transport.c:62:MODULE_PARM_DESC(transport_retry_time, "Packet retransmission timeout in msecs, used in case of buffer full. (default 20)");
> ./transport.c:63:MODULE_PARM_DESC(transport_packet_delay, "Delay between packets to avoid buffer overruns (default 0)");
Better convert them to netlink options.
Next think I'll do is to establish some communication with an external
j1939 component. I'll keep you updated.
regards,
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: 455 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v3] can: flexcan: fix resume function
From: Marc Kleine-Budde @ 2016-09-19 14:20 UTC (permalink / raw)
To: Fabio Estevam; +Cc: wg, linux-can, Fabio Estevam
In-Reply-To: <1473113716-2834-1-git-send-email-festevam@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1075 bytes --]
On 09/06/2016 12:15 AM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> On a imx6ul-pico board the following error is seen during system suspend:
>
> dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110
> PM: Device 2090000.flexcan failed to resume: error -110
>
> The reason for this suspend error is because when the CAN interface is not
> active the clocks are disabled and then flexcan_chip_enable() will
> always fail due to a timeout error.
>
> In order to fix this issue, only call flexcan_chip_enable/disable()
> when the CAN interface is active.
>
> Based on a patch from Dong Aisheng in the NXP kernel.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied to can with stable on Cc.
Thanks,
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: 455 bytes --]
^ permalink raw reply
* pull-request: can 2016-09-19
From: Marc Kleine-Budde @ 2016-09-19 14:19 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request of one patch for the upcoming linux-4.8 release.
The patch by Fabio Estevam fixes the pm handling in the flexcan driver.
regards,
Marc
---
The following changes since commit 7ac327318e09a53e3df431dfd3f664dac7aba4df:
Merge tag 'mac80211-for-davem-2016-09-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2016-09-18 22:26:49 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.8-20160919
for you to fetch changes up to 4de349e786a3a2d51bd02d56f3de151bbc3c3df9:
can: flexcan: fix resume function (2016-09-19 16:09:05 +0200)
----------------------------------------------------------------
linux-can-fixes-for-4.8-20160919
----------------------------------------------------------------
Fabio Estevam (1):
can: flexcan: fix resume function
drivers/net/can/flexcan.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH] can: flexcan: fix resume function
From: Marc Kleine-Budde @ 2016-09-19 14:19 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Fabio Estevam, linux-stable,
Marc Kleine-Budde
In-Reply-To: <20160919141949.5826-1-mkl@pengutronix.de>
From: Fabio Estevam <fabio.estevam@nxp.com>
On a imx6ul-pico board the following error is seen during system suspend:
dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110
PM: Device 2090000.flexcan failed to resume: error -110
The reason for this suspend error is because when the CAN interface is not
active the clocks are disabled and then flexcan_chip_enable() will
always fail due to a timeout error.
In order to fix this issue, only call flexcan_chip_enable/disable()
when the CAN interface is active.
Based on a patch from Dong Aisheng in the NXP kernel.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/flexcan.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 41c0fc9f3b14..16f7cadda5c3 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1268,11 +1268,10 @@ static int __maybe_unused flexcan_suspend(struct device *device)
struct flexcan_priv *priv = netdev_priv(dev);
int err;
- err = flexcan_chip_disable(priv);
- if (err)
- return err;
-
if (netif_running(dev)) {
+ err = flexcan_chip_disable(priv);
+ if (err)
+ return err;
netif_stop_queue(dev);
netif_device_detach(dev);
}
@@ -1285,13 +1284,17 @@ static int __maybe_unused flexcan_resume(struct device *device)
{
struct net_device *dev = dev_get_drvdata(device);
struct flexcan_priv *priv = netdev_priv(dev);
+ int err;
priv->can.state = CAN_STATE_ERROR_ACTIVE;
if (netif_running(dev)) {
netif_device_attach(dev);
netif_start_queue(dev);
+ err = flexcan_chip_enable(priv);
+ if (err)
+ return err;
}
- return flexcan_chip_enable(priv);
+ return 0;
}
static SIMPLE_DEV_PM_OPS(flexcan_pm_ops, flexcan_suspend, flexcan_resume);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v4] can: sja1000: Optimise register accesses
From: Marc Kleine-Budde @ 2016-09-19 14:08 UTC (permalink / raw)
To: Nikita Edward Baruzdin, linux-can
In-Reply-To: <20160908135101.17978-1-nebaruzdin@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5497 bytes --]
On 09/08/2016 03:51 PM, Nikita Edward Baruzdin wrote:
> Since PCI bus width is at least 32 bits, using ioread32()/iowrite32()
> instead of consecutive ioread8()/iowrite8() calls seems reasonable.
>
> Thus, this patch introduces [read|write]_reg_rep() interface functions
> that are used to read/write CAN ID and payload data.
>
> * For plx_pci driver this interface is implemented as
> plx_pci_[read|write]_reg_rep() that use ioread32()/iowrite32() for
> register accesses as much as possible to improve driver performance.
>
> * For other drivers the default implementation,
> sja1000_[read|write]_reg_rep(), is used for now. These functions
> still access registers in a series of ioread8()/iowrite8() calls.
>
> Signed-off-by: Nikita Edward Baruzdin <nebaruzdin@gmail.com>
> ---
> drivers/net/can/sja1000/plx_pci.c | 38 +++++++++++++++++++++++++++
> drivers/net/can/sja1000/sja1000.c | 55 ++++++++++++++++++++++++---------------
> drivers/net/can/sja1000/sja1000.h | 4 +++
> 3 files changed, 76 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
> index 3eb7430..ff2858f 100644
> --- a/drivers/net/can/sja1000/plx_pci.c
> +++ b/drivers/net/can/sja1000/plx_pci.c
> @@ -371,6 +371,42 @@ static void plx_pci_write_reg(const struct sja1000_priv *priv, int port, u8 val)
> iowrite8(val, priv->reg_base + port);
> }
>
> +static void plx_pci_read_reg_rep(const struct sja1000_priv *priv, int reg,
> + u8 *buffer, size_t count)
> +{
> + while (count >= 4) {
> + *(__le32 *)buffer = cpu_to_le32(ioread32(priv->reg_base + reg));
> + buffer += 4;
> + reg += 4;
> + count -= 4;
> + }
> + if (count & 2) {
> + *(__le16 *)buffer = cpu_to_le16(ioread16(priv->reg_base + reg));
> + buffer += 2;
> + reg += 2;
> + }
> + if (count & 1)
> + *buffer = ioread8(priv->reg_base + reg);
> +}
> +
> +static void plx_pci_write_reg_rep(const struct sja1000_priv *priv, int reg,
> + const u8 *buffer, size_t count)
> +{
> + while (count >= 4) {
> + iowrite32(le32_to_cpu(*(__le32 *)buffer), priv->reg_base + reg);
> + buffer += 4;
> + reg += 4;
> + count -= 4;
> + }
> + if (count & 2) {
> + iowrite16(le16_to_cpu(*(__le16 *)buffer), priv->reg_base + reg);
> + buffer += 2;
> + reg += 2;
> + }
> + if (count & 1)
> + iowrite8(*buffer, priv->reg_base + reg);
> +}
> +
> /*
> * Check if a CAN controller is present at the specified location
> * by trying to switch 'em from the Basic mode into the PeliCAN mode.
> @@ -626,6 +662,8 @@ static int plx_pci_add_card(struct pci_dev *pdev,
> priv->reg_base = addr + cm->offset;
> priv->read_reg = plx_pci_read_reg;
> priv->write_reg = plx_pci_write_reg;
> + priv->read_reg_rep = plx_pci_read_reg_rep;
> + priv->write_reg_rep = plx_pci_write_reg_rep;
>
> /* Check if channel is present */
> if (plx_pci_check_sja1000(priv)) {
> diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
> index 9f10779..ff046f3 100644
> --- a/drivers/net/can/sja1000/sja1000.c
> +++ b/drivers/net/can/sja1000/sja1000.c
> @@ -82,6 +82,24 @@ static const struct can_bittiming_const sja1000_bittiming_const = {
> .brp_inc = 1,
> };
>
> +static void sja1000_read_reg_rep(const struct sja1000_priv *priv, int reg,
> + u8 *buffer, size_t count)
> +{
> + int i;
> +
> + for (i = 0; i < count; i++)
> + buffer[i] = priv->read_reg(priv, reg + i);
> +}
> +
> +static void sja1000_write_reg_rep(const struct sja1000_priv *priv, int reg,
> + const u8 *buffer, size_t count)
> +{
> + int i;
> +
> + for (i = 0; i < count; i++)
> + priv->write_reg(priv, reg + i, buffer[i]);
> +}
> +
> static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val)
> {
> unsigned long flags;
> @@ -288,7 +306,7 @@ static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb,
> canid_t id;
> uint8_t dreg;
> u8 cmd_reg_val = 0x00;
> - int i;
> + u8 id_buf[4];
>
> if (can_dropped_invalid_skb(dev, skb))
> return NETDEV_TX_OK;
> @@ -305,19 +323,16 @@ static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb,
> fi |= SJA1000_FI_FF;
> dreg = SJA1000_EFF_BUF;
> priv->write_reg(priv, SJA1000_FI, fi);
> - priv->write_reg(priv, SJA1000_ID1, (id & 0x1fe00000) >> 21);
> - priv->write_reg(priv, SJA1000_ID2, (id & 0x001fe000) >> 13);
> - priv->write_reg(priv, SJA1000_ID3, (id & 0x00001fe0) >> 5);
> - priv->write_reg(priv, SJA1000_ID4, (id & 0x0000001f) << 3);
> + *(__be32 *)id_buf = cpu_to_be32(id << 3);
> + priv->write_reg_rep(priv, SJA1000_ID1, id_buf, 4);
I talked to my PCI expert and we came to the conclusion that it's a very
bad idea to acess the PCI bus with 32 bit on non aligned addresses.
#define SJA1000_ID1 0x11
This may work on x86 but we're not sure about other platforms.
Maybe it's an option to create a struct describing the memory layout
starting with 0x10. And then read it in different chunks, depending if
we have a read_rep function or not.
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: 455 bytes --]
^ permalink raw reply
* Re: [PATCH] CAN bus MIOe-3680 PCI (dual SJA1000 channel) emulation added.
From: Deniz Eren @ 2016-09-18 4:33 UTC (permalink / raw)
To: Pavel Pisa; +Cc: pbonzini, jasowang, rizzo, qemu-devel, linux-can
In-Reply-To: <201609081910.28236.pisa@cmp.felk.cvut.cz>
Hi Pavel,
Thank you for the merge - CAN-bus support for QEMU is very important in my opinion. Most embedded applications utilise CAN and virtualising this interface gives an amazing integration test harness.
Best regards,
Deniz
Sent from my iPhone
Deniz Eren
+61 400 307 762
> On 9 Sep. 2016, at 3:10 am, Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote:
>
> Hello Deniz,
>
> thanks much for contribution and testing.
>
> I have applied your patches to our QEMU
> repo
>
> https://github.com/CTU-IIG/qemu
>
> You find QEMU-2.6.1 based version of our merged
> patches on "merged-2.6" branch.
>
> I have updated and shortly tested all our topic branches
> with actual QEMU-2.7.0 release. Simple test with
> Linux within Linux and SocketCAN on both sides
> works for PCI CAN-S (single SJA1000 channel) card
> well with QEMU-2.7.0.
>
> So I have undated all topics branches "can-pci",
> "mf624" and "apohw" to this version then and created
> "merged-2.7" branch. "merged" branch is now moved
> to "merged-2.7" as well.
>
> Your offer to help with mainlining is great as well.
> Some discussion with somebody from core QEMU team
> member is required.
>
> I hope that actual CAN chip driver and PCI cards
> follow QOM model right way. Problem is the simple
> bus used for mesages delivery between CAN controllers.
> These buses should be converted somehow to QOM acceptable
> model. But for embedded development when you do not
> freeze emulated system state is actual solution quite
> usable as well.
>
> It would be great to implement CAN FD (Flexible Datarate)
> controller emulation support as well.
>
> I am trying to find some diploma student for that for
> two years already because he/she can have continuous
> time for such work and testing which I cannot find.
> Help from other instreested or project users would
> be great as well.
>
> Best wishes,
>
> Pavel
>
>
>
>
^ permalink raw reply
* (unknown),
From: makafe david @ 2016-09-17 8:07 UTC (permalink / raw)
Hello!
I have something I wanna share with you. Kindly reply back if interested.
Thank you!!
^ permalink raw reply
* Open Source CANopen Stack
From: Andri Yngvason @ 2016-09-16 18:23 UTC (permalink / raw)
To: linux-can
Hi guys,
I've written a new CANopen master.
I asked the boss if I could make it Open Source and he said yes.
So... enjoy :)
https://github.com/marel-keytech/openCANopen
Best regards,
Andri
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-12 21:11 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Felipe Balbi, Julia Lawall, linux-renesas-soc, joe,
kernel-janitors, Sergei Shtylyov, linux-pm, platform-driver-x86,
linux-media, linux-can, Tatyana Nikolova, Shiraz Saleem,
Mustafa Ismail, Chien Tin Tung, linux-rdma, netdev, devel,
alsa-devel, linux-kernel, linux-fbdev, linux-wireless,
Jason Gunthorpe
In-Reply-To: <20160912201450.GA8889@intel.com>
On Mon, 12 Sep 2016, Jarkko Sakkinen wrote:
> On Mon, Sep 12, 2016 at 04:43:58PM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> > > On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> > >>
> > >>
> > >> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> > >>
> > >> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > >> > > Constify local structures.
> > >> > >
> > >> > > The semantic patch that makes this change is as follows:
> > >> > > (http://coccinelle.lip6.fr/)
> > >> >
> > >> > Just my two cents but:
> > >> >
> > >> > 1. You *can* use a static analysis too to find bugs or other issues.
> > >> > 2. However, you should manually do the commits and proper commit
> > >> > messages to subsystems based on your findings. And I generally think
> > >> > that if one contributes code one should also at least smoke test changes
> > >> > somehow.
> > >> >
> > >> > I don't know if I'm alone with my opinion. I just think that one should
> > >> > also do the analysis part and not blindly create and submit patches.
> > >>
> > >> All of the patches are compile tested. And the individual patches are
> > >
> > > Compile-testing is not testing. If you are not able to test a commit,
> > > you should explain why.
> >
> > Dude, Julia has been doing semantic patching for years already and
> > nobody has raised any concerns so far. There's already an expectation
> > that Coccinelle *works* and Julia's sematic patches are sound.
> >
> > Besides, adding 'const' is something that causes virtually no functional
> > changes to the point that build-testing is really all you need. Any
> > problems caused by adding 'const' to a definition will be seen by build
> > errors or warnings.
> >
> > Really, just stop with the pointless discussion and go read a bit about
> > Coccinelle and what semantic patches are giving you. The work done by
> > Julia and her peers are INRIA have measurable benefits.
> >
> > You're really making a thunderstorm in a glass of water.
>
> Hmm... I've been using coccinelle in cyclic basis for some time now.
> My comment was oversized but I didn't mean it to be impolite or attack
> of any kind for that matter.
No problem :) Thanks for the feedback.
julia
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Jarkko Sakkinen @ 2016-09-12 20:14 UTC (permalink / raw)
To: Felipe Balbi
Cc: alsa-devel, Mustafa Ismail, Tatyana Nikolova, kernel-janitors,
linux-fbdev, platform-driver-x86, devel, linux-scsi, linux-rdma,
Jason Gunthorpe, linux-acpi, tpmdd-devel, linux-media, linux-pm,
linux-can, Julia Lawall, Shiraz Saleem, Sergei Shtylyov, netdev,
Chien Tin Tung, linux-wireless, linux-kernel, linux-spi,
linux-renesas-soc, linux-usb, joe
In-Reply-To: <877fah5j35.fsf@linux.intel.com>
On Mon, Sep 12, 2016 at 04:43:58PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> > On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> >>
> >>
> >> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> >>
> >> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> >> > > Constify local structures.
> >> > >
> >> > > The semantic patch that makes this change is as follows:
> >> > > (http://coccinelle.lip6.fr/)
> >> >
> >> > Just my two cents but:
> >> >
> >> > 1. You *can* use a static analysis too to find bugs or other issues.
> >> > 2. However, you should manually do the commits and proper commit
> >> > messages to subsystems based on your findings. And I generally think
> >> > that if one contributes code one should also at least smoke test changes
> >> > somehow.
> >> >
> >> > I don't know if I'm alone with my opinion. I just think that one should
> >> > also do the analysis part and not blindly create and submit patches.
> >>
> >> All of the patches are compile tested. And the individual patches are
> >
> > Compile-testing is not testing. If you are not able to test a commit,
> > you should explain why.
>
> Dude, Julia has been doing semantic patching for years already and
> nobody has raised any concerns so far. There's already an expectation
> that Coccinelle *works* and Julia's sematic patches are sound.
>
> Besides, adding 'const' is something that causes virtually no functional
> changes to the point that build-testing is really all you need. Any
> problems caused by adding 'const' to a definition will be seen by build
> errors or warnings.
>
> Really, just stop with the pointless discussion and go read a bit about
> Coccinelle and what semantic patches are giving you. The work done by
> Julia and her peers are INRIA have measurable benefits.
>
> You're really making a thunderstorm in a glass of water.
Hmm... I've been using coccinelle in cyclic basis for some time now.
My comment was oversized but I didn't mean it to be impolite or attack
of any kind for that matter.
> --
> balbi
/Jarkko
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Jarkko Sakkinen @ 2016-09-12 18:50 UTC (permalink / raw)
To: Julia Lawall
Cc: Felipe Balbi, linux-renesas-soc, joe, kernel-janitors,
Sergei Shtylyov, linux-pm, platform-driver-x86, linux-media,
linux-can, Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail,
Chien Tin Tung, linux-rdma, netdev, devel, alsa-devel,
linux-kernel, linux-fbdev, linux-wireless, Jason Gunthorpe,
tpmdd-devel, linux-scsi@
In-Reply-To: <alpine.DEB.2.10.1609121548200.29099@hadrien>
On Mon, Sep 12, 2016 at 03:52:08PM +0200, Julia Lawall wrote:
>
>
> On Mon, 12 Sep 2016, Felipe Balbi wrote:
>
> >
> > Hi,
> >
> > Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> > > On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> > >>
> > >>
> > >> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> > >>
> > >> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > >> > > Constify local structures.
> > >> > >
> > >> > > The semantic patch that makes this change is as follows:
> > >> > > (http://coccinelle.lip6.fr/)
> > >> >
> > >> > Just my two cents but:
> > >> >
> > >> > 1. You *can* use a static analysis too to find bugs or other issues.
> > >> > 2. However, you should manually do the commits and proper commit
> > >> > messages to subsystems based on your findings. And I generally think
> > >> > that if one contributes code one should also at least smoke test changes
> > >> > somehow.
> > >> >
> > >> > I don't know if I'm alone with my opinion. I just think that one should
> > >> > also do the analysis part and not blindly create and submit patches.
> > >>
> > >> All of the patches are compile tested. And the individual patches are
> > >
> > > Compile-testing is not testing. If you are not able to test a commit,
> > > you should explain why.
> >
> > Dude, Julia has been doing semantic patching for years already and
> > nobody has raised any concerns so far. There's already an expectation
> > that Coccinelle *works* and Julia's sematic patches are sound.
> >
> > Besides, adding 'const' is something that causes virtually no functional
> > changes to the point that build-testing is really all you need. Any
> > problems caused by adding 'const' to a definition will be seen by build
> > errors or warnings.
> >
> > Really, just stop with the pointless discussion and go read a bit about
> > Coccinelle and what semantic patches are giving you. The work done by
> > Julia and her peers are INRIA have measurable benefits.
> >
> > You're really making a thunderstorm in a glass of water.
>
> Thanks for the defense, but since a lot of these patches torned out to be
> wrong, due to an incorrect parse by Coccinelle, combined with an
> unpleasantly lax compiler, Jarkko does have a point that I should have
> looked at the patches more carefully. In any case, I have written to the
> maintainers relevant to the patches that turned out to be incorrect.
Exactly. I'm not excepting that every commit would require extensive
analysis but it would be good to quickly at least skim through commits
and see if they make sense (or ask if unsure) :)
And I'm fine with compile testing if it is mentioned in the commit msg.
> julia
/Jarkko
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Geert Uytterhoeven @ 2016-09-12 13:57 UTC (permalink / raw)
To: Felipe Balbi
Cc: Jarkko Sakkinen, Julia Lawall, Linux-Renesas, Joe Perches,
kernel-janitors@vger.kernel.org, Sergei Shtylyov, Linux PM list,
platform-driver-x86, Linux Media Mailing List, linux-can,
Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail, Chien Tin Tung,
linux-rdma, netdev@vger.kernel.org, driverdevel
In-Reply-To: <877fah5j35.fsf@linux.intel.com>
On Mon, Sep 12, 2016 at 3:43 PM, Felipe Balbi
<felipe.balbi@linux.intel.com> wrote:
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
>> On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
>>> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
>>> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
>>> > > Constify local structures.
>>> > >
>>> > > The semantic patch that makes this change is as follows:
>>> > > (http://coccinelle.lip6.fr/)
>>> >
>>> > Just my two cents but:
>>> >
>>> > 1. You *can* use a static analysis too to find bugs or other issues.
>>> > 2. However, you should manually do the commits and proper commit
>>> > messages to subsystems based on your findings. And I generally think
>>> > that if one contributes code one should also at least smoke test changes
>>> > somehow.
>>> >
>>> > I don't know if I'm alone with my opinion. I just think that one should
>>> > also do the analysis part and not blindly create and submit patches.
>>>
>>> All of the patches are compile tested. And the individual patches are
>>
>> Compile-testing is not testing. If you are not able to test a commit,
>> you should explain why.
>
> Dude, Julia has been doing semantic patching for years already and
> nobody has raised any concerns so far. There's already an expectation
> that Coccinelle *works* and Julia's sematic patches are sound.
+1
> Besides, adding 'const' is something that causes virtually no functional
> changes to the point that build-testing is really all you need. Any
> problems caused by adding 'const' to a definition will be seen by build
> errors or warnings.
Unfortunately in this particular case they could lead to failures that can only
be detected at runtime, when failing o write to a read-only piece of memory,
due to the casting away of the constness of the pointers later.
Fortunately this was detected during code review (doh...).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-12 13:52 UTC (permalink / raw)
To: Felipe Balbi
Cc: alsa-devel, Mustafa Ismail, Tatyana Nikolova, kernel-janitors,
linux-fbdev, Jarkko Sakkinen, platform-driver-x86, devel,
linux-scsi, linux-rdma, Jason Gunthorpe, linux-acpi, tpmdd-devel,
linux-media, linux-pm, linux-can, Julia Lawall, Shiraz Saleem,
Sergei Shtylyov, netdev, Chien Tin Tung, linux-wireless,
linux-kernel, linux-spi, linux-renesas-soc, linux-usb
In-Reply-To: <877fah5j35.fsf@linux.intel.com>
On Mon, 12 Sep 2016, Felipe Balbi wrote:
>
> Hi,
>
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> > On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> >>
> >>
> >> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> >>
> >> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> >> > > Constify local structures.
> >> > >
> >> > > The semantic patch that makes this change is as follows:
> >> > > (http://coccinelle.lip6.fr/)
> >> >
> >> > Just my two cents but:
> >> >
> >> > 1. You *can* use a static analysis too to find bugs or other issues.
> >> > 2. However, you should manually do the commits and proper commit
> >> > messages to subsystems based on your findings. And I generally think
> >> > that if one contributes code one should also at least smoke test changes
> >> > somehow.
> >> >
> >> > I don't know if I'm alone with my opinion. I just think that one should
> >> > also do the analysis part and not blindly create and submit patches.
> >>
> >> All of the patches are compile tested. And the individual patches are
> >
> > Compile-testing is not testing. If you are not able to test a commit,
> > you should explain why.
>
> Dude, Julia has been doing semantic patching for years already and
> nobody has raised any concerns so far. There's already an expectation
> that Coccinelle *works* and Julia's sematic patches are sound.
>
> Besides, adding 'const' is something that causes virtually no functional
> changes to the point that build-testing is really all you need. Any
> problems caused by adding 'const' to a definition will be seen by build
> errors or warnings.
>
> Really, just stop with the pointless discussion and go read a bit about
> Coccinelle and what semantic patches are giving you. The work done by
> Julia and her peers are INRIA have measurable benefits.
>
> You're really making a thunderstorm in a glass of water.
Thanks for the defense, but since a lot of these patches torned out to be
wrong, due to an incorrect parse by Coccinelle, combined with an
unpleasantly lax compiler, Jarkko does have a point that I should have
looked at the patches more carefully. In any case, I have written to the
maintainers relevant to the patches that turned out to be incorrect.
julia
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Felipe Balbi @ 2016-09-12 13:43 UTC (permalink / raw)
To: Jarkko Sakkinen, Julia Lawall
Cc: linux-renesas-soc, joe, kernel-janitors, Sergei Shtylyov,
linux-pm, platform-driver-x86, linux-media, linux-can,
Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail, Chien Tin Tung,
linux-rdma, netdev, devel, alsa-devel, linux-kernel, linux-fbdev,
linux-wireless, Jason Gunthorpe, tpmdd-devel, linux-scsi,
linux-spi
In-Reply-To: <20160912131625.GD957@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
Hi,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
>>
>>
>> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
>>
>> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
>> > > Constify local structures.
>> > >
>> > > The semantic patch that makes this change is as follows:
>> > > (http://coccinelle.lip6.fr/)
>> >
>> > Just my two cents but:
>> >
>> > 1. You *can* use a static analysis too to find bugs or other issues.
>> > 2. However, you should manually do the commits and proper commit
>> > messages to subsystems based on your findings. And I generally think
>> > that if one contributes code one should also at least smoke test changes
>> > somehow.
>> >
>> > I don't know if I'm alone with my opinion. I just think that one should
>> > also do the analysis part and not blindly create and submit patches.
>>
>> All of the patches are compile tested. And the individual patches are
>
> Compile-testing is not testing. If you are not able to test a commit,
> you should explain why.
Dude, Julia has been doing semantic patching for years already and
nobody has raised any concerns so far. There's already an expectation
that Coccinelle *works* and Julia's sematic patches are sound.
Besides, adding 'const' is something that causes virtually no functional
changes to the point that build-testing is really all you need. Any
problems caused by adding 'const' to a definition will be seen by build
errors or warnings.
Really, just stop with the pointless discussion and go read a bit about
Coccinelle and what semantic patches are giving you. The work done by
Julia and her peers are INRIA have measurable benefits.
You're really making a thunderstorm in a glass of water.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-12 13:23 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: alsa-devel, Mustafa Ismail, Tatyana Nikolova, kernel-janitors,
linux-fbdev, platform-driver-x86, devel, linux-scsi, linux-rdma,
Jason Gunthorpe, linux-acpi, tpmdd-devel, linux-media, linux-pm,
linux-can, Shiraz Saleem, Sergei Shtylyov, netdev, Chien Tin Tung,
linux-wireless, linux-kernel, linux-spi, linux-renesas-soc,
linux-usb, joe
In-Reply-To: <20160912131625.GD957@intel.com>
On Mon, 12 Sep 2016, Jarkko Sakkinen wrote:
> On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> >
> >
> > On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> >
> > > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > > > Constify local structures.
> > > >
> > > > The semantic patch that makes this change is as follows:
> > > > (http://coccinelle.lip6.fr/)
> > >
> > > Just my two cents but:
> > >
> > > 1. You *can* use a static analysis too to find bugs or other issues.
> > > 2. However, you should manually do the commits and proper commit
> > > messages to subsystems based on your findings. And I generally think
> > > that if one contributes code one should also at least smoke test changes
> > > somehow.
> > >
> > > I don't know if I'm alone with my opinion. I just think that one should
> > > also do the analysis part and not blindly create and submit patches.
> >
> > All of the patches are compile tested. And the individual patches are
>
> Compile-testing is not testing. If you are not able to test a commit,
> you should explain why.
>
> > submitted to the relevant maintainers. The individual commit messages
> > give a more detailed explanation of the strategy used to decide that the
> > structure was constifiable. It seemed redundant to put that in the cover
> > letter, which will not be committed anyway.
>
> I don't mean to be harsh but I do not care about your thought process
> *that much* when I review a commit (sometimes it might make sense to
> explain that but it depends on the context).
>
> I mostly only care why a particular change makes sense for this
> particular subsystem. The report given by a static analysis tool can
> be a starting point for making a commit but it's not sufficient.
> Based on the report you should look subsystems as individuals.
OK, thanks for the feedback.
julia
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Jarkko Sakkinen @ 2016-09-12 13:16 UTC (permalink / raw)
To: Julia Lawall
Cc: linux-renesas-soc, joe, kernel-janitors, Sergei Shtylyov,
linux-pm, platform-driver-x86, linux-media, linux-can,
Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail, Chien Tin Tung,
linux-rdma, netdev, devel, alsa-devel, linux-kernel, linux-fbdev,
linux-wireless, Jason Gunthorpe, tpmdd-devel, linux-scsi,
linux-spi
In-Reply-To: <alpine.DEB.2.10.1609121051050.3049@hadrien>
On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
>
>
> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
>
> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > > Constify local structures.
> > >
> > > The semantic patch that makes this change is as follows:
> > > (http://coccinelle.lip6.fr/)
> >
> > Just my two cents but:
> >
> > 1. You *can* use a static analysis too to find bugs or other issues.
> > 2. However, you should manually do the commits and proper commit
> > messages to subsystems based on your findings. And I generally think
> > that if one contributes code one should also at least smoke test changes
> > somehow.
> >
> > I don't know if I'm alone with my opinion. I just think that one should
> > also do the analysis part and not blindly create and submit patches.
>
> All of the patches are compile tested. And the individual patches are
Compile-testing is not testing. If you are not able to test a commit,
you should explain why.
> submitted to the relevant maintainers. The individual commit messages
> give a more detailed explanation of the strategy used to decide that the
> structure was constifiable. It seemed redundant to put that in the cover
> letter, which will not be committed anyway.
I don't mean to be harsh but I do not care about your thought process
*that much* when I review a commit (sometimes it might make sense to
explain that but it depends on the context).
I mostly only care why a particular change makes sense for this
particular subsystem. The report given by a static analysis tool can
be a starting point for making a commit but it's not sufficient.
Based on the report you should look subsystems as individuals.
> julia
/Jarkko
^ permalink raw reply
* Re: [PATCH 11/26] can: constify local structures
From: Julia Lawall @ 2016-09-12 12:33 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: joe, kernel-janitors, Marc Kleine-Budde, linux-can, netdev,
linux-kernel
In-Reply-To: <1473599168-30561-12-git-send-email-Julia.Lawall@lip6.fr>
On Sun, 11 Sep 2016, Julia Lawall wrote:
> For structure types defined in the same file or local header files, find
> top-level static structure declarations that have the following
> properties:
> 1. Never reassigned.
> 2. Address never taken
> 3. Not passed to a top-level macro call
> 4. No pointer or array-typed field passed to a function or stored in a
> variable.
> Declare structures having all of these properties as const.
Actually, this patch should be dropped. Coccinelle did not recognize
kernel_ulong_t as a type, so it interpreted eg
(kernel_ulong_t)&plx_pci_card_info_adlink
as a bit and operation.
julia
> Done using Coccinelle.
> Based on a suggestion by Joe Perches <joe@perches.com>.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> The semantic patch seems too long for a commit log, but is in the cover
> letter.
>
> drivers/net/can/c_can/c_can_pci.c | 4 ++--
> drivers/net/can/sja1000/plx_pci.c | 20 ++++++++++----------
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/can/c_can/c_can_pci.c b/drivers/net/can/c_can/c_can_pci.c
> index 7be393c..4bc345d 100644
> --- a/drivers/net/can/c_can/c_can_pci.c
> +++ b/drivers/net/can/c_can/c_can_pci.c
> @@ -251,14 +251,14 @@ static void c_can_pci_remove(struct pci_dev *pdev)
> pci_disable_device(pdev);
> }
>
> -static struct c_can_pci_data c_can_sta2x11= {
> +static const struct c_can_pci_data c_can_sta2x11 = {
> .type = BOSCH_C_CAN,
> .reg_align = C_CAN_REG_ALIGN_32,
> .freq = 52000000, /* 52 Mhz */
> .bar = 0,
> };
>
> -static struct c_can_pci_data c_can_pch = {
> +static const struct c_can_pci_data c_can_pch = {
> .type = BOSCH_C_CAN,
> .reg_align = C_CAN_REG_32,
> .freq = 50000000, /* 50 MHz */
> diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
> index 3eb7430..59bc378 100644
> --- a/drivers/net/can/sja1000/plx_pci.c
> +++ b/drivers/net/can/sja1000/plx_pci.c
> @@ -170,7 +170,7 @@ struct plx_pci_card_info {
> void (*reset_func)(struct pci_dev *pdev);
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_adlink = {
> +static const struct plx_pci_card_info plx_pci_card_info_adlink = {
> "Adlink PCI-7841/cPCI-7841", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {1, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x80, 0x80} },
> @@ -178,7 +178,7 @@ static struct plx_pci_card_info plx_pci_card_info_adlink = {
> /* based on PLX9052 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_adlink_se = {
> +static const struct plx_pci_card_info plx_pci_card_info_adlink_se = {
> "Adlink PCI-7841/cPCI-7841 SE", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x80, 0x80} },
> @@ -186,7 +186,7 @@ static struct plx_pci_card_info plx_pci_card_info_adlink_se = {
> /* based on PLX9052 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_esd200 = {
> +static const struct plx_pci_card_info plx_pci_card_info_esd200 = {
> "esd CAN-PCI/CPCI/PCI104/200", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x100, 0x80} },
> @@ -194,7 +194,7 @@ static struct plx_pci_card_info plx_pci_card_info_esd200 = {
> /* based on PLX9030/9050 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_esd266 = {
> +static const struct plx_pci_card_info plx_pci_card_info_esd266 = {
> "esd CAN-PCI/PMC/266", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x100, 0x80} },
> @@ -202,7 +202,7 @@ static struct plx_pci_card_info plx_pci_card_info_esd266 = {
> /* based on PLX9056 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_esd2000 = {
> +static const struct plx_pci_card_info plx_pci_card_info_esd2000 = {
> "esd CAN-PCIe/2000", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x100, 0x80} },
> @@ -210,7 +210,7 @@ static struct plx_pci_card_info plx_pci_card_info_esd2000 = {
> /* based on PEX8311 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_ixxat = {
> +static const struct plx_pci_card_info plx_pci_card_info_ixxat = {
> "IXXAT PC-I 04/PCI", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x00, 0x80}, {2, 0x200, 0x80} },
> @@ -218,7 +218,7 @@ static struct plx_pci_card_info plx_pci_card_info_ixxat = {
> /* based on PLX9050 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_marathon_pci = {
> +static const struct plx_pci_card_info plx_pci_card_info_marathon_pci = {
> "Marathon CAN-bus-PCI", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x00, 0x00}, {4, 0x00, 0x00} },
> @@ -234,7 +234,7 @@ static struct plx_pci_card_info plx_pci_card_info_marathon_pcie = {
> /* based on PEX8311 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_tews = {
> +static const struct plx_pci_card_info plx_pci_card_info_tews = {
> "TEWS TECHNOLOGIES TPMC810", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x000, 0x80}, {2, 0x100, 0x80} },
> @@ -242,7 +242,7 @@ static struct plx_pci_card_info plx_pci_card_info_tews = {
> /* based on PLX9030 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_cti = {
> +static const struct plx_pci_card_info plx_pci_card_info_cti = {
> "Connect Tech Inc. CANpro/104-Plus Opto (CRG001)", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {0, 0x00, 0x00}, { {2, 0x000, 0x80}, {2, 0x100, 0x80} },
> @@ -250,7 +250,7 @@ static struct plx_pci_card_info plx_pci_card_info_cti = {
> /* based on PLX9030 */
> };
>
> -static struct plx_pci_card_info plx_pci_card_info_elcus = {
> +static const struct plx_pci_card_info plx_pci_card_info_elcus = {
> "Eclus CAN-200-PCI", 2,
> PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
> {1, 0x00, 0x00}, { {2, 0x00, 0x80}, {3, 0x00, 0x80} },
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-12 8:54 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Julia Lawall, linux-renesas-soc, joe, kernel-janitors,
Sergei Shtylyov, linux-pm, platform-driver-x86, linux-media,
linux-can, Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail,
Chien Tin Tung, linux-rdma, netdev, devel, alsa-devel,
linux-kernel, linux-fbdev, linux-wireless, Jason Gunthorpe,
tpmdd-devel, linux-scsi
In-Reply-To: <20160911172105.GB5493@intel.com>
On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > Constify local structures.
> >
> > The semantic patch that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
>
> Just my two cents but:
>
> 1. You *can* use a static analysis too to find bugs or other issues.
> 2. However, you should manually do the commits and proper commit
> messages to subsystems based on your findings. And I generally think
> that if one contributes code one should also at least smoke test changes
> somehow.
>
> I don't know if I'm alone with my opinion. I just think that one should
> also do the analysis part and not blindly create and submit patches.
All of the patches are compile tested. And the individual patches are
submitted to the relevant maintainers. The individual commit messages
give a more detailed explanation of the strategy used to decide that the
structure was constifiable. It seemed redundant to put that in the cover
letter, which will not be committed anyway.
julia
>
> Anyway, I'll apply the TPM change at some point. As I said they were
> for better. Thanks.
>
> /Jarkko
>
> > // <smpl>
> > // The first rule ignores some cases that posed problems
> > @r disable optional_qualifier@
> > identifier s != {peri_clk_data,threshold_attr,tracer_flags,tracer};
> > identifier i != {s5k5baf_cis_rect,smtcfb_fix};
> > position p;
> > @@
> > static struct s i@p = { ... };
> >
> > @lstruct@
> > identifier r.s;
> > @@
> > struct s { ... };
> >
> > @used depends on lstruct@
> > identifier r.i;
> > @@
> > i
> >
> > @bad1@
> > expression e;
> > identifier r.i;
> > assignment operator a;
> > @@
> > (<+...i...+>) a e
> >
> > @bad2@
> > identifier r.i;
> > @@
> > &(<+...i...+>)
> >
> > @bad3@
> > identifier r.i;
> > declarer d;
> > @@
> > d(...,<+...i...+>,...);
> >
> > @bad4@
> > identifier r.i;
> > type T;
> > T[] e;
> > identifier f;
> > position p;
> > @@
> >
> > f@p(...,
> > (
> > (<+...i...+>)
> > &
> > e
> > )
> > ,...)
> >
> > @bad4a@
> > identifier r.i;
> > type T;
> > T *e;
> > identifier f;
> > position p;
> > @@
> >
> > f@p(...,
> > (
> > (<+...i...+>)
> > &
> > e
> > )
> > ,...)
> >
> > @ok5@
> > expression *e;
> > identifier r.i;
> > position p;
> > @@
> > e =@p i
> >
> > @bad5@
> > expression *e;
> > identifier r.i;
> > position p != ok5.p;
> > @@
> > e =@p (<+...i...+>)
> >
> > @rr depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5@
> > identifier s,r.i;
> > position r.p;
> > @@
> >
> > static
> > +const
> > struct s i@p = { ... };
> >
> > @depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5
> > disable optional_qualifier@
> > identifier rr.s,r.i;
> > @@
> >
> > static
> > +const
> > struct s i;
> > // </smpl>
> >
> > ---
> >
> > drivers/acpi/acpi_apd.c | 8 +++---
> > drivers/char/tpm/tpm-interface.c | 10 ++++----
> > drivers/char/tpm/tpm-sysfs.c | 2 -
> > drivers/cpufreq/intel_pstate.c | 8 +++---
> > drivers/infiniband/hw/i40iw/i40iw_uk.c | 6 ++---
> > drivers/media/i2c/tvp514x.c | 2 -
> > drivers/media/pci/ddbridge/ddbridge-core.c | 18 +++++++--------
> > drivers/media/pci/ngene/ngene-cards.c | 14 ++++++------
> > drivers/media/pci/smipcie/smipcie-main.c | 8 +++---
> > drivers/misc/sgi-xp/xpc_uv.c | 2 -
> > drivers/net/arcnet/com20020-pci.c | 10 ++++----
> > drivers/net/can/c_can/c_can_pci.c | 4 +--
> > drivers/net/can/sja1000/plx_pci.c | 20 ++++++++---------
> > drivers/net/ethernet/mellanox/mlx4/main.c | 4 +--
> > drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 -
> > drivers/net/ethernet/renesas/sh_eth.c | 14 ++++++------
> > drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 -
> > drivers/net/wireless/ath/dfs_pattern_detector.c | 2 -
> > drivers/net/wireless/intel/iwlegacy/3945.c | 4 +--
> > drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 2 -
> > drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 2 -
> > drivers/platform/chrome/chromeos_laptop.c | 22 +++++++++----------
> > drivers/platform/x86/intel_scu_ipc.c | 6 ++---
> > drivers/platform/x86/intel_telemetry_debugfs.c | 2 -
> > drivers/scsi/esas2r/esas2r_flash.c | 2 -
> > drivers/scsi/hptiop.c | 6 ++---
> > drivers/spi/spi-dw-pci.c | 4 +--
> > drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 2 -
> > drivers/usb/misc/ezusb.c | 2 -
> > drivers/video/fbdev/matrox/matroxfb_g450.c | 2 -
> > lib/crc64_ecma.c | 2 -
> > sound/pci/ctxfi/ctatc.c | 2 -
> > sound/pci/hda/patch_ca0132.c | 10 ++++----
> > sound/pci/riptide/riptide.c | 2 -
> > 40 files changed, 110 insertions(+), 110 deletions(-)
>
^ permalink raw reply
* Fwd: [GIT] Networking
From: Oliver Hartkopp @ 2016-09-12 6:45 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can@vger.kernel.org
In-Reply-To: <20160911.200825.1735122029283603358.davem@davemloft.net>
Hello Marc,
we are already in RC6 now.
Do you plan to upstream some of the fixes posted on linux-can ML soon?
Regards,
Oliver
-------- Forwarded Message --------
Subject: [GIT] Networking
Date: Sun, 11 Sep 2016 20:08:25 -0700 (PDT)
From: David Miller <davem@davemloft.net>
To: torvalds@linux-foundation.org
CC: akpm@linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Mostly small sets of driver fixes scattered all over the place.
1) Mediatek driver fixes from Sean Wang. Forward port not written
correctly during TX map, missed handling of EPROBE_DEFER, and
mistaken use of put_page() instead of skb_free_frag().
2) Fix socket double-free in KCM code, from WANG Cong.
3) QED driver fixes from Sudarsana Reddy Kalluru, including a fix
for using the dcbx buffers before initializing them.
4) Mellanox Switch driver fixes from Jiri Pirko, including a fix for
double fib removals and an error handling fix in
mlxsw_sp_module_init().
5) Fix kernel panic when enabling LLDP in i40e driver, from Dave
Ertman.
6) Fix padding of TSO packets in thunderx driver, from Sunil Goutham.
7) TCP's rcv_wup not initialized properly when using fastopen, from
Neal Cardwell.
8) Don't use uninitialized flow keys in flow dissector, from Gao
Feng.
9) Use after free in l2tp module unload, from Sabrina Dubroca.
10) Fix interrupt registry ordering issues in smsc911x driver, from
Jeremy Linton.
11) Fix crashes in bonding having to do with enslaving and rx_handler,
from Mahesh Bandewar.
12) AF_UNIX deadlock fixes from Linus.
13) In mlx5 driver, don't read skb->xmit_mode after it might have been
freed from the TX reclaim path. From Tariq Toukan.
14) Fix a bug from 2015 in TCP Yeah where the congestion window does
not increase, from Artem Germanov.
15) Don't pad frames on receive in NFP driver, from Jakub Kicinski.
16) Fix chunk fragmenting in SCTP wrt. GSO, from Marcelo Ricardo
Leitner.
17) Fix deletion of VRF routes, from Mark Tomlinson.
18) Fix device refcount leak when DAD fails in ipv6, from Wei Yongjun.
Please pull, thanks a lot!
The following changes since commit e4e98c460ad38c78498622a164fd5ef09a2dc9cb:
Merge tag 'hwmon-for-linus-v4.8-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
(2016-08-29 19:12:35 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to 373df3131aa83bd3e0ea7cd15be92d942d75fc72:
Merge branch 'mlx4-fixes' (2016-09-11 19:40:26 -0700)
----------------------------------------------------------------
Alexey Kodanev (1):
net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key
Andy Gospodarek (1):
MAINTAINERS: update to working email address
Arend Van Spriel (1):
brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()
Arik Nemtsov (1):
mac80211: TDLS: don't require beaconing for AP BW
Artem Germanov (1):
tcp: cwnd does not increase in TCP YeAH
Ashok Raj Nagarajan (1):
ath10k: fix get rx_status from htt context
Bodong Wang (1):
net/mlx5e: Move an_disable_cap bit to a new position
Cathy Luo (1):
mwifiex: fix large amsdu packets causing firmware hang
Chris Brandt (1):
net: ethernet: renesas: sh_eth: add POST registers for rz
Dave Ertman (1):
i40e: Fix kernel panic on enable/disable LLDP
Dave Jones (1):
ipv6: release dst in ping_v6_sendmsg
David Ahern (1):
xfrm: Only add l3mdev oif to dst lookups
David S. Miller (15):
Merge tag 'mac80211-for-davem-2016-08-30' of
git://git.kernel.org/.../jberg/mac80211
Merge git://git.kernel.org/.../pablo/nf
Merge branch 'mediatek-fixes'
Merge branch 'qed-fixes'
Merge branch 'mlxsw-fixes'
Merge tag 'wireless-drivers-for-davem-2016-08-29' of
git://git.kernel.org/.../kvalo/wireless-drivers
Merge branch 'thunderx-fixes'
Merge branch 'smsc911x-fixes'
Merge branch 'vxlan-fixes'
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
Merge branch 'mlx5-fixes'
Merge branch 'nfp-fixes'
Merge branch 'mlxsw-fixes'
Merge tag 'wireless-drivers-for-davem-2016-09-08' of
git://git.kernel.org/.../kvalo/wireless-drivers
Merge branch 'mlx4-fixes'
Davide Caratti (1):
bridge: re-introduce 'fix parsing of MLDv2 reports'
Eli Cooper (1):
ipv6: Don't unset flowi6_proto in ipxip6_tnl_xmit()
Emmanuel Grumbach (2):
iwlwifi: mvm: consider P2p device type for firmware dump triggers
iwlwifi: mvm: don't use ret when not initialised
Eric Dumazet (1):
tcp: fastopen: avoid negative sk_forward_alloc
Felix Fietkau (2):
ath9k: fix client mode beacon configuration
ath9k: fix using sta->drv_priv before initializing it
Florian Fainelli (1):
MAINTAINERS: Update CPMAC email address
Gal Pressman (3):
net/mlx5e: Prevent casting overflow
net/mlx5e: Fix global PFC counters replication
net/mlx5e: Fix parsing of vlan packets when updating lro header
Gao Feng (1):
rps: flow_dissector: Fix uninitialized flow_keys used in
__skb_get_hash possibly
Giedrius Statkevičius (1):
ath9k: bring back direction setting in ath9k_{start_stop}
Guilherme G. Piccoli (1):
bnx2x: don't reset chip on cleanup if PCI function is offline
Helmut Buchsbaum (1):
net: macb: initialize checksum when using checksum offloading
Ido Schimmel (3):
mlxsw: spectrum: Don't take multiple references on a FID
mlxsw: spectrum: Use existing flood setup when adding VLANs
mlxsw: spectrum: Set port type before setting its address
Ivan Vecera (1):
tg3: Fix for disallow tx coalescing time to be 0
Jakub Kicinski (3):
nfp: remove linux/version.h includes
nfp: drop support for old firmware ABIs
nfp: don't pad frames on receive
Jean Delvare (1):
drivers: net: phy: mdio-xgene: Add hardware dependency
Jeremy Linton (4):
net: smsc911x: Remove multiple exit points from smsc911x_open
net: smsc911x: Fix register_netdev, phy startup, driver unload
ordering
net: smsc911x: Move interrupt handler before open
net: smsc911x: Move interrupt allocation to open/stop
Jiri Benc (2):
vxlan: reject multicast destination without an interface
vxlan: fix duplicated and wrong error messages
Jiri Pirko (5):
mlxsw: spectrum_router: Fix failure caused by double fib removal
from HW
mlxsw: spectrum_router: Fix fib entry update path
mlxsw: spectrum: Fix error path in mlxsw_sp_module_init
mlxsw: spectrum_router: Fix netevent notifier registration
mlxsw: spectrum_router: Fix error path in mlxsw_sp_router_init
Johannes Berg (1):
Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit
Kernel"
Kalle Valo (3):
Merge ath-current from ath.git
Merge tag 'iwlwifi-for-kalle-2016-08-29' of
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge ath-current from ath.git
Kamal Heib (2):
net/mlx4_en: Fix the return value of mlx4_en_dcbnl_set_all()
net/mlx4_en: Fix the return value of mlx4_en_dcbnl_set_state()
Lars Persson (1):
dwc_eth_qos: do not register semi-initialized device
Linus Lüssing (1):
cfg80211: Add stub for cfg80211_get_station()
Linus Torvalds (2):
Revert "af_unix: Fix splice-bind deadlock"
af_unix: split 'u->readlock' into two: 'iolock' and 'bindlock'
Liping Zhang (6):
netfilter: nft_reject: restrict to INPUT/FORWARD/OUTPUT
netfilter: nfnetlink: use list_for_each_entry_safe to delete all
objects
netfilter: cttimeout: put back l4proto when replacing timeout policy
netfilter: cttimeout: unlink timeout objs in the unconfirmed ct lists
netfilter: nft_meta: improve the validity check of pkttype set expr
netfilter: nf_tables_netdev: remove redundant ip_hdr assignment
Mahesh Bandewar (1):
bonding: Fix bonding crash
Marcelo Ricardo Leitner (1):
sctp: identify chunks that need to be fragmented at IP level
Mark Tomlinson (1):
net: Don't delete routes in different VRFs
Miaoqing Pan (1):
ath9k: fix AR5416 access GPIO warning
Michael Chan (1):
bnxt_en: Fix TX push operation on ARM64.
Mohammed Shafi Shajakhan (1):
ath10k: Remove driver log suggesting QCA9887 support is experimental
Moshe Shemesh (1):
net/mlx4_en: Fix panic on xmit while port is down
Neal Cardwell (1):
tcp: fastopen: fix rcv_wup initialization for TFO server on SYN/data
Nicolas Dichtel (2):
ipv6: add missing netconf notif when 'all' is updated
netconf: add a notif when settings are created
Nikolay Aleksandrov (1):
net: bridge: don't increment tx_dropped in br_do_proxy_arp
Parthasarathy Bhuvaragan (1):
tipc: fix random link resets while adding a second bearer
Peer, Ilan (1):
iwlwifi: mvm: Advertise support for AP channel width change
Sabrina Dubroca (2):
netfilter: ebtables: put module reference when an incorrect
extension is found
l2tp: fix use-after-free during module unload
Sean Wang (9):
net: ethernet: mediatek: fix fails from TX housekeeping due to
incorrect port setup
net: ethernet: mediatek: fix incorrect return value of
devm_clk_get with EPROBE_DEFER
net: ethernet: mediatek: fix API usage with skb_free_frag
net: ethernet: mediatek: remove redundant free_irq for
devm_request_irq allocated irq
net: ethernet: mediatek: fix logic unbalance between probe and remove
net: ethernet: mediatek: fix issue of driver removal with
interface is up
net: ethernet: mediatek: fix the missing of_node_put() after node
is used done inside mtk_mdio_init
net: ethernet: mediatek: use devm_mdiobus_alloc instead of
mdiobus_alloc inside mtk_mdio_init
net: ethernet: mediatek: fix error handling inside mtk_mdio_init
Sharon Dvir (1):
iwlwifi: mvm: check if vif is NULL before using it
Sudarsana Reddy Kalluru (3):
qed*: Disallow dcbx configuration for VF interfaces.
qed: Set selection-field while configuring the app entry in ieee
mode.
qed: Clear dcbx memory buffers before the usage.
Sudip Mukherjee (1):
net: smsc: remove build warning of duplicate definition
Sunil Goutham (2):
net: thunderx: Fix for HW issue while padding TSO packet
net: thunderx: Fix for issues with multiple CQEs posted for a TSO
packet
Tariq Toukan (2):
net/mlx5e: Fix xmit_more counter race issue
net/mlx4_en: Fixes for DCBX
Tobias Brunner (1):
xfrm: Ignore socket policies when rebuilding hash tables
Vegard Nossum (3):
xfrm: fix crash in XFRM_MSG_GETSA netlink handler
xfrm: get rid of incorrect WARN
xfrm: get rid of another incorrect WARN
WANG Cong (1):
kcm: fix a socket double free
Wei Yongjun (1):
ipv6: addrconf: fix dev refcont leak when DAD failed
Wu Fengguang (1):
qed: fix kzalloc-simple.cocci warnings
mhiramat@kernel.org (2):
brcmfmac: Check rtnl_lock is locked when removing interface
brcmfmac: Change vif_event_lock to spinlock
MAINTAINERS | 4 +-
drivers/net/bonding/bond_main.c | 7 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 19 ++++--
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 +-
drivers/net/ethernet/broadcom/tg3.c | 11 +---
drivers/net/ethernet/cadence/macb.c | 23 ++++++++
drivers/net/ethernet/cavium/thunder/nic.h | 1 +
drivers/net/ethernet/cavium/thunder/nic_main.c | 11 +++-
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 20 +++++--
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 64
+++++++++++++++++---
drivers/net/ethernet/intel/i40e/i40e_main.c | 15 +++--
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 82
+++++++++++++-------------
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 22 ++++---
drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 57
+++++++++---------
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 21 +++----
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 12 ++--
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 15 +----
drivers/net/ethernet/mellanox/mlx4/port.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 8 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 22 ++++---
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 28
++++++---
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 +
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 160
+++++++++++++++++++++++++++++++------------------
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 28
++++-----
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 5 --
drivers/net/ethernet/netronome/nfp/nfp_net_ethtool.c | 1 -
drivers/net/ethernet/netronome/nfp/nfp_netvf_main.c | 7 +--
drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 20 ++++++-
drivers/net/ethernet/qlogic/qede/qede_main.c | 3 +-
drivers/net/ethernet/renesas/sh_eth.c | 7 +++
drivers/net/ethernet/smsc/smc91x.h | 2 +
drivers/net/ethernet/smsc/smsc911x.c | 213
++++++++++++++++++++++++++++++++----------------------------------
drivers/net/ethernet/synopsys/dwc_eth_qos.c | 38
++++++------
drivers/net/phy/Kconfig | 1 +
drivers/net/vxlan.c | 38
++++--------
drivers/net/wireless/ath/ath10k/htt_rx.c | 10 ++--
drivers/net/wireless/ath/ath10k/pci.c | 1 -
drivers/net/wireless/ath/ath9k/hw.c | 4 +-
drivers/net/wireless/ath/ath9k/main.c | 18 ++++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 28
++++-----
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 8 ++-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.h | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 +
drivers/net/wireless/marvell/mwifiex/11n_aggr.c | 3 +-
include/linux/mlx5/mlx5_ifc.h | 5 +-
include/linux/netdevice.h | 1 +
include/net/af_unix.h | 2 +-
include/net/cfg80211.h | 9 +++
include/net/ip_fib.h | 3 +-
include/net/netfilter/nft_meta.h | 4 ++
include/net/netfilter/nft_reject.h | 4 ++
net/bridge/br_input.c | 7 +--
net/bridge/br_multicast.c | 2 +-
net/bridge/netfilter/ebtables.c | 2 +
net/bridge/netfilter/nft_meta_bridge.c | 1 +
net/core/dev.c | 16 +++++
net/core/flow_dissector.c | 6 +-
net/ipv4/devinet.c | 11 ++--
net/ipv4/fib_frontend.c | 3 +-
net/ipv4/fib_semantics.c | 8 ++-
net/ipv4/netfilter/nft_reject_ipv4.c | 1 +
net/ipv4/tcp_fastopen.c | 2 +
net/ipv4/tcp_yeah.c | 2 +-
net/ipv4/xfrm4_policy.c | 2 +-
net/ipv6/addrconf.c | 18 +++++-
net/ipv6/ip6_tunnel.c | 2 +
net/ipv6/netfilter/nft_reject_ipv6.c | 1 +
net/ipv6/ping.c | 9 ++-
net/ipv6/xfrm6_input.c | 1 +
net/ipv6/xfrm6_policy.c | 2 +-
net/kcm/kcmsock.c | 3 +-
net/l2tp/l2tp_core.c | 3 +
net/mac80211/tdls.c | 7 ++-
net/netfilter/nf_tables_netdev.c | 1 -
net/netfilter/nfnetlink_acct.c | 6 +-
net/netfilter/nfnetlink_cttimeout.c | 49
++++++++-------
net/netfilter/nft_meta.c | 17 ++++--
net/netfilter/nft_reject.c | 16 +++++
net/netfilter/nft_reject_inet.c | 7 ++-
net/sctp/output.c | 13 +++-
net/tipc/name_distr.c | 8 ++-
net/unix/af_unix.c | 111
+++++++++++++++-------------------
net/wireless/wext-core.c | 25 +-------
net/xfrm/xfrm_input.c | 14 ++---
net/xfrm/xfrm_policy.c | 4 ++
net/xfrm/xfrm_user.c | 13 ++--
92 files changed, 875 insertions(+), 610 deletions(-)
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-11 19:11 UTC (permalink / raw)
To: Joe Perches
Cc: alsa-devel, Mustafa Ismail, Tatyana Nikolova, kernel-janitors,
linux-fbdev, platform-driver-x86, devel, linux-scsi, linux-rdma,
Jason Gunthorpe, linux-acpi, tpmdd-devel, linux-media, linux-pm,
linux-can, Julia Lawall, Shiraz Saleem, Sergei Shtylyov, netdev,
Chien Tin Tung, linux-wireless, linux-kernel, linux-spi,
linux-renesas-soc, linux-usb
In-Reply-To: <1473616576.19464.10.camel@perches.com>
On Sun, 11 Sep 2016, Joe Perches wrote:
> On Sun, 2016-09-11 at 15:05 +0200, Julia Lawall wrote:
> > Constify local structures.
>
> Thanks Julia.
>
> A few suggestions & questions:
>
> Perhaps the script should go into scripts/coccinelle/
> so that future cases could be caught by the robot
> and commit message referenced by the patch instances.
OK.
> Can you please compile the files modified using the
> appropriate defconfig/allyesconfig and show the
I currently send patches for this issue only for files that compile using
the x86 allyesconfig.
> movement from data to const by using
> $ size <object>.new/old
> and include that in the changelogs (maybe next time)?
OK, thanks for the suggestion.
> Is it possible for a rule to trace the instances where
> an address of a struct or struct member is taken by
> locally defined and declared function call where the
> callee does not modify any dereferenced object?
>
> ie:
>
> struct foo {
> int bar;
> char *baz;
> };
>
> struct foo qux[] = {
> { 1, "description 1" },
> { 2, "dewcription 2" },
> [ n, "etc" ]...,
> };
>
> void message(struct foo *msg)
> {
> printk("%d %s\n", msg->bar, msg->baz);
> }
>
> where some code uses
>
> message(qux[index]);
>
> So could a coccinelle script change:
>
> struct foo qux[] = { to const struct foo quz[] = {
>
> and
>
> void message(struct foo *msg) to void message(const struct foo *msg)
Yes, this could be possible too.
Thanks for the feedback.
julia
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Joe Perches @ 2016-09-11 17:56 UTC (permalink / raw)
To: Julia Lawall, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Mustafa Ismail,
Tatyana Nikolova, kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-can-u79uwXL29TY76Z2rM5mHXA,
Shiraz Saleem, Sergei Shtylyov, netdev-u79uwXL29TY76Z2rM5mHXA,
Chien Tin Tung, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1473599168-30561-1-git-send-email-Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
On Sun, 2016-09-11 at 15:05 +0200, Julia Lawall wrote:
> Constify local structures.
Thanks Julia.
A few suggestions & questions:
Perhaps the script should go into scripts/coccinelle/
so that future cases could be caught by the robot
and commit message referenced by the patch instances.
Can you please compile the files modified using the
appropriate defconfig/allyesconfig and show the
movement from data to const by using
$ size <object>.new/old
and include that in the changelogs (maybe next time)?
Is it possible for a rule to trace the instances where
an address of a struct or struct member is taken by
locally defined and declared function call where the
callee does not modify any dereferenced object?
ie:
struct foo {
int bar;
char *baz;
};
struct foo qux[] = {
{ 1, "description 1" },
{ 2, "dewcription 2" },
[ n, "etc" ]...,
};
void message(struct foo *msg)
{
printk("%d %s\n", msg->bar, msg->baz);
}
where some code uses
message(qux[index]);
So could a coccinelle script change:
struct foo qux[] = { to const struct foo quz[] = {
and
void message(struct foo *msg) to void message(const struct foo *msg)
------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Jarkko Sakkinen @ 2016-09-11 17:21 UTC (permalink / raw)
To: Julia Lawall
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Mustafa Ismail,
Tatyana Nikolova, kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
platform-driver-x86-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-can-u79uwXL29TY76Z2rM5mHXA,
Shiraz Saleem, Sergei Shtylyov, netdev-u79uwXL29TY76Z2rM5mHXA,
Chien Tin Tung, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <1473599168-30561-1-git-send-email-Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> Constify local structures.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
Just my two cents but:
1. You *can* use a static analysis too to find bugs or other issues.
2. However, you should manually do the commits and proper commit
messages to subsystems based on your findings. And I generally think
that if one contributes code one should also at least smoke test changes
somehow.
I don't know if I'm alone with my opinion. I just think that one should
also do the analysis part and not blindly create and submit patches.
Anyway, I'll apply the TPM change at some point. As I said they were
for better. Thanks.
/Jarkko
> // <smpl>
> // The first rule ignores some cases that posed problems
> @r disable optional_qualifier@
> identifier s != {peri_clk_data,threshold_attr,tracer_flags,tracer};
> identifier i != {s5k5baf_cis_rect,smtcfb_fix};
> position p;
> @@
> static struct s i@p = { ... };
>
> @lstruct@
> identifier r.s;
> @@
> struct s { ... };
>
> @used depends on lstruct@
> identifier r.i;
> @@
> i
>
> @bad1@
> expression e;
> identifier r.i;
> assignment operator a;
> @@
> (<+...i...+>) a e
>
> @bad2@
> identifier r.i;
> @@
> &(<+...i...+>)
>
> @bad3@
> identifier r.i;
> declarer d;
> @@
> d(...,<+...i...+>,...);
>
> @bad4@
> identifier r.i;
> type T;
> T[] e;
> identifier f;
> position p;
> @@
>
> f@p(...,
> (
> (<+...i...+>)
> &
> e
> )
> ,...)
>
> @bad4a@
> identifier r.i;
> type T;
> T *e;
> identifier f;
> position p;
> @@
>
> f@p(...,
> (
> (<+...i...+>)
> &
> e
> )
> ,...)
>
> @ok5@
> expression *e;
> identifier r.i;
> position p;
> @@
> e =@p i
>
> @bad5@
> expression *e;
> identifier r.i;
> position p != ok5.p;
> @@
> e =@p (<+...i...+>)
>
> @rr depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5@
> identifier s,r.i;
> position r.p;
> @@
>
> static
> +const
> struct s i@p = { ... };
>
> @depends on used && !bad1 && !bad2 && !bad3 && !bad4 && !bad4a && !bad5
> disable optional_qualifier@
> identifier rr.s,r.i;
> @@
>
> static
> +const
> struct s i;
> // </smpl>
>
> ---
>
> drivers/acpi/acpi_apd.c | 8 +++---
> drivers/char/tpm/tpm-interface.c | 10 ++++----
> drivers/char/tpm/tpm-sysfs.c | 2 -
> drivers/cpufreq/intel_pstate.c | 8 +++---
> drivers/infiniband/hw/i40iw/i40iw_uk.c | 6 ++---
> drivers/media/i2c/tvp514x.c | 2 -
> drivers/media/pci/ddbridge/ddbridge-core.c | 18 +++++++--------
> drivers/media/pci/ngene/ngene-cards.c | 14 ++++++------
> drivers/media/pci/smipcie/smipcie-main.c | 8 +++---
> drivers/misc/sgi-xp/xpc_uv.c | 2 -
> drivers/net/arcnet/com20020-pci.c | 10 ++++----
> drivers/net/can/c_can/c_can_pci.c | 4 +--
> drivers/net/can/sja1000/plx_pci.c | 20 ++++++++---------
> drivers/net/ethernet/mellanox/mlx4/main.c | 4 +--
> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 -
> drivers/net/ethernet/renesas/sh_eth.c | 14 ++++++------
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 -
> drivers/net/wireless/ath/dfs_pattern_detector.c | 2 -
> drivers/net/wireless/intel/iwlegacy/3945.c | 4 +--
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 2 -
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 2 -
> drivers/platform/chrome/chromeos_laptop.c | 22 +++++++++----------
> drivers/platform/x86/intel_scu_ipc.c | 6 ++---
> drivers/platform/x86/intel_telemetry_debugfs.c | 2 -
> drivers/scsi/esas2r/esas2r_flash.c | 2 -
> drivers/scsi/hptiop.c | 6 ++---
> drivers/spi/spi-dw-pci.c | 4 +--
> drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 2 -
> drivers/usb/misc/ezusb.c | 2 -
> drivers/video/fbdev/matrox/matroxfb_g450.c | 2 -
> lib/crc64_ecma.c | 2 -
> sound/pci/ctxfi/ctatc.c | 2 -
> sound/pci/hda/patch_ca0132.c | 10 ++++----
> sound/pci/riptide/riptide.c | 2 -
> 40 files changed, 110 insertions(+), 110 deletions(-)
------------------------------------------------------------------------------
^ permalink raw reply
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