mbox series

[GIT,PULL] spi updates for v5.2

Message ID 20190506143301.GU14916@sirena.org.uk (mailing list archive)
State New, archived
Headers show
Series [GIT,PULL] spi updates for v5.2 | expand

Pull-request

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.2

Message

Mark Brown May 6, 2019, 2:33 p.m. UTC
The following changes since commit 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b:

  Linux 5.1-rc7 (2019-04-28 17:04:13 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.2

for you to fetch changes up to 2e5f081003f033d37be3faf052aaccc8b6a44aa5:

  Merge branch 'spi-5.2' into spi-next (2019-05-02 11:20:29 +0900)

----------------------------------------------------------------
spi: Updates for v5.2

One small feature was added this release but the bulk of the diffstat
and the changelog comes from the fact that several older drivers got
some fairly hefty reworks and a couple of new drivers were added:

 - Support for detailed control of timing around chip selects from
   Sowjanya Komatineni.
 - A big set of fixes and imrovements for the Tegra114 driver from
   Sowjanya Komatineni.
 - A big simplification of the GPIO driver from Andrey Smirnov.
 - DMA support and fixes for the Freescale LPSPI driver from Clark Wang.
 - Fixes and optimizations for the bcm2835aux from Martin Sparl.
 - New drivers for Mediatek MT7621 (graduated from staging) and Zynq QSPI.

----------------------------------------------------------------
Aditya Pakki (1):
      spi : spi-topcliff-pch: Fix to handle empty DMA buffers

Andrey Smirnov (12):
      spi: gpio: Drop unused spi_to_pdata()
      spi: gpio: Add local struct device pointer in spi_gpio_probe()
      spi: gpio: Add local struct spi_bitbang pointer in spi_gpio_probe()
      spi: gpio: Simplify SPI_MASTER_NO_TX check in spi_gpio_probe()
      spi: gpio: Drop unused pdata copy in struct spi_gpio
      spi: gpio: Don't request CS GPIO in DT use-case
      spi: Don't call spi_get_gpio_descs() before device name is set
      spi: gpio: Drop mflags argument from spi_gpio_request()
      spi: gpio: Drop unused pdev field in struct spi_gpio
      spi: gpio: Make sure spi_master_put() is called in every error path
      spi: bitbang: Introduce spi_bitbang_init()
      spi: gpio: Use devm_spi_register_master()

Andy Shevchenko (3):
      spi: pxa2xx-pci: Drop unused header inclusion
      spi: pxa2xx: Introduce DMA burst size support
      spi: pxa2xx: Debug print DMA burst size

Arnd Bergmann (3):
      spi: work around clang bug in SPI_BPW_RANGE_MASK()
      spi: fix SPI_BPW_RANGE_MASK() regression
      spi: export tracepoint symbols to modules

Axel Lin (4):
      spi: at91-usart: Remove duplicated checking for spi->bits_per_word
      spi: fsl-lpspi: Fix problematic dev_set_drvdata call
      spi: fsl-lpspi: Fix build warning when !CONFIG_PM
      spi: fsl-lpspi: Clean up fsl_lpspi_probe

Cao Van Dong (1):
      spi: sh-msiof: Document r8a77470 bindings

Cezary Gapinski (1):
      spi: pic32: fix dma channels termination

Chris Lesiak (1):
      spi: Fix zero length xfer bug

Clark Wang (9):
      spi: lpspi: Add i.MX8 boards support for lpspi
      doc: lpspi: Document DT bindings for LPSPI clocks
      spi: lpspi: add the error info of transfer speed setting
      spi: lpspi: use the core way to implement cs-gpio function
      spi: lpspi: add dma mode support
      spi: lpspi: Add the missing NULL check
      spi: lpspi: Code cleanup
      spi: lpspi: fix dataloss when SS is inactivated between every words
      spi: lpspi: add missing complete in abort func at dma mode

Claudiu Beznea (1):
      spi: atmel-quadspi: fix crash while suspending

Daniel Gomez (1):
      spi: AD ASoC: declare missing of table

Evan Green (1):
      spi: pxa2xx: Add support for Intel Comet Lake

Fabien Dessenne (2):
      spi: stm32-qspi: manage the get_irq error case
      spi: stm32: return the get_irq error

Flavio Suligoi (3):
      spi: pxa2xxx: change "no DMA channels..." msg from debug to warning
      spi: pxa2xx: use a module softdep for dw_dmac
      spi: pxa2xx: fix SCR (divisor) calculation

Gareth Williams (1):
      dt-bindings: snps,dw-apb-ssi: Add optional clock bindings documentation

Geert Uytterhoeven (8):
      spi: rspi: Fix register initialization while runtime-suspended
      spi: rspi: Fix sequencer reset during initialization
      spi: sh-msiof: Use BIT() and GENMASK()
      spi: sh-msiof: Use readl_poll_timeout_atomic() instead of open-coding
      spi: sh-msiof: Add reset of registers before starting transfer
      spi: spi-gpio: Remove spi->controller_data comment
      spi: Add missing error handling for CS GPIOs
      spi: sh-msiof: Convert to use GPIO descriptors

Han Xu (1):
      spi: lpspi: enable runtime pm for lpspi

Hoan Nguyen An (1):
      spi: rspi: Fix handling of QSPI code when transmit and receive

Jan Kundrát (2):
      spi: spidev: Enable control of inter-word delays
      spi: orion: Support spi_xfer->word_delay_usecs

Jarkko Nikula (3):
      spi: pxa2xx: Use struct spi_device directly in pxa2xx_spi_transfer_one()
      spi: pxa2xx: Unify remaing prints in pxa2xx_spi_transfer_one()
      spi: Remove one needless transfer speed fall back case

Leilk Liu (1):
      dt-bindings: spi: spi-mt65xx: add support for MT8516

Linus Walleij (1):
      spi: ep93xx: Convert to use CS GPIO descriptors

Ludovic Barre (4):
      spi: spi-mem: stm32-qspi: avoid memory corruption at low frequency
      spi: spi-mem: stm32-qspi: add suspend/resume support
      spi: stm32-qspi: add spi_master_put in release function
      spi: stm32-qspi: add dma support

Mark Brown (5):
      Merge branch 'spi-5.1' into spi-5.2 for stm32
      Merge tag 'v5.1-rc1' into spi-5.2
      Merge branch 'spi-5.1' into spi-5.2
      Merge branch 'spi-5.1' into spi-linus
      Merge branch 'spi-5.2' into spi-next

Martin Sperl (9):
      spi: bcm2835aux: unifying code between polling and interrupt driven code
      spi: bcm2835aux: remove dangerous uncontrolled read of fifo
      spi: bcm2835aux: fix corruptions for longer spi transfers
      spi: bcm2835aux: remove dead code
      spi: bcm2835aux: fix driver to not allow 65535 (=-1) cs-gpios
      spi: bcm2835aux: warn in dmesg that native cs is not really supported
      spi: bcm2835aux: setup gpio-cs to output and correct level during setup
      spi: bcm2835aux: make the polling duration limits configurable
      spi: bcm2835aux: add driver stats to debugfs

Meghana Madhyastha (1):
      spi/spi-bcm2835: Split transfers that exceed DLEN

Naga Sureshkumar Relli (4):
      spi: spi-mem: export spi_mem_default_supports_op()
      dt-bindings: spi: Add device tree binding documentation for Zynq QSPI controller
      spi: spi-mem: Add support for Zynq QSPI controller
      spi: spi-mem: zynq-qspi: Fix build error on architectures missing readsl/writesl

Noralf Trønnes (3):
      spi: Remove warning in spi_split_transfers_maxsize()
      spi: Release spi_res after finalizing message
      spi/trace: Cap buffer contents at 64 bytes

Phil Edworthy (2):
      dt-bindings: snps,dw-apb-ssi: Add mandatory clock bindings documentation
      spi: dw: Add support for an optional interface clock

Randolph Maaßen (1):
      spi: tegra20-slink: change chip select action order

Rasmus Villemoes (5):
      spi: spi-fsl-spi: support use of the SPISEL_BOOT signal on MPC8309
      spi: spi-fsl-spi: remove always-true conditional in fsl_spi_do_one_msg
      spi: spi-fsl-spi: relax message sanity checking a little
      spi: spi-fsl-spi: allow changing bits_per_word while CS is still active
      spi: spi-fsl-spi: automatically adapt bits-per-word in cpu mode

Serge Semin (1):
      spi: Clear SPI_CS_HIGH flag from bad_bits for GPIO chip-select

Sergei Shtylyov (2):
      spi: kill useless initializer in spi_register_controller()
      spi-mem: fix kernel-doc for spi_mem_dirmap_{read|write}()

Sowjanya Komatineni (22):
      spi: tegra114: clear packed bit for unpacked mode
      spi: tegra114: fix for unpacked mode transfers
      spi: tegra114: terminate dma and reset on transfer timeout
      spi: tegra114: flush fifos
      spi: tegra114: configure dma burst size to fifo trig level
      spi: tegra114: reset controller on probe
      spi: tegra114: use packed mode for 32 bits per word
      spi: tegra114: add SPI_LSB_FIRST support
      spi: tegra114: de-assert CS before SPI mode change
      spi: tegra114: avoid reset call in atomic context
      spi: tegra114: dump SPI registers during timeout
      spi: tegra114: set supported bits per word
      spi: tegra114: use unpacked mode for below 4 bytes
      spi: tegra114: set bus number based on id
      spi: tegra114: add dual mode support
      spi: tegra114: add 3 wire transfer mode support
      spi: tegra114: add support for interrupt mask
      spi-summary: document set_cs_timing
      spi: add a method for configuring CS timing
      spi: document tx/rx clock delay properties
      spi: expand mode support
      spi: tegra114: fix PIO transfer

Stefan Roese (1):
      spi: mt7621: Move SPI driver out of staging

Trent Piepho (2):
      spi: imx: add module parameter to control DMA use
      spi: imx: stop buffer overflow in RX FIFO flush

Volker Haspel (1):
      spi: spi-fsl-qspi: use devm_spi_register_controller

Wolfram Sang (1):
      spi: mxic: simplify getting .driver_data

YueHaibing (4):
      spi: atmel-quadspi: Make atmel_qspi_get_name static
      spi: bcm2835aux: Fix build error without CONFIG_DEBUG_FS
      spi: spi-mem: Fix build error without CONFIG_SPI_MEM
      spi: spi-mem: Make spi_mem_default_supports_op() static inline

kbuild test robot (3):
      spi: lpspi: fsl_lpspi_runtime_resume() can be static
      spi: spi-mem: stm32-qspi: stm32_qspi_pm_ops can be static
      spi: bcm2835aux: polling_limit_us can be static

 Documentation/devicetree/bindings/spi/fsl-spi.txt  |   4 +
 .../bindings/spi/nvidia,tegra114-spi.txt           |  20 +
 Documentation/devicetree/bindings/spi/sh-msiof.txt |   1 +
 .../devicetree/bindings/spi/snps,dw-apb-ssi.txt    |  10 +-
 .../devicetree/bindings/spi/spi-fsl-lpspi.txt      |  10 +-
 .../devicetree/bindings/spi/spi-mt65xx.txt         |   1 +
 .../devicetree/bindings/spi/spi-mt7621.txt         |  26 +
 .../devicetree/bindings/spi/spi-zynq-qspi.txt      |  25 +
 Documentation/spi/spi-summary                      |   6 +
 arch/arm/mach-ep93xx/edb93xx.c                     |  13 +-
 arch/arm/mach-ep93xx/simone.c                      |  11 +-
 arch/arm/mach-ep93xx/ts72xx.c                      |  25 +-
 arch/arm/mach-ep93xx/vision_ep9307.c               |  15 +-
 arch/sh/boards/mach-ecovec24/setup.c               |  12 +-
 drivers/spi/Kconfig                                |  16 +-
 drivers/spi/Makefile                               |   2 +
 drivers/spi/atmel-quadspi.c                        |   8 +-
 drivers/spi/spi-at91-usart.c                       |   8 +-
 drivers/spi/spi-bcm2835.c                          |  39 +-
 drivers/spi/spi-bcm2835aux.c                       | 205 ++++--
 drivers/spi/spi-bitbang.c                          |  66 +-
 drivers/spi/spi-dw-mmio.c                          |  12 +
 drivers/spi/spi-ep93xx.c                           |  32 +-
 drivers/spi/spi-fsl-lib.h                          |   2 +
 drivers/spi/spi-fsl-lpspi.c                        | 573 ++++++++++++++--
 drivers/spi/spi-fsl-qspi.c                         |   2 +-
 drivers/spi/spi-fsl-spi.c                          |  81 ++-
 drivers/spi/spi-gpio.c                             | 227 +++---
 drivers/spi/spi-imx.c                              |   9 +-
 drivers/spi/spi-mem.c                              |   8 +-
 drivers/{staging/mt7621-spi => spi}/spi-mt7621.c   |  83 ++-
 drivers/spi/spi-mxic.c                             |   6 +-
 drivers/spi/spi-orion.c                            |   4 +
 drivers/spi/spi-pic32.c                            |   2 +-
 drivers/spi/spi-pxa2xx-dma.c                       |   4 +-
 drivers/spi/spi-pxa2xx-pci.c                       |   5 +-
 drivers/spi/spi-pxa2xx.c                           |  38 +-
 drivers/spi/spi-rspi.c                             | 119 ++--
 drivers/spi/spi-sh-msiof.c                         | 224 +++---
 drivers/spi/spi-stm32-qspi.c                       | 229 ++++++-
 drivers/spi/spi-stm32.c                            |   5 +-
 drivers/spi/spi-tegra114.c                         | 310 +++++++--
 drivers/spi/spi-tegra20-slink.c                    |  12 +-
 drivers/spi/spi-topcliff-pch.c                     |  15 +-
 drivers/spi/spi-zynq-qspi.c                        | 761 +++++++++++++++++++++
 drivers/spi/spi.c                                  |  76 +-
 drivers/spi/spidev.c                               |   4 +-
 drivers/staging/Kconfig                            |   2 -
 drivers/staging/Makefile                           |   1 -
 drivers/staging/mt7621-spi/Kconfig                 |   6 -
 drivers/staging/mt7621-spi/Makefile                |   1 -
 drivers/staging/mt7621-spi/TODO                    |   5 -
 include/linux/platform_data/spi-ep93xx.h           |   4 -
 include/linux/spi/pxa2xx_spi.h                     |   1 +
 include/linux/spi/spi-mem.h                        |  12 +
 include/linux/spi/spi.h                            |  24 +-
 include/linux/spi/spi_bitbang.h                    |   1 +
 include/trace/events/spi.h                         |  10 +-
 include/uapi/linux/spi/spidev.h                    |   6 +-
 sound/soc/codecs/adau1977-spi.c                    |  11 +
 60 files changed, 2650 insertions(+), 800 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-mt7621.txt
 create mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
 rename drivers/{staging/mt7621-spi => spi}/spi-mt7621.c (88%)
 create mode 100644 drivers/spi/spi-zynq-qspi.c
 delete mode 100644 drivers/staging/mt7621-spi/Kconfig
 delete mode 100644 drivers/staging/mt7621-spi/Makefile
 delete mode 100644 drivers/staging/mt7621-spi/TODO

Comments

Linus Torvalds May 6, 2019, 7:01 p.m. UTC | #1
Mark,
 gmail once again hates your emails. Your email ends up as spam, due to

    dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org

but it has a DKIM signature for sirena.org.uk:

    DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=sirena.org.uk; ...

Hmm?

                Linus
Mark Brown May 7, 2019, 2:18 a.m. UTC | #2
On Mon, May 06, 2019 at 12:01:44PM -0700, Linus Torvalds wrote:
> Mark,
>  gmail once again hates your emails. Your email ends up as spam, due to
> 
>     dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org

That looks like it's a fail on validation of the kernel.org bit of
things which I have no control over and which purposely doesn't
advertise DKIM stuff in the hope that people will actually be able to
send mail from non-kernel.org mail servers.  I'm really unsure why
that's failing at all, there's no policy for kernel.org to fail.

> but it has a DKIM signature for sirena.org.uk:
> 
>     DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=sirena.org.uk; ...

which should match the envelope sender.

As far as I can tell Google is going to be unhappy no matter what unless
I use their services - if there's DKIM records it's not going to like
that the from is from kernel.org and if I don't have DKIM records then
it's not going to like that either and I'll be more vulnerable to the
blacklists that try to extort money out of people for permanent
delisting.

Possibly it's not actually anything to do with the DKIM and it's just
upset that I'm travelling and so the mail was injected from a mobile
broadband IP in Japan which doesn't match up with the .uk domain.
Linus Torvalds May 7, 2019, 2:34 a.m. UTC | #3
On Mon, May 6, 2019 at 7:19 PM Mark Brown <broonie@kernel.org> wrote:
> >
> >     dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org
>
> That looks like it's a fail on validation of the kernel.org bit of
> things which I have no control over and which purposely doesn't
> advertise DKIM stuff in the hope that people will actually be able to
> send mail from non-kernel.org mail servers.

Looking around, I think you're right, and it's probably not actually
the DKIM thing that causes problems.

Because yes, kernel.org dmarc will just say "ignore".

So I think it's just google that still doesn't like sirena.org.uk.
Iirc, that's happened before, no?

                   Linus
Mark Brown May 7, 2019, 3:02 a.m. UTC | #4
On Tue, May 07, 2019 at 11:18:53AM +0900, Mark Brown wrote:

> Possibly it's not actually anything to do with the DKIM and it's just
> upset that I'm travelling and so the mail was injected from a mobile
> broadband IP in Japan which doesn't match up with the .uk domain.

I've tried sending equivalent mail to one of my own Google accounts and
it gets delivered, though I do see the dmarc=fail bit in the headers.
The full header there is for a newer spec called ARC that builds even
more stuff on top of DKIM and SPF.

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=gYHUGKmm;
       spf=pass (google.com: best guess record for domain of broonie@sirena.org.uk designates 2a01:7e01::f03c:91ff:fed4:a3b6 as permitted sender) smtp.mailfrom=broonie@sirena.org.uk;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org

which suggests it's adding some guesswork in there on top of what's
explicitly in there for SPF (though that's not causing trouble as it
worked out that the mail is OK).  The fact that this got through OK and
all the NONEs there suggest that they are to at least some extent doing
the right thing with the lack of any advertised policies for kernel.org,
either something else about the message or your incoming mail is causing
the spam filtering.

Unfortunately I can't immediately see any exim stuff for ARC (and I
don't know that there's anything there that could really help) and I
can't do DKIM for kernel.org (for good reasons), the only thing I can
think of is to disable signing of the From: and hope Google just stop
trying to validate it but that doesn't seem ideal.  Everything I'm
seeing is saying that Google just isn't enthusiastic about domains like
kernel.org which is going an issue.

Not really sure what I can do here...
Mark Brown May 7, 2019, 3:09 a.m. UTC | #5
On Mon, May 06, 2019 at 07:34:29PM -0700, Linus Torvalds wrote:

> So I think it's just google that still doesn't like sirena.org.uk.
> Iirc, that's happened before, no?

In the past that always looked like it was triggered by some of the
blacklists that basically seem to have a business model that involves
at least partly charging people money for whitelisting and so are
perhaps a little trigger happy when it comes to listing servers.  This
time around I'm not seeing any signs of that happening but I might've
missed some, I don't know if Google stopped using those blacklists or
something.
Linus Torvalds May 7, 2019, 3:13 a.m. UTC | #6
On Mon, May 6, 2019 at 8:02 PM Mark Brown <broonie@kernel.org> wrote:
>
>                    Everything I'm
> seeing is saying that Google just isn't enthusiastic about domains like
> kernel.org which is going an issue.

Well, there are other people who use kernel.org email addresses.  Ingo
Molnar, Rafael Wysocki, a couple of others.  But you're the one
getting marked as spam.

Somebody just hates you. I do end up checking my spam-box regularly,
so maybe it doesn't matter.

                 Linus
Mark Brown May 7, 2019, 11:03 a.m. UTC | #7
On Mon, May 06, 2019 at 08:13:49PM -0700, Linus Torvalds wrote:
> On Mon, May 6, 2019 at 8:02 PM Mark Brown <broonie@kernel.org> wrote:

> >                    Everything I'm
> > seeing is saying that Google just isn't enthusiastic about domains like
> > kernel.org which is going an issue.

> Well, there are other people who use kernel.org email addresses.  Ingo
> Molnar, Rafael Wysocki, a couple of others.  But you're the one
> getting marked as spam.

I'm not going to search for rule 36 SPI.

> Somebody just hates you. I do end up checking my spam-box regularly,
> so maybe it doesn't matter.

Some spot checks are suggesting that they use gmail as their outbound
relay which I can imagine they'd like but would break some stuff for me
for non-kernel.org mail I think, it'd be a major rework to not inject
stuff via sendmail.
Sebastian Reichel May 7, 2019, 12:07 p.m. UTC | #8
Hi,

On Tue, May 07, 2019 at 08:03:45PM +0900, Mark Brown wrote:
> On Mon, May 06, 2019 at 08:13:49PM -0700, Linus Torvalds wrote:
> > On Mon, May 6, 2019 at 8:02 PM Mark Brown <broonie@kernel.org> wrote:
> 
> > >                    Everything I'm
> > > seeing is saying that Google just isn't enthusiastic about domains like
> > > kernel.org which is going an issue.
> 
> > Well, there are other people who use kernel.org email addresses.  Ingo
> > Molnar, Rafael Wysocki, a couple of others.  But you're the one
> > getting marked as spam.
> 
> I'm not going to search for rule 36 SPI.
> 
> > Somebody just hates you. I do end up checking my spam-box regularly,
> > so maybe it doesn't matter.
> 
> Some spot checks are suggesting that they use gmail as their outbound
> relay which I can imagine they'd like but would break some stuff for me
> for non-kernel.org mail I think, it'd be a major rework to not inject
> stuff via sendmail.

FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
added that service in 2014. You can get a password with

ssh git@gitolite.kernel.org getsmtppass

and then use the following settings for (example for git):

[sendemail]
    smtpserver     = mail.kernel.org
    smtpserverport = 587
    smtpencryption = tls
    smtpuser       = <user>@kernel.org
    smtppass       = [randomstring]

-- Sebastian
Linus Torvalds May 7, 2019, 3:08 p.m. UTC | #9
On Mon, May 6, 2019 at 7:33 AM Mark Brown <broonie@kernel.org> wrote:
>
> spi: Updates for v5.2

Hmm. Please be more careful. Commit 1dfbf334f123 ("spi: ep93xx:
Convert to use CS GPIO descriptors") caused a new warning because it
removed a "for ()" loop, but left the now unused variable 'i' around.

I fixed it up in the merge, because I hate warnings that may hide real
problems. But I also expect maintainers to check their warnings,
exactly because the normal build is supposed to have none. So a new
warning does stand out.

                    Linus
pr-tracker-bot@kernel.org May 7, 2019, 3:10 p.m. UTC | #10
The pull request you sent on Mon, 6 May 2019 23:33:01 +0900:

> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9bff9dfc513bd5de72cb59f4bffb72cf0a5aa526

Thank you!
Mark Brown May 8, 2019, 6:09 a.m. UTC | #11
On Tue, May 07, 2019 at 02:07:30PM +0200, Sebastian Reichel wrote:

> FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
> added that service in 2014. You can get a password with

> ssh git@gitolite.kernel.org getsmtppass
> 
> and then use the following settings for (example for git):

I'd have to send all mail out via kernel.org to do that, or persuade a
MTA to route mail differently based on contents which seems interesting
- I inject most of my mail via /usr/sbin/sendmail rather than SMTP
(including a bunch of scripts).
Mark Brown May 8, 2019, 6:11 a.m. UTC | #12
On Tue, May 07, 2019 at 08:08:50AM -0700, Linus Torvalds wrote:
> On Mon, May 6, 2019 at 7:33 AM Mark Brown <broonie@kernel.org> wrote:

> > spi: Updates for v5.2

> Hmm. Please be more careful. Commit 1dfbf334f123 ("spi: ep93xx:
> Convert to use CS GPIO descriptors") caused a new warning because it
> removed a "for ()" loop, but left the now unused variable 'i' around.

> I fixed it up in the merge, because I hate warnings that may hide real
> problems. But I also expect maintainers to check their warnings,
> exactly because the normal build is supposed to have none. So a new
> warning does stand out.

Sorry, I've actually got a fix for that queued but obviously didn't
manage to make sure it made it all the way through the process to the
pull request.
Sebastian Reichel May 8, 2019, 10:13 a.m. UTC | #13
Hi,

On Wed, May 08, 2019 at 03:09:36PM +0900, Mark Brown wrote:
> On Tue, May 07, 2019 at 02:07:30PM +0200, Sebastian Reichel wrote:
> > FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
> > added that service in 2014. You can get a password with
> 
> > ssh git@gitolite.kernel.org getsmtppass
> > 
> > and then use the following settings for (example for git):
> 
> I'd have to send all mail out via kernel.org to do that, or persuade a
> MTA to route mail differently based on contents which seems interesting
> - I inject most of my mail via /usr/sbin/sendmail rather than SMTP
> (including a bunch of scripts).

I have a locally installed postfix in sender dependent relay
configuration, which does that for me:

http://www.postfix.org/SOHO_README.html#client_sasl_sender

-- Sebastian
Brian Masney May 8, 2019, 10:20 a.m. UTC | #14
On Wed, May 08, 2019 at 03:09:36PM +0900, Mark Brown wrote:
> On Tue, May 07, 2019 at 02:07:30PM +0200, Sebastian Reichel wrote:
> 
> > FWIW, I send out kernel.org mails via mail.kernel.org. Konstantin
> > added that service in 2014. You can get a password with
> 
> > ssh git@gitolite.kernel.org getsmtppass
> > 
> > and then use the following settings for (example for git):
> 
> I'd have to send all mail out via kernel.org to do that, or persuade a
> MTA to route mail differently based on contents which seems interesting
> - I inject most of my mail via /usr/sbin/sendmail rather than SMTP
> (including a bunch of scripts).

I use a program called msmtp (https://marlam.de/msmtp/) to route email
to different SMTP servers based on my sender address. Once you have your
accounts configured, replace the call to the sendmail binary in your MUA
with msmtp and it'll route the email differently for you. It's included
in the package repositories for most major Linux distributions. Here's
two resources I found that show how to configure mutt and git send-email
to use msmtp:

https://hostpresto.com/community/tutorials/how-to-send-email-from-the-command-line-with-msmtp-and-mutt/
https://jordonwu.github.io/blog/2015/12/01/git-send-email-and-msmtp-config/

Once you have msmtp setup, send test emails from each of your accounts
to check-auth@verifier.port25.com to have a bot verify that your email
is setup properly (DKIM, SPF, reverse DNS, etc).

Brian
Mark Brown May 8, 2019, 10:27 a.m. UTC | #15
On Wed, May 08, 2019 at 12:13:01PM +0200, Sebastian Reichel wrote:
> On Wed, May 08, 2019 at 03:09:36PM +0900, Mark Brown wrote:

> > I'd have to send all mail out via kernel.org to do that, or persuade a
> > MTA to route mail differently based on contents which seems interesting
> > - I inject most of my mail via /usr/sbin/sendmail rather than SMTP
> > (including a bunch of scripts).

> I have a locally installed postfix in sender dependent relay
> configuration, which does that for me:

> http://www.postfix.org/SOHO_README.html#client_sasl_sender

I'm using exim on the central relay box which is much more painful to
configure than postfix sadly (one of these days I'll get round to
converting to Postfix since I prefer it and already use it on my client
boxes but the DKIM stuff is painful enough and there's enough stuff
using the box that it'll require me to actually sit down properly to do
something as substantial as cutting over MTAs).  It's also not clear to
me that Postfix can be configured based on From rather than envelope
sender, I have used the configuration options you're pointing at for
envelope senders before but at least at that time Postfix didn't support
setting envelope sender via /usr/sbin/sendmail.