Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()
On Wed, May 6, 2020 at 6:29 PM Jan Kara wrote:
>
> On Wed 06-05-20 17:51:39, Souptick Joarder wrote:
> > On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote:
> > >
> > > On Wed 06-05-20 02:06:56, Souptick Joarder wrote:
> > > > On Wed, May 6, 2020 at 1:08 AM John Hubbard wrote:
> > > > >
> > > > > On 2020-05-05 12:14, Souptick Joarder wrote:
> > > > > > Currently {get|pin}_user_pages_fast() have 3 return value 0, -errno
> > > > > > and no of pinned pages. The only case where these two functions will
> > > > > > return 0, is for nr_pages <= 0, which doesn't find a valid use case.
> > > > > > But if at all any, then a -ERRNO will be returned instead of 0,
> > > > > > which
> > > > > > means {get|pin}_user_pages_fast() will have 2 return values -errno &
> > > > > > no of pinned pages.
> > > > > >
> > > > > > Update all the callers which deals with return value 0 accordingly.
> > > > >
> > > > > Hmmm, seems a little shaky. In order to do this safely, I'd recommend
> > > > > first changing gup_fast/pup_fast so so that they return -EINVAL if
> > > > > the caller specified nr_pages==0, and of course auditing all callers,
> > > > > to ensure that this won't cause problems.
> > > >
> > > > While auditing it was figured out, there are 5 callers which cares for
> > > > return value
> > > > 0 of gup_fast/pup_fast. What problem it might cause if we change
> > > > gup_fast/pup_fast
> > > > to return -EINVAL and update all the callers in a single commit ?
> > >
> > > Well, first I'd ask a different question: Why do you want to change the
> > > current behavior? It's not like the current behavior is confusing.
> > > Callers
> > > that pass >0 pages can happily rely on the simple behavior of < 0 return
> > > on
> > > error or > 0 return if we mapped some pages. Callers that can possibly ask
> > > to map 0 pages can get 0 pages back - kind of expected - and I don't see
> > > any benefit in trying to rewrite these callers to handle -EINVAL
> > > instead...
> >
> > Callers with a request to map 0 pages doesn't have a valid use case. But if
> > any
> > caller end up doing it mistakenly, -errno should be returned to caller
> > rather than 0
> > which will indicate more precisely that map 0 pages is not a valid
> > request from caller.
>
> Well, I believe this depends on the point of view. Similarly as reading 0
> bytes is successful, we could consider mapping 0 pages successful as well.
> And there can be valid cases where number of pages to map is computed from
> some input and when 0 pages should be mapped, it is not a problem and your
> change would force such callers to special case this with explicitely
> checking for 0 pages to map and not calling GUP in that case at all.
>
> I'm not saying what you propose is necessarily bad, I just say I don't find
> it any better than the current behavior and so IMO it's not worth the
> churn. Now if you can come up with some examples of current in-kernel users
> who indeed do get the handling of the return value wrong, I could be
> convinced otherwise.
There are 5 callers of {get|pin}_user_pages_fast().
arch/ia64/kernel/err_inject.c#L145
staging/gasket/gasket_page_table.c#L489
Checking return value 0 doesn't make sense for above 2.
drivers/platform/goldfish/goldfish_pipe.c#L277
net/rds/rdma.c#L165
drivers/tee/tee_shm.c#L262
These 3 callers have calculated the no of pages value before passing it to
{get|pin}_user_pages_fast(). But if they end up passing nr_pages <= 0, a return
value of either 0 or -EINVAL doesn't going to harm any existing
behavior of callers.
IMO, it is safe to return -errno for nr_pages <= 0, for
{get|pin}_user_pages_fast().
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next v2] staging: kpc2000: fix error return code in kp2000_pcie_probe()
Fantastic. Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next v2] staging: kpc2000: fix error return code in kp2000_pcie_probe()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function. Also
removed var 'rv' since we can use 'err' instead.
Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers")
Signed-off-by: Wei Yongjun
---
v1 -> v2: fix code aligns and add fixes
---
drivers/staging/kpc2000/kpc2000/core.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000/core.c
b/drivers/staging/kpc2000/kpc2000/core.c
index 7b00d7069e21..358d7b2f4ad1 100644
--- a/drivers/staging/kpc2000/kpc2000/core.c
+++ b/drivers/staging/kpc2000/kpc2000/core.c
@@ -298,7 +298,6 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
{
int err = 0;
struct kp2000_device *pcard;
- int rv;
unsigned long reg_bar_phys_addr;
unsigned long reg_bar_phys_len;
unsigned long dma_bar_phys_addr;
@@ -445,11 +444,11 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
if (err < 0)
goto err_release_dma;
- rv = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
-pcard->name, pcard);
- if (rv) {
+ err = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
+ pcard->name, pcard);
+ if (err) {
dev_err(>pdev->dev,
- "%s: failed to request_irq: %d\n", __func__, rv);
+ "%s: failed to request_irq: %d\n", __func__, err);
goto err_disable_msi;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: kpc2000: fix error return code in kp2000_pcie_probe()
On 2020/5/6 20:57, Dan Carpenter wrote:
> On Wed, May 06, 2020 at 12:52:55PM +, Wei Yongjun wrote:
>> Fix to return a negative error code from the error handling
>> case instead of 0, as done elsewhere in this function. Also
>> removed var 'rv' since we can use 'err' instead.
>>
>> Signed-off-by: Wei Yongjun
>
> Also could you add a Fixes tag? This goes all the way back to the
> original commit:
>
> Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics
> drivers")
>
Will fix both of your comments in next version, thanks.
Regards,
Wei Yongjun
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()
On Wed 06-05-20 17:51:39, Souptick Joarder wrote:
> On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote:
> >
> > On Wed 06-05-20 02:06:56, Souptick Joarder wrote:
> > > On Wed, May 6, 2020 at 1:08 AM John Hubbard wrote:
> > > >
> > > > On 2020-05-05 12:14, Souptick Joarder wrote:
> > > > > Currently {get|pin}_user_pages_fast() have 3 return value 0, -errno
> > > > > and no of pinned pages. The only case where these two functions will
> > > > > return 0, is for nr_pages <= 0, which doesn't find a valid use case.
> > > > > But if at all any, then a -ERRNO will be returned instead of 0, which
> > > > > means {get|pin}_user_pages_fast() will have 2 return values -errno &
> > > > > no of pinned pages.
> > > > >
> > > > > Update all the callers which deals with return value 0 accordingly.
> > > >
> > > > Hmmm, seems a little shaky. In order to do this safely, I'd recommend
> > > > first changing gup_fast/pup_fast so so that they return -EINVAL if
> > > > the caller specified nr_pages==0, and of course auditing all callers,
> > > > to ensure that this won't cause problems.
> > >
> > > While auditing it was figured out, there are 5 callers which cares for
> > > return value
> > > 0 of gup_fast/pup_fast. What problem it might cause if we change
> > > gup_fast/pup_fast
> > > to return -EINVAL and update all the callers in a single commit ?
> >
> > Well, first I'd ask a different question: Why do you want to change the
> > current behavior? It's not like the current behavior is confusing. Callers
> > that pass >0 pages can happily rely on the simple behavior of < 0 return on
> > error or > 0 return if we mapped some pages. Callers that can possibly ask
> > to map 0 pages can get 0 pages back - kind of expected - and I don't see
> > any benefit in trying to rewrite these callers to handle -EINVAL instead...
>
> Callers with a request to map 0 pages doesn't have a valid use case. But if
> any
> caller end up doing it mistakenly, -errno should be returned to caller
> rather than 0
> which will indicate more precisely that map 0 pages is not a valid
> request from caller.
Well, I believe this depends on the point of view. Similarly as reading 0
bytes is successful, we could consider mapping 0 pages successful as well.
And there can be valid cases where number of pages to map is computed from
some input and when 0 pages should be mapped, it is not a problem and your
change would force such callers to special case this with explicitely
checking for 0 pages to map and not calling GUP in that case at all.
I'm not saying what you propose is necessarily bad, I just say I don't find
it any better than the current behavior and so IMO it's not worth the
churn. Now if you can come up with some examples of current in-kernel users
who indeed do get the handling of the return value wrong, I could be
convinced otherwise.
Honza
--
Jan Kara
SUSE Labs, CR
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: kpc2000: fix error return code in kp2000_pcie_probe()
On Wed, May 06, 2020 at 12:52:55PM +, Wei Yongjun wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function. Also
> removed var 'rv' since we can use 'err' instead.
>
> Signed-off-by: Wei Yongjun
Also could you add a Fixes tag? This goes all the way back to the
original commit:
Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers")
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] staging: kpc2000: fix error return code in kp2000_pcie_probe()
On Wed, May 06, 2020 at 12:52:55PM +, Wei Yongjun wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function. Also
> removed var 'rv' since we can use 'err' instead.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/staging/kpc2000/kpc2000/core.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/kpc2000/kpc2000/core.c
> b/drivers/staging/kpc2000/kpc2000/core.c
> index 7b00d7069e21..14e07742dc9d 100644
> --- a/drivers/staging/kpc2000/kpc2000/core.c
> +++ b/drivers/staging/kpc2000/kpc2000/core.c
> @@ -298,7 +298,6 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
> {
> int err = 0;
> struct kp2000_device *pcard;
> - int rv;
> unsigned long reg_bar_phys_addr;
> unsigned long reg_bar_phys_len;
> unsigned long dma_bar_phys_addr;
> @@ -445,11 +444,11 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
> if (err < 0)
> goto err_release_dma;
>
> - rv = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
> + err = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
>pcard->name, pcard);
^
Could you add a space character here so the white space still aligns?
Otherwise it looks good. :)
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] staging: kpc2000: fix error return code in kp2000_pcie_probe()
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function. Also
removed var 'rv' since we can use 'err' instead.
Signed-off-by: Wei Yongjun
---
drivers/staging/kpc2000/kpc2000/core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000/core.c
b/drivers/staging/kpc2000/kpc2000/core.c
index 7b00d7069e21..14e07742dc9d 100644
--- a/drivers/staging/kpc2000/kpc2000/core.c
+++ b/drivers/staging/kpc2000/kpc2000/core.c
@@ -298,7 +298,6 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
{
int err = 0;
struct kp2000_device *pcard;
- int rv;
unsigned long reg_bar_phys_addr;
unsigned long reg_bar_phys_len;
unsigned long dma_bar_phys_addr;
@@ -445,11 +444,11 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
if (err < 0)
goto err_release_dma;
- rv = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
+ err = request_irq(pcard->pdev->irq, kp2000_irq_handler, IRQF_SHARED,
pcard->name, pcard);
- if (rv) {
+ if (err) {
dev_err(>pdev->dev,
- "%s: failed to request_irq: %d\n", __func__, rv);
+ "%s: failed to request_irq: %d\n", __func__, err);
goto err_disable_msi;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()
On Wed, May 6, 2020 at 3:36 PM Jan Kara wrote:
>
> On Wed 06-05-20 02:06:56, Souptick Joarder wrote:
> > On Wed, May 6, 2020 at 1:08 AM John Hubbard wrote:
> > >
> > > On 2020-05-05 12:14, Souptick Joarder wrote:
> > > > Currently {get|pin}_user_pages_fast() have 3 return value 0, -errno
> > > > and no of pinned pages. The only case where these two functions will
> > > > return 0, is for nr_pages <= 0, which doesn't find a valid use case.
> > > > But if at all any, then a -ERRNO will be returned instead of 0, which
> > > > means {get|pin}_user_pages_fast() will have 2 return values -errno &
> > > > no of pinned pages.
> > > >
> > > > Update all the callers which deals with return value 0 accordingly.
> > >
> > > Hmmm, seems a little shaky. In order to do this safely, I'd recommend
> > > first changing gup_fast/pup_fast so so that they return -EINVAL if
> > > the caller specified nr_pages==0, and of course auditing all callers,
> > > to ensure that this won't cause problems.
> >
> > While auditing it was figured out, there are 5 callers which cares for
> > return value
> > 0 of gup_fast/pup_fast. What problem it might cause if we change
> > gup_fast/pup_fast
> > to return -EINVAL and update all the callers in a single commit ?
>
> Well, first I'd ask a different question: Why do you want to change the
> current behavior? It's not like the current behavior is confusing. Callers
> that pass >0 pages can happily rely on the simple behavior of < 0 return on
> error or > 0 return if we mapped some pages. Callers that can possibly ask
> to map 0 pages can get 0 pages back - kind of expected - and I don't see
> any benefit in trying to rewrite these callers to handle -EINVAL instead...
Callers with a request to map 0 pages doesn't have a valid use case. But if any
caller end up doing it mistakenly, -errno should be returned to caller
rather than 0
which will indicate more precisely that map 0 pages is not a valid
request from caller.
With these, 3rd return value 0, is no more needed.
That was the thought behind this proposal.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: os_dep: Cleanup pointer casting code style
On Sat, May 02, 2020 at 08:47:50AM +0800, Yu Jian Wu wrote:
> Cleanup by adding a space between type and pointer, in accordance with
> checkpatch.pl message "(foo*)" should be "(foo *)".
>
> Signed-off-by: Yu Jian Wu
> ---
> .../staging/rtl8723bs/os_dep/ioctl_cfg80211.c| 16
> drivers/staging/rtl8723bs/os_dep/recv_linux.c| 2 +-
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> index b037868fbf22..8377bc75e308 100644
> --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> @@ -98,7 +98,7 @@ static struct ieee80211_channel rtw_2ghz_channels[] = {
>
> static void rtw_2g_channels_init(struct ieee80211_channel *channels)
> {
> - memcpy((void*)channels, (void*)rtw_2ghz_channels,
> + memcpy((void *)channels, (void *)rtw_2ghz_channels,
These casts aren't required. It would be better to remove them.
memcpy(channels, rtw_2ghz_channels,
sizeof(*channel) * RTW_2G_CHANNELS_NUM);
Same for a bunch of the others as well.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages_fast()
On Wed 06-05-20 02:06:56, Souptick Joarder wrote:
> On Wed, May 6, 2020 at 1:08 AM John Hubbard wrote:
> >
> > On 2020-05-05 12:14, Souptick Joarder wrote:
> > > Currently {get|pin}_user_pages_fast() have 3 return value 0, -errno
> > > and no of pinned pages. The only case where these two functions will
> > > return 0, is for nr_pages <= 0, which doesn't find a valid use case.
> > > But if at all any, then a -ERRNO will be returned instead of 0, which
> > > means {get|pin}_user_pages_fast() will have 2 return values -errno &
> > > no of pinned pages.
> > >
> > > Update all the callers which deals with return value 0 accordingly.
> >
> > Hmmm, seems a little shaky. In order to do this safely, I'd recommend
> > first changing gup_fast/pup_fast so so that they return -EINVAL if
> > the caller specified nr_pages==0, and of course auditing all callers,
> > to ensure that this won't cause problems.
>
> While auditing it was figured out, there are 5 callers which cares for
> return value
> 0 of gup_fast/pup_fast. What problem it might cause if we change
> gup_fast/pup_fast
> to return -EINVAL and update all the callers in a single commit ?
Well, first I'd ask a different question: Why do you want to change the
current behavior? It's not like the current behavior is confusing. Callers
that pass >0 pages can happily rely on the simple behavior of < 0 return on
error or > 0 return if we mapped some pages. Callers that can possibly ask
to map 0 pages can get 0 pages back - kind of expected - and I don't see
any benefit in trying to rewrite these callers to handle -EINVAL instead...
Honza
--
Jan Kara
SUSE Labs, CR
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: KASAN: slab-out-of-bounds Read in hfa384x_usbin_callback
Am Freitag, den 20.03.2020, 12:28 -0700 schrieb syzbot: > Hello, > > syzbot found the following crash on: > > HEAD commit:e17994d1 usb: core: kcov: collect coverage from usb comple.. > git tree: https://github.com/google/kasan.git usb-fuzzer > console output: https://syzkaller.appspot.com/x/log.txt?x=11d74573e0 > kernel config: https://syzkaller.appspot.com/x/.config?x=5d64370c438bc60 > dashboard link: https://syzkaller.appspot.com/bug?extid=7d42d68643a35f71ac8a > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15fa561de0 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15d74573e0 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+7d42d68643a35f71a...@syzkaller.appspotmail.com > Hi, is this bug still active and can a test be run on it? I requested one yesterday. If my analysis is correct this bug has security implications, so it is kind of important. Regards Oliver ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v10 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/Makefile |2 +-
drivers/gpu/drm/bridge/analogix/Kconfig |8 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 1961 +
drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
5 files changed, 2368 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..bcd388a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e930ff9..c772be2 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -2,3 +2,11 @@
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_ANX7625
+ tristate "Analogix Anx7625 MIPI to DP interface support"
+ depends on DRM
+ depends on OF
+ help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter designed
+ for portable devices. It converts MIPI/DPI to DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index fdbf3fd..b6c4a19 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..2afa869
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,1961 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "anx7625.h"
+
+/*
+ * There is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+ u8 offset;
+ struct device *dev = >dev;
+ int ret;
+
+ if (client == ctx->last_client)
+ return 0;
+
+ ctx->last_client = client;
+
+ if (client == ctx->i2c.tcpc_client)
+ offset = RSVD_00_ADDR;
+ else if (client == ctx->i2c.tx_p0_client)
+ offset = RSVD_D1_ADDR;
+ else if (client == ctx->i2c.tx_p1_client)
+ offset = RSVD_60_ADDR;
+ else if (client == ctx->i2c.rx_p0_client)
+ offset = RSVD_39_ADDR;
+ else if (client == ctx->i2c.rx_p1_client)
+ offset = RSVD_7F_ADDR;
+ else
+ offset = RSVD_00_ADDR;
+
+ ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev,
+ "fail to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+ return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+ struct i2c_client *client, u8 reg_addr)
+{
+ int ret;
+ struct device *dev = >dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_byte_data(client, reg_addr);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
[PATCH v10 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI to DisplayPort 1.3 4K.
You can add support to your board with binding.
Example:
anx7625_bridge: encoder@58 {
compatible = "analogix,anx7625";
reg = <0x58>;
status = "okay";
enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
ports {
#address-cells = <1>;
#size-cells = <0>;
mipi2dp_bridge_in: port@0 {
reg = <0>;
anx7625_in: endpoint {
remote-endpoint = <_dsi>;
};
};
mipi2dp_bridge_out: port@1 {
reg = <1>;
anx7625_out: endpoint {
remote-endpoint = <_in>;
};
};
};
};
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/analogix,anx7625.yaml | 98 ++
1 file changed, 98 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 000..6e54176
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ "#address-cells": true
+ "#size-cells": true
+
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: used for interrupt pin B8.
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description:
+ Video port for MIPI DSI input.
+
+ port@1:
+type: object
+description:
+ Video port for panel or connector.
+
+required:
+- port@0
+- port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+anx7625_bridge: encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi2dp_bridge_in: port@0 {
+reg = <0>;
+anx7625_in: endpoint {
+remote-endpoint = <_dsi>;
+};
+};
+
+mipi2dp_bridge_out: port@1 {
+reg = <1>;
+anx7625_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
+};
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v10 0/2] Add initial support for slimport anx7625
Hi all, The following series add support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the v10 version, any mistakes, please let me know, I will fix it in the next series. Change history: v10: Fix comments from Rob Herring, Daniel. - Fix dt_binding_check warning. - Update description. v9: Fix comments from Sam, Nicolas, Daniel - Remove extcon interface. - Remove DPI support. - Fix dt_binding_check complains. - Code clean up and update description. v8: Fix comments from Nicolas. - Fix several coding format. - Update description. v7: - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver .../bindings/display/bridge/analogix,anx7625.yaml | 98 + drivers/gpu/drm/bridge/Makefile|2 +- drivers/gpu/drm/bridge/analogix/Kconfig|8 + drivers/gpu/drm/bridge/analogix/Makefile |1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 1961 drivers/gpu/drm/bridge/analogix/anx7625.h | 397 6 files changed, 2466 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
