<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Kconfig</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>1dd1b521 - can: remove obsolete PCH CAN driver</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#1dd1b521</link>
        <description>can: remove obsolete PCH CAN driverThe PCH CAN driver is a driver for a Bosch C_CAN controller IP core whichis attached to the system via PCI. This code has been introduced in 2011by Oki Semiconductors developers to support the Intel Atom E6xx seriesI/O Hub (aka EG20T IOH PCH CAN). Since 2012 the driver only has beenmaintained by the kernel community.As there is a well maintained and continously tested C_CAN/D_CAN driverwhich also supports the PCI configuration from the PCH CAN EG20T setupthis driver became obsolete.Cc: Jacob Kroon &lt;jacob.kroon@gmail.com&gt;Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;Cc: Dario Binacchi &lt;dariobin@libero.it&gt;Cc: Wolfgang Grandegger &lt;wg@grandegger.com&gt;Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;Link: https://lore.kernel.org/all/20220924174424.86541-1-socketcan@hartkopp.netAcked-by: Jacob Kroon &lt;jacob.kroon@gmail.com&gt;Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Sat, 24 Sep 2022 17:44:24 +0000</pubDate>
        <dc:creator>Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;</dc:creator>
    </item>
<item>
        <title>a7f7f624 - treewide: replace &apos;---help---&apos; in Kconfig files with &apos;help&apos;</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#a7f7f624</link>
        <description>treewide: replace &apos;---help---&apos; in Kconfig files with &apos;help&apos;Since commit 84af7a6194e4 (&quot;checkpatch: kconfig: prefer &apos;help&apos; over&apos;---help---&apos;&quot;), the number of &apos;---help---&apos; has been graduallydecreasing, but there are still more than 2400 instances.This commit finishes the conversion. While I touched the lines,I also fixed the indentation.There are a variety of indentation styles found.  a) 4 spaces + &apos;---help---&apos;  b) 7 spaces + &apos;---help---&apos;  c) 8 spaces + &apos;---help---&apos;  d) 1 space + 1 tab + &apos;---help---&apos;  e) 1 tab + &apos;---help---&apos;    (correct indentation)  f) 1 tab + 1 space + &apos;---help---&apos;  g) 1 tab + 2 spaces + &apos;---help---&apos;In order to convert all of them to 1 tab + &apos;help&apos;, I ran thefollowing commend:  $ find . -name &apos;Kconfig*&apos; | xargs sed -i &apos;s/^[[:space:]]*---help---/\thelp/&apos;Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Sat, 13 Jun 2020 16:50:22 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;masahiroy@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>ec8f24b7 - treewide: Add SPDX license identifier - Makefile/Kconfig</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#ec8f24b7</link>
        <description>treewide: Add SPDX license identifier - Makefile/KconfigAdd SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any formThese files fall under the project license, GPL v2 only. The resulting SPDXlicense identifier is:  GPL-2.0-onlySigned-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Sun, 19 May 2019 12:07:45 +0000</pubDate>
        <dc:creator>Thomas Gleixner &lt;tglx@linutronix.de&gt;</dc:creator>
    </item>
<item>
        <title>524369e2 - can: c_can: remove obsolete STRICT_FRAME_ORDERING Kconfig option</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#524369e2</link>
        <description>can: c_can: remove obsolete STRICT_FRAME_ORDERING Kconfig optionIn 2b9aecdce2 (&quot;can: c_can: Disable rx split as workaround&quot;) a new Kconfigoption was introduced as a workaround. The tests performed by Alexander Steinconfirmed this option to be obsolete with all the other cleanups and fixesthat had been discussed that time:http://marc.info/?l=linux-can&amp;m=139746476821294&amp;w=2Both (author and tester) agreed to remove this Kconfig option again:http://marc.info/?l=linux-can&amp;m=139883820714229&amp;w=2As some more cleanups took place since then a simple revert is not possible.This patch removes the entire option as it would behave when disabled.Further beautification&#8217;s can be done later.Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;Tested-by: Alexander Stein &lt;alexander.stein@systec-electronic.com&gt;Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Tue, 06 May 2014 17:45:38 +0000</pubDate>
        <dc:creator>Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;</dc:creator>
    </item>
<item>
        <title>2b9aecdc - can: c_can: Disable rx split as workaround</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#2b9aecdc</link>
        <description>can: c_can: Disable rx split as workaroundThe RX buffer split causes packet loss in the hardware:What happens is:RX Packet 1 --&gt; message buffer 1 (newdat bit is not cleared)RX Packet 2 --&gt; message buffer 2 (newdat bit is not cleared)RX Packet 3 --&gt; message buffer 3 (newdat bit is not cleared)RX Packet 4 --&gt; message buffer 4 (newdat bit is not cleared)RX Packet 5 --&gt; message buffer 5 (newdat bit is not cleared)RX Packet 6 --&gt; message buffer 6 (newdat bit is not cleared)RX Packet 7 --&gt; message buffer 7 (newdat bit is not cleared)RX Packet 8 --&gt; message buffer 8 (newdat bit is not cleared)Clear newdat bit in message buffer 1Clear newdat bit in message buffer 2Clear newdat bit in message buffer 3Clear newdat bit in message buffer 4Clear newdat bit in message buffer 5Clear newdat bit in message buffer 6Clear newdat bit in message buffer 7Clear newdat bit in message buffer 8Now if during that clearing of newdat bits, a new message comes in,the HW gets confused and drops it.It does not matter how many of them you clear. I put a delay betweenclear of buffer 1 and buffer 2 which was long enough that the messageshould have been queued either in buffer 1 or buffer 9. But it did notshow up anywhere. The next message ended up in buffer 1. So thehardware lost a packet of course without telling it via one of theerror handlers.That does not happen on all clear newdat bit events. I see one of 10kpackets dropped in the scenario which allows us to reproduce. But thetrace looks always the same.Not splitting the RX Buffer avoids the packet loss but can causereordering. It&apos;s hard to trigger, but it CAN happen.With that mode we use the HW as it was probably designed for. We readfrom the buffer 1 upwards and clear the buffer as we get themessage. That&apos;s how all microcontrollers use it. So I assume that theway we handle the buffers was never really tested. According to thepublic documentation it should just work :)Let the user decide which evil is the lesser one.[ Oliver Hartkopp: Provided a sane config option and help text and  made me switch to favour potential and unlikely reordering over  packet loss ]Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;Tested-by: Alexander Stein &lt;alexander.stein@systec-electronic.com&gt;Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Fri, 11 Apr 2014 08:13:16 +0000</pubDate>
        <dc:creator>Thomas Gleixner &lt;tglx@linutronix.de&gt;</dc:creator>
    </item>
<item>
        <title>6586c5d7 - can: Kconfig: convert &apos;depends on CAN_DEV&apos; into &apos;if CAN_DEV...endif&apos; block</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#6586c5d7</link>
        <description>can: Kconfig: convert &apos;depends on CAN_DEV&apos; into &apos;if CAN_DEV...endif&apos; blockThis patch adds an &apos;if CAN_DEV...endif&apos; Block around the CAN driversymbols in drivers/net/can/Kconfig. So the &apos;depends on CAN&apos; dependenciescan be removed.Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Fri, 20 Jul 2012 19:04:13 +0000</pubDate>
        <dc:creator>Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;</dc:creator>
    </item>
<item>
        <title>5b92da04 - c_can_pci: generic module for C_CAN/D_CAN on PCI</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#5b92da04</link>
        <description>c_can_pci: generic module for C_CAN/D_CAN on PCISigned-off-by: Federico Vaga &lt;federico.vaga@gmail.com&gt;Acked-by: Giancarlo Asnaghi &lt;giancarlo.asnaghi@st.com&gt;Cc: Alan Cox &lt;alan@linux.intel.com&gt;Acked-by: Wolfgang Grandegger &lt;wg@grandegger.com&gt;Acked-by: Bhupesh Sharma &lt;bhupesh.sharma@st.com&gt;[mkl: fix call to pci_iounmap]Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Thu, 14 Jun 2012 11:43:42 +0000</pubDate>
        <dc:creator>Federico Vaga &lt;federico.vaga@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>69927fcc - can: c_can: Add support for Bosch D_CAN controller</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#69927fcc</link>
        <description>can: c_can: Add support for Bosch D_CAN controllerThis patch adds the support for D_CAN controller driver to the existingC_CAN driver.Bosch D_CAN controller is a full-CAN implementation which is compliantto CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can beobtained from: http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/can/d_can_users_manual_111.pdfA new array is added for accessing the d_can registers, according to d_cancontroller register space.Current D_CAN implementation has following limitations, this is doneto avoid large changes to the C_CAN driver.1. Message objects are limited to 32, 16 for RX and 16 for TX. C_CAN IP   supports upto 32 message objects but in case of D_CAN we can configure   upto 128 message objects.2. Using two 16bit reads/writes for accessing the 32bit D_CAN registers.3. These patches have been tested on little endian machine, there might   be some hidden endian-related issues due to the nature of the accesses   (32-bit registers accessed as 2 16-bit registers). However, I do not   have a big-endian D_CAN implementation to confirm.Signed-off-by: AnilKumar Ch &lt;anilkumar@ti.com&gt;Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Tue, 29 May 2012 05:43:16 +0000</pubDate>
        <dc:creator>AnilKumar Ch &lt;anilkumar@ti.com&gt;</dc:creator>
    </item>
<item>
        <title>881ff67a - can: c_can: Added support for Bosch C_CAN controller</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/net/can/c_can/Kconfig#881ff67a</link>
        <description>can: c_can: Added support for Bosch C_CAN controllerBosch C_CAN controller is a full-CAN implementation which is compliantto CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can beobtained from:http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/c_can/users_manual_c_can.pdfThis patch adds the support for this controller.The following are the design choices made while writing the controllerdriver:1. Interface Register set IF1 has be used only in the current design.2. Out of the 32 Message objects available, 16 are kept aside for RX   purposes and the rest for TX purposes.3. NAPI implementation is such that both the TX and RX paths function   in polling mode.Signed-off-by: Bhupesh Sharma &lt;bhupesh.sharma@st.com&gt;Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;

            List of files:
            /linux-6.15/drivers/net/can/c_can/Kconfig</description>
        <pubDate>Mon, 14 Feb 2011 06:51:44 +0000</pubDate>
        <dc:creator>Bhupesh Sharma &lt;bhupesh.sharma@st.com&gt;</dc:creator>
    </item>
</channel>
</rss>
