Re: [PATCH part3 v12 00/10] Cleanup platform pci_domain_nr()

> > Doesn't apply to v4.4-rc2. Please refresh and repost if this is still > relevant. Hi Bjorn, this is still relevant, I will refresh it and post the new version soon. Thanks! Yijing. > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

Hi Bjorn, use devm_request_resource() for host bridge resource is cool, what about do the similar change for x86, now we request host bridge resource in pci_acpi_root_add_resources() in x86, and we would release the host bridge resource when host bridge device refcount reach 0. This logic may

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

在 2016/6/21 23:03, Bjorn Helgaas 写道: > On Tue, Jun 21, 2016 at 07:58:08PM +0800, wangyijing wrote: >> Hi Bjorn, use devm_request_resource() for host bridge resource is cool, >> what about do the similar change for x86, now we request host bridge resource >> in pci_ac

Re: [RESEND PATCH 2/3] bcache: update document info

Hi Coly, thanks to your review and comments. Commit 77b5a08427e875 ("bcache: don't embed 'return' statements in closure macros") remove the return in continue_at(), so I think we should update the document info about continue_at(). Thanks! Yijing. 在 2016/6/29 18:16, Coly Li 写道: > 在 16/6/22

Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()

在 2016/6/29 18:20, Coly Li 写道: > 在 16/6/22 上午10:10, Yijing Wang 写道: >> Cache_sb is not used in cache_alloc, and we have copied >> sb info to cache->sb already, remove it. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/super.c |4 ++-- >> 1 files

Re: [RESEND PATCH 2/3] bcache: update document info

在 2016/7/1 12:21, Coly Li 写道: > 在 16/7/1 上午9:51, wangyijing 写道: >> Hi Coly, thanks to your review and comments. >> >> Commit 77b5a08427e875 ("bcache: don't embed 'return' statements in closure >> macros") >> remove the return in continue_at(), so I t

Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()

在 2016/7/1 12:24, Coly Li 写道: > 在 16/7/1 上午10:09, wangyijing 写道: >> >> >> 在 2016/6/29 18:20, Coly Li 写道: >>> 在 16/6/22 上午10:10, Yijing Wang 写道: >>>> Cache_sb is not used in cache_alloc, and we have copied >>>> sb info to cache->sb already,

Re: [PATCH v3 2/3] bcache: update document info

在 2016/7/4 13:49, Coly Li 写道: > 在 16/7/4 上午9:23, Yijing Wang 写道: >> There is no return in continue_at(), update the documentation. >> > > Thanks. > > Acked-by: Coly Li Thanks very much! > >> Signed-off-by: Yijing Wang >> --- >>

Re: [RFC][PATCH v2 0/2] Improve libsas hotplug

Hi James, sorry to bother you, these two patches try to fix several issues in libsas, Dan Williams and John Garry also found similar issue, and post some patches before. Dan Williams's solution fix the sysfs warning calltrace, but may introduce new flutter issue. In these two patches, we

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

>>> I have not seen the flutter issue. I am just trying to solve the horrible >>> WARN dump. >>> However I do understand that there may be a issue related to how we queue >>> the events; there was a recent attempt to fix this, but it came to nothing: >>>

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

> > They're not the same. I don't see how your solution properly deals with > remote sas_port deletion. > > When we unplug a device connected to an expander, can't the sas_port be > deleted twice, in sas_unregister_devs_sas_addr() from domain revalidation and > also now in

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

>> >> The events are not lost. > > In sas_queue_event(), if there is a particular event pending for a port/PHY, > we cannot queue further same event types for that port/PHY. I think my > colleagues found issue where we try to enqueue multiple complementary events. Yes， we found this issue in

Re: [PATCH 2/2] bcache: remove unused parameter

在 2016/11/27 16:00, Coly Li 写道: > On 2016/11/25 上午9:40, Yijing Wang wrote: >> Parameter bio is no longer used, clean it. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/request.c | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >>

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

在 2016/11/27 15:57, Coly Li 写道: > On 2016/11/25 上午9:39, Yijing Wang wrote: >> set_capacity() has been called in bcache_device_init(), >> remove the redundant one. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/super.c | 3 --- >> 1 file changed, 3

Re: [PATCH] PCI: Enumerate switches below PCI-to-PCIe bridges

Reviewed-by: Yijing Wang 在 2017/1/11 23:44, Bjorn Helgaas 写道: > PCI: Enumerate switches below PCI-to-PCIe bridges > > A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary > interface and a PCI Express secondary interface. The PCIe interface is a >

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

>>> I want to make sure that the set_capacity call that happens on cache >>> attachment is not necessary when a backing device is attached without >> >> Hi Eric, set_capacity() which removed in this patch is happened at >> cached_dev_init() >> which is called when register a backing device, what

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

在 2016/11/30 4:49, Eric Wheeler 写道: > On Fri, 25 Nov 2016, Yijing Wang wrote: > >> set_capacity() has been called in bcache_device_init(), >> remove the redundant one. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/super.c | 3 --- >> 1 file changed, 3

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

>>> It probably is a duplicate set_capacity, but has anyone tested bringing on >>> a writeback volume, and late-attaching the cache volume with this patch >>> applied? >>> >>> Otherwise stated, is it possible to get the backing device attached >>> without setting the capacity? >> >> Hi Eric, I

Re: [PATCH v3 7/7] libsas: release disco mutex during waiting in sas_ex_discover_end_dev

在 2017/7/14 0:10, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> Disco mutex was introudced to prevent domain rediscovery competing >> with ata error handling(87c8331). If we have already hold the lock >> in sas_revalidate_domain and sync executing probe, deadlock caused, >>

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

Hi, I'm sorry to say that I have to stop the libsas hotplug improvement work, I will resign from Huawei, so I have no time and hardware to continue to work at this issue. John is very familiar with this work, and provide a lot of good suggestions. So if John like, I am glad he could join to

Re: [PATCH v3 4/7] libsas: add sas event wait-complete support

在 2017/7/14 14:51, Hannes Reinecke 写道: > On 07/10/2017 09:06 AM, Yijing Wang wrote: >> Introduce wait-complete for libsas sas event processing, >> execute sas port create/destruct in sync. >> >> Signed-off-by: Yijing Wang >> CC: John Garry >> CC:

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

在 2017/7/12 17:59, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> This patchset is based Johannes's patch >> "scsi: sas: scsi_queue_work can fail, so make callers aware" >> >> Now the libsas hotplug has some issues, Dan Williams report >> a similar bug here before >>

Re: [PATCH v3 5/7] libsas: add a new workqueue to run probe/destruct discovery event

在 2017/7/13 0:50, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> Sometimes, we want sync libsas probe or destruct in sas discovery work, >> like when libsas revalidate domain. We need to split probe and destruct >> work from the scsi host workqueue. >> >> Signed-off-by: Yijing Wang

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

在 2017/7/12 17:59, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> This patchset is based Johannes's patch >> "scsi: sas: scsi_queue_work can fail, so make callers aware" >> >> Now the libsas hotplug has some issues, Dan Williams report >> a similar bug here before >>

Re: [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

There is no special meaning for the pool size, if flutter of > 25 events, notify sas events will return error, and the further step work is depending on LLDD drivers. I hope libsas could do more work in this case, but now it seems a little difficult, this patch may be a

Re: [PATCH v3 6/7] libsas: add wait-complete support to sync discovery event

在 2017/7/12 21:51, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> >> static void sas_chain_event(int event, unsigned long *pending, >> @@ -592,9 +596,9 @@ int sas_discover_event(struct asd_sas_port *port, enum >> discover_event ev) >> { >> struct sas_discovery *disc; >> >> +

Re: [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

在 2017/7/12 16:17, John Garry 写道: > On 12/07/2017 03:06, wangyijing wrote: >>>> -unsigned long port_events_pending; >>>> -unsigned long phy_events_pending; >>>> +struct asd_sas_event port_events[PORT_POOL_SIZE]; >>>> +

Re: [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

>> -unsigned long port_events_pending; >> -unsigned long phy_events_pending; >> +struct asd_sas_event port_events[PORT_POOL_SIZE]; >> +struct asd_sas_event phy_events[PHY_POOL_SIZE]; >> >> int error; > > Hi Yijing, > > So now we are creating a static pool of events per

Re: [PATCH v3 2/7] libsas: remove unused port_gone_completion

在 2017/7/11 23:54, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> No one uses the port_gone_completion in struct asd_sas_port, >> clean it out. > > This seems like a reasonable tidy-up patch which could be taken in isolation, > having no dependency on the rest of the series. Yes.

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

在 2017/7/13 16:08, John Garry 写道: > On 13/07/2017 02:37, wangyijing wrote: >>> > So much nicer. BTW, /dev/sdb is a SATA disk, the rest are SAS. >> Oh, I take a mistake ? The result you tested the hotplug which applied this >> patchset is fine ? >> >> Tha

Re: [PATCH v2 0/5] Re-order scsi_remove_host and sas_remove_host in SAS HBA LLDDs

>> >> Please repost the series against the current tree. Also a cover >> letter with a bit more explanation would be good. >> > > Great, I think that my colleagues can send an updated version next week. I will send a new version with a cover letter these days, before that, we need to do a

Re: [PATCH 1/2] libsas: Don't process sas events in static works

>> > > I have seen this scenario on our development board when we have a bad > physical cable connection - the PHY continually goes up and down in a loop. > > So, in this regard, it is worth safeguarding against this scenario. OK, I will reconsider this case. Thanks! Yijing. > > John > >

Re: [PATCH 1/2] libsas: Don't process sas events in static works

Hi Dan, thanks for your review and comments! 在 2017/5/21 11:44, Dan Williams 写道: > On Fri, May 19, 2017 at 11:39 PM, Yijing Wang wrote: >> Now libsas hotplug work is static, LLDD driver queue >> the hotplug work into shost->work_q. If LLDD driver >> burst post lots hotplug

Re: [PATCH 2/2] libsas: Enhance libsas hotplug

Hi John, thanks for your review and comments! 在 2017/5/25 17:04, John Garry 写道: > Hi, > > There are some comments, inline. > > In general, if it works, it looks ok. > > Other reviews would be greatly appreciated - Hannes, Christoph, Johannes, Dan > - please. > >> Libsas complete a hotplug

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

在 2017/6/14 21:08, John Garry 写道: > On 14/06/2017 10:04, wangyijing wrote: >>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event >>>> event) >>>> >> { >>>> >> +struct sas_ha_

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

在 2017/6/15 16:00, John Garry 写道: > On 15/06/2017 08:37, wangyijing wrote: >> >> >> 在 2017/6/14 21:08, John Garry 写道: >>> On 14/06/2017 10:04, wangyijing wrote: >>>>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event

Re: [PATCH v2 2/2] libsas: Enhance libsas hotplug

>> In this patch, we try to solve these issues in following steps: >> 1. create a new workqueue used to run sas event work, instead of scsi host >> workqueue, >>because we may block sas event work, we cannot block the normal scsi >> works. >>When libsas receive a phy down event,

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event >> event) >> { >> +struct sas_ha_event *ev; >> + >> BUG_ON(event >= HA_NUM_EVENTS); >> >> -sas_queue_event(event, _ha->pending, >> -_ha->ha_events[event].work, sas_ha); >> +ev =

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

在 2017/6/14 17:18, Johannes Thumshirn 写道: > On 06/14/2017 11:04 AM, wangyijing wrote: >>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event >>>> event) >>>> { >>>> + struct sas_ha_event *ev; >>>> + >>

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

在 2017/7/12 17:59, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> This patchset is based Johannes's patch >> "scsi: sas: scsi_queue_work can fail, so make callers aware" >> >> Now the libsas hotplug has some issues, Dan Williams report >> a similar bug here before >>

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

在 2017/7/12 17:59, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> This patchset is based Johannes's patch >> "scsi: sas: scsi_queue_work can fail, so make callers aware" >> >> Now the libsas hotplug has some issues, Dan Williams report >> a similar bug here before >>

Re: [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

There is no special meaning for the pool size, if flutter of > 25 events, notify sas events will return error, and the further step work is depending on LLDD drivers. I hope libsas could do more work in this case, but now it seems a little difficult, this patch may be a

Re: [PATCH v3 6/7] libsas: add wait-complete support to sync discovery event

在 2017/7/12 21:51, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> >> static void sas_chain_event(int event, unsigned long *pending, >> @@ -592,9 +596,9 @@ int sas_discover_event(struct asd_sas_port *port, enum >> discover_event ev) >> { >> struct sas_discovery *disc; >> >> +

Re: [PATCH v3 5/7] libsas: add a new workqueue to run probe/destruct discovery event

在 2017/7/13 0:50, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> Sometimes, we want sync libsas probe or destruct in sas discovery work, >> like when libsas revalidate domain. We need to split probe and destruct >> work from the scsi host workqueue. >> >> Signed-off-by: Yijing Wang

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

在 2017/7/13 16:08, John Garry 写道: > On 13/07/2017 02:37, wangyijing wrote: >>> > So much nicer. BTW, /dev/sdb is a SATA disk, the rest are SAS. >> Oh, I take a mistake ? The result you tested the hotplug which applied this >> patchset is fine ? >> >> Tha

Re: [PATCH v3 7/7] libsas: release disco mutex during waiting in sas_ex_discover_end_dev

在 2017/7/14 0:10, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> Disco mutex was introudced to prevent domain rediscovery competing >> with ata error handling(87c8331). If we have already hold the lock >> in sas_revalidate_domain and sync executing probe, deadlock caused, >>

Re: [PATCH v3 4/7] libsas: add sas event wait-complete support

在 2017/7/14 14:51, Hannes Reinecke 写道: > On 07/10/2017 09:06 AM, Yijing Wang wrote: >> Introduce wait-complete for libsas sas event processing, >> execute sas port create/destruct in sync. >> >> Signed-off-by: Yijing Wang >> CC: John Garry >> CC: Johannes Thumshirn >> CC: Ewan Milne >> CC:

Re: [PATCH v3 0/7] Enhance libsas hotplug feature

Hi, I'm sorry to say that I have to stop the libsas hotplug improvement work, I will resign from Huawei, so I have no time and hardware to continue to work at this issue. John is very familiar with this work, and provide a lot of good suggestions. So if John like, I am glad he could join to

Re: [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

>> -unsigned long port_events_pending; >> -unsigned long phy_events_pending; >> +struct asd_sas_event port_events[PORT_POOL_SIZE]; >> +struct asd_sas_event phy_events[PHY_POOL_SIZE]; >> >> int error; > > Hi Yijing, > > So now we are creating a static pool of events per

Re: [PATCH v3 2/7] libsas: remove unused port_gone_completion

在 2017/7/11 23:54, John Garry 写道: > On 10/07/2017 08:06, Yijing Wang wrote: >> No one uses the port_gone_completion in struct asd_sas_port, >> clean it out. > > This seems like a reasonable tidy-up patch which could be taken in isolation, > having no dependency on the rest of the series. Yes.

Re: [PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

在 2017/7/12 16:17, John Garry 写道: > On 12/07/2017 03:06, wangyijing wrote: >>>> -unsigned long port_events_pending; >>>> -unsigned long phy_events_pending; >>>> +struct asd_sas_event port_events[PORT_POOL_SIZE]; >>>> +

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

>> >> The events are not lost. > > In sas_queue_event(), if there is a particular event pending for a port/PHY, > we cannot queue further same event types for that port/PHY. I think my > colleagues found issue where we try to enqueue multiple complementary events. Yes， we found this issue in

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

在 2016/11/27 15:57, Coly Li 写道: > On 2016/11/25 上午9:39, Yijing Wang wrote: >> set_capacity() has been called in bcache_device_init(), >> remove the redundant one. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/super.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git

Re: [PATCH 2/2] bcache: remove unused parameter

在 2016/11/27 16:00, Coly Li 写道: > On 2016/11/25 上午9:40, Yijing Wang wrote: >> Parameter bio is no longer used, clean it. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/request.c | 12 ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git

Re: [PATCH 1/2] libsas: Don't process sas events in static works

>> > > I have seen this scenario on our development board when we have a bad > physical cable connection - the PHY continually goes up and down in a loop. > > So, in this regard, it is worth safeguarding against this scenario. OK, I will reconsider this case. Thanks! Yijing. > > John > >

Re: [PATCH v2 0/5] Re-order scsi_remove_host and sas_remove_host in SAS HBA LLDDs

>> >> Please repost the series against the current tree. Also a cover >> letter with a bit more explanation would be good. >> > > Great, I think that my colleagues can send an updated version next week. I will send a new version with a cover letter these days, before that, we need to do a

Re: [PATCH 2/2] libsas: Enhance libsas hotplug

Hi John, thanks for your review and comments! 在 2017/5/25 17:04, John Garry 写道: > Hi, > > There are some comments, inline. > > In general, if it works, it looks ok. > > Other reviews would be greatly appreciated - Hannes, Christoph, Johannes, Dan > - please. > >> Libsas complete a hotplug

Re: [PATCH 1/2] libsas: Don't process sas events in static works

Hi Dan, thanks for your review and comments! 在 2017/5/21 11:44, Dan Williams 写道: > On Fri, May 19, 2017 at 11:39 PM, Yijing Wang wrote: >> Now libsas hotplug work is static, LLDD driver queue >> the hotplug work into shost->work_q. If LLDD driver >> burst post lots hotplug events to libsas, the

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

> > They're not the same. I don't see how your solution properly deals with > remote sas_port deletion. > > When we unplug a device connected to an expander, can't the sas_port be > deleted twice, in sas_unregister_devs_sas_addr() from domain revalidation and > also now in

Re: [RFC][PATCH v2 0/2] Improve libsas hotplug

Hi James, sorry to bother you, these two patches try to fix several issues in libsas, Dan Williams and John Garry also found similar issue, and post some patches before. Dan Williams's solution fix the sysfs warning calltrace, but may introduce new flutter issue. In these two patches, we

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

>>> I have not seen the flutter issue. I am just trying to solve the horrible >>> WARN dump. >>> However I do understand that there may be a issue related to how we queue >>> the events; there was a recent attempt to fix this, but it came to nothing: >>>

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event >> event) >> { >> +struct sas_ha_event *ev; >> + >> BUG_ON(event >= HA_NUM_EVENTS); >> >> -sas_queue_event(event, _ha->pending, >> -_ha->ha_events[event].work, sas_ha); >> +ev =

Re: [PATCH v2 2/2] libsas: Enhance libsas hotplug

>> In this patch, we try to solve these issues in following steps: >> 1. create a new workqueue used to run sas event work, instead of scsi host >> workqueue, >>because we may block sas event work, we cannot block the normal scsi >> works. >>When libsas receive a phy down event,

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

在 2017/6/14 17:18, Johannes Thumshirn 写道: > On 06/14/2017 11:04 AM, wangyijing wrote: >>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event >>>> event) >>>> { >>>> + struct sas_ha_event *ev; >>>> + >>

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

在 2017/6/14 21:08, John Garry 写道: > On 14/06/2017 10:04, wangyijing wrote: >>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event >>>> event) >>>> >> { >>>> >> +struct sas_ha_

Re: [PATCH v2 1/2] libsas: Don't process sas events in static works

在 2017/6/15 16:00, John Garry 写道: > On 15/06/2017 08:37, wangyijing wrote: >> >> >> 在 2017/6/14 21:08, John Garry 写道: >>> On 14/06/2017 10:04, wangyijing wrote: >>>>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event

Re: [PATCH] PCI: Enumerate switches below PCI-to-PCIe bridges

Reviewed-by: Yijing Wang 在 2017/1/11 23:44, Bjorn Helgaas 写道: > PCI: Enumerate switches below PCI-to-PCIe bridges > > A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary > interface and a PCI Express secondary interface. The PCIe interface is a > Downstream Port that

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

>>> I want to make sure that the set_capacity call that happens on cache >>> attachment is not necessary when a backing device is attached without >> >> Hi Eric, set_capacity() which removed in this patch is happened at >> cached_dev_init() >> which is called when register a backing device, what

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

在 2016/11/30 4:49, Eric Wheeler 写道: > On Fri, 25 Nov 2016, Yijing Wang wrote: > >> set_capacity() has been called in bcache_device_init(), >> remove the redundant one. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/super.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

>>> It probably is a duplicate set_capacity, but has anyone tested bringing on >>> a writeback volume, and late-attaching the cache volume with this patch >>> applied? >>> >>> Otherwise stated, is it possible to get the backing device attached >>> without setting the capacity? >> >> Hi Eric, I

Re: [PATCH part3 v12 00/10] Cleanup platform pci_domain_nr()

> > Doesn't apply to v4.4-rc2. Please refresh and repost if this is still > relevant. Hi Bjorn, this is still relevant, I will refresh it and post the new version soon. Thanks! Yijing. > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [RESEND PATCH 2/3] bcache: update document info

Hi Coly, thanks to your review and comments. Commit 77b5a08427e875 ("bcache: don't embed 'return' statements in closure macros") remove the return in continue_at(), so I think we should update the document info about continue_at(). Thanks! Yijing. 在 2016/6/29 18:16, Coly Li 写道: > 在 16/6/22

Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()

在 2016/6/29 18:20, Coly Li 写道: > 在 16/6/22 上午10:10, Yijing Wang 写道: >> Cache_sb is not used in cache_alloc, and we have copied >> sb info to cache->sb already, remove it. >> >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/super.c |4 ++-- >> 1 files changed, 2 insertions(+), 2

Re: [RESEND PATCH 1/3] bcache: Remove redundant parameter for cache_alloc()

在 2016/7/1 12:24, Coly Li 写道: > 在 16/7/1 上午10:09, wangyijing 写道: >> >> >> 在 2016/6/29 18:20, Coly Li 写道: >>> 在 16/6/22 上午10:10, Yijing Wang 写道: >>>> Cache_sb is not used in cache_alloc, and we have copied >>>> sb info to cache->sb

Re: [RESEND PATCH 2/3] bcache: update document info

在 2016/7/1 12:21, Coly Li 写道: > 在 16/7/1 上午9:51, wangyijing 写道: >> Hi Coly, thanks to your review and comments. >> >> Commit 77b5a08427e875 ("bcache: don't embed 'return' statements in closure >> macros") >> remove the return in continue_at(), so I t

Re: [PATCH v3 2/3] bcache: update document info

在 2016/7/4 13:49, Coly Li 写道: > 在 16/7/4 上午9:23, Yijing Wang 写道: >> There is no return in continue_at(), update the documentation. >> > > Thanks. > > Acked-by: Coly Li Thanks very much! > >> Signed-off-by: Yijing Wang >> --- >> drivers/md/bcache/closure.c |2 +- >>

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

在 2016/6/21 23:03, Bjorn Helgaas 写道: > On Tue, Jun 21, 2016 at 07:58:08PM +0800, wangyijing wrote: >> Hi Bjorn, use devm_request_resource() for host bridge resource is cool, >> what about do the similar change for x86, now we request host bridge resource >> in pci_ac

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

Hi Bjorn, use devm_request_resource() for host bridge resource is cool, what about do the similar change for x86, now we request host bridge resource in pci_acpi_root_add_resources() in x86, and we would release the host bridge resource when host bridge device refcount reach 0. This logic may