Patches ready for picking up:
Patch 1 fixes a bug in fw_devlink.
Patch 2-4 are meant to make debugging easier
Patch 5 and 6 fix fw_devlink issues with PHYs and networking
Andrew,
I think Patch 5 and 6 should be picked up be Greg too. Let me know if
you disagree.
-Saravana
Cc: John Stultz <[email protected]>
Cc: Marek Szyprowski <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Vladimir Oltean <[email protected]>
v1->v2:
- Added a few Reviewed-by and Tested-by tags
- Addressed Geert's comments in patches 3 and 5
- Dropped the fw_devlink.debug patch
- Added 2 more patches to the series to address other fw_devlink issues
Thanks,
Saravana
Saravana Kannan (6):
driver core: fw_devlink: Improve handling of cyclic dependencies
driver core: Set deferred probe reason when deferred by driver core
driver core: Create __fwnode_link_del() helper function
driver core: Add debug logs when fwnode links are added/deleted
driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD
net: mdiobus: Set FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for mdiobus parents
drivers/base/core.c | 90 ++++++++++++++++++++++++++------------
drivers/net/phy/mdio_bus.c | 4 ++
include/linux/fwnode.h | 11 +++--
3 files changed, 75 insertions(+), 30 deletions(-)
--
2.33.0.309.g3052b89438-goog
The same code is repeated in multiple locations. Create a helper
function for it.
Signed-off-by: Saravana Kannan <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
---
drivers/base/core.c | 35 +++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index ca6c61a2e2e9..5e7faad4e083 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -101,6 +101,19 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup)
return ret;
}
+/**
+ * __fwnode_link_del - Delete a link between two fwnode_handles.
+ * @link: the fwnode_link to be deleted
+ *
+ * The fwnode_link_lock needs to be held when this function is called.
+ */
+static void __fwnode_link_del(struct fwnode_link *link)
+{
+ list_del(&link->s_hook);
+ list_del(&link->c_hook);
+ kfree(link);
+}
+
/**
* fwnode_links_purge_suppliers - Delete all supplier links of fwnode_handle.
* @fwnode: fwnode whose supplier links need to be deleted
@@ -112,11 +125,8 @@ static void fwnode_links_purge_suppliers(struct fwnode_handle *fwnode)
struct fwnode_link *link, *tmp;
mutex_lock(&fwnode_link_lock);
- list_for_each_entry_safe(link, tmp, &fwnode->suppliers, c_hook) {
- list_del(&link->s_hook);
- list_del(&link->c_hook);
- kfree(link);
- }
+ list_for_each_entry_safe(link, tmp, &fwnode->suppliers, c_hook)
+ __fwnode_link_del(link);
mutex_unlock(&fwnode_link_lock);
}
@@ -131,11 +141,8 @@ static void fwnode_links_purge_consumers(struct fwnode_handle *fwnode)
struct fwnode_link *link, *tmp;
mutex_lock(&fwnode_link_lock);
- list_for_each_entry_safe(link, tmp, &fwnode->consumers, s_hook) {
- list_del(&link->s_hook);
- list_del(&link->c_hook);
- kfree(link);
- }
+ list_for_each_entry_safe(link, tmp, &fwnode->consumers, s_hook)
+ __fwnode_link_del(link);
mutex_unlock(&fwnode_link_lock);
}
@@ -1868,9 +1875,7 @@ static void __fw_devlink_link_to_consumers(struct device *dev)
if (!own_link || ret == -EAGAIN)
continue;
- list_del(&link->s_hook);
- list_del(&link->c_hook);
- kfree(link);
+ __fwnode_link_del(link);
}
}
@@ -1922,9 +1927,7 @@ static void __fw_devlink_link_to_suppliers(struct device *dev,
if (!own_link || ret == -EAGAIN)
continue;
- list_del(&link->s_hook);
- list_del(&link->c_hook);
- kfree(link);
+ __fwnode_link_del(link);
/* If no device link was created, nothing more to do. */
if (ret)
--
2.33.0.309.g3052b89438-goog
When the driver core defers the probe of a device, set the deferred
probe reason so that it's easier to debug. The deferred probe reason is
available in debugfs under devices_deferred.
Signed-off-by: Saravana Kannan <[email protected]>
---
drivers/base/core.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 316df6027093..ca6c61a2e2e9 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -975,6 +975,7 @@ int device_links_check_suppliers(struct device *dev)
{
struct device_link *link;
int ret = 0;
+ struct fwnode_handle *sup_fw;
/*
* Device waiting for supplier to become available is not allowed to
@@ -983,10 +984,11 @@ int device_links_check_suppliers(struct device *dev)
mutex_lock(&fwnode_link_lock);
if (dev->fwnode && !list_empty(&dev->fwnode->suppliers) &&
!fw_devlink_is_permissive()) {
- dev_dbg(dev, "probe deferral - wait for supplier %pfwP\n",
- list_first_entry(&dev->fwnode->suppliers,
- struct fwnode_link,
- c_hook)->supplier);
+ sup_fw = list_first_entry(&dev->fwnode->suppliers,
+ struct fwnode_link,
+ c_hook)->supplier;
+ dev_err_probe(dev, -EPROBE_DEFER, "wait for supplier %pfwP\n",
+ sup_fw);
mutex_unlock(&fwnode_link_lock);
return -EPROBE_DEFER;
}
@@ -1001,8 +1003,9 @@ int device_links_check_suppliers(struct device *dev)
if (link->status != DL_STATE_AVAILABLE &&
!(link->flags & DL_FLAG_SYNC_STATE_ONLY)) {
device_links_missing_supplier(dev);
- dev_dbg(dev, "probe deferral - supplier %s not ready\n",
- dev_name(link->supplier));
+ dev_err_probe(dev, -EPROBE_DEFER,
+ "supplier %s not ready\n",
+ dev_name(link->supplier));
ret = -EPROBE_DEFER;
break;
}
--
2.33.0.309.g3052b89438-goog
If a parent device is also a supplier to a child device, fw_devlink=on by
design delays the probe() of the child device until the probe() of the
parent finishes successfully.
However, some drivers of such parent devices (where parent is also a
supplier) expect the child device to finish probing successfully as soon as
they are added using device_add() and before the probe() of the parent
device has completed successfully. One example of such a case is discussed
in the link mentioned below.
Add a flag to make fw_devlink=on not enforce these supplier-consumer
relationships, so these drivers can continue working.
Link: https://lore.kernel.org/netdev/CAGETcx_uj0V4DChME-gy5HGKTYnxLBX=TH2rag29f_p=UcG+Tg@mail.gmail.com/
Signed-off-by: Saravana Kannan <[email protected]>
---
drivers/base/core.c | 19 +++++++++++++++++++
include/linux/fwnode.h | 11 ++++++++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index f06e8e2dc69b..15986cc2fe5e 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1736,6 +1736,25 @@ static int fw_devlink_create_devlink(struct device *con,
struct device *sup_dev;
int ret = 0;
+ /*
+ * In some cases, a device P might also be a supplier to its child node
+ * C. However, this would defer the probe of C until the probe of P
+ * completes successfully. This is perfectly fine in the device driver
+ * model. device_add() doesn't guarantee probe completion of the device
+ * by the time it returns.
+ *
+ * However, there are a few drivers that assume C will finish probing
+ * as soon as it's added and before P finishes probing. So, we provide
+ * a flag to let fw_devlink know not to delay the probe of C until the
+ * probe of P completes successfully.
+ *
+ * When such a flag is set, we can't create device links where P is the
+ * supplier of C as that would delay the probe of C.
+ */
+ if (sup_handle->flags & FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD &&
+ fwnode_is_ancestor_of(sup_handle, con->fwnode))
+ return -EINVAL;
+
sup_dev = get_dev_from_fwnode(sup_handle);
if (sup_dev) {
/*
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 59828516ebaf..9f4ad719bfe3 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -22,10 +22,15 @@ struct device;
* LINKS_ADDED: The fwnode has already be parsed to add fwnode links.
* NOT_DEVICE: The fwnode will never be populated as a struct device.
* INITIALIZED: The hardware corresponding to fwnode has been initialized.
+ * NEEDS_CHILD_BOUND_ON_ADD: For this fwnode/device to probe successfully, its
+ * driver needs its child devices to be bound with
+ * their respective drivers as soon as they are
+ * added.
*/
-#define FWNODE_FLAG_LINKS_ADDED BIT(0)
-#define FWNODE_FLAG_NOT_DEVICE BIT(1)
-#define FWNODE_FLAG_INITIALIZED BIT(2)
+#define FWNODE_FLAG_LINKS_ADDED BIT(0)
+#define FWNODE_FLAG_NOT_DEVICE BIT(1)
+#define FWNODE_FLAG_INITIALIZED BIT(2)
+#define FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD BIT(3)
struct fwnode_handle {
struct fwnode_handle *secondary;
--
2.33.0.309.g3052b89438-goog
There are many instances of PHYs that depend on a switch to supply a
resource (Eg: interrupts). Switches also expects the PHYs to be probed
by their specific drivers as soon as they are added. If that doesn't
happen, then the switch would force the use of generic PHY drivers for
the PHY even if the PHY might have specific driver available.
fw_devlink=on by design can cause delayed probes of PHY. To avoid, this
we need to set the FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for the switch's
fwnode before the PHYs are added. The most generic way to do this is to
set this flag for the parent of MDIO busses which is typically the
switch.
For more context:
https://lore.kernel.org/lkml/[email protected]/#t
Suggested-by: Andrew Lunn <[email protected]>
Signed-off-by: Saravana Kannan <[email protected]>
---
drivers/net/phy/mdio_bus.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 53f034fc2ef7..ee8313a4ac71 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -525,6 +525,10 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
NULL == bus->read || NULL == bus->write)
return -EINVAL;
+ if (bus->parent && bus->parent->of_node)
+ bus->parent->of_node->fwnode.flags |=
+ FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD;
+
BUG_ON(bus->state != MDIOBUS_ALLOCATED &&
bus->state != MDIOBUS_UNREGISTERED);
--
2.33.0.309.g3052b89438-goog
When we have a dependency of the form:
Device-A -> Device-C
Device-B
Device-C -> Device-B
Where,
* Indentation denotes "child of" parent in previous line.
* X -> Y denotes X is consumer of Y based on firmware (Eg: DT).
We have cyclic dependency: device-A -> device-C -> device-B -> device-A
fw_devlink current treats device-C -> device-B dependency as an invalid
dependency and doesn't enforce it but leaves the rest of the
dependencies as is.
While the current behavior is necessary, it is not sufficient if the
false dependency in this example is actually device-A -> device-C. When
this is the case, device-C will correctly probe defer waiting for
device-B to be added, but device-A will be incorrectly probe deferred by
fw_devlink waiting on device-C to probe successfully. Due to this, none
of the devices in the cycle will end up probing.
To fix this, we need to go relax all the dependencies in the cycle like
we already do in the other instances where fw_devlink detects cycles.
A real world example of this was reported[1] and analyzed[2].
[1] - https://lore.kernel.org/lkml/[email protected]/
[2] - https://lore.kernel.org/lkml/CAGETcx8peaew90SWiux=TyvuGgvTQOmO4BFALz7aj0Za5QdNFQ@mail.gmail.com/
Fixes: f9aa460672c9 ("driver core: Refactor fw_devlink feature")
Reported-by: Marek Szyprowski <[email protected]>
Signed-off-by: Saravana Kannan <[email protected]>
---
drivers/base/core.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index e65dd803a453..316df6027093 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1772,14 +1772,21 @@ static int fw_devlink_create_devlink(struct device *con,
* be broken by applying logic. Check for these types of cycles and
* break them so that devices in the cycle probe properly.
*
- * If the supplier's parent is dependent on the consumer, then
- * the consumer-supplier dependency is a false dependency. So,
- * treat it as an invalid link.
+ * If the supplier's parent is dependent on the consumer, then the
+ * consumer and supplier have a cyclic dependency. Since fw_devlink
+ * can't tell which of the inferred dependencies are incorrect, don't
+ * enforce probe ordering between any of the devices in this cyclic
+ * dependency. Do this by relaxing all the fw_devlink device links in
+ * this cycle and by treating the fwnode link between the consumer and
+ * the supplier as an invalid dependency.
*/
sup_dev = fwnode_get_next_parent_dev(sup_handle);
if (sup_dev && device_is_dependent(con, sup_dev)) {
- dev_dbg(con, "Not linking to %pfwP - False link\n",
- sup_handle);
+ dev_info(con, "Fixing up cyclic dependency with %pfwP (%s)\n",
+ sup_handle, dev_name(sup_dev));
+ device_links_write_lock();
+ fw_devlink_relax_cycle(con, sup_dev);
+ device_links_write_unlock();
ret = -EINVAL;
} else {
/*
--
2.33.0.309.g3052b89438-goog
This will help with debugging fw_devlink issues.
Signed-off-by: Saravana Kannan <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
---
drivers/base/core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 5e7faad4e083..f06e8e2dc69b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -95,6 +95,8 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup)
list_add(&link->s_hook, &sup->consumers);
list_add(&link->c_hook, &con->suppliers);
+ pr_debug("%pfwP Linked as a fwnode consumer to %pfwP\n",
+ con, sup);
out:
mutex_unlock(&fwnode_link_lock);
@@ -109,6 +111,8 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup)
*/
static void __fwnode_link_del(struct fwnode_link *link)
{
+ pr_debug("%pfwP Dropping the fwnode link to %pfwP\n",
+ link->consumer, link->supplier);
list_del(&link->s_hook);
list_del(&link->c_hook);
kfree(link);
--
2.33.0.309.g3052b89438-goog
On Wed, Sep 15, 2021 at 10:11 AM Saravana Kannan <[email protected]> wrote:
> When the driver core defers the probe of a device, set the deferred
> probe reason so that it's easier to debug. The deferred probe reason is
> available in debugfs under devices_deferred.
>
> Signed-off-by: Saravana Kannan <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Saravana,
On 15.09.2021 10:11, Saravana Kannan wrote:
> Patches ready for picking up:
> Patch 1 fixes a bug in fw_devlink.
> Patch 2-4 are meant to make debugging easier
> Patch 5 and 6 fix fw_devlink issues with PHYs and networking
Is this patchset supposed to fix the PHY related issues I've experienced
or does it also require the Andrew's patch for 'mdio-parent-bus'? If the
first, then applying only this patchset on top of today's linux-next
doesn't fix the ethernet issue on my Amlogic SoC based test boards.
> Andrew,
>
> I think Patch 5 and 6 should be picked up be Greg too. Let me know if
> you disagree.
>
> -Saravana
>
> Cc: John Stultz <[email protected]>
> Cc: Marek Szyprowski <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: Andrew Lunn <[email protected]>
> Cc: Vladimir Oltean <[email protected]>
>
> v1->v2:
> - Added a few Reviewed-by and Tested-by tags
> - Addressed Geert's comments in patches 3 and 5
> - Dropped the fw_devlink.debug patch
> - Added 2 more patches to the series to address other fw_devlink issues
>
> Thanks,
> Saravana
>
> Saravana Kannan (6):
> driver core: fw_devlink: Improve handling of cyclic dependencies
> driver core: Set deferred probe reason when deferred by driver core
> driver core: Create __fwnode_link_del() helper function
> driver core: Add debug logs when fwnode links are added/deleted
> driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD
> net: mdiobus: Set FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for mdiobus parents
>
> drivers/base/core.c | 90 ++++++++++++++++++++++++++------------
> drivers/net/phy/mdio_bus.c | 4 ++
> include/linux/fwnode.h | 11 +++--
> 3 files changed, 75 insertions(+), 30 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
On Wed, Sep 15, 2021 at 01:11:32AM -0700, Saravana Kannan wrote:
> Patches ready for picking up:
> Patch 1 fixes a bug in fw_devlink.
> Patch 2-4 are meant to make debugging easier
> Patch 5 and 6 fix fw_devlink issues with PHYs and networking
>
> Andrew,
>
> I think Patch 5 and 6 should be picked up be Greg too. Let me know if
> you disagree.
>
> -Saravana
You are mixing fixes and development work. You should not do that,
please keep them separate. They are heading in different
directions. Fixed should get applied to -rc1, where as development
work will be queued for the next merge window.
You are also missing Fixes: tags for the two MDIO patches. Stable
needs them to know how far back to port the fixes.
Andrew
On Wed, Sep 15, 2021 at 1:44 AM Marek Szyprowski
<[email protected]> wrote:
>
> Hi Saravana,
>
> On 15.09.2021 10:11, Saravana Kannan wrote:
> > Patches ready for picking up:
> > Patch 1 fixes a bug in fw_devlink.
> > Patch 2-4 are meant to make debugging easier
> > Patch 5 and 6 fix fw_devlink issues with PHYs and networking
>
> Is this patchset supposed to fix the PHY related issues I've experienced
> or does it also require the Andrew's patch for 'mdio-parent-bus'? If the
> first, then applying only this patchset on top of today's linux-next
> doesn't fix the ethernet issue on my Amlogic SoC based test boards.
Marek,
The issue you hit was actually a general issue with fw_devlink and
that's fixed by Patch 1. But I also needed to revert the phy-handle
patch for other reasons (see commit text) and that fixes the issue you
were hitting without needing the 'mdio-parent-bus' patch.
https://lore.kernel.org/lkml/[email protected]/
When I eventually bring back phy-handle support, I'll need the
'mdio-parent-bus' to not break your use case.
Hope that clarifies things.
-Saravana
>
> > Andrew,
> >
> > I think Patch 5 and 6 should be picked up be Greg too. Let me know if
> > you disagree.
> >
> > -Saravana
> >
> > Cc: John Stultz <[email protected]>
> > Cc: Marek Szyprowski <[email protected]>
> > Cc: Rob Herring <[email protected]>
> > Cc: Geert Uytterhoeven <[email protected]>
> > Cc: Andrew Lunn <[email protected]>
> > Cc: Vladimir Oltean <[email protected]>
> >
> > v1->v2:
> > - Added a few Reviewed-by and Tested-by tags
> > - Addressed Geert's comments in patches 3 and 5
> > - Dropped the fw_devlink.debug patch
> > - Added 2 more patches to the series to address other fw_devlink issues
> >
> > Thanks,
> > Saravana
> >
> > Saravana Kannan (6):
> > driver core: fw_devlink: Improve handling of cyclic dependencies
> > driver core: Set deferred probe reason when deferred by driver core
> > driver core: Create __fwnode_link_del() helper function
> > driver core: Add debug logs when fwnode links are added/deleted
> > driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD
> > net: mdiobus: Set FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for mdiobus parents
> >
> > drivers/base/core.c | 90 ++++++++++++++++++++++++++------------
> > drivers/net/phy/mdio_bus.c | 4 ++
> > include/linux/fwnode.h | 11 +++--
> > 3 files changed, 75 insertions(+), 30 deletions(-)
> >
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
On Wed, Sep 15, 2021 at 5:14 AM Andrew Lunn <[email protected]> wrote:
>
> On Wed, Sep 15, 2021 at 01:11:32AM -0700, Saravana Kannan wrote:
> > Patches ready for picking up:
> > Patch 1 fixes a bug in fw_devlink.
> > Patch 2-4 are meant to make debugging easier
> > Patch 5 and 6 fix fw_devlink issues with PHYs and networking
> >
> > Andrew,
> >
> > I think Patch 5 and 6 should be picked up be Greg too. Let me know if
> > you disagree.
> >
> > -Saravana
>
> You are mixing fixes and development work. You should not do that,
> please keep them separate. They are heading in different
> directions. Fixed should get applied to -rc1, where as development
> work will be queued for the next merge window.
Done.
https://lore.kernel.org/lkml/[email protected]/
-Saravana
-Saravana
>
> You are also missing Fixes: tags for the two MDIO patches. Stable
> needs them to know how far back to port the fixes.
>
> Andrew
Hi,
On 15.09.2021 18:44, Saravana Kannan wrote:
> On Wed, Sep 15, 2021 at 1:44 AM Marek Szyprowski
> <[email protected]> wrote:
>> On 15.09.2021 10:11, Saravana Kannan wrote:
>>> Patches ready for picking up:
>>> Patch 1 fixes a bug in fw_devlink.
>>> Patch 2-4 are meant to make debugging easier
>>> Patch 5 and 6 fix fw_devlink issues with PHYs and networking
>> Is this patchset supposed to fix the PHY related issues I've experienced
>> or does it also require the Andrew's patch for 'mdio-parent-bus'? If the
>> first, then applying only this patchset on top of today's linux-next
>> doesn't fix the ethernet issue on my Amlogic SoC based test boards.
> Marek,
>
> The issue you hit was actually a general issue with fw_devlink and
> that's fixed by Patch 1. But I also needed to revert the phy-handle
> patch for other reasons (see commit text) and that fixes the issue you
> were hitting without needing the 'mdio-parent-bus' patch.
> https://lore.kernel.org/lkml/[email protected]/
>
> When I eventually bring back phy-handle support, I'll need the
> 'mdio-parent-bus' to not break your use case.
>
> Hope that clarifies things.
Okay, I missed the fact that you have sent the revert of the phy-handle
patch. Now I see it in the linux-next, so everything is fine.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland