<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/tty/serial/max310x.c, branch dev-5.3</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.3</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2019-06-03T11:53:20+00:00</updated>
<entry>
<title>Merge 5.2-rc3 into tty-next</title>
<updated>2019-06-03T11:53:20+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2019-06-03T11:53:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=888dc273ea4e7ca332a6f73d10dfc8f2b212c803'/>
<id>urn:sha1:888dc273ea4e7ca332a6f73d10dfc8f2b212c803</id>
<content type='text'>
We want the tty/serial fixes in here as well.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Fix external crystal register setup</title>
<updated>2019-05-21T10:18:17+00:00</updated>
<author>
<name>Joe Burmeister</name>
<email>joe.burmeister@devtank.co.uk</email>
</author>
<published>2019-05-13T10:23:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5d24f455c182d5116dd5db8e1dc501115ecc9c2c'/>
<id>urn:sha1:5d24f455c182d5116dd5db8e1dc501115ecc9c2c</id>
<content type='text'>
The datasheet states:

  Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking
(crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable
clocking
  Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal
oscillator. When using an external clock source at XIN, CrystalEn must
be set low.

The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not.

This was required to make the MAX3107 with an external crystal on our
board able to send or receive data.

Signed-off-by: Joe Burmeister &lt;joe.burmeister@devtank.co.uk&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Split uart characters insertion loop</title>
<updated>2019-05-21T10:15:54+00:00</updated>
<author>
<name>Serge Semin</name>
<email>fancer.lancer@gmail.com</email>
</author>
<published>2019-05-14T10:14:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9c12d739d69b80847e99d24692ff20de993bf172'/>
<id>urn:sha1:9c12d739d69b80847e99d24692ff20de993bf172</id>
<content type='text'>
Batch read mode doesn't check any conditions or flags except the Rx
overflow one. But it may only happen after the last character is pushed
into the RHR register. In this case we shouldn't push all the read
characters with overrun flag set, but only the last one caused the
FIFO overflow. This commit splits the characters retrieval loop into
two parts. First one is ordinary intsert-chars procedure without taking
the overrun status into account. Second part inserts the last character
checking whether the overrun happened and pushing a '\0' character with
TTY_OVERRUN flag to a flip-buffer.

If we left the loop the way it was the '\0' character would be inserted
after each character retrieved at the overrun occasion.

Signed-off-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Optionally enable rs485 on startup</title>
<updated>2019-05-21T10:15:53+00:00</updated>
<author>
<name>Serge Semin</name>
<email>fancer.lancer@gmail.com</email>
</author>
<published>2019-05-14T10:14:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2b9e6f0a400b6be1a408cd63ed09cfeb8f5dd627'/>
<id>urn:sha1:2b9e6f0a400b6be1a408cd63ed09cfeb8f5dd627</id>
<content type='text'>
UART port might be pre-configured with rs485 enabled flag at the
time of the port starting up process. In this case we need to
have the hardware rs485-related registers initialized in accordance
with the rs485 flags and settings provided by the configs descriptor.

Signed-off-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Add rx-during-tx rs485 flag support</title>
<updated>2019-05-21T10:15:53+00:00</updated>
<author>
<name>Serge Semin</name>
<email>fancer.lancer@gmail.com</email>
</author>
<published>2019-05-14T10:14:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=68f22c0c99d9c3534b88d1cd1215753a7a3655aa'/>
<id>urn:sha1:68f22c0c99d9c3534b88d1cd1215753a7a3655aa</id>
<content type='text'>
The driver currently sets the echo suppression bit by default when rs485
is enabled. Naturally it disables any data retrieval in rs485 mode while
RTSn is pushed up. The receiver gate (RX_) can be enabled just by clearing
(or not setting) the EchoSuprs bit of mode2 register. So by setting or
clearing the bit we implement the SER_RS485_RX_DURING_TX rs485 flag
support.

Signed-off-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Fix invalid baudrate divisors calculator</title>
<updated>2019-05-21T10:15:53+00:00</updated>
<author>
<name>Serge Semin</name>
<email>fancer.lancer@gmail.com</email>
</author>
<published>2019-05-14T10:14:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=35240ba26a932b279a513f66fa4cabfd7af55221'/>
<id>urn:sha1:35240ba26a932b279a513f66fa4cabfd7af55221</id>
<content type='text'>
Current calculator doesn't do it' job quite correct. First of all the
max310x baud-rates generator supports the divisor being less than 16.
In this case the x2/x4 modes can be used to double or quadruple
the reference frequency. But the current baud-rate setter function
just filters all these modes out by the first condition and setups
these modes only if there is a clocks-baud division remainder. The former
doesn't seem right at all, since enabling the x2/x4 modes causes the line
noise tolerance reduction and should be only used as a last resort to
enable a requested too high baud-rate.

Finally the fraction is supposed to be calculated from D = Fref/(c*baud)
formulae, but not from D % 16, which causes the precision loss. So to speak
the current baud-rate calculator code works well only if the baud perfectly
fits to the uart reference input frequency.

Lets fix the calculator by implementing the algo fully compliant with
the fractional baud-rate generator described in the datasheet:
D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode
respectively, Fref - reference input frequency. The divisor fraction is
calculated from the same formulae, but making sure it is found with a
resolution of 0.0625 (four bits).

Signed-off-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Don't pass stacked buffers to SPI</title>
<updated>2019-05-21T10:15:53+00:00</updated>
<author>
<name>Serge Semin</name>
<email>fancer.lancer@gmail.com</email>
</author>
<published>2019-05-14T10:14:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b7382c73b2d7102154cb077dde9aa9370b776874'/>
<id>urn:sha1:b7382c73b2d7102154cb077dde9aa9370b776874</id>
<content type='text'>
SPI transfer tx/rx buffers must be DMA-safe and the structure
documentation clearly states this. Data declared on the system stack isn't
DMA-safe [1]. Instead at least kernel memory should be used for the
buffers. In order to fix this here we can create the buffers at the device
probing stage and use them without any synchronization, since batch
read/write methods are called from non-reentrant contexts - either from
rx-event IRQ threaded handler or from the tx workqueue item.

[1] Documentation/DMA-API-HOWTO.txt

Signed-off-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Introduce max310x_one port macro-wrapper</title>
<updated>2019-05-21T10:15:53+00:00</updated>
<author>
<name>Serge Semin</name>
<email>fancer.lancer@gmail.com</email>
</author>
<published>2019-05-14T10:14:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1b5d239af3dad5b2572c9dab2e70f6735410e18f'/>
<id>urn:sha1:1b5d239af3dad5b2572c9dab2e70f6735410e18f</id>
<content type='text'>
uart_port structure instance is embedded into the max310x_one
super-structure, which is accessed by some of the uart-port callback
methods. In order to improve the callback's code readability lets
define the to_max310x_port() wrapper which just translates the passed
uart_port pointer to the max310x_one one. It is also going to be
handy in future commits.

Signed-off-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tty: max310x: Simplify tx-work item code</title>
<updated>2019-05-21T10:15:53+00:00</updated>
<author>
<name>Serge Semin</name>
<email>fancer.lancer@gmail.com</email>
</author>
<published>2019-05-14T10:14:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2987590b7846bc55530d02fcb568ce338a1e5bdd'/>
<id>urn:sha1:2987590b7846bc55530d02fcb568ce338a1e5bdd</id>
<content type='text'>
Since cmwq introduction in the kernel, workqueues've been turned into
non-reentrant execution contexts [1]. It means any work item is
guaranteed to be executed by at most one worker system-wide at any
given time. Since tx-handler max310x_handle_tx() is called by a
single work item we don't need it to be self-protected by the mutex.
We also don't need to check the tx work item pending state before
scheduling it (which in the first place was racy btw), since cmwq will
make sure to reschedule the item if it wasn't pending at the moment of
schedule_work() call.

[1] Documentation/core-api/workqueue.rst

Signed-off-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>serial: max310x: Fix to avoid potential NULL pointer dereference</title>
<updated>2019-03-19T14:37:43+00:00</updated>
<author>
<name>Aditya Pakki</name>
<email>pakki001@umn.edu</email>
</author>
<published>2019-03-18T23:44:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=3a10e3dd52e80b9a97a3346020024d17b2c272d6'/>
<id>urn:sha1:3a10e3dd52e80b9a97a3346020024d17b2c272d6</id>
<content type='text'>
of_match_device can return a NULL pointer when matching device is not
found. This patch avoids a scenario causing NULL pointer derefernce.

Signed-off-by: Aditya Pakki &lt;pakki001@umn.edu&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
